Re[2]: [higgins-dev] java.security style IdAS Registration

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Markus,

Actually I see a problem with that.

One of very important use cases for us (implementation of
URI/relationship cards) is to create an instance of IContext from a
ContextID which is in general unknown at the deployment stage.

In this case we need to be able to add somehow context configuration
at runtime. The only additional information we have in this case is
that our instance of a context must have specific schema.

Valery

Wednesday, July 11, 2007, 4:42:14 AM, you wrote:

> Hello Jim,

> I'm especially looking forward to your feedback.

> The new IdASRegistry will only instantiate and configure Context
> Factories that are really needed. It will not start up with a fully
> populated list of everything it can find. Once a Context Factory is
> instantiated and configured, it will be cached by the IdASRegistry
> in case it is needed again later (unless the cache is explicitly disabled).

> I agree U1 is the "core use case", and it will be easy.
> U2 will also be possible but obviously is a more expensive operation than U1.
> U3 (with my current understanding) will NOT be possible. The
> IdASRegistry can find a Context Factory for a given Context Id, but
> it can NOT register Context Ids or Contexts itself. If anyone sees a
> problem with that, let me know !!! 

> More information + examples + code coming soon...

> Markus

> On 7/10/07, Jim Sermersheim <jimse@xxxxxxxxxx > wrote:
>   
>  
> Markus,
>  
>  
>  
> I've been wondering about the way the current IdASRegistry works
> and am interested in finding out what you'll be doing to change it. 
> For example, I dislike that the current IdASRegistry gets populated
> with Context Factories that may never be used.  Sometimes I'm left
> wondering -- why do we need an IdASRegistry at all?  
>  
>  
>  
> I think we need some use cases.  If the only use case we have is like this:
>  
> U1) From a known ContextID, create an instance of IContext
>  
>  
>  
> then it seems like we only need a way to resolve the contextID to
> the proper config data, from that context config we locate the
> context factory config data, and between these two sets of data,
> we're able to get an instance of the factory, and from that, get an
> instance of the context.  For this, I don't see a need to fill up a
> registry from which we then query as to which factory can produce the context.
>  
>  
>  
> If we have other use cases like:
>  
> U2) Enumerate all known Context Factories
>  
> U3) Enumerate all known Contexts, all instantiated Contexts, or all potential Contexts
>  
>  
>  
> then we might need something more like today's registry.  At first,
> we thought we might need U2 and/or U3, but no one has ever used them (that I know of).
>  
>  
>  
> Likely there are even more use cases that I haven't listed, but
> none of which have been required yet either.
>  
>  
>  
> Jim

>>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 7/10/07 5:21 PM >>> 

> Hello,

> Just to let everyone know, I have been working on a replacement for
> IdASRegistry, which uses XRDS documents to register and retrieve
> context factories. I will have much more information about this
> within the next few days and then hope to get feedback / suggestions on it!

> For now I can say it will make proper use of the Configuration
> component, so if you make JNDIContextFactory a configurable component, that's the way to go!

> Markus

>   
> On 7/10/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:  
> Is anyone using the java.security style of registering Context
> Factories any more?  It seemed an odd fit from the get go but now
> that I'm converting over to the new higgins configuration code in
> the JNDI CP, I will not even be able to support that method any
> more.  I'm making the JNDIContextFactory a configurable component
> and the  java.security method doesn't allow for any additional
> configuration to be passed.  I could support a "null" configuration
> for the JNDIContextFactory (which is, in essence, what I've done
> until now), but I figure, why support this method at all any more if
> noone is using it.  The only code I know of which even try to test it is in the JNDI CP test suite.

> I vote we rip the java.security registration mechanism out of the
> IdASRegistry.  Can anyone justify it's continued existence?

> Thanks,
> Tom


> _______________________________________________
>  higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/higgins-dev



>  
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/higgins-dev



>