Weblogic 12c Web Service NullPointerException

Question

For some reason the invocation of Web Service throws NullPointerException on my local Weblogic 12c installation. The same package works correctly on another instance of Weblogic 12c, so there must be something wrong on my weblogic configuration or server/java startup parameters. However, I couldn't figure out what's the difference, and server log message doesn't help at all. Of course we are using same JRE and classpath libraries also.

Here is the exception

####<8.8.2017, 2:10:53,106 ip. EEST> <Error> <com.sun.xml.ws.server.sei.TieHandler> <IT-V-R90HKRNH> <is-mansrv> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <HekoPassi> <> <46eb29b8-cb8a-44a9-94ed-e223acc07388-0000005d> <1502190653106> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <null
java.lang.NullPointerException
    at weblogic.ejb.container.internal.BaseWSLocalObject.__WL_preInvoke(BaseWSLocalObject.java:85)
    at com.foo.bar.service.sessionfacade.SessionFacadeBean_afdkf0_WSOImpl.__WL_getPublicKey_WS_preInvoke(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at weblogic.wsee.server.ejb.WsEjb.preInvoke(WsEjb.java:50)
    at weblogic.wsee.jaxws.WLSEjbInstanceResolver$WLSEjbInvoker.invoke(WLSEjbInstanceResolver.java:193)
    at weblogic.wsee.jaxws.WLSInstanceResolver$WLSInvoker.invoke(WLSInstanceResolver.java:93)
    at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149)
    at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:88)
    at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
    at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
    at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
    at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
    at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:419)
    at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:868)
    at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:422)
    at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:169)
    at weblogic.wsee.jaxws.WLSServletAdapter.handle(WLSServletAdapter.java:229)
    at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:667)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:368)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:163)
    at weblogic.wsee.util.ServerSecurityHelper.authenticatedInvoke(ServerSecurityHelper.java:108)
    at weblogic.wsee.jaxws.HttpServletAdapter$3.run(HttpServletAdapter.java:286)
    at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:295)
    at weblogic.wsee.jaxws.JAXWSServlet.doRequest(JAXWSServlet.java:128)
    at weblogic.servlet.http.AbstractAsyncServlet.service(AbstractAsyncServlet.java:103)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:286)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:350)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:247)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3679)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3649)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326)
    at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197)
    at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)
    at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)
    at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2433)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2281)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2259)
    at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1691)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1651)
    at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:270)
    at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
    at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
    at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
    at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
    at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

Any idea what may cause this exception (or how I can debug it, seems like the exception is thrown from a dynamic proxy generated by weblogic, before the control even goes to implementation class). Can I make the exception more verbose? May this be an security issue? But then again, nothing in the stacktrace indicates that. Also, there are no exceptions in deployment log.

Racehorse

I have found that error occurs when config.xml contains <debug-scope> <name>weblogic</name> <enabled>true</enabled> </debug-scope>. Do you have such configuration? – Boiler

There is no enough information, on which someone can tell you the solution. Like what webservice are you trying to access. Is it specific to specific webservice api ? how are you trying to execute/call ? – Motorcycle

The stacktrace weblogic.wsee.jaxws clearly states I'm using the JAX-WS API and Weblogic implementation. I'm just trying to access typical web service with SoapUI using WS-security digest authentication. – Racehorse

Answer 1

Hope this helps :

(from MOSC(My Oracle Support Community) java.lang.NullPointerException: com.sun.xml.ws.spi.db.JAXBWrapperAccessor.getPropertyAccessor When Deploying WebService (Doc ID 2207272.1))

APPLIES TO:

Oracle WebLogic Server - Version 12.1.1.0 to 12.2.1.2.0 [Release 12c] Information in this document applies to any platform.

SYMPTOMS

When attempting to deploying a webservice application with the below sample code snippet,

@WebService
public interface HelloServiceInterface {
@WebMethod
@RequestWrapper(className = "hello.HelloRequest")
public String hello(@WebParam(name = "names") List<String> names);

the following error occurs:

java.lang.NullPointerException: at com.sun.xml.ws.spi.db.JAXBWrapperAccessor.getPropertyAccessor(JAXBWrapperAccessor.java:261) at com.sun.xml.ws.db.toplink.JAXBContextWrapper.getElementPropertyAccessor(JAXBContextWrapper.java:170) at com.sun.xml.ws.server.sei.EndpointArgumentsBuilder$DocLit.(EndpointArgumentsBuilder.java:598) at com.sun.xml.ws.server.sei.TieHandler.createArgumentsBuilder(TieHandler.java:143) at com.sun.xml.ws.server.sei.TieHandler.(TieHandler.java:115) at com.sun.xml.ws.db.DatabindingImpl.(DatabindingImpl.java:118) at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:74) at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:58) at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:120) at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:521) at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:300) at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:164) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:577) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:560) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:639) at weblogic.wsee.jaxws.JAXWSDeployedServlet.getEndpoint(JAXWSDeployedServlet.java:355) at weblogic.wsee.jaxws.JAXWSServlet.registerEndpoint(JAXWSServlet.java:167) at weblogic.wsee.jaxws.JAXWSServlet.init(JAXWSServlet.java:79) at weblogic.wsee.jaxws.JAXWSDeployedServlet.init(JAXWSDeployedServlet.java:91) at javax.servlet.GenericServlet.init(GenericServlet.java:244)

CAUSE

This is a known issue with Eclipselink MOXy provider. XmlElementWrapper annotation ignored. The issue is reported in Bug:16685902 [ https://support.oracle.com/epmos/faces/BugDisplay?parent=DOCUMENT&sourceId=2207272.1&id=16685902 ] - WEBSERVICE PARAMETER LIST GIVES NULLPOINTEREXCEPTION AT DEPLOYMENT.

SOLUTION

Apply Patch 16685902 [ https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2207272.1&patchId=16685902 ] to WebLogic Server 12.1.1. As a workaround, avoid using Eclipselink MOXy provider in WebLogic by doing below:

set PRE_CLASSPATH=%WLS%\modules\databinding.override_1.0.0.0.jar

REFERENCES

BUG:16685902 [ https://support.oracle.com/epmos/faces/BugDisplay?parent=DOCUMENT&sourceId=2207272.1&id=16685902 ] - WEBSERVICE PARAMETER LIST GIVES NULLPOINTEREXCEPTION AT DEPLOYMENT

Gesticulate

Answer 2

This is not necessary the bug mentioned. That bug is resolved since 12.1.3

The mentioned workaround works (changing the JAXB Provider), but it is a bad solution to hardcode in PRE_CLASSPATH variable (maybe only for a development environment).

Weblogic since version 12.1.1 changed default JAXB provider from Glassfish RI to Eclipse MOXy, then you can use Glassfish again configuring Java Service Provider Interface (SPI)

https://docs.oracle.com/middleware/1213/wls/WSGET/jax-ws-datatypes.htm#WSGET345

This way you can see the real root cause. In our case it was a problem about duplicated classes (created with JAXB, and having different attributes, but the same package/namespace).

Staves