Follow Us on Twitter

OWSM java.lang.NoSuchMethodError when using wss_username_token_service_policy

by Laurens van der Starre on December 27, 2013 · 1 comment

After upgrading an Oracle Service Bus 11.1.1.5 to 11.1.1.7 the inbound OSB proxies that enforce the oracle/wss_username_token_service_policy started to fail with the following errors in the logs:

java.lang.NoSuchMethodError: com.bea.wli.sb.security.wss.WssInboundContext.setRequestMessage(Ljavax/xml/soap/SOAPMessage;Ljava/lang/Class;Ljavax/xml/soap/MessageFactory;)V
        at com.bea.wli.sb.security.wss.wsm.WsmInboundHandler.processRequest(WsmInboundHandler.java:230)
        at com.bea.wli.sb.security.wss.WssHandlerImpl.doInboundRequest(WssHandlerImpl.java:228)
        at com.bea.wli.sb.context.BindingLayerImpl.addRequest(BindingLayerImpl.java:291)
        at com.bea.wli.sb.pipeline.MessageProcessor.processRequest(MessageProcessor.java:92)
        at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:597)
        at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:595)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
        at com.bea.wli.sb.security.WLSSecurityContextService.runAs(WLSSecurityContextService.java:55)
        at com.bea.wli.sb.pipeline.RouterManager.processMessage(RouterManager.java:594)
        at com.bea.wli.sb.transports.TransportManagerImpl.receiveMessage(TransportManagerImpl.java:398)
        at com.bea.wli.sb.transports.http.generic.RequestHelperBase.invokePipeline(RequestHelperBase.java:185)
        at com.bea.wli.sb.transports.http.wls.HttpTransportServlet$RequestHelperWLS.invokePipeline(HttpTransportServlet.java:228)
        at com.bea.wli.sb.transports.http.generic.RequestHelperBase$1.run(RequestHelperBase.java:160)
        at com.bea.wli.sb.transports.http.generic.RequestHelperBase$1.run(RequestHelperBase.java:158)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
        at com.bea.wli.sb.transports.http.generic.RequestHelperBase.securedInvoke(RequestHelperBase.java:157)
        at com.bea.wli.sb.transports.http.generic.RequestHelperBase.service(RequestHelperBase.java:105)
        at com.bea.wli.sb.transports.http.wls.HttpTransportServlet.service(HttpTransportServlet.java:129)
        at weblogic.servlet.FutureResponseServlet.service(FutureResponseServlet.java:24)
        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.ServletStubImpl.execute(ServletStubImpl.java:184)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3741)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3705)
        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:2282)
        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2181)
        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1491)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:252)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>

Apparently the WsmInbound API changed between the 11.1.1.5 and 11.1.1.7 version. Somehow, somewhere some cached JAR file is screwing up the internal workings of the OWSM. To fix this do the following:

First untarget the “OWSM Policy Support in OSB Initializer Aplication” from everything (but remember where it was target to. Probably the AdminServer and the OSB cluster).

Target Deployment

┬áThen shutdown the domain. In the <DOMAIN_HOME>/servers/<SERVERNAME> remove the cache and tmp directory. Afterwards, start the domain. Target the “OWSM Policy Support in OSB Initializer Aplication” to the correct targets again. Stop the domain, and again remove the cache and tmp directories just as before (just for the heck of it). Finally, start the domain, and you’ll all set!

OWSM java.lang.NoSuchMethodError when using wss_username_token_service_policy, 5.0 out of 5 based on 4 ratings
Ratings:
VN:D [1.9.22_1171]
Rating: 5.0/5 (4 votes cast)

{ 1 comment… read it below or add one }

Ramesh February 25, 2014 at 5:49 pm

This helped us alot in resolving the issue and thanks for posting it

Reply

Leave a Comment

 

Previous post:

Next post:

About Whitehorses
Company profile
Services
Technology

Whitehorses website

Home page
Whitebooks
Jobs

Follow us
Blog post RSS
Comment RSS
Twitter