I'm not positive on it, but I seem to remember getting this error when I
used a different version of the addressing/rampart modules with a
specific version of Axis 2.
E.g. Axis 2 1.3 and rampart 1.2 and addressing 1.2.
Changing all modules are jars to be for the same release of Axis 2 fixed
it up.
2.
Sounds like you have an older version of QName (which lacks that constructor) on your path (looks similar to a WebSphere 5.x problem where one of the parent classloaders loads an older version of QName). Try something like QName.class.getProtectionDomain().getCodeSource().getLocation() at the point of the exception to see which one is being used.
3.I dont know whats the cause and solution on this
> issue. However, I
> > think you can workaround this by using Sun's jms
> API instead of
> > weblogic's. You can do this by placing Sun's jms
> jar in the WL
> > classpath before weblogic's weblogic jar.
4.
This most likely is a class loading issue because the QName class in weblogic.jar is loaded earlier by the system classloader and can’t be “overridden” by the EAR/WAR classloader. But that’s just my best bet as I am not a classloader expert when it comes to WebLogic’s classloading mechanism.
5.Solution for WebLogic Server: put QName (qname.jar) ahead of
weblogic.jar in your classpath and do not load qname.jar from the lib
directory of your web application.
6.
In my company’s production environment (2000 users) we use a patch directory for WebLogic patches (quite a few…) we receive from BEA. The patches are being put ahead of weblogic.jar in the classpath. But our WebLogic administrator denied my request to put qname.jar in it because its not an “official” patch from BEA. So I opened a case at BEA’s support website. I was instructed to deliver a test case which you find a bit lower on this page.
If you are in a similar situation and have access to the support area you can refer to my BEA case #691432 to obtain an official patch/recommendation for the QName issue. I haven’t yet tested if the problem still exists in WebLogic 9.x which uses Java 5. I’m planning to do this in the first quarter of 2008.
used a different version of the addressing/rampart modules with a
specific version of Axis 2.
E.g. Axis 2 1.3 and rampart 1.2 and addressing 1.2.
Changing all modules are jars to be for the same release of Axis 2 fixed
it up.
2.
Sounds like you have an older version of QName (which lacks that constructor) on your path (looks similar to a WebSphere 5.x problem where one of the parent classloaders loads an older version of QName). Try something like QName.class.getProtectionDomain().getCodeSource().getLocation() at the point of the exception to see which one is being used.
3.I dont know whats the cause and solution on this
> issue. However, I
> > think you can workaround this by using Sun's jms
> API instead of
> > weblogic's. You can do this by placing Sun's jms
> jar in the WL
> > classpath before weblogic's weblogic jar.
4.
This most likely is a class loading issue because the QName class in weblogic.jar is loaded earlier by the system classloader and can’t be “overridden” by the EAR/WAR classloader. But that’s just my best bet as I am not a classloader expert when it comes to WebLogic’s classloading mechanism.
5.Solution for WebLogic Server: put QName (qname.jar) ahead of
weblogic.jar in your classpath and do not load qname.jar from the lib
directory of your web application.
6.
In my company’s production environment (2000 users) we use a patch directory for WebLogic patches (quite a few…) we receive from BEA. The patches are being put ahead of weblogic.jar in the classpath. But our WebLogic administrator denied my request to put qname.jar in it because its not an “official” patch from BEA. So I opened a case at BEA’s support website. I was instructed to deliver a test case which you find a bit lower on this page.
If you are in a similar situation and have access to the support area you can refer to my BEA case #691432 to obtain an official patch/recommendation for the QName issue. I haven’t yet tested if the problem still exists in WebLogic 9.x which uses Java 5. I’m planning to do this in the first quarter of 2008.