make Jetty7 serve WebService request

I'm unfortunately not aware of the changes which happened in Jetty 7, like why JettyHttpServer.createContext() should not start the jettyContextHandler and what you mean with volatile _handlers. Any explanation on this would be helpful.

What I can tell you is that the org.mortbay.jetty.j2se6 package name was very poorly chosen as this code does not depend on J2SE6 but on JAX-WS2 RI. It would be nice to address that as well.

Hi Ludovic,

I started to check usability of Jetty just a week ago and found it very nice.
This blog entry
http://tech-eureka.blogspot.com/2009/10/jax-ws-inside-jetty.html
made me aware that I could use this for serving SOAP requests as well.

This worked.

Unfortunately the project this is going to be incorporated already switched to
Jetty 7.

So I had to check how to port this.
Enough about history.

With "now volatile _handler" I mean a change in org.eclipse.jetty.server.handler
In Jetty 6 the _handler field wasn't volatile but now it is. That's
why your original code
in JettyHttpServer.java

Handler[] handlers = _server.getHandlers();
for (int i = 0; i < handlers.length; i++)
{
if (handlers[i] instanceof HandlerCollection)

}

doesn't work any longer. _server.getHandler() doesn't return the
HandlerCollection.

The other remark concering start() is simply an observation by me.
If I leave your code in the original state, where start() is called,
Jetty7 now raises
an IllegalStateException.

I have no idea about the background for those changes from Jetty6 to
Jetty7 and can
only hope Jesse knows more.

Hope this sounds understandable now
Axel

Attached Jetty 6's J2SE contrib module, cleaned up, refreshed and ported to Jetty 7.

There were very many problems, most of which because Jetty 6 is way more permissive than Jetty 7.

I've also renamed the module (and packages and classes) to 'jetty-jaxws2-spi' as you can use this on JDK 1.5 if you added the Metro jars in your classpath. This means there is no dependency on JDK 1.6 anymore to build the module as well.

I've only briefly tested it but so far it seems to work fine.

Works for me. Phantastic job done, Ludovic!

Axel

I have added this into jetty7 and wired it up into the default build so at least this module will be released with the next update.

following up on the list with some additional bits before I close out the issue.

jesse

Jesse, Ludovic,

I don't think we should have a package of org.eclipse for stuff that lives on codehaus. Can we make that org.mortbay?

Also, I'm a little confused as to how jetty acting as the web server in the jvm is related to handling web services? Can someone give me the 1 minute Dummies Guide on this?

thanks,
Jan

Jan,

This stuff already exists and works fine for Jetty 6 and already is hosted on Codehaus. This issue is about porting that exact same functionality to Jetty 7 which wasn't completely trivial to do.

In a nutshell, this module allows one to publish JAX-WS2 endpoints on Jetty (using http://java.sun.com/javase/6/docs/api/javax/xml/ws/Endpoint.html#publish%28java.lang.String,%20java.lang.Object%29) instead of on the JVM's embedded web server.

There are many advantages in doing that but the most obvious one IMHO is that you can have a web application AND your web services accessible on the same port which would not be possible if you had to start Jetty for the web app and the jvm web server for the endpoints.

If you need more details, feel free to ask.

Hi Ludovic,

Yup, its all good stuff, thanks! My question was about the name of the package - its a lot more generic than anything to do with jaxws2 isn't it? The classes that have been committed replace jetty as the embedded http server for the jvm. I can't see any classes that implement the javax.xml.ws.spi classes, which would appear to be the glue that is needed to do an Endpoint.publish() to jetty? So, as there's nothing in here that has anything to do with the javax.xml.ws.spi classes, I'm questioning how appropriate the package name is?

cheers
Jan

Jan,

The javax.xml.ws.spi package is meant for plugging in a JAX-WS implementation AFAIK so it has nothing to do with this feature.

The com.sun.net.httpserver.spi actually isn't meant for JAX-WS but for Sun's JAX-WS RI (aka Metro, bundled with the JDK 1.6) only so I agree the package name I proposed is slightly inappropriate.

This module is an excellent addition to Metro as it allows for extremely high scalability and robustness which I believe is also good for Jetty.

Hi Ludovic,

OK, I think I understand now (correct me if I'm wrong). The Metro reference impl of jax-ws uses the jvm's com.sun.httpserver impl for deployment. However, if you don't want to use Metro, you can implement other interfaces to bridge the web container to the jax-ws apis. Is that right?

So, I think the naming of the package you had previously (ie the same as jetty6) is more appropriate, don't you? There are other uses for the com.sun.httpserver impl, its just that Metro happens to be one of them?

What do you think?

Jan

Hi Jan,

Metro could also be used with JDK 1.5 so the j2se6 package name would be a bit confusing then... How about simply calling it metro?

AFAIK only Metro makes use of the com.sun.httpserver implementation but I'm not 100% sure.

Hi Ludovic,

Again, I don't think we should name the package after just a single use-case. I really think something that is more descriptive of what it is, which is the implementation of the com.sun.httpserver.spi is better. But if the interfaces can exist in jdk1.5 then we should definitely drop the "6" from the title.

How about j2sehttpspi?

Jan

j2sehttpspi sounds OK. I think we have a deal

Changed package names as per discussion in this issue with Ludovic.

Jan

I see that this issue has been marked fixed on 7.0.2 however, the jetty 7.0.2 downloaded from the eclipse site does not have the fix (jetty-j2sehttpspi jar file)
Is there a plan to include this into the jetty distribution? Without this, it's impossible to serve SOAP requests from jetty.

For documentation sake, I want to mention that current version of jetty-j2sehttpspi does not support https as a transport.