Configuring class loader?

[Former Member]

G'day,

I am having an issue with the class loader in Netweaver AS Java.

I have deployed a library that contains two jars: one for SAML, and one for DOM (level 3).

My library calls the SAML code, which tries to use some DOM code, but the DOM library in sapxmltoolkit library gets called instead. This DOM library is level 2 (not level 3) and I get an "abstract method error" exception. If I take the DOM library out my SDA and put into into jre/lib/endorsed then the application succeeds.

Modifying jre/lib/endorsed is not an option for production, so is there a way to configure the Netweaver classloader so that the DOM jar in my library gets loaded before the DOM library in sapxmltoolkit?

Geoff

[Former Member]

I have a solution, though it is quite a hack: I post-processed the jar files I need for XML parsing so that all references such as org.w3c.dom are changed to foo.org.w3c.dom, etc. This way there's no interference from other jars in the hierarchy (such as the SAP XML toolkit), since different namespaces are used.

But I will also try modifying the class file loader as suggested by the links above.

[Former Member]

I am curious about your hack. How did you post process the jar files? Did you use a tool to accomplish this? I am running into the same problem with opensaml endorsed jars.

[Former Member]

Yes, I post-processed the jar files.

I wrote a tool reads a jar file, and the class and properties files within that jar, and replaced strings (actually, UTF-8 constants) of the form "x.y.z" and "x/y/z" with "foo.x.y.z" and "foo/x/y/z" respectively.

So my login library that used to reference xalan.jar, xercesImpl.jar etc now references foo-xalan.jar, foo-xercesImpl.jar, etc.

However, there were bugs in some of the XML libraries that use the wrong class loaders for locating parsers. If I modify the source code of the XML libraries, then I can put my modified xalan, xerces, etc into my SDA. If I use the unmodified XML libraries, then I need to put the post-processed jars back into the jre/lib/endorsed folder of the JDK.

Modifying the source of open source XML libraries has all sorts of maintenance and licensing issues so that may not be a practical solution anyway.

I really don't like putting jars into jre/lib/endorsed but because I have modified the jar's package names there are no conflicts with existing libraries.

I am not sure if there are any licensing issues with post-processed xalan. etc. Still need to figure that out.

[Former Member]

G'day,

Checking the log output I see the following:

ClassLoader name: [library:MyLoginModuleLibrary]
[...]
 Loading model: {parent,local,references}

Perhaps there is a way to configure the loading model for this library to {local, parent, references} ?

Geoff

[Former Member]

Hello, I am trying to do the exact same thing. Started searching for a solution yesterday. We have NetWeaver 7.0 on IBM Java 1.4.2. I asked my admin is enter an oss message inquiring about endorsing the JAXP1.3 libraries supplied with OpenSAML. Why do you not consider that an option?

[Former Member]

\[...\]inquiring about endorsing the JAXP1.3 libraries supplied with OpenSAML. Why do you not consider that an option?

Customer requirements do not allow adding any jars into jre/lib/endorsed. I need a way to ensure that the DOM jar in the library I deploy (actually it is a login module, if that makes a difference) is found by the class loader ahead of the DOM jar in the sapxmltoolkit library.

[Former Member]

I ran across these two threads in my searching.

/thread/24988 [original link is broken]

/thread/22479 [original link is broken]