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 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
