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