Deploying Backbase 5.6.4+ application on Weblogic 12c

Recently we deployed the Backbase 5.6.4 application on Weblogic 12.2.1.3 c.  As part of our project we had to migrate to Backbase 5.6.4 version and also upgrade the Weblogic to 12c from 11g version. Backbase supports Weblogic 11g application server and it doesn’t support the deployment to Weblogic 12c as per the documentation for CXP 5.6.4 version. Deployment steps were not available for Weblogic 12c for CXP 5.6.4 version. We had to move to Weblogic 12c as it provides zero downtime deployment and the bank really wanted this upgrade! When we deployed Backbase 5.6.4 to 12c we ran into many problems with  jar conflict issues and class loading issues.

We noticed that the backbase wars like portalserver.war created in the usual way works in Tomcat but not in Weblogic 12c. This blog explains how we solved these conflicts and the steps we have to do to create the Weblogic 12c specific wars that works.

Following are some stacktraces of the class loading issues that came up.

Stacktrace 1
<Dec 8, 2017 2:38:12 PM IST> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application ‘portalserver’.
weblogic.application.ModuleException: 
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1531)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:488)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
Truncated. see log file for complete stacktrace
Caused By: javax.xml.bind.JAXBException: ClassCastException: attempting to cast zip:/domain/consumer_portal/servers/NewPortal_mod/tmp/_WL_user/portalserver/d16z7t/war/WEB-INF/lib/jaxb-api-2.2.6.jar!/javax/xml/bind/JAXBContext.class to jar:file:/middleware/jdk1.7.0_79/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class.  Please make sure that you are specifying the proper ClassLoader.
at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:115)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:187)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:132)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:334)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:431)
Truncated. see log file for complete stacktrace
Stacktrace 2
Caused By: java.lang.ClassCastException: Cannot cast weblogic.wsee.jaxws.framework.policy.WSDLGeneratorExtension to com.sun.xml.ws.api.wsdl.writer.WSDLGeneratorExtension
at java.lang.Class.cast(Class.java:3369)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:360)
at com.sun.xml.ws.util.ServiceFinder.toArray(ServiceFinder.java:211)
at com.sun.xml.ws.server.EndpointFactory.generateWSDL(EndpointFactory.java:411)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:182)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:420)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:237)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:133)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:97)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:705)
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.Event

 

Stacktrace 3
Caused By: java.util.ServiceConfigurationError: javax.xml.stream.XMLInputFactory: Provider com.ctc.wstx.stax.WstxInputFactory not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at javax.xml.stream.FactoryFinder$1.run(FactoryFinder.java:353)
at java.security.AccessController.doPrivileged(Native Method)
at javax.xml.stream.FactoryFinder.findServiceProvider(FactoryFinder.java:341)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:313)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:227)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:154)
at org.hibernate.validator.internal.xml.XmlParserHelper.<init>(XmlParserHelper.java:66)
at org.hibernate.validator.internal.xml.ValidationXmlParser.<init>(ValidationXmlParser.java:60)
at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:287)

Following are the steps we have to do to resolve the classloading issues and jar conflicts.

Step 1

We need to add the following weblogic.xml configuration at portalserver/…./WEB-INF/

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
    <container-descriptor> 
        <prefer-web-inf-classes>true</prefer-web-inf-classes>
    </container-descriptor>

   <session-descriptor>
             <cookie-secure>false</cookie-secure>
          <persistent-store-type>jdbc</persistent-store-type>
          <sharing-enabled>true</sharing-enabled>


         <persistent-store-pool>PortalDS</persistent-store-pool>

         <persistent-store-table>WL_SERVLET_SESSIONS</persistent-store-table>
         <timeout-secs>300</timeout-secs>
    </session-descriptor>

</weblogic-web-app>

Using this configuration we specify weblogic to prefer web-inf classes from the portalserver war over the corresponding classes of weblogic lib directory.

Step 2

Create a maven profile weblogic  in Backbaseproject/webapps/portalserver/pom.xm to exclude some jars from the portalserver.war.

<profile>
    <id>weblogic</id>
    <properties>
        <skipTests>true</skipTests>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <packagingExcludes>
                        WEB-INF/lib/stax-api*.jar,
                        WEB-INF/lib/xercesImpl-*.jar,
                        WEB-INF/lib/jaxws-api-*.jar,
                        WEB-INF/lib/xml-apis*.jar,
                        WEB-INF/lib/geronimo-stax-api_1.0_spec*.jar,
                        WEB-INF/lib/saaj-api-*.jar
                    </packagingExcludes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

Weblogic 12c comes up with these jars and so we have to exclude them from the war. Otherwise there will be jar conflict issues  and classloading issues while the server is starting up. This bundling makes sure that we have the JAXWS-RT-2.1.1.jar in the portalserver.war

 

Using this weblogic  profile if we run mvn clean install -Pweblogic,  it will create the war  excluding the jars mentioned above in the snippet. This war can be deployed to Weblogic 12c.

 

Step 3 
We also faced the jar conflict issue for a particular SOAP service and it started failing after going live. The stacktrace was like this
 Dec 07, 2017 1:24:02 AM com.sun.xml.ws.transport.http.HttpAdapter fixQuotesAroundSoapAction
INFO: Received WS-I BP non-conformant Unquoted SoapAction HTTP header: processMessage
Dec 07, 2017 1:24:02 AM com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit handle
SEVERE: com.sun.xml.ws.api.message.Message.getHeaders()Lcom/sun/xml/ws/api/message/HeaderList;
java.lang.NoSuchMethodError: com.sun.xml.ws.api.message.Message.getHeaders()Lcom/sun/xml/ws/api/message/HeaderList;
at org.apache.chemistry.opencmis.commons.impl.tube.server.WssTube.processResponse(WssTube.java:76)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1147)
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)
After carefully observing the logs we noticed that Weblogic 12c webservice related jars are causing the conflict when ever the SOAP service is invoked. We figured the path of the jar in weblogic and it is
Weblogic_Home/oracle_common/modules/com.oracle.webservices.wls.wls-ws-metainf-services-impl.jar
We removed this jar by renaming with .bak and then the conflict was resolved and the SOAP Service was working fine as was also the rest of the application. We had to resolve this on runtime after we went live with the application

 

Conclusion
Following the above steps we can deploy Backbase 5.6.4+ application on Weblogic 12c successfully. Weblogic 12c has many useful features and I recommend you to upgrade to weblogic 12c for the backbase application.

Leave a Reply

Your email address will not be published. Required fields are marked *