[higgins-dev] Re: Bandit-free sample IdAS consumer code

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

>>> Greg Byrd <gbyrd@xxxxxxxx> 11/13/06 3:44 PM >>>
>
>You're passing a string (prop) to registerContextFactory, rather than an 
>IContextFactory (line 55).   I suppose we could add that to the API, but 
>it's currently not there.  You need to create an object first with 
>newInstance().

In my haste, I forgot to mention that I added that method.  We can remove it if in the end it seems useless.  I also prefixed local member variables with an underscore to make the file more readable to me (sorry if this bugs you, I can change back if you want).
 
>You could make this happen automatically when the IdASRegistry is 
>created by: 
>(1) creating a Provider class, 
>(2) setting the "ContextFactory.FOO" property to the class name, and 
> (3) adding the 
>provider class name to the java.security file.  See the JUnit test code 
>for an example of a Provider class.  (In the tests, the provider is add 
>dynamically via Security.addProvider, rather than via the file.)

Yeah, I was thinking of going that route, but wanted to be lazy and cut/paste from an example :)

Actually that's a lie.  What I was hoping for is to be pointed at a Tomcat config file wherin I could specify the required elements of a Provider.Service and have Tomcat add that to its own Provider (assuming it has one).  I haven't yet seen anything like that yet.

I mean, if ultimately I have to read a) the names of the factories, and b) the contextRefs, and if I have to instantiate the factories and add them to the registry. What does the registry buy me?  I think it just makes it so I don't have to call each factory I know about and call canCreate.

>The "FOO" is the "algorithm" name for the factory.  Right now, this is 
>meaningless, but it is used to distinguish between different context 
>factory classes.  It can be anything you want, as long as it's different 
>for each ContextFactory listed in a given Provider.  Maybe later we can 
>standardize on some labels and their meanings.
>
>Registering the contextRef looks fine to me.

I realized later that I actually don't need to register the contextRef because getContextFactories(contextRef) doesn't need them to be registered (doesn't make use of _registeredContextMap)





Jim Sermersheim wrote:
> <resending again, and cc'ing people who might care.  I don't know why 
> these fail to hit the list>
>  
> <resent -- sorry if this is a duplicate>
>  
> Attached.
>  
> Greg, I used the IdASRegistry in a way that I'm sure is not at all 
> intended because effectively all I did was put stuff into a bag and 
> take it back out (see lines 53 through 72).  Can you give us a brief 
> overview or sample of how it's intended to be used (it would be nice 
> if there was an integration with some Tomcat security provider, but we 
> couldn't figure out what to do there)
>  
> I'll start seeing how this should fit into the STS code next (now that 
> it's completely Bandit free)
>  
> Jim