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>

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 >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

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

On 9/12/2012 12:25 PM, David M. Lloyd wrote: > 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. > Well, in this case, my module is only being used/referenced from a configured standalone.xml security-domain login. So I don't think i need to export any services, correct? I was able to get things working if I manually set the context class loader from with the LoginModule code. But this leaves me wondering if there's something I can do internally in Resteasy to have a cover-all solution (please see my previous email/response).

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