NetWeaver CE 7.1 AS Java classloader headache

[Former Member]

Hi, Why would NetWeaver load a class outside of the current application instead of loading it from the current application? I would have expected a "heavy classloader" to exhibit this behavior, but we have not set this up. In this case, for technical/historical reasons, we have the same named class in both applications; but, the one we are executing from has the necessary getter/setter methods we need.

>>llr -all -f vendor/util/testmodel/struct/WebServicesTestEntDtls.class

>jar:file:/C:/usr/sap/CE1/J05/j2ee/cluster/apps/vendor.com/TestModelWebServices/servlet_jsp/TestModelWS2/root/WEB-INF/lib/appwebservices.jar!/vendor/util/testmodel/struct/WebServicesTestEntDtls.class

>jar:file:/C:/usr/sap/CE1/J05/j2ee/cluster/apps/vendor.com/TestModelWebServices/servlet_jsp/TestModelWS/root/WEB-INF/lib/appwebservices.jar!/vendor/util/testmodel/struct/WebServicesTestEntDtls.class

>jar:file:/C:/usr/sap/CE1/J05/j2ee/cluster/apps/vendor.com/TestModel/app_libraries_container/struct.jar!/vendor/util/testmodel/struct/WebServicesTestEntDtls.class

I've been referring to this document: [http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/1edf5078-0801-0010-2889-b210227f7563].

Is there any other, better documentation?

Based on how this is working it feels like the classloader hierarchy is being violated and is going horizontally across application classloaders, which is what the "Extended SAP Classloading" describes. But, I don't think it's clearly explained and can only assume that those references = settings in "application j2ee-engine.xml" descriptors, which we haven't coded. From telnet I don't see how this is being loaded incorrectly; that is, its direct parent loaders list doesn't reference the vendor/TestModel where it seems to be loaded from.

Thanks,

William

[Former Member]

Rolf, Thank you for your comments. I'm not sure if it's a huge concern for us, more frustrating. I actually think my earlier thread here ([😉 was more of a concern for us because I stumbled on the solution and never understood why it worked for us in the end.

It's not so much what Axis is doing, but how we're trying to support it. In short, rather than code new web services we use Axis2 to identify existing services in our application and invoke them via RMI. So, to do that we have to have all the necessary objects, as in arguments, available to deserialize for Axis2 to make the calls. It's an old architectural decision made in our environment that's exacerbating the situation for us in our duplicate-named objects in the two applications and it's not really possible to change that decision now.

The part that doesn't bother me is that I think NetWeaver is just being very strict and consistent, which it tends to be in comparison to other application servers. The part that bothers me is that this is a situation where we don't seem to have control over the classloading; but, that may be by design because the initial object is in the remote application ear and thus to invoke its methods NetWeaver believes/enforces the object argument we pass in has to be from the same class loader. However, since we don't see this issue with WebSphere or WebLogic I have to wonder why. I would have to devote a few hours (or more!) to remotely debug/trace one of those environments to understand the difference and why it's not an issue in those environments. I'll try to come back to that and update/close-off this thread.

I think it would be very helpful to compile NetWeaver classloader information into a blog posting of some sort as I find it's fragmented and unclear. For someone like myself, who doesn't yet have the necessary NetWeaver background/experience, even small errors, as in the very helpful "Extended Java Class Loading of SAP NetWeaver" document are significant and cause confusion.

Thanks,

William

[rolf_paulsen]

William, there is another interesting document from 2009 about classloading on NetWeaver that I remeber is not too easy to find, in case you do not yet know it:

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/60642a88-95fe-2b10-d387-a245d48fc257&override...

I will get through the other thread - interesting headaches...

Rolf

[Former Member]

Hi Ilan,

Yes, I that's one avenue we're looking at; but, since it's an existing infrastructure there are some risks for us. So, rather than changing our existing "duplicate" struct classes we're looking at generating them as BeanInfo objects, which the Introspector will look for first. Alternatively, we're looking at adopting our Axis 1.4 mechanism of an "indirect" bean call that we hadn't looked at up until now because of differences in our modelling approach and Axis2 architecture. So I appreciate your feedback as I've created this thread as a sanity check to make sure I wasn't missing anything obvious and your comments have been helpful in that.

Thanks,

William

[rolf_paulsen]

Hi William,

I am really interested in this question, but have too less information to see your components and their interaction.

It is frightening to read that classloading sees contents of another ear without being told to do so. Class loading problems are one of the greatest plagues for Java developers, so I would appreciate some more details (and oher input from SAP than quite simple workarounds) to be prepared if we fall into a similar issue.

What does Axis do compared with a "normal" JEE application? Dynamic classloading is not forbidden in the spec, but the creation of classloaders (and threads). Is this something Axis might do?

Regards,

Rolf

[Former Member]

Ilan, I've looked at the classloader viewer in the NWA (not sure if that's the same as the VA you mention), but I think it's hard to use and just more productive to use telnet, but let me know if maybe I'm wrong on that or misunderstanding something. I say "hard to use" because I can't see all the information on one screen and navigating all of the hierarchy is cumbersome and seems to me to be error prone.

You can see my telnet output in the initial post and it shows the classes in both ear files. However, I think the behavior is runtime-specific. That is, Axis2 is dynamically, via the service descriptor, identifying a method/operation to invoke and its arguments. The only way I can see what's going on is to hack the code and put in getClass().getClassLoader() statements. Having done that I know I can load from either of the two application ear class loaders; but, I think it's our application design that has sunk us here, which was never an issue with WebSphere or WebLogic. From what works I'm about 99% sure that NetWeaver is requiring that the 3 objects/classes involved in the Method.invoke() call all come from the same class loader, otherwise I get IllegalArgumentExceptions. I might try running the debug code on WAS or WLS to verify if that's true.

Thanks,

William

[Former Member]

It sounds like you have a real head scratching problem.

Have you considered just adding the "missing" methods to the other class?

Is that possible?

It shouldn't effect the other application if those new methods are never called from there and you don't generate anything from the class' interface.

[Former Member]

Hi Ilan, Thanks for your response. (What I'm seeing here in the forum is different from the email notification sent to me.)

We're not using any NetWeaver tooling, we have all handcrafted or XDoclet-generated descriptors. Reason I can't set application-j2ee-engine.xml to tell NetWeaver where to find the right class is because it's not looking in its own application class loader and pointing to itself gives a deployment error: "References Test: There are no matching deploy time references".

Because this is working with WebSphere and WebLogic, and only a problem with NetWeaver I suspect that NetWeaver is more strict (and/ore not as flexible) in its class loading policies. The same named structs we are trying to reference are generated by our tooling and don't have any getters/setters in the remote application, but do in the local application. If I hack these to add getters/setters it all works on NetWeaver (but changing our tooling is not a trivial activity). From debugging it looks like because we're invoking an object in the other (remote) application that all the objects involved in that method invocation have to be from that remote class loader.

Thanks,

William

[Former Member]

Hmmm..

Have you used the ClassLoader Viewer service in VA to trace the references? You should be able to confirm your hypothesis this way.

[Former Member]

Maybe set a reference to where you want it to go.

--

ilAn