[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [higgins-dev] java.security style IdAS Registration
|
I agree that it is rather responsibility of context factory to create
a brand new context from scratch but another questions are how to
find a factory which could be able to do this and how to register
newly created context in the registry for later use.
Valery
Thursday, July 12, 2007, 4:30:16 PM, you wrote:
> The way I currently understand this, there cannot be a ContextId
> without an already existing context. It's more or less a 'pointer'
> that is able to deliver all information needed to find a suitable
> context factory and instantiate and configure an IContext object.
> And to create a new context from scratch, for which no ContextId
> exists yet, is I think the responsibility of the context factories, not the IdASRegistry?
> I am now putting together some documentation and examples of what I
> got, and then let's see if it meets everybody's requirements and what I need to change...
> Markus
> On 7/11/07, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
>
>
> You're right about me reading it wrong. Valery states that at
> least at runtime, a ContextID is known. Whether that ContextID is
> resolvable (and it may not be if the context never once existed) is
> sort of what you're getting at I think. Valery also states that he
> needs to add the context config at runtime (which would also imply
> that this might be an act of initially creating a context as opposed
> to simply instantiating an IContext which already has backing
> data). Furthermore, he states that there's a requirement that the
> context must have a specific schema.
>
>
>
> If indeed what's needed is for a context to be created from
> scratch, and a specific schema used, I would think the sequence of events would be like:
>
> 1) Create an SEP containing the context config along with
> the ContextID to be used in the Context Registry.
>
> 1.a) Part of the context config would likely contain some "initial
> creation" information which may include instructions or pointers as
> to required schema (and any other required capabilities).
>
> 2) Associate the context config with either an existing Context
> Provider Registry entry or one that will be created
>
> 2.a) Create the Context Provider Registry entry if needed.
>
> 3) Use the Discovery/Registry/Factory thing Markus is building to
> then do the usual look-up instantiation steps.
>
> 4) I'm assuming the Context factory in this case knows how to
> create a new Context from scratch (where no existing backing data
> was present), and whether or not any cruft from step 1.a would need
> to be removed from the context config.
>
>
>
> If the sequence is correct, then we (or the application) need ways of doing steps 1, 2, and 2.a.
>
>
>
> An alternate sequence would put the burden on the resolver to
> attempt to resolve, and failover into some kind of "create SEP" mode.
>
>
>
> To me, what's slightly odd is the presence of a ContextID without
> there ever being an SEP in the Context Registry. Seems like we'd
> expect to see the entry in the registry before knowing the ContextID.
>
>
>
> Jim
>
>>>> Greg Byrd <gbyrd@xxxxxxxx> 7/11/07 11:30 AM >>>
>
> I interpreted Valery's use case as something different from U3 (enumerate all Contexts).
> "Here's a ContextID that I've never seen before -- create an
> IContext object that corresponds to that ID."
> The proposal, as I understand it, is to use XRI resolution to do
> this, but it must have been created (i.e., have an entry in some
> XRDS file, somewhere). At a previous F2F, we talked about what
> happens when you create a brand new Context -- it's associated with
> a specific ContextFactory, and that information is stored
> somewhere. (We called it the registry.)
> ...Greg
> Jim Sermersheim wrote:
>
>
> If U3 is not possible, then I'm not sure U2 is even feasible (at
> least the way I understand
> http://wiki.eclipse.org/IdAS_Registries_Proposal_2B). I think I
> didn't qualify very well what I meant by "all known". Let me ask differently.
>
>
>
> If we have the notion of a Context Provider Registry (which as I
> understand it is simply another set of service endpoints in one or
> more XRDS documents), then in order to enumerate them all, the
> "enumerator" would have to be configured with (or be able to
> discover) a set of XRDS documents to go looking through. Not
> knowing much about XRI/XRDS, I'm not sure if/how that would work.
>
>
>
> Similarly for U3, if we have the notion of a Context Registry
> (which is also a set of service endpoints in one or more XRDS
> documents), then it seems like the same procedure would be followed to enumerate them.
>
>
>
> Also, I'm still unsure of what's required. It looks like Valery
> has a different use case (find a Context that has X capability). I
> don't think all of a Context's capabilities can be represented in
> the config (in the Context Registry) -- specifically if the
> capability is "supports my favorite schema" -- as capabilities like
> that can change quite dynamically. For that use case, it almost
> seems like we would be required to enumerate all Contexts, and apply the capability test(s) to each.
>
>
>
> Probably best not to let this bog down work toward U1, but we need to keep it in mind.
>
>
>
> Jim
>
>
>
>>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 7/10/07 7:42 PM >>>
> 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
> _______________________________________________
> 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
>
