10 Replies Latest reply on Jul 20, 2011 5:47 AM by Alessio Soldano

    jbossws-native: Publish HttpContext via Endpoint API

    Pedro Correia Newbie

      Hello all,

       

      I'm using jboss-5.1.0.GA and currently upgraded jbossws-native to version 3.4.1.GA.

       

      Previously (as in jbossws-native 3.1.2.GA) I was able to publish a Web Service programmatically (via Endpoint) to the container's HTTP server.

      One could either use the static Endpoint.publish or get hold of the running HTTP server/context, eg:

       

      Endpoint endpoint = Endpoint.create(implementor);

      SPIProvider spiProvider = SPIProviderResolver.getInstance().getProvider();

      HttpServer httpServer = spiProvider.getSPI(HttpServerFactory.class).getHttpServer();

      HttpContext context = httpServer.createContext(path);

      endpoint.publish(context);

       

      However, as I understand it after refactoring jbossws-native, the default HTTP server for endpoint publishing is now Netty, as opposed to the container's Apache Tomcat. This refactoring is also evident in the code as HttpServerFactory has been removed from the library!

       

      My question is: How can I maintain the previous behavior, i.e. acquire the container's HTTP Server and publish the webservice on it?

      Is there an alternative to get the JEE HTTP Server? Or was this really broken on purpose to avoid programmatic deployment on the JEE server?

       

      Thanks in advance.

        • 1. jbossws-native: Publish HttpContext via Endpoint API
          Richard Opalka Master

          Hi Pedro,

           

             this feature is no longer supported. It was kinda hack to JBoss AS internals

          If you still need to use similar feature, use standard JAXWS endpoint API instead.

          I also recommend you to use JBossWS CXF instead of JBossWS Native.

           

          Richard

          1 of 1 people found this helpful
          • 2. jbossws-native: Publish HttpContext via Endpoint API
            Pedro Correia Newbie

            Hi Richard,

             

            I understand that the feature has been dropped, but from the end-user point of view I wouldn't really look at it as a "hack".

            If there is a container available (i.e. JBoss/Tomcat) why should one be "forced" to use Netty, Jetty, Glassfish mini-server, etc.?

             

            In other words, it means that any JBossWS javax.xml.ws.Endpoint implementation (native, cxf, metro) is not compatible (programmatically at least) with JEE container deployment; which (by the book) should be performed using the classical WAR packaging approach. Correct?

             

            I was checking CFX "Endpoint" implementation and wondering if, by any chance, would be possible to inject the container's HTTP server in the endpoint's JaxWsServerFactoryBean ? Maybe I am persisting in the "hack" here...

             

            Thanks for your support, I will consider your recommendation for switching to CFX as well.

             

            Pedro

            • 3. jbossws-native: Publish HttpContext via Endpoint API
              Richard Opalka Master

              Comments inlined:

               

              >>> I understand that the feature has been dropped, but from the end-user point of view I wouldn't really look at it as a "hack".

              >>> If there is a container available (i.e. JBoss/Tomcat) why should one be "forced" to use Netty, Jetty, Glassfish mini-server, etc.?

               

              Imagine you're at the end of deployment processing chain (in your case servlet have been initialized).

              When you published endpoint from such servlet using old endpoint publish API the JBossWS AS integration implementation

              called AS internals and was executing deployment chain once again (with many really ugly hacks involved to make it work).

               

              >>> In other words, it means that any JBossWS javax.xml.ws.Endpoint implementation (native, cxf, metro) is not compatible

              >>> (programmatically at least) with JEE container deployment; which (by the book) should be performed using the classical WAR packaging

              >>> approach. Correct?

               

              Unfortunately yes. This part of JAX-WS specification is completely broken an unclear and many pieces of it NOT PORTABLE!

              I'd call it experimental feature of JAX-WS spec.

               

              >>> I was checking CFX "Endpoint" implementation and wondering if, by any chance, would be possible to inject the container's HTTP server in the

              >>> endpoint's JaxWsServerFactoryBean ? Maybe I am persisting in the "hack" here...

               

              Believe me, it wouldn't work

               

              >>> Thanks for your support, I will consider your recommendation for switching to CFX as well.

               

              You are welcome.

               

              Pedro

              • 4. jbossws-native: Publish HttpContext via Endpoint API
                Pedro Correia Newbie

                >>> When you published endpoint from such servlet using old endpoint publish API the JBossWS AS integration implementation

                >>> called AS internals and was executing deployment chain once again

                 

                You have a point. I agree on the "hack" here in terms of lifecycle.

                 

                >>> This part of JAX-WS specification is completely broken an unclear and many pieces of it NOT PORTABLE!

                >>> I'd call it experimental feature of JAX-WS spec.

                 

                I agree javax.xml.ws.Endpoint is far from clear. But despite its lack of typification, method publish(Object serverContext) indicates that «server context encapsulates the server infrastructure and addressing information for a particular transport». At least the purpose to provide control to the user was clear.

                 

                In fact your colleague Alessio Soldano has promoted its use!

                http://jbossws.blogspot.com/2010/08/comsunnethttpserver-transport-using.html

                 

                Correct me if I'm wrong, but in the end it's all about providing a HTTP SPI (which has been broken for JBossWS) in order to plug any HTTP server implementation. In my opinion, apart from the server lifecyle (which appears to be the real issue), it makes sense to allow programmatic deployment in any compliant container.

                 

                I do not question the choice for Netty, Jetty, etc. as a default implementation. But it seems like a step-back for JBossWS to have broken its HTTP SPI. The deployment chain issue could have been solved (or so I wished) by establishing rules for a given server context, e.g. indicating the server lifecycle and initialization was controlled externally. Just a suggestion of course, I have not a clear idea of the complexity involved.

                 

                Bottom-line is... Any luck for a revamped version of the SPI?

                 

                Regards,

                Pedro

                • 5. jbossws-native: Publish HttpContext via Endpoint API
                  Alessio Soldano Master

                  Just to clarify:

                    • the Endpoint.publish() API is meant to be consumed directly by final users in JSE environments only; there's nothing in the spec saying you're granted to have a deployment on the already running container in JavaEE environment; btw, the TCK for that used to assume a new server is actually started
                    • the JAXWS 2.2 spec had a significant improvement over previous versions wrt the Endpoint.publish() API. In particular the Endpoint.publish(javax.xml.ws.spi.http.HttpContext serverContext) method -that's been added in 2.2- allows for portable deployments to "jaxws22-httpspi-compatible" containers; that was not the case (the API was kind of broken) before 2.2
                    • as far as I know, at the moment that set of compatible containers basically includes Grizzly (well, the whole http spi there in the spec has been kind of derived from that) and any http server that can be bridged similarly to what I did for com.sun.net.httpserver (http://anonsvn.jboss.org/repos/jbossws/projects/jaxws-httpserver-httpspi/)
                    • the JBoss AS is currently not included in the set above, and afaik there're no plans atm for working on that
                    • JBossWS Native is not going to see any further development in this area, given this is a really specific usecase and it's also already properly covered by JBossWS-CXf which is the default ws stack and the one the JavaEE 6 certification has been run with and will be run
                  • 6. jbossws-native: Publish HttpContext via Endpoint API
                    Alessio Soldano Master
                    • ah, what Richard removed in 3.4.x is the previously (broken) http spi that was not compatible with jaxws 2.2, hence there was no point in keeping that only for supporting a not-needed-anymore hack in jbossws-native
                    • 7. jbossws-native: Publish HttpContext via Endpoint API
                      Pedro Correia Newbie

                      Hi Alessio,

                       

                      Thanks for your input, my comments below.

                       

                      >>> the Endpoint.publish() API is meant to be consumed directly by final users in JSE environments only;

                       

                      This may be an interesting discussion, since in '09 it did not appear to be that clear e.g. https://issues.jboss.org/browse/JBWS-2674

                      Here you were aiming at «Implement Endpoint.publish() support for both JSE and J2EE environments»

                       

                      >>> there's nothing in the spec saying you're granted to have a deployment on the already running container in JavaEE environment; btw, the TCK for >>> that used to assume a new server is actually started

                       

                      One can also argue there is nothing in the spec saying that you cannot have a running container. The TCK exemplifies with a «hypothetical HTTP server».

                       

                      Ok, I agree that once you establish this interface is valid only for JSE this is a useless discussion.

                      What is most tricky is that JBossWS-Native went from using Tomcat as Endpoint.publish default target container (with or without hacking) to NOT supporting it at all, at least programatically.

                      That is a pain because, if not for better reason, broke the support for programmatic publishing on JBoss-AS

                       

                      Regards,

                      Pedro

                      • 8. Re: jbossws-native: Publish HttpContext via Endpoint API
                        Alessio Soldano Master

                        Hi Pedro,

                         

                        What is most tricky is that JBossWS-Native went from using Tomcat as Endpoint.publish default target container (with or without hacking) to NOT supporting it at all, at least programatically.

                        That is a pain because, if not for better reason, broke the support for programmatic publishing on JBoss-AS

                        I see what you mean. That's quite a different topic though, despite being related.

                        Regardless of the JAXWS spec (which kind of suggested a way for doing that, unfortunately we ended up *partially* supporting something similar just for the sake of passing a test on usecase/scenario that appeared kind of broken in the early versions of the spec), this is a feature that might have a value in general (programmatically publishing a ws endpoint on JBoss AS).

                        Unfortunately that's not supported as of today (and as Richard tried explaining, the previous hack won't have worked today).

                        To be honest this functionality is implemented in a few other JBoss projects; I think I remember the SwitchYard (ESB) and Riftsaw do something similar, probably getting a handle to the deployers, I might need to check / look / ask for the details.

                        Some months back I've been reasoning on this feature wrt the AS7 integration development (http://community.jboss.org/message/572530#572530), however we've been caught by a lot of other AS7 integration issues and the ability to have a MSC service for starting an endpoint independently from a server deployment is still not there and not being worked. Btw, the main blocking dependency for doing that would still not be satisfied (basically, JBossWeb support for programmatically starting a web app in general, https://issues.jboss.org/browse/AS7-351). From a AS7 point of view, my feeling is that this feature might be worked only after the JavaEE certification related work is done.

                        • 9. Re: jbossws-native: Publish HttpContext via Endpoint API
                          Pedro Correia Newbie

                          It's good to see the "feature" is on the roadmap though JEE certification is (obviously) a priority.

                          Maybe you implement it completely separate from JAX-WS, fair is fair, but it is of interest nevertheless.

                           

                          Btw, in your favour, I think the "hack" worked rather well in JBossWS-Native 3.1.2.GA.

                          In fact the most bothering part is that an (apparently simple) error that was reported in 2006 was never fixed in 3 years:

                          https://issues.jboss.org/browse/JBWS-826

                           

                          This annoying message was printed in STDERR on the client-side every time a one-way invocation was made.

                           

                          Anyway, once again thanks for the support. It all seems much more clear after the discussion.

                          • 10. Re: jbossws-native: Publish HttpContext via Endpoint API
                            Alessio Soldano Master

                            Pedro,

                            you might be interested in https://issues.jboss.org/browse/AS7-1322 .

                            Basically, soon AS7 is including an EndpointPublisher API for programmatic deploy of POJO WS endpoints. That is also being wrapped into an AS7 service, as other AS7 subsystems needed to depend on that (for instance JBoss XTS during AS bootstrap, http://community.jboss.org/message/612541). The AS7-351 blocker has been removed with a workaround similar to what has been done for the AS7 welcome page.