Moving to new g. tx and connector jars without all the gbean fluff

[David Jencks <da...@yahoo.com>]

IIUC dblevins recently tried to move to the new g. tx and connector  
jars and was stymied by the api change I made so container managed  
security for connectors can work outside geronimo.

The GenericConnectionManager constructor used to take a boolean  
containerManagedSecurity, and if true it would install a  
SubjectInterceptor that extracted the "next caller" from geronimo's  
ContextManager singleton.

Now if you want container managed security you pass it a  
SubjectSource that the SubjectInterceptor can get the subject from.   
If you don't want container managed security you pass null.

I don't know how openejb would implement container managed security,  
although the boolean is in GeronimoConnectionManagerFactory, so I'm  
not really sure how to update this myself.  The simplest is to not  
implement container managed security at all -- as far as I know no  
one has ever used it -- and just pass null.

If you do want container managed security you have some more work to  
do :-)

You have to have a login module (or other code) that will install a  
javax.resource.spi.security.PasswordCredential into the subject's  
private credentials.   This thing has username, password, and also  
the ManagedConnectionFactory the credential is aimed at.  Theres an  
example of such a login module in geronimo in geronimo-connector, the  
CallerIdentityPasswordCredentialLoginModule an associated gbean that  
puts the MCF into the lm's options.

thanks
david jencks
  

Re: Moving to new g. tx and connector jars without all the gbean fluff

[David Jencks <da...@yahoo.com>]

On Jul 27, 2007, at 12:19 PM, David Blevins wrote:

> On Jul 26, 2007, at 8:17 PM, David Jencks wrote:
>
>> IIUC dblevins recently tried to move to the new g. tx and  
>> connector jars and was stymied by the api change I made so  
>> container managed security for connectors can work outside geronimo.
>>
>> The GenericConnectionManager constructor used to take a boolean  
>> containerManagedSecurity, and if true it would install a  
>> SubjectInterceptor that extracted the "next caller" from  
>> geronimo's ContextManager singleton.
>>
>> Now if you want container managed security you pass it a  
>> SubjectSource that the SubjectInterceptor can get the subject  
>> from.  If you don't want container managed security you pass null.
>>
>> I don't know how openejb would implement container managed  
>> security, although the boolean is in  
>> GeronimoConnectionManagerFactory, so I'm not really sure how to  
>> update this myself.  The simplest is to not implement container  
>> managed security at all -- as far as I know no one has ever used  
>> it -- and just pass null.
>>
>
> Seems like we can easily take the first option now and if someone  
> has time (or there's any user interest) we can poke at the  
> container managed security for resources later.

I did this and committed earlier this afternoon.  It doesn't appear  
to have caused any problems.

thanks
david jencks

>
> -David
>

Re: Moving to new g. tx and connector jars without all the gbean fluff

[David Blevins <da...@visi.com>]

On Jul 26, 2007, at 8:17 PM, David Jencks wrote:

> IIUC dblevins recently tried to move to the new g. tx and connector  
> jars and was stymied by the api change I made so container managed  
> security for connectors can work outside geronimo.
>
> The GenericConnectionManager constructor used to take a boolean  
> containerManagedSecurity, and if true it would install a  
> SubjectInterceptor that extracted the "next caller" from geronimo's  
> ContextManager singleton.
>
> Now if you want container managed security you pass it a  
> SubjectSource that the SubjectInterceptor can get the subject  
> from.  If you don't want container managed security you pass null.
>
> I don't know how openejb would implement container managed  
> security, although the boolean is in  
> GeronimoConnectionManagerFactory, so I'm not really sure how to  
> update this myself.  The simplest is to not implement container  
> managed security at all -- as far as I know no one has ever used it  
> -- and just pass null.
>

Seems like we can easily take the first option now and if someone has  
time (or there's any user interest) we can poke at the container  
managed security for resources later.

-David