>>> 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