On 09/12/2012 10:18 AM, Bill Burke wrote: > I'm creating a custom login-module that is declared within > standalone.xml. This module references a new module that I have > deployed (see below). The login-module class uses Resteasy to make > invocations. The problem is that Resteasy is not able to find and > register built-in providers. Resteasy does this by doing: > > Enumeration<URL> en = > Thread.currentThread().getContextClassLoader().getResources("META-INF/services/" > + Providers.class.getName()); > while (en.hasMoreElements()) > { > URL url = en.nextElement(); > > > No URLs are turning up when calling cl.getResources(). Is there some > configuration switch I don't know about? Yeah - any time you have a dependency on a module whose "META-INF/services" you want to access, you have to add "services="import"" to that dependency, else that directory is filtered out.

I don't believe the context classloader is what you want. You may have better luck with something like getClass().getClassLoader(). Best, Rob ----- Original Message ----- > > > On 9/12/2012 11:23 AM, David M. Lloyd wrote: >> On 09/12/2012 10:18 AM, Bill Burke wrote: >>> I'm creating a custom login-module that is declared within >>> standalone.xml. This module references a new module that I have >>> deployed (see below). The login-module class uses Resteasy to >>> make >>> invocations. The problem is that Resteasy is not able to find and >>> register built-in providers. Resteasy does this by doing: >>> >>> Enumeration<URL> en = >>> Thread.currentThread().getContextClassLoader().getResources("META-INF/services/" >>> + Providers.class.getName()); >>> while (en.hasMoreElements()) >>> { >>> URL url = en.nextElement(); >>> >>> >>> No URLs are turning up when calling cl.getResources(). Is there >>> some >>> configuration switch I don't know about? >> >> Yeah - any time you have a dependency on a module whose >> "META-INF/services" you want to access, you have to add >> "services="import"" to that dependency, else that directory is >> filtered out. > > <dependencies> > <module name="org.jboss.resteasy.resteasy-jackson-provider" > services="import"/> > </dependencies> > > Still doesn't work. > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

Thing is, this works for regular Resteasy WAR deployments. Thread.currentThread().getContextClassloader(). On 9/12/2012 11:51 AM, Rob Cernich wrote: > I don't believe the context classloader is what you want. You may have better luck with something like getClass().getClassLoader(). > > Best, > Rob > > ----- Original Message ----- >> >> >> On 9/12/2012 11:23 AM, David M. Lloyd wrote: >>> On 09/12/2012 10:18 AM, Bill Burke wrote: >>>> I'm creating a custom login-module that is declared within >>>> standalone.xml. This module references a new module that I have >>>> deployed (see below). The login-module class uses Resteasy to >>>> make >>>> invocations. The problem is that Resteasy is not able to find and >>>> register built-in providers. Resteasy does this by doing: >>>> >>>> Enumeration<URL> en = >>>> Thread.currentThread().getContextClassLoader().getResources("META-INF/services/" >>>> + Providers.class.getName()); >>>> while (en.hasMoreElements()) >>>> { >>>> URL url = en.nextElement(); >>>> >>>> >>>> No URLs are turning up when calling cl.getResources(). Is there >>>> some >>>> configuration switch I don't know about? >>> >>> Yeah - any time you have a dependency on a module whose >>> "META-INF/services" you want to access, you have to add >>> "services="import"" to that dependency, else that directory is >>> filtered out. >> >> <dependencies> >> <module name="org.jboss.resteasy.resteasy-jackson-provider" >> services="import"/> >> </dependencies> >> >> Still doesn't work. >> >> Bill >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>

If this is in the context of a deployment, then yes the TCCL will be the class loader of the deployment and that's the one you should use if you want the *combination* of services provided to the deployment by the container *plus* the services defined in the deployment itself. But you're using an intermediate aggregate module (which we don't normally do for AS services). This means in order for it to work you have to do two things: 1. Set the dependencies whose services must be visible to the deployment to services="export" 2. When the module is imported into the deployment (presumably via the deployer), it has to import services from that dependency as well.

I hope you *really* hate modules now. :-)

On 9/12/2012 12:58 PM, David M. Lloyd wrote: > > I hope you *really* hate modules now. :-) > No, modules really help out with things a lot. But, IMO, a lot of this complexity you just outlined could be avoided if the various integration points in AS7 set the context classloader to a intuitive default. For EE deployments, the default TCCL is *VERY* logical. For custom login modules, there is a "module" attribute which allows you to specify the module to load the custom class from. Why not just set the TCCL to the specified/declared "module"? Isn't that what you would expect?

On 09/12/2012 01:22 PM, Jason Greene wrote: > On Sep 12, 2012, at 12:48 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> >> On 9/12/2012 12:58 PM, David M. Lloyd wrote: >>> I hope you *really* hate modules now. :-) >>> >> No, modules really help out with things a lot. But, IMO, a lot of this >> complexity you just outlined could be avoided if the various integration >> points in AS7 set the context classloader to a intuitive default. For >> EE deployments, the default TCCL is *VERY* logical. For custom login >> modules, there is a "module" attribute which allows you to specify the >> module to load the custom class from. Why not just set the TCCL to the >> specified/declared "module"? Isn't that what you would expect? > Yes and that's exactly what it *should* be doing. I remember Anil did a JAAS hack but there could be a problem with it. https://github.com/anilsaldhana/jboss-as/blob/master/security/src/main/ja...

On 09/12/2012 02:51 PM, Bill Burke wrote: > > On 9/12/2012 3:48 PM, Anil Saldhana wrote: >> On 09/12/2012 01:22 PM, Jason Greene wrote: >>> On Sep 12, 2012, at 12:48 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> On 9/12/2012 12:58 PM, David M. Lloyd wrote: >>>>> I hope you *really* hate modules now. :-) >>>>> >>>> No, modules really help out with things a lot. But, IMO, a lot of this >>>> complexity you just outlined could be avoided if the various integration >>>> points in AS7 set the context classloader to a intuitive default. For >>>> EE deployments, the default TCCL is *VERY* logical. For custom login >>>> modules, there is a "module" attribute which allows you to specify the >>>> module to load the custom class from. Why not just set the TCCL to the >>>> specified/declared "module"? Isn't that what you would expect? >>> Yes and that's exactly what it *should* be doing. I remember Anil did a JAAS hack but there could be a problem with it. >> https://github.com/anilsaldhana/jboss-as/blob/master/security/src/main/ja... > ANIL, WTF does this have to do with anything? I'm talking about being > able to use TCCL within a login-module and having it work how you would > expect. My login module is using third-party depdnencies that have no > idea they are being run within a login-module. > > This sets up the classloader as a combination of ModuleCL and TCCL. This is the CL that the LM sees.

On Sep 12, 2012, at 2:57 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > On Sep 12, 2012, at 2:53 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com&gt; wrote: > >> On 09/12/2012 02:51 PM, Bill Burke wrote: >>> On 9/12/2012 3:48 PM, Anil Saldhana wrote: >>>> On 09/12/2012 01:22 PM, Jason Greene wrote: >>>>> On Sep 12, 2012, at 12:48 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>>>> >>>>>> On 9/12/2012 12:58 PM, David M. Lloyd wrote: >>>>>>> I hope you *really* hate modules now. :-) >>>>>>> >>>>>> No, modules really help out with things a lot. But, IMO, a lot of this >>>>>> complexity you just outlined could be avoided if the various integration >>>>>> points in AS7 set the context classloader to a intuitive default. For >>>>>> EE deployments, the default TCCL is *VERY* logical. For custom login >>>>>> modules, there is a "module" attribute which allows you to specify the >>>>>> module to load the custom class from. Why not just set the TCCL to the >>>>>> specified/declared "module"? Isn't that what you would expect? >>>>> Yes and that's exactly what it *should* be doing. I remember Anil did a JAAS hack but there could be a problem with it. >>>> https://github.com/anilsaldhana/jboss-as/blob/master/security/src/main/ja... >>> ANIL, WTF does this have to do with anything? I'm talking about being >>> able to use TCCL within a login-module and having it work how you would >>> expect. My login module is using third-party depdnencies that have no >>> idea they are being run within a login-module. >>> >>> >> This sets up the classloader as a combination of ModuleCL and TCCL. This >> is the CL that the LM sees. > Oh you know what. I think the problem is the security subsystem only sets it for the first module in the stack, making it wrong for all the others. /me goes to look Ok I just looked at that code. The TCCL is set to the *last* module. But yeah the problem is that its set once for the whole login stack. I think to correct this picketbox needs to wrap every login module with a TCCL setup/restore wrapper.

I'm creating a custom login-module that is declared within standalone.xml. This module references a new module that I have deployed (see below). The login-module class uses Resteasy to make invocations. The problem is that Resteasy is not able to find and register built-in providers. Resteasy does this by doing: Enumeration<URL> en = Thread.currentThread().getContextClassLoader().getResources("META-INF/services/" + Providers.class.getName()); while (en.hasMoreElements()) { URL url = en.nextElement(); No URLs are turning up when calling cl. getResources(). Is there some configuration switch I don't know about? Here is my module: <module xmlns="urn:jboss:module:1.1" name="org.jboss.resteasy.resteasy-skeleton-key"> <properties> <property name="jboss.api" value="private"/> </properties> <resources> <resource-root path="resteasy-skeleton-key-core-3.0-alpha-1-SNAPSHOT.jar"/> <resource-root path="resteasy-skeleton-key-as7-3.0-alpha-1-SNAPSHOT.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.servlet.api"/> <module name="javax.security.auth.message.api"/> <module name="javax.security.jacc.api"/> <module name="org.jboss.as.web"/> <module name="javax.ws.rs.api"/> <module name="org.picketbox"/> <module name="org.apache.httpcomponents"/> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> <module name="org.jboss.resteasy.resteasy-jaxrs"/> <module name="org.jboss.resteasy.resteasy-crypto"/> <module name="org.jboss.security.web.login-module-authenticator"/> </dependencies> </module>