1:17 p.m.
Pedro Correia [http://community.jboss.org/people/sgt_pimenta] created the discussion
"jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605513#605513
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605513#605513]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
6:58 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Richard Opalka [http://community.jboss.org/people/ropalka] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605659#605659
--------------------------------------------------------------
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605659#605659]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
10:38 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Pedro Correia [http://community.jboss.org/people/sgt_pimenta] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605699#605699
--------------------------------------------------------------
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605699#605699]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
7:20 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Richard Opalka [http://community.jboss.org/people/ropalka] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605827#605827
--------------------------------------------------------------
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605827#605827]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
2:24 p.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Pedro Correia [http://community.jboss.org/people/sgt_pimenta] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605913#605913
--------------------------------------------------------------
>> 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
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605913#605913]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
2:10 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605978#605978
--------------------------------------------------------------
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/
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605978#605978]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
2:14 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/605980#605980
--------------------------------------------------------------
* 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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605980#605980]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5:08 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Pedro Correia [http://community.jboss.org/people/sgt_pimenta] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/606018#606018
--------------------------------------------------------------
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 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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/606018#606018]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5:56 a.m.
New subject: [JBoss Web Services] - Re: jbossws-native: Publish HttpContext via Endpoint API
Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion
"Re: jbossws-native: Publish HttpContext via Endpoint API"
To view the discussion, visit: http://community.jboss.org/message/606023#606023
--------------------------------------------------------------
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 thing,
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
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 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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/606023#606023]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4795
days inactive
4798
days old
8 comments
3 participants
participants (3)
-
Alessio Soldano -
Pedro Correia
-
Richard Opalka