On Sep 12, 2012, at 2:57 PM, Jason Greene
<jason.greene(a)redhat.com> wrote:
> On Sep 12, 2012, at 2:53 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com> 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>
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.