You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Ludwig <mi...@gmx.de> on 2010/11/20 13:52:01 UTC
Servlet 2.5 SRV.14 and provision of JAX-WS
JAX-WS ships with Sun JDK 1.6 and seems the easiest way to code web
services on this platform. It is really easy to get started:
http://java.dzone.com/articles/jax-ws-hello-world
http://java.dzone.com/articles/jax-ws-deployment-five-minute
I have one question, though. JAX-WS is provided by JDK 1.6, so when I
start Tomcat 6 with a 1.6 JRE why can't it use the JAX-WS from the JRE?
Why do I have to supply a copy of JAX-WS (about 20 JARs in the ZIP you
can download from http://jax-ws.java.net/) in WEB-INF/lib? If I don't,
a ClassNotFoundException ensues. [1]
I can see the server probably shouldn't make AWT or other desktop
components available to the web app, but JAX-WS is clearly a suitable
component for a web container. So why isn't it just made available if
present in the JRE?
I took a look at the Servlet Specification 2.5 MR6. I'm quoting some
parts here, and asking some questions.
SRV.14.2 Web Applications
Java EE technology-compliant containers are required to provide a
mechanism by which a deployer can learn what JAR files containing
resources and code are available for the Web application. Providing
such the mechanism is recommended, but not required for the containers
that are not part of Java EE technology-compliant implementation. The
containers should provide a convenient procedure for editing and
configuring library files or extensions.
Is Tomcat a "Java EE technology-compliant container" as per the spec?
Or is that reserved for the likes of Glassfish and Websphere? (I think
it is.)
If so, what mechanism, other than trial and error, can I learn by what
JAR files are available for the web app?
If not, in case anyone has experience to share, what mechanism is
provided by, say, Glassfish?
In the absence of such a mechanism, I guess I just have to know what's
provided and what isn't, or find out by trial and error? Is there a list
of what's provided by default and what isn't? Or is this something each
web container, like Tomcat or Jetty, may do as it pleases?
Just like the developer may choose to extend the container's JAR library
by making JARs available to the shared or common classloader? (Even
though some prominent list members do not encourage such practice.)
SRV.14.2.1 Web Application Class Loader
Servlet containers that are part of a Java EE product should not allow
the application to override Java SE or Java EE platform classes, such
as those in java.* and javax.* namespaces, that either Java SE or Java
EE do not allow to be modified.
Wouldn't one expect a list of components that *may* be loaded from the
JVM classloader at this point? Like, for instance, JAX-WS when running
from a JDK 1.6?
SRV.14.4.2 Packaging and Deployment of JAX-WS Components
Okay, a section explicitly dealing with JAX-WS here.
Web containers may choose to support running components written to
implement a Web service endpoint as defined by the JAX-RPC and/or
JAX-WS specifications. Web containers embedded in a JavaEE conformant
implementation are required to support JAX-RPC and JAX-WS web service
components. This section describes the packaging and deployment model
for such JAX-RPC and JAX-WS Web component implementations.
So, does hardcore EE conformance require the container to support
JAX-WS, whereas simple containerhood makes it optional? "May choose
to support?" Is using JAX-WS from the JRE then something that Tomcat
might choose to do, but for some reason doesn't?
JSR-109 [http://jcp.org/jsr/detail/109.jsp] defines the model for
packaging a Web service interface with its associated WSDL description
and associated classes. It defines a mechanism for JAX-WS and JAX-RPC
enabled Web containers to link to a component that implements this Web
service. A JAX-WS or JAX-RPC Web service implementation component uses
the APIs defined by the JAX-WS and/or JAX-RPC specifications, which
defines its contract with the JAX-WS and/or JAX-WS enabled Web
containers. It is packaged into the WAR file. The Web service
developer makes a declaration of this component using the usual
<servlet> declaration.
Okay, "[JAX-WS] is packaged into the WAR file." Is this a MUST?
Thanks for any comments.
Michael
[1] Exception for starting Tomcat 6.0.29 with JRE from JDK 1.6.0_22:
Error configuring application listener of class com.sun.xml.ws.transport.http.servlet.WSServletContextListener
java.lang.ClassNotFoundException: com.sun.xml.ws.transport.http.servlet.WSServletContextListener
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1645)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4078)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at org.apache.catalina.core.StandardService.start(StandardService.java:519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
--
Michael Ludwig
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Servlet 2.5 SRV.14 and provision of JAX-WS
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/11/20 Michael Ludwig <mi...@gmx.de>:
>
> I don't know if these com.sun.xml.internal.ws.* things are part of the
> JRE or not, but they do seem to get loaded by "jre6\bin\java.exe", and
> they are in rt.jar (runtime). So they are obviously part of the JRE?
>
They are part of implementation in specific version of JRE on specific
OS by specific vendor.
There are other JRE implementations, e.g. from IBM.
Also, using "internal" in the package name should be a hint.
Public API is mostly in java.*, javax.*, though there are several
endorsed standards,
http://download.oracle.com/javase/6/docs/api/overview-summary.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Servlet 2.5 SRV.14 and provision of JAX-WS
Posted by Michael Ludwig <mi...@gmx.de>.
Konstantin Kolinko schrieb am 20.11.2010 um 17:51 (+0300):
> 2010/11/20 Michael Ludwig <mi...@gmx.de>:
> > JAX-WS ships with Sun JDK 1.6 and seems the easiest way to code web
> > services on this platform. It is really easy to get started:
> >
> > http://java.dzone.com/articles/jax-ws-hello-world
> > http://java.dzone.com/articles/jax-ws-deployment-five-minute
> >
> > I have one question, though. JAX-WS is provided by JDK 1.6, so when I
> > start Tomcat 6 with a 1.6 JRE why can't it use the JAX-WS from the JRE?
> > Why do I have to supply a copy of JAX-WS (about 20 JARs in the ZIP you
> > can download from http://jax-ws.java.net/) in WEB-INF/lib? If I don't,
> > a ClassNotFoundException ensues. [1]
> >
> > Error configuring application listener of class com.sun.xml.ws.transport.http.servlet.WSServletContextListener
> > java.lang.ClassNotFoundException: com.sun.xml.ws.transport.http.servlet.WSServletContextListener
>
> Because there is no such class in your JRE (and there is none in mine as well).
You are right. Thanks.
Maybe I'm unclear about what constitutes the JRE and what doesn't.
Without anything special in "bin" or the env var CLASSPATH set or JAX-WS
in lib/ext, I can start the following from JRE 6:
G:\Eclipse35ws\JAX-WS :: C:\Programme\Java\jre6\bin\java.exe -cp bin juma.WSPublisher
starte juma.mohammad.GreetingImpl@addbf1 auf http://localhost:8283/ws/juma
20.11.2010 16:44:23 com.sun.xml.internal.ws.model.RuntimeModeler getRequestWrapperClass
INFO: Dynamically creating request wrapper Class juma.mohammad.jaxws.SayHello
20.11.2010 16:44:23 com.sun.xml.internal.ws.model.RuntimeModeler getResponseWrapperClass
INFO: Dynamically creating response wrapper bean Class juma.mohammad.jaxws.SayHelloResponse
I don't know if these com.sun.xml.internal.ws.* things are part of the
JRE or not, but they do seem to get loaded by "jre6\bin\java.exe", and
they are in rt.jar (runtime). So they are obviously part of the JRE?
> The same problem would be with
> com.sun.xml.ws.transport.http.servlet.WSServlet
> mentioned in the above article. There is no such class as well.
>
> Using com.sun.* classes directly is not recommended. They are not part
> of the official API and can change without notice.
Yes.
> Also it would be strange to provide servlets in JDK/JRE, because
> javax.servlet.* is not part of JRE API.
I think my error was lumping all these com.sun.*.ws.* packages together.
Some of them do seem to be part of the JRE, others aren't.
So while JAX-WS is provided by the JRE, the servlet specific parts of it
aren't. Which is surprising in that I had assumed a servlet container
would be the usual host for web services. So maybe the JRE has enough to
run web service clients, but not web service servlets.
--
Michael Ludwig
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Servlet 2.5 SRV.14 and provision of JAX-WS
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/11/20 Michael Ludwig <mi...@gmx.de>:
> JAX-WS ships with Sun JDK 1.6 and seems the easiest way to code web
> services on this platform. It is really easy to get started:
>
> http://java.dzone.com/articles/jax-ws-hello-world
> http://java.dzone.com/articles/jax-ws-deployment-five-minute
>
> I have one question, though. JAX-WS is provided by JDK 1.6, so when I
> start Tomcat 6 with a 1.6 JRE why can't it use the JAX-WS from the JRE?
> Why do I have to supply a copy of JAX-WS (about 20 JARs in the ZIP you
> can download from http://jax-ws.java.net/) in WEB-INF/lib? If I don't,
> a ClassNotFoundException ensues. [1]
>
> Error configuring application listener of class com.sun.xml.ws.transport.http.servlet.WSServletContextListener
> java.lang.ClassNotFoundException: com.sun.xml.ws.transport.http.servlet.WSServletContextListener
Because there is no such class in your JRE (and there is none in mine as well).
The same problem would be with
com.sun.xml.ws.transport.http.servlet.WSServlet
mentioned in the above article. There is no such class as well.
Using com.sun.* classes directly is not recommended. They are not part
of the official API and can change without notice.
Also it would be strange to provide servlets in JDK/JRE, because
javax.servlet.* is not part of JRE API.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org