1 2 Previous Next 25 Replies Latest reply on Mar 6, 2006 1:08 AM by Jason Greene

    jbossws packaging/deployment

    Heiko Braun Novice

      I am almost done with eventing beta, the next step would be to package the eventing stuff with the jbossws archives. Eventing comes some soap endpoints, which should be deployed with the jbossws.war . Unfortunatly, the way it is now, when the war gets deployed inside the sar, the deployer doesn't pick up the webservices. It works when the war is deployed separately, i.e:

      deploy
       |_ jbossws.sar
       |_ jbossws.war
      


      I can picture three solutions to the problem:

      A,) Use the packaging structure mentioned above
      B,) Make the sar deployer pick up webservices from russian doll archives
      C,) Separately deploy eventing

      I would vote for option A.


        • 1. Re: jbossws packaging/deployment
          Thomas Diesler Master

          It should be like this

          deploy
           |_ jbossws.sar
           |_ jbossws.war
           |_ jbossws-eventing.war
           |_ jbossws-whatever.war
          


          Is this your option B? If it is, we need to create/fix the issue that does not pick up the endpoints.


          • 2. Re: jbossws packaging/deployment
            Thomas Diesler Master

            More generally, it should be possible to deploy WS endpoints along with with the WS service. Whether this can be done with *.war deployments or not is a secondary issue.

            • 4. Re: jbossws packaging/deployment
              Heiko Braun Novice

              Deploying webservices along with the service archive brings up a problem:

              The webservice deployment interceptors are attached to the subdeployers when the interceptor is started, but the deployment of bundeled artefacts (a war for instance) is actually invoked prior to that. At that time the deployer in charge isn't aware of the deployment interceptor.

              Any ideas how we can solve this?

              • 5. Re: jbossws packaging/deployment
                Thomas Diesler Master

                Have you tried the depends clause in jboss-web?

                • 6. Re: jbossws packaging/deployment
                  Heiko Braun Novice

                  The depends clause orders the deployment as expected, still the WebserviceDeployer is not invoked:

                  [...]
                  2006-02-09 10:44:20,943 DEBUG [org.jboss.ws.server.WebServiceDeployerJSE] Interceptor attached to: 'jboss.web:service=WebServer'
                  2006-02-09 10:44:20,943 DEBUG [org.jboss.ws.server.WebServiceDeployerJSE] Started jboss.ws:service=WebServiceDeployerJSE
                  2006-02-09 10:44:20,943 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.ws:service=WebServiceDeployerJSE dependent components: [ObjectName: jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
                   State: CREATED
                   I Depend On:
                   jboss.ws:service=WebServiceDeployerJSE
                  ]
                  
                  2006-02-09 10:44:20,943 DEBUG [org.jboss.system.ServiceController] starting service jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
                  2006-02-09 10:44:20,943 DEBUG [org.jboss.web.WebModule] Starting jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
                  [...]
                  2006-02-09 10:44:22,015 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jbossws-eventing]] Servlet /jbossws-eventing threw load() exception
                  java.lang.ClassCastException: org.jboss.ws.eventing.SubscriptionManagerEndpointImpl
                  


                  As you can see, the interceptor is now attached to the subdeployer prior to starting the deployment of the war file. Maybe the subdeployer has become stale due to some synchronization issues within the main deployer.

                  • 7. Re: jbossws packaging/deployment
                    Jason Greene Master

                    One approach that could work in the time being is to create a sub directory like so

                    server/default/deploy/jbossws/jbossws.sar
                    server/default/deploy/jbossws/jbossws-eventing.war

                    This would deploy the units together and in the proper order.

                    -Jason

                    • 9. Re: jbossws packaging/deployment
                      Scott Stark Master

                      I think we need to look into the real issue here as having to rely on fragile elements like subdirectories and proper naming to get things to work is not what we want. Can you create a jira issue in JBAS that highlights the dependency problem so Dimitris can look into it?

                      • 11. Re: jbossws packaging/deployment
                        Thomas Diesler Master

                        No, this is not the solution. We can already deploy the endpoint outside of the jbossws.sar.

                        * endpoint deployment together with the sar should be fixed

                        * eventually we should support mbean endoints, which should also work when packaged with jbossws.sar

                        • 12. Re: jbossws packaging/deployment
                          Dimitris Andreadis Master

                          So what happens is the following: We have (in HEAD)

                          jbossws.sar\
                          jbossws.jar
                          jbossws.war
                          jbossws-eventing.war
                          wsdl4j.jar
                          xmlsec.jar

                          WebServiceDeployerJSE was attaching its interceptor to the EJBDeployer during the startService() stage, so initialy I though this was the reason, the interceptor was missing the SubDeployer.create(DeploymentInfo) call to the tomcat deployer, for the jbossws-eventing.war.

                          So I changed WebServiceDeployerJSE (actually WebServiceDeployer) to attach the interceptor in the createService() stage. However, it still doesn't intercept the SubDeployer.create(DeploymentInfo) call.

                          The reason is that although jbossws-eventing.war "depends" on WebServiceDeployerJSE, the dependency is really the following:

                          jboss.web.deployment:war=jbossws-eventing.war,id=99026174 depends on jboss.ws:service=WebServiceDeployerJSE

                          This mbean is created during the Tomcat5 deployer create(DeploymenInfo -> jbossws-eventing.war) processing, so by the time WebServiceDeployerJSE.createService() is executed (and the interceptor gets registered) the call we want to intercept has already happened.

                          So the dependency won't solve the problem. Maybe jason's solution would work, but I didn't try it.

                          • 13. Re: jbossws packaging/deployment
                            Jason Greene Master

                             

                            "dimitris@jboss.org" wrote:
                            So what happens is the following: We have (in HEAD)

                            This mbean is created during the Tomcat5 deployer create(DeploymenInfo -> jbossws-eventing.war) processing, so by the time WebServiceDeployerJSE.createService() is executed (and the interceptor gets registered) the call we want to intercept has already happened.

                            So the dependency won't solve the problem. Maybe jason's solution would work, but I didn't try it.


                            The JBoss Portal WSRP implementation is affected by this very same problem because they deploy a war style webservice as a nested deployment in a sar file. So if the portal sar deploys before the jbossws sar file it can never succeed.

                            Was there a reason why we can't intercept the call to start instead of create? From the 2 minutes I spent looking through the code I can't see why this wouldn't work?

                            -Jason

                            • 14. Re: jbossws packaging/deployment
                              Dimitris Andreadis Master

                              We do intercept the call to start(DeploymentInfo).

                              If the WebServiceDeployerJSE *stuff* can be safely moved from the

                              protected Object create(Invocation invocation, DeploymentInfo di) throws Throwable

                              to the

                              protected Object start(Invocation invocation, DeploymentInfo di) throws Throwable

                              phase, I guess this would solve the problem.

                              1 2 Previous Next