11 Replies Latest reply on Sep 27, 2008 5:34 AM by asoldano

    Deploying web services in service archive

    asoldano

      I've been looking at https://jira.jboss.org/jira/browse/JBWS-2246. As Adrew correctly pointed out, the problem here is that the jbossws deployer relies upon injection into beans declared in server//deploy/jbossws.sar/META-INF/jboss-beans.xml which of course are not available at startup till jbossws.sar itself is deployed.
      I'd say everything required for the deployment should go to server//deployers to solve this. But I'm wondering if leaving part of the beans involved in the deployment (mainly the stack specific ones) in the jbossws.sar was done on purpose for a reason I'm missing. Perhaps Thomas or Heiko can suggest here.

      I've done some tests, anyway, manually moving all the deploy stuff to server//deployers. The problem I see now with JSE endpoints in sar archives is that jbossws needs the classloader to instanciate classes that live in the generated webapp. To achieve this during the deployment the UnifiedMetaDataDeploymentAspect reads the the context classloader from the JBossWebMetaData. That classloader is previously set in the JBossWebMetaData by the TomcatDeployment, but of course that only happens after the jboss.web:service=WebServer is started (and that lives in server//deploy). So the problem in JBWS-2246 would stay, unless we find another solution for this too. Any suggestion?

        • 1. Re: Deploying web services in service archive
          heiko.braun

           


          the jbossws deployer relies upon injection into beans declared in server//deploy/jbossws.sar/META-INF/jboss-beans.xml


          Careful here. The deployers don't use injection, they use a service locator lookup to get to the jbossws runtime. The KernelLocator.class however (part of the runtime) uses injection and is initialized when jbossws.sar is deployed.

          So, the problem you encounter looks like a deployment ordering problem to me. Until jbossws.sar is fully initilaized, the WS deployers cannot do their job. The NPE could be read "JBossWS not initialized yet". Since both WS deployers and WS runtime have different scopes and classloaders you cannot easily put a dependency which prevents these errors. (deployers would depend on deployment)

          This is not a solution, but it should help getting there.



          • 2. Re: Deploying web services in service archive
            asoldano

             

            "heiko.braun@jboss.com" wrote:

            the jbossws deployer relies upon injection into beans declared in server//deploy/jbossws.sar/META-INF/jboss-beans.xml


            Careful here. The deployers don't use injection, they use a service locator lookup to get to the jbossws runtime. The KernelLocator.class however (part of the runtime) uses injection and is initialized when jbossws.sar is deployed.

            Yes, I expressed that not clearly, but that's what I meant.


            So, the problem you encounter looks like a deployment ordering problem to me. Until jbossws.sar is fully initilaized, the WS deployers cannot do their job. The NPE could be read "JBossWS not initialized yet".

            It's actually that problem.

            Since both WS deployers and WS runtime have different scopes and classloaders you cannot easily put a dependency which prevents these errors. (deployers would depend on deployment)

            Exactly, I can't and this would probably be against the as5 design. That's why I was thinking about having everything we need for deployment in server//deployers. So I'm wondering if doing this was evaluated in the past and not done for some reasons ;-)

            • 3. Re: Deploying web services in service archive
              anil.saldhana

              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142029
              is an example of why WS needs to rework the deployers (with the deployerhook concept) to align with the AS5 deployers.

              • 4. Re: Deploying web services in service archive
                heiko.braun

                 


                having everything we need for deployment in server//deployers.


                Hm, I don't know. Guess this is something you need to try. If I remember correctly the main reason for having it in 'deploy' is that you can remove/change it, whereas 'deployers' is more bare bone AS stuff that people shouldn't mess with.

                Maybe you take a look how others deal with it? I.e. EJB3?

                /Heiko

                • 5. Re: Deploying web services in service archive
                  asoldano

                   

                  "heiko.braun@jboss.com" wrote:

                  having everything we need for deployment in server//deployers.


                  Hm, I don't know. Guess this is something you need to try. If I remember correctly the main reason for having it in 'deploy' is that you can remove/change it, whereas 'deployers' is more bare bone AS stuff that people shouldn't mess with.

                  OK, actually I suspected that was somehow related to the stacks switch (having everything stack specific in 'deploy')


                  • 6. Re: Deploying web services in service archive
                    heiko.braun

                    I could as well imagine that the runtime dependencies (tomcat) cause problems when moving that stuff. I.e. when the WS deployer and runtime live under a different scope then the tomcat runtime you just move the problem around. You know what I mean?

                    • 7. Re: Deploying web services in service archive
                      asoldano

                       

                      "heiko.braun@jboss.com" wrote:
                      I could as well imagine that the runtime dependencies (tomcat) cause problems when moving that stuff. I.e. when the WS deployer and runtime live under a different scope then the tomcat runtime you just move the problem around. You know what I mean?


                      I think so; I guess you mean what I wrote at the beginning of the thread, i.e. we rely upon the generated webapp being deployed and started in tomcat, but that can only happen once the tomcat runtime is started too. Otherwise we don't have the right runtime classloader for JSE endpoints.

                      • 8. Re: Deploying web services in service archive
                        anil.saldhana

                        deployers - this dir will contain deployers that build/modify metadata that will go as part of the deployment unit. This can contain real deployers also.

                        deploy - this dir should contain beans etc that have nothing to do with metadata.

                        • 9. Re: Deploying web services in service archive
                          anil.saldhana
                          • 10. Re: Deploying web services in service archive
                            asoldano
                            • 11. Re: Deploying web services in service archive
                              asoldano

                               

                              we rely upon the webapp being deployed and started in tomcat, but that can only happen once the tomcat runtime is started too. Otherwise we don't have the right runtime classloader for JSE endpoints.


                              OK, besides the considerations upon the jbossws deployment design which can probably be improved (I'm posting to another thread on this soon), do you have any suggestion on this issue? Is actually possible to somehow wait for the webapp to be started? Maybe someone with better experience/knowledge on the AS5 design can help.
                              We need the ENCLoader from that webapp, otherwise we can't access the jndi enc context, as eventual lookups for java:comp/env will fail.