[jboss-as7-dev] cl.getResources() doesn't work from module-based code

[David M. Lloyd]

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