-
1. jbossws-native: Publish HttpContext via Endpoint API
ropalka May 17, 2011 7:58 AM (in response to sgt_pimenta)1 of 1 people found this helpfulHi 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
-
2. jbossws-native: Publish HttpContext via Endpoint API
sgt_pimenta May 17, 2011 11:38 AM (in response to ropalka)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
ropalka May 18, 2011 8:20 AM (in response to sgt_pimenta)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
sgt_pimenta May 18, 2011 3:24 PM (in response to ropalka)>>> 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
asoldano May 19, 2011 3:10 AM (in response to sgt_pimenta)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
asoldano May 19, 2011 3:13 AM (in response to asoldano)- 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
sgt_pimenta May 19, 2011 6:08 AM (in response to asoldano)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
asoldano May 19, 2011 6:56 AM (in response to sgt_pimenta)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
sgt_pimenta May 19, 2011 10:42 AM (in response to asoldano)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
asoldano Jul 20, 2011 5:47 AM (in response to sgt_pimenta)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.