Comments inlined
Rio
On 02/15/2011 04:41 PM, David M. Lloyd wrote:
On 02/15/2011 09:36 AM, Alessio Soldano wrote:
> On 02/15/2011 04:22 PM, David M. Lloyd wrote:
>>> Objections / comments ?
>> I object. This is incorrect.
>>
>> These modules are NOT intended to be a magic repository for appending
>> things on to user deployments! These modules are internal
>> implementation modules, which nobody should expect to ever appear on a
>> user class path.
>>
>> If you want to add these additional dependencies to EJB and Servlet
>> deployments then modify the EJB and Servlet deployers to add these
>> dependencies individually.
> Right, just to clarify, I think this is basically what's been said with
> Carlo and Emanuel later on; is that fine?
> IOW the real question here is, are we all OK with having the WS libs in
> the runtime classpath of every ejb/servlet deployments? (as a
> consequence of the need for supporting the usecases mentioned in
> Richard's email)
I'm not sure I understand how these usecases cause a need to include WS
impl libs on the deployment classpath.
Let me explain.
JAX-WS API uses META-INF service-provider approach.
If we didn't set JAX-WS impl, the default (bundled with JVM)
would be used (on flat class path - AS6 days).
However AS7 with JBoss Modules are changing this picture.
The question we'd like to answer with this thread is
"How to do it right with AS7 architecture and what is allowed"
Both TCK and EE specs require that users are able to use JAXWS
client API in pure servlets and in EJBs. This is sometimes not
detectable with classes scanning if JSR 181 annotations are not used
(users can use pure JNDI lookup or even JAX-WS client API directly).
This implies that JAX-WS impl should be visible in servlets and EJBs.
The question is how to do it right in AS7?
Our proposal is to modify both web and ejb3 DU processors to include
JAXWS impl as well in DU dependencies.
Maybe there's better solution to this
"DU classpath setup problem"?
It makes no sense to me because
the deployers can set up any class arrangement they want, and they can
also arrange for TCCL to be set as needed as well.
Right but e.g. for usecase where
user uses JAX-WS API directly
from servlet (or EJB) then web (or EJB3) container is responsible
for setting the proper TCCL.
Maybe illustrating stack trace will tell U more ;)
---
15:37:41,887 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jaxws-endpoint-servlet]]
(pool-2-thread-1) StandardWrapper.Throwable: java.uti
<------>at java.util.ServiceLoader.fail(ServiceLoader.java:224) [:1.6.0_20]
<------>at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
[:1.6.0_20]
<------>at
java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:370)
[:1.6.0_20]
<------>at java.util.ServiceLoader$1.next(ServiceLoader.java:438)
[:1.6.0_20]
<------>at
javax.xml.ws.spi.Provider.getProviderUsingServiceLoader(Provider.java:146)
[jboss-jaxws-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]
<------>at javax.xml.ws.spi.Provider.provider(Provider.java:106)
[jboss-jaxws-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]
<------>at javax.xml.ws.Endpoint.create(Endpoint.java:127)
[jboss-jaxws-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]
<------>at
org.jboss.test.ws.jaxws.endpoint.EndpointServlet.init(EndpointServlet.java:64)
[classe:]
<------>at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208)
[jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
<------>at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1108)
[jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
<------>at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3628)
[jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
<------>at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3851)
[jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
<------>at
org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:61)
[jboss-as-web-7.0.0.Alpha2-SNAPSHOT.jar:7.0.0.Alpha2-SNAPSHOT]
<------>at
org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1163)
<------>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[:1.6.0_20]
<------>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[:1.6.0_20]
<------>at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: java.lang.NoClassDefFoundError: javax/xml/ws/spi/ServiceDelegate
<------>at java.lang.Class.forName0(Native Method) [:1.6.0_20]
<------>at java.lang.Class.forName(Class.java:264) [:1.6.0_20]
<------>at
java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:362)
[:1.6.0_20]
<------>... 14 more
---
Can you or Richard elaborate on the specific issues?
Rio
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942