on 04-09-2008 7:01 PM
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...
Pls give more info from the logs
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)
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
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.
User | Count |
---|---|
85 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.