In order to use a newer DOM parser implantation (e.g. Apache Xerces and SOAP), we must replace the XML4j.jar file in the Domino program directory with the newer one on the Apache site. This may violate the Domino support warranty and it may lead to other problems.
What problems might we encounter if we did this?
Is there any other way to get the Apache functionality we need in our Notes applications?
Does Lotus Notes 6.5x or whatever have the uptodate XML4j.jar?
Thanks,
Kevin
Subject: XML4j.jar Woes
Why do you think you need to replace it?
We are actively using XML4J (legacy code) and Xalan/Xerces side-by-side on the same server.
cheers,
Bram
Subject: RE: XML4j.jar Woes
I’m sooo happy to hear that! Notes.net is full of posts talking about how one cannot do this, or do this very easily. Like this for example:http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/09efd4552fc6153385256f09004efbdc?OpenDocument
Subject: RE: XML4j.jar Woes
Do you use the JavaUserClasses ini variable to add the jar? Are there any ‘gotchas’ in doing this? I see that some on this forum seem to want to shy away from using this solution, though it sounds perfect to me!
Subject: RE: XML4j.jar Woes
Since we only use the Xalan/Xerces parsers in a limited number of agents, we include the jars directly in the agents (and some applications) themselves. It may be possible to store them in the JavaUserClasses in notes.ini but I don’t know this: it may cause problems with precedence.
We have agents that use both legacy XML4J code and newer Xalan/Xerces code side-by-side without any problem. A big part of the domino-XML spectrum should is covered in these agents.
cheers,
Bram
Subject: RE: XML4j.jar Woes
What is happening and what Mr. Kerkhof thinks are happening *might be two seperate things. Here is what I’ve found: If I rename the XML4J.jar in the Notes folder for designer v6.5.1 (and restart) and import older an version directly into an agent, the older version is used. But if I rename XML4J back (and restart), the agent picks up the one on the hard disk first. Thus, my agent breaks. I don’t think this can be solved with JavaUserClasses var but I will try.
Does anyone know a way to force it to ignore Notes’ internal version of XML4J? It would be stupid for Lotus to allow you to overwrite the JDK but yet still pick up certain JARs without regard to user preference.
Subject: RE: XML4j.jar Woes
is that means i can use the xml4j.jar provided with the soapconnect sample on notes.net on my production server? if not, what’s alternative way?