1 2 Previous Next 16 Replies Latest reply on Mar 7, 2006 1:01 PM by starksm64

    Service endpoints nested in *.sar

    thomas.diesler

      This thread is related to

      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=75989

      The issue is that WS endpoint deployment depends on interceptors attached to their respective deployers. The interceptors themselves are attached when the the mbean is jbossws.sar are created.

      This of course is too late for any endpoints that are nested in any service archive (sar).

      i.e. A sar may contain a war which constitues a WS endpoint. The tomcat deployer picks up this war without having the WS interceptor attached. Result is that the WS endpoint is not deployed.

      Generally, I believe we need an approach like this

      #1 all interceptors attach to their respective deployers

      #2 the deployers start picking up their respective deployments

      To work arround this I invented a *.jse deployment, which is just a renamed *.war and created an associated deployer that picks up the *.jse deployment AFTER the WS interceptors are attached.

      Jason, provided another solution which IMHO exploits implementation details of the current arcitecture and is not a general solution to the problem.

      Dimitris, Scott could you please comment on this?

        • 1. Re: Service endpoints nested in *.sar
          thomas.diesler


          IMHO a possible solution would be to declare the WS interceptor on the target deployer and suspend the deployer until all its declared interceptors are attached.

          This is equivalent to saying: A deployer should not commence its operation until it is fully configured (i.e. all interceptors are attached)

          • 2. Re: Service endpoints nested in *.sar
            jason.greene

             

            "thomas.diesler@jboss.com" wrote:
            This thread is related to

            http://www.jboss.org/index.html?module=bb&op=viewtopic&t=75989

            The issue is that WS endpoint deployment depends on interceptors attached to their respective deployers. The interceptors themselves are attached when the the mbean is jbossws.sar are created.

            This of course is too late for any endpoints that are nested in any service archive (sar).

            i.e. A sar may contain a war which constitues a WS endpoint. The tomcat deployer picks up this war without having the WS interceptor attached. Result is that the WS endpoint is not deployed.


            There are actually 3 separate problems:

            1. Interceptors being attached in time for the deployment - This is solved by moving everything to start(), and requiring a dependency in the deployment, which is what I implemented.
            2. Dependencies breaking a deployer - We have a need to do operations that have to happen AFTER the deployment is started. This is because we need the tomcat classloader. You can't do this in an interceptor on AbstractWebContainer, because the deployment is really started in a separate mbean, WebModule. WebModule is generated from AbstractWebContainer, so it can't be intercepted without modifying AbstractWebContainer to allow for an interceptor stack on it.
            3. WAR deployment, init() phase, which was never intercepted, predating the WS deployer startup - The WAR deployer needs to somehow know that a deployment is a WS deployment without the WS deployer being active. This is because there is a war unpacking phase that is critical to WS deployments.



              To work arround this I invented a *.jse deployment, which is just a renamed *.war and created an associated deployer that picks up the *.jse deployment AFTER the WS interceptors are attached.


              This solves 1, 2 and 3 for jse deployements. A top level war deployment and a nested war deployment still suffer from 2 and 3.


              Jason, provided another solution which IMHO exploits implementation details of the current arcitecture and is not a general solution to the problem.


              My solution solves 1 and 2 for all deployments, but not 3. I don?t see how I relied on implementation details. The notification mechanism I used to solve problem 2 uses:


              1. Constant keys that are publicly exposed from AbstractWebDeployer
              2. ServiceContollers public notification interface, and documented notification events
              3. The public deployer info object


                I would have preferred to have an interceptor, but that isn?t currently possible as I explained in the problem 2 description. While the use of notifications may seem odd, the way in which they are used should be very close to the same performance that an interceptor would give you.

                If an interceptor based solution became available, it would be trivial to switch to it.

                The solution to problem 3 involves changing the AbstractWebContainer.init() to identify a WS deployment instead of looking for the WS deployer. This is already partially done because it looks for webservices.xml. My suggested solution I brought up in another thread is to look at every servlet class, and if the class does not implement javax.servlet.Servlet, it is most likely a ws deployment.

                -Jason



            • 3. Re: Service endpoints nested in *.sar
              jason.greene

               

              "thomas.diesler@jboss.com" wrote:

              IMHO a possible solution would be to declare the WS interceptor on the target deployer and suspend the deployer until all its declared interceptors are attached.

              This is equivalent to saying: A deployer should not commence its operation until it is fully configured (i.e. all interceptors are attached)


              This would not solve problems 2 and 3 (descriptions in my previous comment).

              An example of problem 2 is foo1-ws.war depends on foo2.war, and the following deployment order occur:

              jbossws.sar
              foo1-ws.war <--------- failure in start() interceptor (its not yet really started, so no tc classloader is available)
              foo2.war


              An example of problem 3:

              foo1-ws.war <----------- failure, jbossws not yet started
              jbossws.sar

              -Jason

              • 4. Re: Service endpoints nested in *.sar
                jason.greene

                What if we move everything in ServiceEndpoint.start() into the servlet init() method? This would remove the need for the tc classloader and eliminate problem 2.

                We can then modify the WAR deployer to detect a WS deployment, and suspend it following the methodology Thomas suggested. That would solve problems 1 and 3.

                -Jason

                • 5. Re: Service endpoints nested in *.sar
                  starksm64

                  I need to see the current interceptor and work done. The interceptor should probably be installing a custom AbstractWebDeployer that extends the TomcatDeployer to intercept the actual war deployment steps. This custom deployer would be a property int the DeploymentInfo rather than a hard-coded property of the Tomcat5 service getDeployer method:

                   public AbstractWebDeployer getDeployer(DeploymentInfo di) throws Exception
                   {
                   ClassLoader loader = di.ucl;
                   Class deployerClass = loader.loadClass("org.jboss.web.tomcat.tc5.TomcatDeployer");
                   AbstractWebDeployer deployer = (AbstractWebDeployer) deployerClass.newInstance();
                  ...
                  


                  As to whether this should be part of the servlet lifecycle I can't say until I see all that is being done.

                  There are other problems with the current metdata forming an implicit dependency via classes between tomcat and the webservice sar due to the wsdl classes. This needs to be fixed as well.


                  • 6. Re: Service endpoints nested in *.sar
                    jason.greene

                    I decided to revert my changes for now because the dependency mechanism can not gaurantee that even the start interceptor will be attached to AbstractWebContainer, since the jboss-web.xml depends clause only affects WebModule.

                    -Jason

                    • 7. Re: Service endpoints nested in *.sar
                      jason.greene

                       

                      "scott.stark@jboss.org" wrote:
                      I need to see the current interceptor and work done. The interceptor should probably be installing a custom AbstractWebDeployer that extends the TomcatDeployer to intercept the actual war deployment steps. This custom deployer would be a property int the DeploymentInfo rather than a hard-coded property of the Tomcat5 service getDeployer method:

                       public AbstractWebDeployer getDeployer(DeploymentInfo di) throws Exception
                       {
                       ClassLoader loader = di.ucl;
                       Class deployerClass = loader.loadClass("org.jboss.web.tomcat.tc5.TomcatDeployer");
                       AbstractWebDeployer deployer = (AbstractWebDeployer) deployerClass.newInstance();
                      ...
                      


                      As to whether this should be part of the servlet lifecycle I can't say until I see all that is being done.

                      There are other problems with the current metdata forming an implicit dependency via classes between tomcat and the webservice sar due to the wsdl classes. This needs to be fixed as well.


                      I think this would almost solve all of the problems. The only issue that remains is the expansion/unpack step that happens in AbstractWebContainer.init().

                      -Jason

                      • 8. Re: Service endpoints nested in *.sar
                        jason.greene

                        Actually I spoke to soon.

                        The TomcatDeployer is initialized in AbstractWebContainer.create(), which is too soon. We would need to do something like modify the deployer instance in every WebModule after the WebServiceDeployer became live. This would also still require that a dependancy tag on the WebServiceDeployer be in the jboss-web.xml.

                        The main use case is the following deploy order
                        1. earlier-service.sar
                        2. nested web service war
                        3. jbossws.sar

                        -Jason

                        • 9. Re: Service endpoints nested in *.sar
                          jason.greene

                          Another approach would be to pass to modify WebModule to ask for the current deployer in it's start phase, instead of requiring the instance to be passed on construction.

                          -Jason

                          • 10. Re: Service endpoints nested in *.sar
                            starksm64

                            Deploying the jbossws.sar as jbossws.deployer should also remove this dependency problem. On attach/init the jbossws.deployer could replace the deployer instance of the tomcat sar which would externalize this rather than having it be a property of the tomcat implementation.

                            • 11. Re: Service endpoints nested in *.sar
                              jason.greene

                               

                              "scott.stark@jboss.org" wrote:
                              Deploying the jbossws.sar as jbossws.deployer should also remove this dependency problem. On attach/init the jbossws.deployer could replace the deployer instance of the tomcat sar which would externalize this rather than having it be a property of the tomcat implementation.


                              Ok, so deploying as a .deployer would guarantee that jbossws deploys first.
                              So then how do we attach to Tomcat5?

                              As soon as Tomcat5.start succeeds any pending war deployments will be processed so we can't use a standard dependancy.

                              Where you thinking something like a notification handler to pick up when Tomcat5 is created, or did you have something else in mind?

                              -Jason

                              • 12. Re: Service endpoints nested in *.sar
                                starksm64

                                Using a notification to modify the tomcat deployer to be webservice aware. Its just a question of whether this is an extension of the TomcatDeployer or an interceptor is needed to remove some of the current coupling to webservices classes

                                • 13. Re: Service endpoints nested in *.sar
                                  jason.greene

                                  So it looks like our options are:


                                  1. Inheritence
                                  2. Convert TomcatDeployer into an XMBean
                                  3. Generate a CGLIB style proxy, but using javaassist
                                  4. AOP


                                    Ideally there would be decopling, although practically I don't really see a problem with just using inheritence. The contract of AbstractWebDeployer/TomcatDeployer seems to not change very much anyway.

                                    IMO the level of decoupling should depend on future uses. Do you see a future need for this that would dictate one of the other options?

                                    -Jason


                                  • 14. Re: Service endpoints nested in *.sar
                                    starksm64

                                    I don't follow how all these options apply, so maybe you need to drill down into how they map to the deployment lifecycle.

                                    Where we need to get to is an aspectized deployment layer such that there is a webservice aspect that sees one or more components that need a webservice deployment facade. This needs to be broken up into parsing of the metadata that comes from various formats (war, ejb, mbean, mc pojo) and construction of the webservice message handling/routing layers.

                                    1 2 Previous Next