cl.getResources() doesn't work from module-based code

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

cl.getResources() doesn't work from module-based code

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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

David Lloyd-2
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.

See http://is.gd/5E6ym8 for more info.

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


--
- DML


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Rob Cernich
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Rob Cernich
----- Original Message -----
> Thing is, this works for regular Resteasy WAR deployments.
> Thread.currentThread().getContextClassloader().

I think the rules are different for modules.  If you have access to your module's class loader, I would use that.  You might want to peruse some of the other subsystems' code for examples.  (I'm not an expert; just a user.)

>
> 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
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke
In reply to this post by Bill Burke
Ok, in my LoginModule class, I outputed the results from using
getClass().getClassLoader().getResources("META-INF/services" + ...);

This works fine.  But, this doesn't help me as internally Resteasy uses
the thread context classloader to find services files.  How can I change
resteasy so that it uses the correct classloader *internally* in all
environments?  From a WAR deployment I need to find META-INF/services
located both in the deployment and in any imported modules.

Read this did not help me:

https://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide

Didn't help because I'm looking for resources spread out in different
jars, so I don't have a classloader rrefernce point to use other than
the context class loader.

On 9/12/2012 11:59 AM, Bill Burke wrote:

> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

David Lloyd-2
In reply to this post by Bill Burke
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.

Now if you don't want to actually load service implementations from the
deployment itself then you definitely shouldn't be using TCCL; in this
case you'd just use your "skeleton key" module's class loader.

On 09/12/2012 10:59 AM, Bill Burke wrote:

> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>


--
- DML


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke


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

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

David Lloyd-2
On 09/12/2012 11:48 AM, Bill Burke wrote:

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

It's honestly pretty tricky.  When you're loading a class you have to
ask yourself, where might they come from?  And the answer is different
in a standalone application, and it will be different again once Java
has modules.

Context class loader is, like I said, what you want to use when you're
loading from the deployment or current application.  But in some
environments it's just null, so you can't use it everywhere.  The class
loader of the library itself is fine if you're loading from a statically
defined set of implementations.  This won't include any per-deployment
stuff though obviously.

The best answer is really to have a configuration option where you
supply one *or more* class loaders from which resources should be
loaded.  You might even need more than one in the case where some things
are user-overrideable and some are not; you'd also want a configuration
option for each set to include or exclude TCCL.

For a standalone application, most of the time using your current CL is
the best option because it'll be a single flat CL including everything.
  In addition you can include TCCL where appropriate, though it is
usually null for standalone stuff.  So this is really a pretty sane
default that should work both in and out of container environments.

There are some other tricky little issues though.  You must make sure
that you load a resource from the same CL that reported it.  In
addition, you have to flatten duplicates (you would do this by Class
instance, not by string-form class name) because it's possible (likely,
even) that the same implementation might appear via more than one CL.

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

--
- DML


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke


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?


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

David Lloyd-2
On 09/12/2012 12:48 PM, Bill Burke 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?

That seems perfectly reasonable to me.  I think that any time it makes
sense to set TCCL we should do so.

--
- DML


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Anil Saldhana
In reply to this post by Bill Burke
Bill,
   the key to this CL puzzle with the JDK jaas stack may lie here:
https://github.com/anilsaldhana/jboss-as/blob/master/security/src/main/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java

Regards,
Anil

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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

jtgreene
Administrator
In reply to this post by Bill Burke

On Sep 12, 2012, at 12:48 PM, Bill Burke <[hidden email]> 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.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Anil Saldhana
On 09/12/2012 01:22 PM, Jason Greene wrote:

> On Sep 12, 2012, at 12:48 PM, Bill Burke <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Bill Burke


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 <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java

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.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Anil Saldhana
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 <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java
> 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.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

jtgreene
Administrator

On Sep 12, 2012, at 2:53 PM, Anil Saldhana <[hidden email]> 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 <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java
>> 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

jtgreene
Administrator

On Sep 12, 2012, at 2:57 PM, Jason Greene <[hidden email]> wrote:

>
> On Sep 12, 2012, at 2:53 PM, Anil Saldhana <[hidden email]> 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 <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java
>>> 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.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: cl.getResources() doesn't work from module-based code

Anil Saldhana
On 09/12/2012 03:57 PM, Jason Greene wrote:

> On Sep 12, 2012, at 2:57 PM, Jason Greene <[hidden email]> wrote:
>
>> On Sep 12, 2012, at 2:53 PM, Anil Saldhana <[hidden email]> 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 <[hidden email]> 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/java/org/jboss/as/security/plugins/ModuleClassLoaderLocator.java
>>>> 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 created a bug: https://issues.jboss.org/browse/AS7-5551
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12