Topic
  • 13 replies
  • Latest Post - ‏2012-04-19T09:11:53Z by Shawn_Jiang
SystemAdmin
SystemAdmin
2233 Posts

Pinned topic Deployment problem - JAX-WS WAR file on WAS CE 3.0

‏2011-11-29T03:22:50Z |
Hello

I had a similar issue w/ WAS CE 2.1 which appeared to get resolved w/ the proper Deployment plan (geronimo-web.xml) file added to the WAR file -- http://www.ibm.com/developerworks/forums/thread.jspa?threadID=219975
Now, trying the same thing w/ WAS CE 3.0, I continually get deployment failures with a similar WAR (containing a JAX-WS service endpoint) ... complaining that it can't locate the handler-chain configuration. Part of the stack trace at deployment time is:


2011-11-28 21:21:13,869 ERROR [Deployer] Deployment failed due to javax.xml.ws.WebServiceException: Chain not specified at org.apache.geronimo.jaxws.handler.AnnotationHandlerChainFinder.buildHandlerChainFromClass(AnnotationHandlerChainFinder.java:80) at org.apache.geronimo.jaxws.handler.AnnotationHandlerChainFinder.buildHandlerChainFromClass(AnnotationHandlerChainFinder.java:91) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverPOJOWebServices(AdvancedWARWebServiceFinder.java:120) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverWebServices(AdvancedWARWebServiceFinder.java:44) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverWebServices(AdvancedWARWebServiceFinder.java:37) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:51) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:28) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.discoverWebServices(JAXWSServiceBuilder.java:231)


However - it deploys/runs perfectly on a Tomcat 6 or 7 installation where I simply drop the WAR into the webapps folder of those Tomcat server installations. My WAR has all of the JAX-WS RI 2.2.5 jar files included in the /WEB-INF/lib location because I DON'T want to use Axis2 or CXF which appear to be the forced choices in WAS CE 3.0. With WAS CE 2.1, I was able to successfully deploy a similar WAR using a similar geronimo-web.xml file (added to the /WEB-INF location alongside the normal web.xml file): - this one is for CE 3.0...


<?xml version=
"1.0" encoding=
"UTF-8"?> <web-app xmlns=
"http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys=
"http://geronimo.apache.org/xml/ns/deployment-1.2" xmlns:name=
"http://geronimo.apache.org/xml/ns/naming-1.2" xmlns:app=
"http://geronimo.apache.org/xml/ns/j2ee/application-2.0" xmlns:sec=
"http://geronimo.apache.org/xml/ns/security-2.0" xmlns:jaspi=
"http://geronimo.apache.org/xml/ns/geronimo-jaspi" xmlns:pers=
"http://java.sun.com/xml/ns/persistence"> <dep:environment xmlns:dep=
"http://geronimo.apache.org/xml/ns/deployment-1.2"> <dep:moduleId> <dep:groupId>com.acme.book.webservices</dep:groupId> <dep:artifactId>PurchaseOrderServiceWS</dep:artifactId> <dep:version>3.0</dep:version> <dep:type>war</dep:type> </dep:moduleId> <dep:hidden-classes> <dep:filter>org.apache.axis2</dep:filter> <dep:filter>com.sun.xml</dep:filter> <dep:filter>javax.xml.bind</dep:filter> <dep:filter>javax.xml.ws</dep:filter> </dep:hidden-classes> </dep:environment> <context-root>/PurchaseOrderServiceWS</context-root> </web-app>


This was successfully suggested by those on the previous thread noted above - http://www.ibm.com/developerworks/forums/thread.jspa?threadID=219975. I then tried adding an additional package in the list of filters:

<dep:filter>org.apache.geronimo.jaxws.handler</dep:filter>


<?xml version=
"1.0" encoding=
"UTF-8"?> <web-app xmlns=
"http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys=
"http://geronimo.apache.org/xml/ns/deployment-1.2" xmlns:name=
"http://geronimo.apache.org/xml/ns/naming-1.2" xmlns:app=
"http://geronimo.apache.org/xml/ns/j2ee/application-2.0" xmlns:sec=
"http://geronimo.apache.org/xml/ns/security-2.0" xmlns:jaspi=
"http://geronimo.apache.org/xml/ns/geronimo-jaspi" xmlns:pers=
"http://java.sun.com/xml/ns/persistence"> <dep:environment xmlns:dep=
"http://geronimo.apache.org/xml/ns/deployment-1.2"> <dep:moduleId> <dep:groupId>com.acme.book.webservices</dep:groupId> <dep:artifactId>PurchaseOrderServiceWS</dep:artifactId> <dep:version>3.0</dep:version> <dep:type>war</dep:type> </dep:moduleId> <dep:hidden-classes> <dep:filter>org.apache.axis2</dep:filter> <dep:filter>org.apache.geronimo.jaxws.handler</dep:filter> <dep:filter>com.sun.xml</dep:filter> <dep:filter>javax.xml.bind</dep:filter> <dep:filter>javax.xml.ws</dep:filter> </dep:hidden-classes> </dep:environment> <context-root>/PurchaseOrderServiceWS</context-root> </web-app>


However, it still does not work and continues to throw the exception upon deployment. I made sure that the handler-chain.xml file is in the same package as the @WebService-annotated class containing the @HandlerChain annotation and as I noted, it all works fine on plain Tomcat server.

Perhaps I am misunderstanding how this is supposed to work. If I am providing JAR files in my WAR (WEB-INF/lib)...should these dep:filter entries be used to block such packages from the PARENT stack? At least that is what I thought.

Any insight would be appreciated.

Thanks in advance.
Updated on 2012-04-19T09:11:53Z at 2012-04-19T09:11:53Z by Shawn_Jiang
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-05T01:26:10Z  
    After hours of repeated attempts including using the "inverse-classloading" element in the geronimo-web.xml to force the classloading to use /WEB-INF/lib content first, nothing has yet worked. It's now to the point where WAS CE 3.0 is becoming a case of "not an option" for what we are doing.

    Between the deployment failures for a simple JAX-WS WAR and/or having the Administrative Console lock up with "connection reset",

    javax.servlet.ServletException: javax.portlet.PortletException: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Read timed out
    org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:141)

    perhaps it's time to look for a different product. This has been disappointing.
  • Ivan.Xu
    Ivan.Xu
    14 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-07T06:34:41Z  
    After hours of repeated attempts including using the "inverse-classloading" element in the geronimo-web.xml to force the classloading to use /WEB-INF/lib content first, nothing has yet worked. It's now to the point where WAS CE 3.0 is becoming a case of "not an option" for what we are doing.

    Between the deployment failures for a simple JAX-WS WAR and/or having the Administrative Console lock up with "connection reset",

    javax.servlet.ServletException: javax.portlet.PortletException: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Read timed out
    org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:141)

    perhaps it's time to look for a different product. This has been disappointing.
    could you attach your sample application somewhere if there is no confidential info in it, I would like to try it on CE 3.0.
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-09T02:21:57Z  
    • Ivan.Xu
    • ‏2011-12-07T06:34:41Z
    could you attach your sample application somewhere if there is no confidential info in it, I would like to try it on CE 3.0.
    I will upload the WAR file but you will need to copy the JARs into the /WEB-INF/lib of that WAR file from the zip download at this http://jax-ws.java.net/2.2.5/ :

    I just deployed and started the exact same WAR on Tomcat 7.0.22:

    Dec 8, 2011 8:42:30 PM org.apache.catalina.core.AprLifecycleListener init
    INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Java\jdk1.6.0_29\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;<REMOVED NUMEROUS DIRECTORIES ON PATH>;C:\EclipseIndigo_2011_SR1\eclipse;;.
    Dec 8, 2011 8:42:32 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
    WARNING: SetPropertiesRule{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:PurchaseOrderServiceWS' did not find a matching property.
    Dec 8, 2011 8:42:33 PM org.apache.coyote.AbstractProtocol init
    INFO: Initializing ProtocolHandler
    Dec 8, 2011 8:42:33 PM org.apache.coyote.AbstractProtocol init
    INFO: Initializing ProtocolHandler
    Dec 8, 2011 8:42:33 PM org.apache.catalina.startup.Catalina load
    INFO: Initialization processed in 3641 ms
    Dec 8, 2011 8:42:33 PM org.apache.catalina.core.StandardService startInternal
    INFO: Starting service Catalina
    Dec 8, 2011 8:42:33 PM org.apache.catalina.core.StandardEngine startInternal
    INFO: Starting Servlet Engine: Apache Tomcat/7.0.22
    Dec 8, 2011 8:42:34 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom
    INFO: Creation of SecureRandom instance for session ID generation using SHA1PRNG took 181 milliseconds.
    Dec 8, 2011 8:42:34 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
    INFO: WSSERVLET12: JAX-WS context listener initializing
    log4j: reset attribute= "false".
    log4j: Threshold ="null".
    log4j: Level value for root is TRACE.
    log4j: root level set to TRACE
    log4j: Class name: http://org.apache.log4j.AsyncAppender
    log4j: Attaching appender named FileOut to appender named ASYNC.
    log4j: Class name: http://org.apache.log4j.DailyRollingFileAppender
    log4j: Setting property file to http://applogs/PurchaseOrderServiceWS.log.
    log4j: Setting property datePattern to .
    log4j: Setting property append to true.
    log4j: Setting property threshold to ALL.
    log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
    log4j: Setting property conversionPattern to [%d %-5p - TXID: %X{TXID} UID: %X{UID} ORGOID: %X{ORGOID} AOID: %X{AOID}] - %m%n.
    log4j: setFile called: applogs/PurchaseOrderServiceWS.log, true
    log4j: setFile ended
    log4j: Appender FileOut to be rolled at midnight.
    log4j: Adding appender named ASYNC to category root.
    Dec 8, 2011 8:42:36 PM com.sun.xml.ws.transport.http.servlet.WSServletDelegate <init>
    INFO: WSSERVLET14: JAX-WS servlet initializing
    Dec 8, 2011 8:42:36 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler
    Dec 8, 2011 8:42:37 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler
    Dec 8, 2011 8:42:37 PM org.apache.catalina.startup.Catalina start
    INFO: Server startup in 3489 ms

    Checking that it is up and running...(HTML markup removed)

    Web Services
    Endpoint Information
    Service Name: {http://webservices.book.acme.com/}BookOrderManagerService
    Port Name: {http://webservices.book.acme.com/}BookOrderManagerServicePort

    Address: http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService
    WSDL: http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService?wsdl
    Implementation class: com.acme.book.webservices.BookOrderManagerWS
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-09T02:47:40Z  
    I will upload the WAR file but you will need to copy the JARs into the /WEB-INF/lib of that WAR file from the zip download at this http://jax-ws.java.net/2.2.5/ :

    I just deployed and started the exact same WAR on Tomcat 7.0.22:

    Dec 8, 2011 8:42:30 PM org.apache.catalina.core.AprLifecycleListener init
    INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Java\jdk1.6.0_29\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;<REMOVED NUMEROUS DIRECTORIES ON PATH>;C:\EclipseIndigo_2011_SR1\eclipse;;.
    Dec 8, 2011 8:42:32 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
    WARNING: SetPropertiesRule{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:PurchaseOrderServiceWS' did not find a matching property.
    Dec 8, 2011 8:42:33 PM org.apache.coyote.AbstractProtocol init
    INFO: Initializing ProtocolHandler
    Dec 8, 2011 8:42:33 PM org.apache.coyote.AbstractProtocol init
    INFO: Initializing ProtocolHandler
    Dec 8, 2011 8:42:33 PM org.apache.catalina.startup.Catalina load
    INFO: Initialization processed in 3641 ms
    Dec 8, 2011 8:42:33 PM org.apache.catalina.core.StandardService startInternal
    INFO: Starting service Catalina
    Dec 8, 2011 8:42:33 PM org.apache.catalina.core.StandardEngine startInternal
    INFO: Starting Servlet Engine: Apache Tomcat/7.0.22
    Dec 8, 2011 8:42:34 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom
    INFO: Creation of SecureRandom instance for session ID generation using SHA1PRNG took 181 milliseconds.
    Dec 8, 2011 8:42:34 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
    INFO: WSSERVLET12: JAX-WS context listener initializing
    log4j: reset attribute= "false".
    log4j: Threshold ="null".
    log4j: Level value for root is TRACE.
    log4j: root level set to TRACE
    log4j: Class name: http://org.apache.log4j.AsyncAppender
    log4j: Attaching appender named FileOut to appender named ASYNC.
    log4j: Class name: http://org.apache.log4j.DailyRollingFileAppender
    log4j: Setting property file to http://applogs/PurchaseOrderServiceWS.log.
    log4j: Setting property datePattern to .
    log4j: Setting property append to true.
    log4j: Setting property threshold to ALL.
    log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
    log4j: Setting property conversionPattern to [%d %-5p - TXID: %X{TXID} UID: %X{UID} ORGOID: %X{ORGOID} AOID: %X{AOID}] - %m%n.
    log4j: setFile called: applogs/PurchaseOrderServiceWS.log, true
    log4j: setFile ended
    log4j: Appender FileOut to be rolled at midnight.
    log4j: Adding appender named ASYNC to category root.
    Dec 8, 2011 8:42:36 PM com.sun.xml.ws.transport.http.servlet.WSServletDelegate <init>
    INFO: WSSERVLET14: JAX-WS servlet initializing
    Dec 8, 2011 8:42:36 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler
    Dec 8, 2011 8:42:37 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler
    Dec 8, 2011 8:42:37 PM org.apache.catalina.startup.Catalina start
    INFO: Server startup in 3489 ms

    Checking that it is up and running...(HTML markup removed)

    Web Services
    Endpoint Information
    Service Name: {http://webservices.book.acme.com/}BookOrderManagerService
    Port Name: {http://webservices.book.acme.com/}BookOrderManagerServicePort

    Address: http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService
    WSDL: http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService?wsdl
    Implementation class: com.acme.book.webservices.BookOrderManagerWS
    The attached WAR has the source, compiled classes but does not have all the JAR files from the JAX-WS RI 2.2.5 distribution for obvious size reasons. These need to be put into the /WEB-INF/lib location of the WAR. That is how it was deployed to Tomcat and how am I trying to deploy to WAS CE.
  • Ivan.Xu
    Ivan.Xu
    14 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-12T04:13:16Z  
    The attached WAR has the source, compiled classes but does not have all the JAR files from the JAX-WS RI 2.2.5 distribution for obvious size reasons. These need to be put into the /WEB-INF/lib location of the WAR. That is how it was deployed to Tomcat and how am I trying to deploy to WAS CE.
    Just try your sample, the following steps seems to work for me :
    a. Execute the command before starting CE 3.0 : set GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true , need to use export if working on Linux. The configuration is to force CE 3.0 only checks whether there is POJO classes in web.xml, considering that all the SEI configurations are in sun-jaxws.xml file, this is somewhat workaround to ask CE not to process web service for the deployed application.
    b. Remove the inverse-classloading in the geronimo-web.xml.

    The application could be deployed succesfully, and could access http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService?WSDL for the WSDL work. Think that the application should be initialized.
    One thing to be noticed is that, now the deployed application uses the shipped jaxb impl/api, jaxws api, saaj api/impl etc. Could use some hidden-class or import-package to force to use the ones from the application, while I would suggest to leave it there except for there is really issue for that. From the best practice side, it is good to always use the sample spec API from server.
    If any other problem, please feel free to post it here.
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2011-12-13T21:35:10Z  
    • Ivan.Xu
    • ‏2011-12-12T04:13:16Z
    Just try your sample, the following steps seems to work for me :
    a. Execute the command before starting CE 3.0 : set GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true , need to use export if working on Linux. The configuration is to force CE 3.0 only checks whether there is POJO classes in web.xml, considering that all the SEI configurations are in sun-jaxws.xml file, this is somewhat workaround to ask CE not to process web service for the deployed application.
    b. Remove the inverse-classloading in the geronimo-web.xml.

    The application could be deployed succesfully, and could access http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService?WSDL for the WSDL work. Think that the application should be initialized.
    One thing to be noticed is that, now the deployed application uses the shipped jaxb impl/api, jaxws api, saaj api/impl etc. Could use some hidden-class or import-package to force to use the ones from the application, while I would suggest to leave it there except for there is really issue for that. From the best practice side, it is good to always use the sample spec API from server.
    If any other problem, please feel free to post it here.
    Ivan

    Thank you very much for the reply. It seems your 2 points (a. and b.) did the trick:

    • I installed the Eclipse plug-in for WAS CE 3.0, in addition to installing the server distribution from IBM itself on the file system.
    • I started the server from the Server View (tab) and then opened the Admin Console - I did alter the VM arguments in the Server Configuration dialog in Eclipse (using Indigo) for this WAS CE 3.0 server, to add the one item in bold:
    -javaagent:"$(GERONIMO_HOME)/lib/agent/transformer.jar" -Djava.ext.dirs="$(GERONIMO_HOME)/lib/ext;$(JRE_HOME)/lib/ext" -Djava.endorsed.dirs="$(GERONIMO_HOME)/lib/endorsed;$(JRE_HOME)/lib/endorsed" -Xms256m -Xmx512m -XX:MaxPermSize=128m -Dorg.apache.geronimo.home.dir="$(GERONIMO_HOME)" -Dkaraf.home="$(GERONIMO_HOME)" -Dkaraf.base="$(GERONIMO_HOME)" -Djava.util.logging.config.file="$(GERONIMO_HOME)/etc/java.util.logging.properties" -Dkaraf.startLocalConsole=false -Dkaraf.startRemoteShell=false -Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true

    • Rather than add the "project" to the server in the IDE, I ran my Ant script, let it generate the WAR file w/ the modified geronimo-web.xml file and placed it in a temp location.
    • I then used the Admin Console to install the WAR (from that temp location) like any other WAR on the running server and .... IT WORKED :-) .

    The output of the WAR install and start-up is below. I was able to browse to the Web Services page (and WSDL) as you did below....

    
    2011-12-13 16:12:05,545 INFO  [SupportedModesServiceImpl] Portlet mode 
    'edit' not found 
    
    for portletId: 
    'plugin.Deployment!-2135677113|0' 2011-12-13 16:13:37,088 INFO  [Parameters] Parameters: Invalid chunk 
    '' ignored. 2011-12-13 16:14:30,894 INFO  [DeploymentContext] The Lenient Manifest Classpath processing mode is in effect. This option can be altered by specifying -DXorg.apache.geronimo.deployment.LenientMFCP=true|
    
    false Specify =
    "true" 
    
    for more lenient processing such as ignoring missing jars and references that are not spec compliant. 2011-12-13 16:15:17,802 INFO  [KernelContextGBean] bound gbean com.acme.book.webservices/PurchaseOrderServiceWS/3.0/war?J2EEApplication=null,WebModule=com.acme.book.webservices/PurchaseOrderServiceWS/3.0/war,j2eeType=ValidatorFactory,name=ValidatorFactory at name jca:/com.acme.book.webservices/PurchaseOrderServiceWS/ValidatorFactory/ValidatorFactory 2011-12-13 16:15:35,214 INFO  [OpenEJBLifecycle] OpenWebBeans Container is starting... 2011-12-13 16:15:35,214 INFO  [PluginLoader] Adding OpenWebBeansPlugin : [CdiPlugin] 2011-12-13 16:15:35,215 INFO  [PluginLoader] Adding OpenWebBeansPlugin : [GeronimoWebBeansPlugin] 2011-12-13 16:15:36,390 INFO  [BeansDeployer] All injection points were validated successfully. 2011-12-13 16:15:36,390 INFO  [OpenEJBLifecycle] OpenWebBeans Container has started, it took [1176] ms. 2011-12-13 16:15:37,660 INFO  [http] WSSERVLET14: JAX-WS servlet initializing 2011-12-13 16:15:37,663 INFO  [http] WSSERVLET12: JAX-WS context listener initializing 2011-12-13 16:15:37,663 INFO  [http] WSSERVLET12: JAX-WS context listener initializing 2011-12-13 16:15:37,742 INFO  [SupportedModesServiceImpl] Portlet mode 
    'edit' not found 
    
    for portletId: 
    'plugin.Deployment!-2135677113|0'
    

    Content of the geronimo-web.xml now simply just has:

    
    <?xml version=
    "1.0" encoding=
    "UTF-8"?> <web-app xmlns=
    "http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"> <dep:environment xmlns:dep=
    "http://geronimo.apache.org/xml/ns/deployment-1.2"> <dep:moduleId> <dep:groupId>com.acme.book.webservices</dep:groupId> <dep:artifactId>PurchaseOrderServiceWS</dep:artifactId> <dep:version>3.0</dep:version> <dep:type>war</dep:type> </dep:moduleId> <dep:dependencies/> </dep:environment> <context-root>/PurchaseOrderServiceWS</context-root> </web-app>
    
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0 (added JAX-RS class)

    ‏2012-01-24T23:22:36Z  
    • Ivan.Xu
    • ‏2011-12-12T04:13:16Z
    Just try your sample, the following steps seems to work for me :
    a. Execute the command before starting CE 3.0 : set GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true , need to use export if working on Linux. The configuration is to force CE 3.0 only checks whether there is POJO classes in web.xml, considering that all the SEI configurations are in sun-jaxws.xml file, this is somewhat workaround to ask CE not to process web service for the deployed application.
    b. Remove the inverse-classloading in the geronimo-web.xml.

    The application could be deployed succesfully, and could access http://localhost:8080/PurchaseOrderServiceWS/BookOrderManagerService?WSDL for the WSDL work. Think that the application should be initialized.
    One thing to be noticed is that, now the deployed application uses the shipped jaxb impl/api, jaxws api, saaj api/impl etc. Could use some hidden-class or import-package to force to use the ones from the application, while I would suggest to leave it there except for there is really issue for that. From the best practice side, it is good to always use the sample spec API from server.
    If any other problem, please feel free to post it here.
    Hi Ivan

    New updated question on same issue but different condition. We have repackaged the WAR, this time to carry the CXF libraries instead of the JAX-WS RI (Metro libs). In that WAR is also now a JAX-RS annotated (REST) endpoint class along with the original JAX-WS endpoint class. Start-up occurs OK until it hits that JAX-RS annotated class where it starts throwing exceptions related to Apache Wink (and we don't want to use that)...

    Caused by: java.lang.ClassCastException: class javax.ws.rs.core.Application at java.lang.Class.asSubclass(Class.java:3018) at org.apache.geronimo.wink.deployment.WinkModuleBuilderExtension.initContext(WinkModuleBuilderExtension.java:174)

    Is there a similar override (as you described for the JAX-WS case) to force it to NOT use Wink (the CXF implementation we are using provides both JAX-WS and JAX-RS support that we need).

    Any advice would be appreciated.

    Thanks

    Mark
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0 (added JAX-RS class)

    ‏2012-01-25T14:44:00Z  
    Hi Ivan

    New updated question on same issue but different condition. We have repackaged the WAR, this time to carry the CXF libraries instead of the JAX-WS RI (Metro libs). In that WAR is also now a JAX-RS annotated (REST) endpoint class along with the original JAX-WS endpoint class. Start-up occurs OK until it hits that JAX-RS annotated class where it starts throwing exceptions related to Apache Wink (and we don't want to use that)...

    Caused by: java.lang.ClassCastException: class javax.ws.rs.core.Application at java.lang.Class.asSubclass(Class.java:3018) at org.apache.geronimo.wink.deployment.WinkModuleBuilderExtension.initContext(WinkModuleBuilderExtension.java:174)

    Is there a similar override (as you described for the JAX-WS case) to force it to NOT use Wink (the CXF implementation we are using provides both JAX-WS and JAX-RS support that we need).

    Any advice would be appreciated.

    Thanks

    Mark
    Update:

    We found the following thread http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14701752 which discusses disabling Wink by setting load="false" on the entries in the /var/config/config.xml file:

    <module load="false" name="org.apache.geronimo.configs/wink/3.0-w20110721/car"/>
    <module load="false" name="org.apache.geronimo.configs/wink-deployer/3.0-w20110721/car"/>

    Doing this allowed the WAR file to deploy successfully. However, it fails to start up with numerous exceptions relating to Spring problems (perhaps a classloader issue?).

    The WAR contains all the necessary CXF related JAR files in its /WEB-INF/lib and the exact SAME WAR deploys and runs flawlessly on Tomcat 7 - both JAX-WS and JAX-RS endpoints respond correctly.

    Portion only of stacktrace as it was huge:
    2012-01-24 23:20:42,575 INFO DeploymentContext The Lenient Manifest Classpath processing mode is in effect.
    This option can be altered by specifying -DXorg.apache.geronimo.deployment.LenientMFCP=true|false
    Specify ="true" for more lenient processing such as ignoring missing jars and references that are not spec compliant.
    2012-01-24 23:22:45,541 INFO KernelContextGBean bound gbean com.acme.book.webservices/BookOrderManagerWS/3.0/war?J2EEApplication=null,WebModule=com.acme.book.webservices/BookOrderManagerWS/3.0/war,j2eeType=ValidatorFactory,name=ValidatorFactory at name jca:/com.acme.book.webservices/BookOrderManagerWS/ValidatorFactory/ValidatorFactory
    2012-01-24 23:23:44,775 INFO OpenEJBLifecycle OpenWebBeans Container is starting...
    2012-01-24 23:23:44,775 INFO PluginLoader Adding OpenWebBeansPlugin : CdiPlugin
    2012-01-24 23:23:44,775 INFO PluginLoader Adding OpenWebBeansPlugin : GeronimoWebBeansPlugin
    2012-01-24 23:23:45,931 INFO BeansDeployer All injection points were validated successfully.
    2012-01-24 23:23:45,931 INFO OpenEJBLifecycle OpenWebBeans Container has started, it took 1156 ms.
    2012-01-24 23:23:46,027 INFO ContextLoader Root WebApplicationContext: initialization started
    2012-01-24 23:23:46,058 INFO XmlWebApplicationContext Refreshing Root WebApplicationContext: startup date Tue Jan 24 23:23:46 EST 2012; root of context hierarchy
    2012-01-24 23:23:46,120 INFO XmlBeanDefinitionReader Loading XML bean definitions from ServletContext resource [/WEB-INF/cxf-beans.xml]
    2012-01-24 23:23:46,151 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf.xml
    2012-01-24 23:23:46,167 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf-extension-soap.xml
    2012-01-24 23:23:46,183 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf-servlet.xml
    2012-01-24 23:23:46,385 INFO DefaultListableBeanFactory Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1ea248f: defining beans http://cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,jsonProvider,bookService,bookordermanagerws,bookServiceRS; root of factory hierarchy
    2012-01-24 23:23:47,384 INFO ServerImpl Setting the server's publish address to be /RS
    2012-01-24 23:23:47,494 INFO ReflectionServiceFactoryBean Creating Service {http://webservices.book.acme.com/}BookOrderManagerService from WSDL: wsdl/BookOrderManagerService.wsdl
    2012-01-24 23:23:47,603 INFO DefaultListableBeanFactory Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1ea248f: defining beans http://cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,jsonProvider,bookService,bookordermanagerws,bookServiceRS; root of factory hierarchy
    2012-01-24 23:23:47,603 INFO XmlWebApplicationContext Closing Root WebApplicationContext: startup date Tue Jan 24 23:23:46 EST 2012; root of context hierarchy
    2012-01-24 23:23:47,603 WARN XmlWebApplicationContext Exception thrown from ApplicationListener handling ContextClosedEvent
    org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'cxf': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:209)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:196)
    at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:148)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:86)
    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
    at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1007)
    at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:970)
    at org.apache.cxf.bus.spring.SpringBus.destroyBeans(SpringBus.java:131)
    at org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:217)

    ...
    ...
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2012-01-25T14:45:39Z  
    added new question relating to same application but with a configuration change due to added JAX-RS functionality
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2012-01-26T05:07:33Z  
    I may not get enough message from the paste exception message, it looks to me that it is not the root cause, could you attach the log file ?
  • SystemAdmin
    SystemAdmin
    2233 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2012-01-26T12:43:49Z  
    As requested by Ivan... server.log is attached.

    Attachments

  • Ivan.Xu
    Ivan.Xu
    14 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0

    ‏2012-01-28T06:21:25Z  
    I used the example JavaFirstSpringSupport.war with the CXF build, and could reproduce this error. After debuging a bit, it looks to me that it may be a defect in Tomcat, and have sent an email to Tomcat community to double check it. Before that, you could try the solution below :
    a. Move the cxf-servlet.xml to WEB-INF/classes directory, and add the configuration below in the web.xml, depending on which is used to initliaze the cxf engine, you need to add it to the correct place. The sample I tried is to use servlet, the stack showed in your log is to use a listener.
    <init-param>
    <param-name>config-location</param-name>
    <param-value>classpath:cxf-servlet.xml</param-value>
    </init-param>
    b. create a geronimo-web.xml, and add a filter below, this will force to use the xmlschema versions shipped in the application. As the one in server is older than the one in CXF 2.5.*.
    <dep:hidden-classes>
    <dep:filter>org.apache.ws.commons.schema*</dep:filter>
    </dep:hidden-classes>
    Hope it helps.
  • Shawn_Jiang
    Shawn_Jiang
    154 Posts

    Re: Deployment problem - JAX-WS WAR file on WAS CE 3.0 (added JAX-RS class)

    ‏2012-04-19T09:11:53Z  
    Update:

    We found the following thread http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14701752 which discusses disabling Wink by setting load="false" on the entries in the /var/config/config.xml file:

    <module load="false" name="org.apache.geronimo.configs/wink/3.0-w20110721/car"/>
    <module load="false" name="org.apache.geronimo.configs/wink-deployer/3.0-w20110721/car"/>

    Doing this allowed the WAR file to deploy successfully. However, it fails to start up with numerous exceptions relating to Spring problems (perhaps a classloader issue?).

    The WAR contains all the necessary CXF related JAR files in its /WEB-INF/lib and the exact SAME WAR deploys and runs flawlessly on Tomcat 7 - both JAX-WS and JAX-RS endpoints respond correctly.

    Portion only of stacktrace as it was huge:
    2012-01-24 23:20:42,575 INFO DeploymentContext The Lenient Manifest Classpath processing mode is in effect.
    This option can be altered by specifying -DXorg.apache.geronimo.deployment.LenientMFCP=true|false
    Specify ="true" for more lenient processing such as ignoring missing jars and references that are not spec compliant.
    2012-01-24 23:22:45,541 INFO KernelContextGBean bound gbean com.acme.book.webservices/BookOrderManagerWS/3.0/war?J2EEApplication=null,WebModule=com.acme.book.webservices/BookOrderManagerWS/3.0/war,j2eeType=ValidatorFactory,name=ValidatorFactory at name jca:/com.acme.book.webservices/BookOrderManagerWS/ValidatorFactory/ValidatorFactory
    2012-01-24 23:23:44,775 INFO OpenEJBLifecycle OpenWebBeans Container is starting...
    2012-01-24 23:23:44,775 INFO PluginLoader Adding OpenWebBeansPlugin : CdiPlugin
    2012-01-24 23:23:44,775 INFO PluginLoader Adding OpenWebBeansPlugin : GeronimoWebBeansPlugin
    2012-01-24 23:23:45,931 INFO BeansDeployer All injection points were validated successfully.
    2012-01-24 23:23:45,931 INFO OpenEJBLifecycle OpenWebBeans Container has started, it took 1156 ms.
    2012-01-24 23:23:46,027 INFO ContextLoader Root WebApplicationContext: initialization started
    2012-01-24 23:23:46,058 INFO XmlWebApplicationContext Refreshing Root WebApplicationContext: startup date Tue Jan 24 23:23:46 EST 2012; root of context hierarchy
    2012-01-24 23:23:46,120 INFO XmlBeanDefinitionReader Loading XML bean definitions from ServletContext resource [/WEB-INF/cxf-beans.xml]
    2012-01-24 23:23:46,151 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf.xml
    2012-01-24 23:23:46,167 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf-extension-soap.xml
    2012-01-24 23:23:46,183 INFO XmlBeanDefinitionReader Loading XML bean definitions from class path resource http://META-INF/cxf/cxf-servlet.xml
    2012-01-24 23:23:46,385 INFO DefaultListableBeanFactory Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1ea248f: defining beans http://cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,jsonProvider,bookService,bookordermanagerws,bookServiceRS; root of factory hierarchy
    2012-01-24 23:23:47,384 INFO ServerImpl Setting the server's publish address to be /RS
    2012-01-24 23:23:47,494 INFO ReflectionServiceFactoryBean Creating Service {http://webservices.book.acme.com/}BookOrderManagerService from WSDL: wsdl/BookOrderManagerService.wsdl
    2012-01-24 23:23:47,603 INFO DefaultListableBeanFactory Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1ea248f: defining beans http://cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,jsonProvider,bookService,bookordermanagerws,bookServiceRS; root of factory hierarchy
    2012-01-24 23:23:47,603 INFO XmlWebApplicationContext Closing Root WebApplicationContext: startup date Tue Jan 24 23:23:46 EST 2012; root of context hierarchy
    2012-01-24 23:23:47,603 WARN XmlWebApplicationContext Exception thrown from ApplicationListener handling ContextClosedEvent
    org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'cxf': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:209)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:196)
    at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:148)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:86)
    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
    at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1007)
    at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:970)
    at org.apache.cxf.bus.spring.SpringBus.destroyBeans(SpringBus.java:131)
    at org.apache.cxf.bus.CXFBusImpl.shutdown(CXFBusImpl.java:217)

    ...
    ...
    Hi MCS,

    Are you still experiencing the same issue when running war with added JAX-RS class ? From your description, you are using CXF lib in your war as the jaxws and jaxrs impl instead of using the jaxws/jaxrs function provided by WASCE itself. In this case, a common best practice would be disable the jaxws and jaxrs functions in CE so that they don't kick in to leave things to CXF to handle.

    There are suggestion to disable the jaxws and wink module in config.xml before, but with a new feature "disabling specific deployers using system properties" [1] introduced in WASCE 3.0.0.1, you can use system properties to disable these function easily.

    Take your case as an example, you might want to disable built-in jaxws and jaxrs builder in WASCE 3.0.0.1 with following steps.

    1, export GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.support=false -Dorg.apache.geronimo.jaxrs.support=false
    2, start WASCE.
    3, deploy your CXF based application.

    This way, WASCE will leave all the jaxws and jaxrs bootstrap to CXF. It will be much easier to bypass most of your current issues. After that, you might need use import-package (import-package plus ! is recommended against hidden-classes) in your geornimo-web.xml to resolve some remaining class conflict based on what you have in your WEB-INF/lib.

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1">
    <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
    <dep:moduleId>
    <dep:groupId>com.yours</dep:groupId>
    <dep:artifactId>webapp</dep:artifactId>
    <dep:version>1.0</dep:version>
    <dep:type>war</dep:type>
    </dep:moduleId>
    <dep:dependencies/>
    *<import-package>!org.apache.ws.commons.schema*</import-package>*
    </dep:environment>
    <context-root>/app</context-root>
    </web-app>

    Please tell me if you still have problems with the instructions above.

    [1]http://publib.boulder.ibm.com/wasce/V3.0.0/en/disabling-specific-deployers-using-system-properties.html