12 Replies Latest reply on Oct 17, 2006 9:05 AM by thomas.diesler

    JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redeploym

    dlofthouse

      For users deploying a JSR-181 POJO deployment with an exploded WAR subsequent deployments fail as the web.xml is modified with the JBossWS servlet name. On the next deployment it is the JBossWS servlet that is checked for annotations not the endpoint class itself, this means the web service is not detected.

      The only option the user has is to manually put the original web.xml back in place for each deployment / server restart.

      A second minor problem is that users deploying JSR-109 POJO endpoints with an exploded war may not want their web.xml modified by JBoss, however their web service is still correctly deployed for subsequent deployments.

      So far I can see the following options: -

      1 - Modify org.jboss.metadata.WebMetaData so that it also reads the init-params from the web.xml, if the servlet-class is an implementation of StandardEndpointServlet then we can lookup the 'ServiceEndpointImpl' parameter and test that instead.

      2 - Instead of modifying the web.xml deployment descriptor create a new file to use in place of the web.xml descriptor, this means we can write the changes to the new file without affecting the original file.

      It is not currently exposed as an attribute of the MBean but the StandardContext class within Tomcat does have an attribute 'altDDName', this attribute can be set to override the name of the deployment descriptor to use so an alternative can be specified.

      3 - JBossWS in addition to using the WebMetaData can also parse the web.xml to retrieve the parameters so as for 1 if the JBossWS servlet is found the 'ServiceEndpointImpl' parameter can be used to identify the correct class to check for annotations.

        • 1. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
          jason.greene

          I actually like option 2 the best.

          • 2. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
            dlofthouse

            Personally I prefer option 2 as well as this means for all deployments we will allways be working with a clean web.xml and it means the user never sees their web.xml modified.

            The downside of this approach is that for it to work 3 different products need to change.

            Tomcat needs to be changed so that the 'altDDName' attribute is exposed. At the moment I can access this from JBoss as: -

            Context ctx = (Context) server.getAttribute(objectName, "managedResource");
            ctx.setAltDDName(metaData.getAltDD());


            However this is a bit of a hack and if we are going to use it it should be exposed properly.

            Secondly the WebMetaData class will need modifying so include an attribute to hold the name of the new web.xml so that TomcatDeployer can pass it to Tomcat.

            The earliest we could get this in would be for JBoss 4.0.6.GA and once in JBossWS would not be compatible with previous JBossAS versions.

            Having said that despite the number of projects affected this is probably the simplest to implement, just a few lines of changes in each product.

            • 3. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
              starksm64

              1 is the direction will be moving towards in head as that layer that actually deploys the web app should just be given the metadata that describes what the web app consists of. Any number of other deployers can have run earlier in the deployment phase to produce this metadata from various sources.

              A hybrid approach that moves closer to what is needed in jboss5 would be a plugin into the tomcat deployer that allowed modification of the WebMetaData. This needs to be an optional plugin binding so that we don't have to pulling in the entire webservice stack for a tomcat only config. If the plugin has modifed that data, then the tomcat deployer can write out a modified web.xml and reference it via the alt-dd.

              • 4. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                jason.greene

                 

                "scott.stark@jboss.org" wrote:
                1 is the direction will be moving towards in head as that layer that actually deploys the web app should just be given the metadata that describes what the web app consists of. Any number of other deployers can have run earlier in the deployment phase to produce this metadata from various sources.

                A hybrid approach that moves closer to what is needed in jboss5 would be a plugin into the tomcat deployer that allowed modification of the WebMetaData. This needs to be an optional plugin binding so that we don't have to pulling in the entire webservice stack for a tomcat only config. If the plugin has modifed that data, then the tomcat deployer can write out a modified web.xml and reference it via the alt-dd.



                Perhaps we should delay this bug as part of the jboss 5 integration. Is there a reason for JBWS-1133 to get resolved sooner? How large is the demand?

                -Jason

                • 5. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                  dlofthouse

                  At the moment we have one request for this. Parsing the web.xml is not a big job so maybe we should just go with option 3 for the moment until the refactoring takes place.

                  • 6. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                    dlofthouse

                    At the moment we have one request for this. Parsing the web.xml is not a big job so maybe we should just go with option 3 for the moment until the refactoring takes place.

                    • 7. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                      jason.greene

                       

                      "darran.lofthouse@jboss.com" wrote:
                      At the moment we have one request for this. Parsing the web.xml is not a big job so maybe we should just go with option 3 for the moment until the refactoring takes place.


                      For the temporary fix, You could do something like look at the WebMetaData, see if there is a ServiceEndpointServlet, and only in that case parse the web.xml.

                      -Jason

                      • 8. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                        thomas.diesler

                        I believe

                        http://jira.jboss.com/jira/browse/JBWS-1133

                        is a variant of

                        http://jira.jboss.com/jira/browse/JBWS-124

                        which lives in the jbossas testsuite.

                        REwriting of of web.xml is necessary because otherwise Tomcat does not eploy the webapp in the first place. It expects a servlet in <servlet-class>.

                        The service deployer should detect an already modified web.xml and not touch it again. Please pull in JBWS124TestCase to our testsuite and modify it using an JSR181 endpoint.

                        • 9. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                          dlofthouse

                          It is the fact that we don't modify the web.xml again that is the problem for the JSR-181 deployments.

                          For JSR-109 deployments we do not have a problem because we have a webservices.xml that lists which servlets are actually endpoints.

                          However for JSR-181 deployments to identify which servlets are actually endpoints we check all of the servlets to see if they are annotated with @WebService, as the JBossWS servlet is not annotated with @WebService the deployment of the JSR-181 endpoint is skipped for all subsequent deployments.

                          • 10. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                            thomas.diesler

                            Ok, sorry I missed the point.

                            In that case, since we already can detect that a web.xml is modified we know the endpoint bean class. This bean should then be passed through the same logic that detected the JSR181 endpoint on first time deployment.

                            • 11. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                              dlofthouse

                              Yes the main problem is that at the time of deployment we do not have access to the parameters passed to the servlet, we need the parameters as it is one of those that contains the class name of the endpoint.

                              Option 1 was an option so that JBossAS could pass JBossWS all of the configured parameters within the 'org.jboss.metadata.WebMetaData' so we can easily access it.

                              Option 3 is that we read the web.xml ourselves to extract the parameters.

                              Option 2 was just an alternative we could follow if we wanted to leave the original web.xml alone so for each deployment we would start with a clean web.xml so JBossWS wouldn't need to be coded to cope with first and second deployments.

                              • 12. Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep
                                thomas.diesler

                                I think we can safely postpone this issue until the complete set of metadata is available in WebMetaData. A possible workaround is not to use exploded wars with jsr181 endpoints.