1 2 Previous Next 15 Replies Latest reply on Oct 26, 2007 10:20 AM by ejb3workshop

    Endpoint redeployment

    thomas.diesler

      This post is related to

      http://jira.jboss.org/jira/browse/JBWS-1762

      Whatever happens for every type of endpoint deployment (ejb21, ejb3, jse) the deployers should be able to detect that it has already been done. This approach would not distinguish that it has been done by the user or a previous deployment step (i.e. after restart)

      I don't know how the various deployers would detect that the work has already been done. This would vary for every endpoint type and probably also for jboss versions.

      You could also approach this from a different angle. An endpoint deployment must survive a server crash (i.e. no time for rollback). When the server comes up again, endpoints must be recognized as such.

        • 1. Re: Endpoint redeployment
          richard_opalka

          We've got the following problem:

          Thomas want to support the following usecase:
          * User will provide the web.xml which looks like:

          <web-app xmlns="http://java.sun.com/xml/ns/j2ee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
           version="2.4">
          
           <!-- Test that we can deploy an already modified web.xml -->
           <servlet>
           <servlet-name>Hello</servlet-name>
           <servlet-class>org.jboss.wsf.stack.jbws.EndpointServlet</servlet-class>
           <init-param>
           <param-name>jboss.ws.endpoint</param-name>
           <param-value>org.jboss.test.ws.jaxrpc.jbws124.HelloJavaBean</param-value>
           </init-param>
           </servlet>
           <servlet-mapping>
           <servlet-name>Hello</servlet-name>
           <url-pattern>/*</url-pattern>
           </servlet-mapping>
          </web-app>


          REQUIREMENT: Such web.xml should be detected as webservice archive.

          If I will consider server side deployment implementation how it works now then
          this requirement is in collision with the following usecase:
          1) EJB archive is detected as webservice deployment
          2) web.xml file is generated for all EJB webservices
          3) web.xml file is modified in the same way as the above example (probably to not be detected as webservice deployment by non EJB deployer hooks in current implementation)
          4) War deployer hooks are called for created war deployment

          If I'll consider the above requirement that such web archives should be recognized as
          webservice deployments then this archive will be recognized as webservices
          archive and JBossWS war deployer hook will try to redeploy it. This redeployment will of course fail because the endpoint registry already have already registered EJB beans).

          Questions to be answered during this discussion:
          * How could non EJB deployers detect that deployment work had been already done by EJB deployers and nothing should be done for such archives?
          * Do we really want to support the above requirement?

          NOTE: In memory changes only are not possible, because we're talking about JBoss 4.x. So there's no workaround to creation of web.xml files on the file system.

          Richard

          • 2. Re: Endpoint redeployment
            thomas.diesler

            Richard, you are probably aware that JBWS124TestCase already works for all jbossas versions, aren't you?

            • 3. Re: Endpoint redeployment
              richard_opalka

               

              "thomas.diesler@jboss.com" wrote:
              Richard, you are probably aware that JBWS124TestCase already works for all jbossas versions, aren't you?


              Yes, I executed all the tests in my branch against all JBoss AS servers with my fix.

              • 4. Re: Endpoint redeployment
                thomas.diesler

                 


                * How could non EJB deployers detect that deployment work had been already done by EJB deployers and nothing should be done for such archives?


                I guess you'll have to investigate the ejb / war relationship a little. I would suppose (since the identity of the webapp is deterministic) that it is possible to check for its existance.

                In jboss50 it probably pays to look into in memory webapp deployment for ejb endpoints. In that case the deployer would not have to have complex detection logic based on webapp archives.


                • 5. Re: Endpoint redeployment
                  thomas.diesler

                  Yes


                  An endpoint deployment must survive a server crash. When the server comes up again, endpoints must be recognized as such.



                  • 6. Re: Endpoint redeployment
                    richard_opalka

                     

                    "thomas.diesler@jboss.com" wrote:
                    Richard, you are probably aware that JBWS124TestCase already works for all jbossas versions, aren't you?


                    In this case it works because JAXRPC war deployer hook checks whether there's the webservices.xml file. If yes it is recognized as webservices archive. In the case of JAX-RPC based webservices that provide webservices.xml there's no problem. In such case webservices.xml is inspected to look for webservices, and not web.xml (as in the case of JAXWS services)

                    • 7. Re: Endpoint redeployment
                      richard_opalka

                      To be more concrete problem is related to JAXWS endpoints only. In the case of JAX-RPC endpoints there's no problem, because webservices archive detections is based on webservices.xml file existence in classloader.

                      Richard

                      • 8. Re: Endpoint redeployment
                        thomas.diesler

                        The first thing to do is probably to setup the test matrix that deployes every kind on WS endpoints, takes the appserver down, restarts it again and finally exercises the endpoints.

                        This needs to be automated and hooked up in hudson.
                        When we have this we can worry and fix endpoint specific problems.

                        Without a comprehensive test matrix we can never be sure that appserver chages won't break this functionality.

                        This of course is not needed if a WS endpoint deployment is stateless in terms of deployment.

                        • 9. Re: Endpoint redeployment
                          richard_opalka

                          I agree Thomas,

                          I'll prepare the test matrix for all kind of endpoints.

                          Richard

                          • 10. Re: Endpoint redeployment
                            richard_opalka

                            The test matrix must consider the following types of archive deployment too:

                            * packaged ear
                            * unpackaged ear
                            * packaged war
                            * unpackaged war

                            for each type of endpoint.

                            Richard

                            • 11. Re: Endpoint redeployment
                              jalla

                              is this fixed in jboss ws 2.0.1?

                              • 12. Re: Endpoint redeployment
                                ropalka

                                No, it is not fixed in JBossWS 2.0.1

                                Richard

                                • 13. Re: Endpoint redeployment
                                  01012003

                                  Will it be fixed in future versions? What is the workaround here? The web services deployed does not work after simple restart. One has to make changes to web.xml...

                                  • 14. Re: Endpoint redeployment
                                    ropalka

                                    Yes,

                                    there is the plan to fix it in next versions. However the fix requires further investigations.

                                    Richard

                                    1 2 Previous Next