cancel
Showing results for 
Search instead for 
Did you mean: 

Class javax/xml/namespace/QName violates loader constraints

Former Member
0 Kudos

Hi,

I am trying to deploy my enterprise application to NetWeaver 7.0 sp14. I am getting class linkage error using xmlbeans. I've tried to use xmlbeans 1.x, 2.2, and 2.3 (current version). Could you please help me???

thanks...

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Pls give more info from the logs

Former Member
0 Kudos

Thank you so much for a quick reply. Here's the error from the log:

#005056AB05D50082000000000000107C00044A6758088C9D#1207707624897#System.out#application_name#System.out#Guest#0##n/a##8340031005db11dd956f005056ab05d5#Thread[Thread-122,5,SAPEngine_Application_Thread[impl:3]_Group]##0#0#Info##Plain###2008-04-08 19:20:24,881 ERROR [com.xyz.application.api.planning.item.impl.InboundPartListenerImpl] - <Class javax/xml/namespace/QName violates loader constraints>

java.lang.LinkageError: Class javax/xml/namespace/QName violates loader constraints

at com.xyz.application.api.oagi.OAGI.getObjectFromAnyTypeByType(OAGI.java:698)

at com.xyz.application.api.planning.item.impl.PartMapperImpl.getItemMasterHeaderUserAreaType(PartMapperImpl.java:696)

at com.xyz.application.api.planning.item.impl.PartMapperImpl.map(PartMapperImpl.java:232)

at com.xyz.application.api.planning.item.impl.PartMapperImpl.map(PartMapperImpl.java:136)

at com.xyz.application.api.planning.item.impl.InboundPartListenerImpl.processInboundMessage(InboundPartListenerImpl.java:157)

at com.xyz.application.api.planning.item.impl.InboundPartListenerImpl.onMessage(InboundPartListenerImpl.java:95)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)

at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)

at org.springframework.aop.aspectj.AspectJAfterAdvice.invoke(AspectJAfterAdvice.java:42)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)

at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)

at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)

at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)

at $Proxy1700.onMessage(Unknown Source)

at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:510)

at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:445)

at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:414)

at org.springframework.jms.listener.AbstractMessageListenerContainer.executeListener(AbstractMessageListenerContainer.java:386)

at org.springframework.jms.listener.SimpleMessageListenerContainer$2.onMessage(SimpleMessageListenerContainer.java:205)

at com.sap.jms.client.session.Session.run(Session.java:715)

at com.sap.jms.client.session.WaiterThread.run(WaiterThread.java:61)

Former Member
0 Kudos

I've been reading SDN posts and searched internet on this matter. Is there a way to set in the application that the parent classes are loaded last so that the application classes and application library take precedence?

Former Member
0 Kudos

Check out Note 1138545 - Using a newer QName class from a web application

Note 990854 - Class conflicts with third party libraries on J2EE Engine

Former Member
0 Kudos

I am new to this forum. The note number you gave, are they the thread number (doesn't seem to work)?

Former Member
0 Kudos

You need to login to https://websmp104.sap-ag.de/notes and mention the note number, and you can read the details explained in note and solve your issue as suggested.

REMINDER: If you posted the question, please reward points for good answers*. Thanks

Former Member
0 Kudos

Somehow, I cannot login to this site. Would I need to create a different user account for this site?

Former Member
0 Kudos

No need for a seperate account. you can use the same oss id

Am pasting the note for you here :

Note 1138545 - Using a newer QName class from a web application

Summary

Symptom

One would like to use a newer version of javax.xml.namespace.QName class from a web application (jsp or servlet component) running on the j2ee engine.

Reason and Prerequisites

One would like to use a newer version of javax.xml.namespace.QName class from a web application (jsp or servlet component) running on the j2ee engine.

Solution

There is a set of default application references, which are specified by the deploy service property StandardApplicationReferences. This property contains all standard platform provided libraries part of the j2ee specification. The references specified in the property are added to each application loader first. This is a behaviour by design, allowing the platform provided implementations to have precedence over any classes present in a deployed application.

The approach described in note 990854 should work in most of the cases, and is the recommended one.

However if the web application that uses QName class is a third party software and cannot be modified according to the mentioned note, the following workaround can be used:

1. Create a j2ee engine library component containing only the newer version of the QName class

2. Deploy the library on the j2ee engine

3. Put the library name in first place in StandardApplicationReferences property of deploy service and restart the j2ee engine

NB! Please note that the approach described in the note is valid only for QName class as it is currently compatible with the older version. In case an incompatibility arises in the future implementing the note might lead to not working web services applications, both custom and SAP delivered ones.

Note 990854 - Class conflicts with third party libraries on J2EE Engine

Summary

Symptom

One would like to use a third party library containing classes with same name but different version from the ones provided by default with the J2EE engine. One such example could be third party web services implementations.

Other terms

web services class conflict j2ee engine

Reason and Prerequisites

One would like to use a third party library containing classes with same name but different version from the ones provided by default with the J2EE engine. One such example could be third party web services implementations.

Solution

There is a set of default application references, which are specified by the deploy service property StandardApplicationReferences. This property contains all standard platform provided libraries part of the j2ee specification. The references specified in the property are added to each application loader first .

This is a behaviour by design, allowing the platform provided implementations to have precedence over any classes present in a deployed application.

In case one would anyway like to use in an application third party libraries for which a different implementation is provided by the j2ee engine by default the following approach can be used:

1. Declare all jars of the third party implementation in a separate library

2. Create an interface to access and work with the third party implementation classes and bundle it with the jars files in the library mentioned in point 1 above.

There should be no third party usage of the "duplicate" classes, provided by the engine and by the third party implementation inside the application.

In case there are such usages they will "see" the J2EE Engine

delivered libraries - the default platform implementation. Any usage of the classes from the third party implementation should be encapsulated inside the library code.

3. Specify a reference from your application to the library created in point 1 above.

Former Member
0 Kudos

I followed the instructions from the notes, but it didn't work I am still getting the same error. Any idea?

Former Member
0 Kudos

Try restart the server and see. Send me the new log.

Former Member
0 Kudos

My mistake. That actually seemed to have worked (I did restart the engine per note's instruction). Thank you so much. I prematurely assumed that I was getting the same error because the application failed to do what it was supposed to do.

Answers (0)