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

[Alessio Soldano]

I've just created https://issues.jboss.org/browse/JBEE-75 for the 
changes on JBoss JAXWS Api side. That's just the inital set of changes, 
to allow dynamically loading the jbossws client module.
Once that's in, I have all other modifications ready on jbossws and AS7 
side ready to be committed/pulled.

I'll catch Shelly / David on IRC later ;-)
Cheers
Alessio

On 02/16/2011 09:34 PM, Richard Opalka wrote:
> 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
>>


-- 
Alessio Soldano
Web Service Lead, JBoss