CXF Webservice issue in weblogic server

Question

I am trying to call a webservice from my webapplication which works fine with servers like Apache Tomcat or JBoss, but fails with below exception in Weblogic server.

Any solution for this ?

java.lang.ExceptionInInitializerError
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at java.lang.Class.newInstance(Class.java:379)
        at org.apache.geronimo.osgi.locator.ProviderLocator.getService(ProviderLocator.java:234)
        at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:176)
        at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:220)
        at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)
        at javax.xml.ws.spi.Provider.provider(Provider.java:43)
        at javax.xml.ws.Service.<init>(Service.java:35)
        at com.my.Tpackage.imageSign.FIUsbWebServiceService.<init>(FIUsbWebServiceService.java:40)
        at com.my.Tpackage.imageSign.SignatureWebServiceClient.getWebServiceResponse(SignatureWebServiceClient.java:32)
        at com.my.Tpackage.imageSign.MyAction.getMySignatureImage(MyAction.java:47)
        at com.my.Tpackage.imageSign.MyAction.execute(MyAction.java:28)
        at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
        at com.montran.security.SecureRequestProcessor.processActionPerform(SecureRequestProcessor.java:707)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
        at com.montran.main.action.InheritanceActionServet.process(InheritanceActionServet.java:332)
        at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
        at com.my.security.ActivityLoggingFilter.doFilter(ActivityLoggingFilter.java:88)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
        at com.my.security.AuthenticationFilter.doFilter(AuthenticationFilter.java:179)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
        at com.my.security.InjectionFilter.filter(InjectionFilter.java:453)
        at com.my.security.InjectionFilter.doFilter(InjectionFilter.java:360)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)
        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused by: javax.xml.ws.WebServiceException: Error creating JAXBContext for W3CEndpointReference.
        at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:237)
        at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:232)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.xml.ws.spi.ProviderImpl.getEPRJaxbContext(ProviderImpl.java:232)
        at com.sun.xml.ws.spi.ProviderImpl.<clinit>(ProviderImpl.java:95)
        ... 44 more
Caused by: javax.xml.bind.JAXBException
 - with linked exception:
[com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
org.w3c.dom.Element is an interface, and JAXB can't handle interfaces.
        this problem is related to the following location:
                at org.w3c.dom.Element
                at public java.util.List com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements.elements
                at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements
                at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements com.sun.xml.ws.developer.MemberSubmissionEndpointReference.referenceProperties
                at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
]
        at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:263)
        at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
        at javax.xml.bind.ContextFinder.find(ContextFinder.java:432)
        at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
        at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)
        at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:235)
        ... 48 more
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
org.w3c.dom.Element is an interface, and JAXB can't handle interfaces.
        this problem is related to the following location:
                at org.w3c.dom.Element
                at public java.util.List com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements.elements
                at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements
                at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements com.sun.xml.ws.developer.MemberSubmissionEndpointReference.referenceProperties
                at com.sun.xml.ws.developer.MemberSubmissionEndpointReference

        at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:106)
        at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:466)
        at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:298)
        at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:141)
        at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1163)
        at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)
        at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248)
        ... 53 more

Possible duplicate of [WebLogic clientgen doesn't work from WebLogic](http://stackoverflow.com/questions/11283489/weblogic-clientgen-doesnt-work-from-weblogic) — Frank, Apr 27 '16 at 12:35
Right Frank, it is similar issue. What dependency cleanup is required, I am still not getting the resolution. — Shreyas Dave, Apr 27 '16 at 13:04

Frank · Answer 1 · 2016-04-27T14:07:21.867

In your weblogic-application.xml you must define your JAXB-provider to be the one from cxf not the sun reference implementation (com.sun.xml...).

Add the following to the mentioned file

 <prefer-web-inf-classes>true</prefer-web-inf-classes>

This leads to reversing the classloading process. So the classes you provide with your war are loaded before the ones from weblogic.

EDIT:

The Documentation for Provider says:

The algorithm used to locate the provider subclass to use consists of the following steps:

If a resource with the name of META-INF/services/javax.xml.ws.spi.Provider exists, then its first
line, if present, is used as the UTF-8 encoded name of the
implementation class.

If the $java.home/lib/jaxws.properties file exists and it is readable by the java.util.Properties.load(InputStream) method and it
contains an entry whose key is javax.xml.ws.spi.Provider, then the
value of that entry is used as the name of the implementation class.

If a system property with the name javax.xml.ws.spi.Provider is defined, then its value is used as the name of the implementation
class.

Finally, a default implementation class name is used.

so, if the changing the classloading is not enough add the following

 <prefer-application-resources>  
   <resource-name>META-INF/services/javax.xml.ws.spi.Provider</resource-name>  
 </prefer-application-resources>

to weblogic-application.xml

That is strange. I tried to reproduce with a service of mine and it works as expected. Are you sure that the correct cxf jars (cxf-rt-frontend-jaxws.jar) are packed into your application? Inside this jar there should be the file with the mentioned name containing this string: `org.apache.cxf.jaxws22.spi.ProviderImpl`. Check your stacktrace if there is still `com.sun.xml.ws.spi.ProviderImpl` in it. — Frank, Apr 29 '16 at 07:07

CXF Webservice issue in weblogic server

1 Answers1