Java: JavaUserClasses vs <<notes>>\jvm\lib\ext

HCL Domino Domino Forum
1

Hi

I’m just struggling a bit with java agents and xml. It seems the built-in domino XML classes do not support SAX2 or DOM2 (?) so I want to use Apache Xerces for my java xml processing. There is also little or no available documentation for the IBM/Lotus XML vendor specific XML classes needed and no JAXP API. In other words, this just won’t do (unless I’m missing something here?)

I have put the XercesImpl.jar and xml-apis.jar from the Xerces distribution in my <>\jvm\lib\ext directory. I though this might be sufficient, but this doesn’t resolve issues surrounding getting past NOT using the XML classes/interfaces distributed with domino, most of them old and lacking newer functionality, most noticably org.w3c.dom.DOMImplementation.createDocumentType() and org.w3c.dom.DOMImplementation.createDocument() from the DOM interface.

Also, when writing a simple java agent using domino designer, it seems it can’t find certain methods in the jar files when they are only available in the jvm\lib\ext and also conflict with the built-in XML classes. I was having trouble getting the designer java compiler to find certain methods in the org.apache.xml.serialize.OutputFormat class distributed in the XercesImpl.jar file. I hadn’t specified this file in the JavaUserClasses ini variable and therefore it seemed designer was finding an instance of OutputFormat in the LotusXSL.jar file. Yes, I know Lotus actually gave away parts of what is today the Xalan distribution, but I didn’t think the package name would mention apache. I couldn’t understand why this wasn’t working until I looked inside LotusXSL.jar to see if this could be true.

Anyway, my question is will the settings in the JavaUserClasses interfere with normal usage of XML4j.jar and LotusXSL.jar? I mean, I’m not the only one using the domino server for XML processing and there are people running LotusScript agents etc. also processing XML using the classes available to them. Will they still be able to access the built-in xml functionality or will they now be using classes/interfaces from the Xerces distribution?

It seems for all other jar classes NOT conflicting with any available jar files distributed with domino do not need to be specified in the JavaUserClasses. These need only to be popped into the jvm\lib\ext directory. Correct?

Another thing, just why aren’t the XML4j.jar and LotusXSL.jar classes supporting newer parsing functionality? DOM3 is just around the corner and domino doesn’t even support DOM2, SAX2 or JAXP? What gives? Is there a good reason?

Not too impressed… the documentation on xml parsing/processing is also seriously lacking. Why are there no javadocs available for the distributes jar files? I’m also missing javadocs for the contents of notes.jar. The designer help database is far too inconsistent in my opinion. It also assumes you have to have a notes client installed to be able to use the documentation.

Comments?

2

Subject: Java: JavaUserClasses vs <>\jvm\lib\ext

Anyway, my question is will the settings in the JavaUserClasses interfere with normal usage of XML4j.jar and LotusXSL.jar?

Yes, to the extent that there are similarly named classes in the various packages. JavaUserClasses is added to the FRONT of the JVM sun.boot.class.path and will thus mask any identically named classes with come later in the path. This was done with purpose for several reasons, one of which may be historical now and not as valid as it once was.

It seems for all other jar classes NOT conflicting with any available jar files distributed with domino do not need to be specified in the JavaUserClasses. These need only to be popped into the jvm\lib\ext directory. Correct?

In theory yes, but as you noted in your followup post there is a bug or unexplained behavior in the Domino JRE such that if JavaUserClasses is specified, the JAR’s in the jvm\lib\ext directory are not found. I was not able to find the root of this problem prior to leaving IBM and as far as I know, it still exists, at least up through Notes/Domino 6.5. So the perference should be to use jvm\lib\ext unless you have some overriding reason to use JavaUserClasses.

Another thing, just why aren’t the XML4j.jar and LotusXSL.jar classes supporting newer parsing functionality? DOM3 is just around the corner and domino doesn’t even support DOM2, SAX2 or JAXP? What gives? Is there a good reason?

I’m not touching this one with a 10-foot pole.

Not too impressed… the documentation on xml parsing/processing is also seriously lacking. Why are there no javadocs available for the distributes jar files?

Most of these JAR’s are actually gotten from various locations and just re-distributed. But yes, I agree the documention should be shipped along with them rather than making you go find it. But they are out there on various IBM and Lotus sites, do a search, you’ll find them.

I’m also missing javadocs for the contents of notes.jar. The designer help database is far too inconsistent in my opinion. It also assumes you have to have a notes client installed to be able to use the documentation.

The decision was made early on to produce the documentation in NSF format to keep things consistent and the prevailing opinion at the time was that the primary use of Java would be by lotusscript programmers who were already familar with the nsf doc versions. This leads directly to the very strange format of the Java class documentation in the NSF, it closely mirrors the lotusscript format. But I agree with you 100%, it’s awful and there really should be direct javadoc generated docs for Notes.jar and NCSO.jar.

Joseph Millar

Principal Software Engineer

Brightline Technology

3

Subject: Java: JavaUserClasses vs <>\jvm\lib\ext

Another thing is the fact that ever since I started using the JavaUserClasses ini setting to override XML4j.jar and LotusXSL.jar, the jvm can’t see the jar files in the lib\ext directory without also having to specify them in the JavaUserClasses. This used to work without the JavaUserClasses setting (only in ext).

Is this just me or is this a fact?

Do there exist any best practices for deploying jar files on the domino server? The ext directory made things relativly easy. The JavaUserClasses makes things more arkward (also the known JavaUserClasses max length limit). Distributing the jar files with every agent isn’t a good option for common functionality shared between agents (apart from replication)

Common’ people. I know there are others with similar experiences. Share your knowlendge.

4

Subject: RE: Java: JavaUserClasses vs <>\jvm\lib\ext

Hi Lee,

You’re right, we are out here!!! In fact, I was so frustrated with all these problems that I built a product named “fleXML for Domino”. The tool is free and you can request a download at our web site: http://www.stonepondsoftware.com.

Let me know if you have any questions,

Scott

5

Subject: RE: Java: JavaUserClasses vs <>\jvm\lib\ext

I am exactly where you are right now, trying desperately to get Domino to “see” Xalan and Xerces when they reside in the ext directory. The only way to use those classes is to define them in JavaUserClasses (sigh).

I have another major problem with Domino (6.5) running on AIX (5.2) in combination with this. I transform CSV data into XML (using my own transformation classes). I feed my XML document (as a string) into a DomDocument (Xerces), where the total size of my XML is roughly 4kb and do some operations on it. The real fun part of this is the following:

Even tough i have set the max heap size to 150MB (in notes.ini), i always get a “OutOfMemoryException” after 4 runs. I am very careful to reCycle everything and empty every used object before exiting my scheduled agent, but i still get this error. I had a lot of trouble in the past running scheduled agents under Domino 5.0.11 that connected to SAP (using their jCO connector) and never got it to run correctly. I later found out that Lotus had acknowledged this as a “semaphore deadlock problem” which i was hoping to be solved in the 6.X codebase, but it don’t look good at all right now.

Our interim solution was to abandon the agent manager and use the “two-headed beast” pattern and run the programs triggered as Ctrl-M jobs under Unix, awaiting a more stable Domino version (if such a thing would ever be released)…

only my 2 cents worth…

Kind regards

Daniel