Re: [higgins-dev] Scoping of configuration elements

["Markus Sabadello" <msabadello@xxxxxxxxxxxxx>]

No, this is not possible with XRDS. Every service endpoint is isolated from the others.

However, all we are saying about an IContextId is that it contains everything you need to get an IContext. Right now, the IContextId is always backed by an XRDS document, but this is just one possibility. In theory there can be other kinds of IContextIds that can share some configuration data.

Anyway, at the moment, I think the answer to that question is no.....

Markus

On 7/19/07, Tom Doman < TDoman@xxxxxxxxxx> wrote:

Markus,

While there may be some use case where Context Factories need to share
global configuration, what I need is to share common configuration elements
among Contexts, not Context Factories.

For example, a _javascript_ variable containing a large mapping table that I
want to share across, say, 3 JNDI Contexts, but not my 2 Jena nor my
4 SQL contexts.  Make sense?  Would that be doable in XRDS?

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 7/19/2007 5:14 PM >>>
I am not sure I understand everything in the thread (parent/child
relationships between different configurations?!), but it would be possible
in XRDS to have a global configuration (not just in the individual SEPs).

This global configuration would then be passed as the first parameter of
IConfigurableComponent.configure() and be the same for all context
factories. If you think this makes sense, I'll do it.

Markus

On 7/19/07, Greg Byrd <gbyrd@xxxxxxxx> wrote:
>
>
> After thinking about this more deeply (and reviewing code), there's not
> enough information passed into the SettingHandler to do the sort of scoping
> that you're asking for.  The SettingHandler has no idea about parent/child
> relationships.  The ReferenceHandler only looks through the map that it's
> been given -- in the current MapHandler (and its descendents), this is the
> map that's currently being processed, not the map of all previously-seen
> settings.
>
> I can think of a way for the ReferenceHandler to see the "global" map AND
> the current map -- by changing MapHandler to put the newly-created map into
> the global map before calling the enclosed SettingHandlers.  However, this
> means that a reference would have to include a complete path from the
> top-level map to the particular setting that you want.  ( E.g., find the
> top-level "foo" setting, then look inside it for the "bar" setting, etc.)
> This may be OK, but it doesn't seem easily maintainable.  (If I copy a
> setting, because it's mostly the same, but it's at a different level....)
>
> I can't really think of a way to search "up" to the parent, then
> grandparent, etc., since we have a map, not a tree.
>
> I understand that you want to avoid duplication, and I agree.  Seems even
> harder, though, with the XRDS way of configuring ContextFactories.  Each
> will be its own SEP, and there's no common place to put global info (as far
> as I know).  Could put them in a different file, I guess -- use FileHandler
> to point to the file, open it, create a ConfigurationHandler (or whatever
> you like) to read the settings.  Not pretty.
>
> So, two things:
>
> (1) Does the ReferenceHandler approach that I tried to explain above meet
> your needs?  (Specify from top down.)
> (2) Even if it does, is this capability going to be useless for the XRDS
> configuration anyway?  (In which case, I wouldn't bother to implement it.)
>
> ...Greg
>
>
> Tom Doman wrote:
>
> In the old Realms configuration code that the Novell contributed CPs have been using, we had the ability to scope configuration elements to allow them to be referenced by any element within the same scope or any sub-scope of that element.  For example, in the _javascript_ policy definitions, we could define a mapping table at the highest scope, and reference it throughout a number of context definitions, regardless of the depth of the sub-scope where the reference took place.
>
> In the Higgins configuration code, currently, we can only reference older siblings.  We'd like to be able to retain this scoping ability so we don't have to redefine the same tables in every context.  A "reference by id" mechanism might also suffice or be even cleaner where within the scope we desire it, we can say, "I want elements 12, 19, & 34".  At any rate, we'd like something that allows us to not have to duplicate potentially large pieces of configuration everywhere it's wanted.  Perhaps there's something like this already in there that I've missed.
>
> Thanks,
> Tom
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@eclipse.orghttps://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