I agree with the use cases, but I would rather see test cases to support them. You are in fact putting them in the wrong location. For an user deployment to see those modules they need to be added to https://github.com/wolfc/jboss-as/blob/ejb3-domain/ejb3/src/main/java/org... This branch is still in experimental stage. Carlo On 02/15/2011 12:04 PM, Richard Opalka wrote: > I'd like to change the following AS7 modules > > org.jboss.as.web > org.jboss.as.ejb3 > > to include the following dependencies > > <!-- JSR 181 WS MD --> > <module name="javax.jws.api"/> > <!-- JSR 224 JAXWS API --> > <module name="javax.xml.ws.api"/> > <!-- JBossWS SPI --> > <module name="org.jboss.ws.spi" /> > <!-- CXF META-INF servicies --> > <module name="org.jboss.ws.cxf.jbossws-cxf-factories" > services="import"/> > <!-- CXF JAXWS API impl --> > <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/> > > It's required by JAX-WS 22 & EE6 specs and TCK to have > JAX-WS client runtime available in Servlets and EJBs automatically. > > I'm also attaching some usecases to demonstrate usecases. > > Objections / comments ? > > Rio > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

U're right Carlo! So any objections / comments if we'd change these DU processors to include these dependencies? This is general DU classpath setup problem :( Rio On 02/15/2011 12:23 PM, Carlo de Wolf wrote: > This is the web equivalent: > https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jbo... > > Carlo > > On 02/15/2011 12:20 PM, Carlo de Wolf wrote: >> I agree with the use cases, but I would rather see test cases to >> support them. >> >> You are in fact putting them in the wrong location. For an user >> deployment to see those modules they need to be added to >> https://github.com/wolfc/jboss-as/blob/ejb3-domain/ejb3/src/main/java/org... >> This branch is still in experimental stage. >> >> Carlo >> >> On 02/15/2011 12:04 PM, Richard Opalka wrote: >>> I'd like to change the following AS7 modules >>> >>> org.jboss.as.web >>> org.jboss.as.ejb3 >>> >>> to include the following dependencies >>> >>> <!-- JSR 181 WS MD --> >>> <module name="javax.jws.api"/> >>> <!-- JSR 224 JAXWS API --> >>> <module name="javax.xml.ws.api"/> >>> <!-- JBossWS SPI --> >>> <module name="org.jboss.ws.spi" /> >>> <!-- CXF META-INF servicies --> >>> <module name="org.jboss.ws.cxf.jbossws-cxf-factories" >>> services="import"/> >>> <!-- CXF JAXWS API impl --> >>> <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/> >>> >>> It's required by JAX-WS 22 & EE6 specs and TCK to have >>> JAX-WS client runtime available in Servlets and EJBs automatically. >>> >>> I'm also attaching some usecases to demonstrate usecases. >>> >>> Objections / comments ? >>> >>> Rio >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > -- Richard Opalka ropalka(a)redhat.com JBoss, by Red Hat Office: +420 222 365 200 Mobile: +420 731 186 942 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Hi Emanuel, yes, we have our own WS DU processor that works well for WS deployments. The issue I raised here is related to pure EJB3/Servlet components that inject WS objects. Such deployments are not detected as WS deployment Rio On 02/15/2011 01:34 PM, Emanuel Muckenhuber wrote: > I think the better approach would be that you add your own DU processor > adding WS module dependencies as part of your subsystem. > > On 02/15/2011 12:53 PM, Richard Opalka wrote: >> U're right Carlo! >> >> So any objections / comments if we'd change >> these DU processors to include these dependencies? >> This is general DU classpath setup problem :( >> >> Rio >> >> On 02/15/2011 12:23 PM, Carlo de Wolf wrote: >>> This is the web equivalent: >>> https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jbo... >>> >>> Carlo >>> >>> On 02/15/2011 12:20 PM, Carlo de Wolf wrote: >>>> I agree with the use cases, but I would rather see test cases to >>>> support them. >>>> >>>> You are in fact putting them in the wrong location. For an user >>>> deployment to see those modules they need to be added to >>>> https://github.com/wolfc/jboss-as/blob/ejb3-domain/ejb3/src/main/java/org... >>>> This branch is still in experimental stage. >>>> >>>> Carlo >>>> >>>> On 02/15/2011 12:04 PM, Richard Opalka wrote: >>>>> I'd like to change the following AS7 modules >>>>> >>>>> org.jboss.as.web >>>>> org.jboss.as.ejb3 >>>>> >>>>> to include the following dependencies >>>>> >>>>> <!-- JSR 181 WS MD --> >>>>> <module name="javax.jws.api"/> >>>>> <!-- JSR 224 JAXWS API --> >>>>> <module name="javax.xml.ws.api"/> >>>>> <!-- JBossWS SPI --> >>>>> <module name="org.jboss.ws.spi" /> >>>>> <!-- CXF META-INF servicies --> >>>>> <module name="org.jboss.ws.cxf.jbossws-cxf-factories" >>>>> services="import"/> >>>>> <!-- CXF JAXWS API impl --> >>>>> <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/> >>>>> >>>>> It's required by JAX-WS 22& EE6 specs and TCK to have >>>>> JAX-WS client runtime available in Servlets and EJBs automatically. >>>>> >>>>> I'm also attaching some usecases to demonstrate usecases. >>>>> >>>>> Objections / comments ? >>>>> >>>>> Rio >>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> -- >> Richard Opalka >> ropalka(a)redhat.com >> JBoss, by Red Hat >> >> Office: +420 222 365 200 >> Mobile: +420 731 186 942 >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I see, i should have read the examples more carefully then ;) Although i was more referring to the fact if you disable e.g. the WS subsystem - it maybe should also disable the client capabilities you mentioned? On 02/15/2011 01:45 PM, Richard Opalka wrote: > Hi Emanuel, > > yes, we have our own WS DU processor that works well for WS deployments. > The issue I raised here is related to pure EJB3/Servlet components > that inject WS objects. Such deployments are not detected as WS deployment > > Rio > > On 02/15/2011 01:34 PM, Emanuel Muckenhuber wrote: >> I think the better approach would be that you add your own DU processor >> adding WS module dependencies as part of your subsystem. >> >> On 02/15/2011 12:53 PM, Richard Opalka wrote: >>> U're right Carlo! >>> >>> So any objections / comments if we'd change >>> these DU processors to include these dependencies? >>> This is general DU classpath setup problem :( >>> >>> Rio >>> >>> On 02/15/2011 12:23 PM, Carlo de Wolf wrote: >>>> This is the web equivalent: >>>> https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jbo... >>>> >>>> Carlo >>>> >>>> On 02/15/2011 12:20 PM, Carlo de Wolf wrote: >>>>> I agree with the use cases, but I would rather see test cases to >>>>> support them. >>>>> >>>>> You are in fact putting them in the wrong location. For an user >>>>> deployment to see those modules they need to be added to >>>>> https://github.com/wolfc/jboss-as/blob/ejb3-domain/ejb3/src/main/java/org... >>>>> This branch is still in experimental stage. >>>>> >>>>> Carlo >>>>> >>>>> On 02/15/2011 12:04 PM, Richard Opalka wrote: >>>>>> I'd like to change the following AS7 modules >>>>>> >>>>>> org.jboss.as.web >>>>>> org.jboss.as.ejb3 >>>>>> >>>>>> to include the following dependencies >>>>>> >>>>>> <!-- JSR 181 WS MD --> >>>>>> <module name="javax.jws.api"/> >>>>>> <!-- JSR 224 JAXWS API --> >>>>>> <module name="javax.xml.ws.api"/> >>>>>> <!-- JBossWS SPI --> >>>>>> <module name="org.jboss.ws.spi" /> >>>>>> <!-- CXF META-INF servicies --> >>>>>> <module name="org.jboss.ws.cxf.jbossws-cxf-factories" >>>>>> services="import"/> >>>>>> <!-- CXF JAXWS API impl --> >>>>>> <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/> >>>>>> >>>>>> It's required by JAX-WS 22& EE6 specs and TCK to have >>>>>> JAX-WS client runtime available in Servlets and EJBs automatically. >>>>>> >>>>>> I'm also attaching some usecases to demonstrate usecases. >>>>>> >>>>>> Objections / comments ? >>>>>> >>>>>> Rio >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-as7-dev mailing list >>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> -- >>> Richard Opalka >>> ropalka(a)redhat.com >>> JBoss, by Red Hat >>> >>> Office: +420 222 365 200 >>> Mobile: +420 731 186 942 >>> >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> 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.

Isn't this just a matter of looking to see if there is a @WebServiceRef in the annotaiton index?

On 2/15/11 9:40 AM, Darran Lofthouse wrote: > On 02/15/2011 03:39 PM, Jason T. Greene wrote: >> >> Isn't this just a matter of looking to see if there is a @WebServiceRef >> in the annotaiton index? > > There are currently plenty of users that will place a WS client within > either their servlets or EJBs but without injection. Yeah ignore that, I half read the post. Technically deployments do need to see the API classes, there is nothing wrong with that. However I am not so sure about: <!-- CXF META-INF servicies --> > <module name="org.jboss.ws.cxf.jbossws-cxf-factories" services="import"/> > <!-- CXF JAXWS API impl --> > <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/> In pricipal user code should only need to import an API. Then the container impl takes care of passing a ref that is castable to the API. The one exception is of course, static factories, which are more complex to solve. I assume thats why we have service loader imports on those.

We should keep in the back of our mind that users may want to override this, and go with some different JAX-WS client (sacraficing EE integration features). Until we have the custom classloading deployment config its hard to say how this will be accomplished.

On 2/15/11 9: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) > Cheers Isn't this just a matter of looking to see if there is a @WebServiceRef in the annotaiton index?

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.

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.

Can you or Richard elaborate on the specific issues?

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 >