For a project we want to use dojo 1.7.2. I downloaded the version and unzipped everything to a directory.
I added the ibm directory from the js\dojo.1.5.1 directory of my 8.5.3 domino server.
And package all the files as a executable jar file.
In Domino 8.5.3 dojo 1.6.1 is loaded as OSGi bundle and is located in the \osgi\shared\eclipse\plugins
Is there a way to use the newest version of Dojo as OSGi bundle, the same way as dojo 1.6.1 is deployed??
Does your plugin define a Dojo version. I'm looking at the explanation for how the Domino 8.5.3 plugin defines the Dojo version on Page 40 of XPages Portable Command Guide, the section entitled "Installing Multiple Dojo Versions and Determining the Version Used".
It uses an inner text file in the plugin "/resource/dojo.properties" and a property line:
DojoVersion.versionStr=1.6.1
If you define a higher version number in your plugin, I believe that should get used by default. Alternatively, you should be able to define a different version number and use the xsp.client.dojo.script.version property in xsp.properties.
Have you tried xsp.client.script.dojo.version?
Related
Notes 10.0.1 FP3 causing below compile errors, but Notes 9.0.1 FP10 SHF81 doesn't have the same issue. Is there a way to resolve this without having 9.0.1 installed?
1) Cannot nest 'IBM/Notes/framework/rcp/eclipse/plugins/org.eclipse.swt.win32.win32.x86_3.105.3.20190810-1410'
2) Container 'IniVariable Java Library' references non-existing library 'IBM\Notes\Data\SwPDFC\java\ver6.20.000\swpdfc-2.0.0.jar'
It looks like your using the SWING PDF Converter. Maybe you should try to reinstall the Converter or maybe you have to look if there's a newer version that is compatible with Notes version 10. As stwissel pointed out Notes version 10 uses Java8 and OpenJDK, so maybe a newer version of the SWING PDF Converter is the solution.
When you create a new blank database it automatically includes 'Plug-in Dependencies' which appear to pull in everything in the 'Notes\framework\rcp\eclipse\plugins' folder which includes the referenced plug-in shown in the error message. The problem is when you add a new variable classpath entry and select ECLIPSE_HOME, then navigate to the same 'Notes\framework\rcp\eclipse\plugins' location.
If you select a different folder for your new variable classpath entry or remove either the 'ECLIPSE_HOME' or 'Plug-in Dependencies' from your Build Path Libraries the error goes away. I have included the below screenshot showing what I mean.
Since the Extension Library was rolled into the Notes core it must now be part of the Plug-in Dependencies causing a conflict when being added via the IniVariable option for those using 10.0.1. I still need to confirm the build path with a co-worker who has Notes 9.0.1 FP10 SHF81.
I'm getting the error below when I run my application:
com.ibm.xsp.FacesExceptionEx: The application /test/Test.nsf requires com.ibm.xsp.extlib.relational.library
The extension library cannot be found, but the library was installed by replicating the updatesite.nsf from the main server to the current server throwing this error.
When I issue the command below:
tell http osgi ss com.ibm.xsp.extlib
The log show that the library is ACTIVE, but does not show that it has been INSTALLED.
Since the library is already on the server, how can I install it?
Your support will be appreciated.
Thanks.
com.ibm.xsp.extlib.relational.library is not part of the core 9.0.1 Extension Library. It was only incorporated into the core OpenNTF Extension Library in 9.0.1_v00_10. It was not incorporated into core IBM Extension Library until Feature Pack 8. You will see that nothing starting com.ibm.xsp.extlib is referenced in your screenshot of the server console, and version 9.0.1_v00_00 which shows you only have 9.0.1 base Extension Library installed. There are three options:
Install ExtLibX component from the OpenNTF Extension Library. You will still be using the base 9.0.1 version for all other controls.
Upgrade the version of the Extension Library to a more recent version, e.g. 9.0.1_v00_17. This will override the base 9.0.1 version of all Extension Library controls.
Upgrade to 9.0.1 Feature Pack 8.
Note that if you use ExtLibX, SSJS code or XPages components will continue to work when you subsequently upgrade ExtLib (or Domino to FP8+). However, to avoid name collisions, the Java class names will change. If you use custom Java code, you will need to edit and update the classes to the new Java package names when upgrading in the future.
I've read several questions on this site and elsewhere that indicate that when Oracle JDK7 is installed, it should not be necessary to specify the classpath to jfxrt.jar when the JDK is installed correctly. Unfortunately, my installation does not seem to be correct, but I cannot figure out what is wrong.
I used the correct RPM for my Red Hat Enterprise Linux 6.2 Server and I'm able to build JavaFX apps in Eclipse when I added the jfxrt.jar to the External Jars. But when trying to compile and run from the command line, it does not find JavaFX classes unless I specify the -cp option to javac and java. The server was originally using openjdk-1.6, but I used alternatives to configure javac and java to point to the newly installed JDK. It looks like that is working fine, except for this issue.
I found that the same problem plagued me when trying to run the JavaFX Exporter. I was trying to export a project that runs fine in Eclipse. But it could not find the JavaFX classes when trying to run. And I haven't worked out how to tell the exporter where the jfxrt.jar file is located.
For reference, the jfxrt.jar is located at /usr/java/jdk1.7.0_21/jre/lib/jfxtr.jar on my system.
when Oracle JDK7 is installed, it should not be necessary to specify the classpath to jfxrt.jar when the JDK is installed correctly.
That is not true.
If you want to compile and run a JavaFX application in Java 7 (u21) and you are not using the JavaFX packaging tools, you need to add jfxrt.jar to your classpath.
See Compile code using JavaFX 2.0 (using command line) for samples of setting the JavaFX classpath for compiling (with javac) and running (with java) a JavaFX 2 application from the command line.
Some IDEs or IDE extensions are aware of this and will automatically add jfxrt.jar to your classpath (e.g. the e(fx)clipse plugin or the NetBeans JavaFX project type).
Some 3rd party tools such as the JavaFX Maven Plugin or the JavaFX Gradle Plugin also package JavaFX applications so that you don't need to add jfxrt.jar to your classpath.
For Eclipse development, use of the e(fx)clipse plugin is recommended, as it takes care of classpath issues (as well as providing other useful capabilities for JavaFX developers).
For Java 8, jfxrt.jar is on the default classpath, so you don't need to explicitly set your classpath to use JavaFX with tools like javac.exe or java.exe for that Java version.
OpenJdk7 does not include jfxrt.jar. Use Oracle Jdk7 instead will help.
I am using Liferay 6.1.1GA2, which includes YUI 3.4.0. As of this posting, the YUI library is currently up to version 3.8.0.
Is there a way to upgrade this library within Liferay so that I won't have to include the newer version inside each portlet I deploy? I can see including the current version on top of the Liferay version leading to problems very quickly.
Currently I am try to solve a bug in an application. Therefor I need the 1.4.3 dojo version.
On my 8.5.3 Domino server, by default there will be the 1.6.1 dojo version loaded.
This version is somewhere in a plugin, and not in the data\domino\js directery. The highest version is 1.5.1.
If I use the property 'xsp.client.script.dojo.version' in the xsp.properties file to set the required dojo version. It is not picked up by the database.
So where can I disable the 1.6.1 dojo version?
There is a known bug in 8.5.3 where the xsp.client.script.dojo.version is not honored if the setting to aggregate the CSS and JS is enabled on the Xpages panel of the application properties.
Disabling the "Use runtime optimized JavaScript and CSS resources" setting will allow your Xpage application to run with the lower version of dojo specified.
In 8.5.2 you had to set xsp.client.script.dojo.version in the server's xsp.properties. With 8.5.3 if you set it in the Application's xsp.properties, the setting is honoured. There's currently no option to set it at XPage level.
IBM are aware of the issue with "Use optimized runtime JavaScript and CSS resources" setting, so hopefully it will be fixed in 8.5.3 FP1.
Check out my blog post on this, shortly after 8.5.3 went gold http://www.intec.co.uk/domino-8-5-3-greater-power-over-dojo-thanks-ibm-for-your-work/