web-dev-qa-db-fra.com

Service Web Weblogic 12c NullPointerException

Pour une raison quelconque, l’appel du service Web lève l’exception NullPointerException sur l’installation locale de Weblogic 12c. Le même package fonctionne correctement sur une autre instance de Weblogic 12c. Il doit donc y avoir un problème avec la configuration de weblogic ou les paramètres de démarrage serveur/Java. Cependant, je ne pouvais pas comprendre quelle était la différence et le message du journal du serveur ne m'aidait pas du tout. Bien sûr, nous utilisons les mêmes bibliothèques JRE et classpath.

Voici l'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)

Toute idée de ce qui peut causer cette exception (ou de la façon dont je peux la déboguer, semble être levée à partir d'un proxy dynamique généré par weblogic, avant même que le contrôle ne passe à la classe d'implémentation). Puis-je rendre l'exception plus détaillée? Est-ce que cela peut être un problème de sécurité? Mais là encore, rien dans le stacktrace ne l'indique. En outre, il n'y a aucune exception dans le journal de déploiement.

javaweb-servicesjava-eeweblogicjax-ws
12
Tuomas Toivonen

Ce n'est pas nécessaire le bug mentionné. Ce bug est résolu depuis 12.1.3

La solution de contournement mentionnée fonctionne (modification du fournisseur JAXB), mais il s'agit d'une mauvaise solution pour coder en dur dans la variable PRE_CLASSPATH (peut-être uniquement pour un environnement de développement).

Depuis la version 12.1.1, Weblogic a modifié le fournisseur JAXB par défaut de Glassfish RI à Eclipse MOXy. Vous pouvez ensuite utiliser Glassfish à nouveau pour la configuration de l'interface SPI (Java Service Provider Interface).

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

De cette façon, vous pouvez voir la vraie cause racine. Dans notre cas, il s'agissait d'un problème concernant les classes dupliquées (créées avec JAXB et ayant des attributs différents, mais le même package/espace de noms).

0
devwebcl