2:34 p.m.
Copy/paste the IRC log for tracking the discussion
---
<opalka> dmlloyd, Nihility Folks, I'm reading your discussion about EE
Apis/Impls U had - http://fpaste.org/8UEL/
<opalka> dmlloyd, Nihility is it the suggested solution? Could U explain
it more?
<dmlloyd> opalka: well your issue was a little different from alessio's
<opalka> dmlloyd, what U mean?
<dmlloyd> opalka: at least from your email. The solution we're going
with for WS is two part: 1) hide the impl from the user deployment,
modify the API to use a module-friendly mechanism for finding the impl,
and use a special aggregate CL for the TCCL but only when calling into
CXF; 2) later, we will fix CXF to only use TCCL for searching the user
deployment and use a different provided CL for searching for its own
components
<opalka> dmlloyd, I see U know about the CXF issue i.e. that it uses
TCCL for everything ;)
<opalka> dmlloyd, 2) makes perfect sense to me
<dmlloyd> opalka: yeah we need to lay out a rule that TCCL = user
deployment *only*, and should not be used for anything else
<opalka> dmlloyd, there's one unclear part for me in 1) - what U mean
with ' modify the API to use a module-friendly mechanism for finding the
impl' ?
<opalka> dmlloyd, I completely agree on 2) - this needs to be fixed on
CXF side
<dmlloyd> opalka: that's just a nice way of saying, make it do
Class.forName("our.impl.Class", true,
Module.loadModule("org.jboss.ws.whatever").getClassLoader()) if no match
is found on the TCCL
<opalka> dmlloyd, ok, understood
<dmlloyd> opalka: I feel confident that the spec allows this, or close
enough
<opalka> dmlloyd, thanks for feedback
<dmlloyd> np
---
Rio
On 02/15/2011 09:51 PM, Richard Opalka wrote:
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