[jboss-as7-dev] Missing dependencies in Web & EJB3 AS7 modules

[Richard Opalka]

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 at redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942