[TransWarp] naming.lookup requires kwarg creationParent

Phillip J. Eby pje at telecommunity.com
Sat May 10 10:05:13 EDT 2003

At 01:20 PM 5/10/03 +0200, ueck at net-labs.de wrote:
>Hi Phillip,
>one thing that often happens to me lately is, that when i do:
>something = naming.lookup(context, "some://url")
>the configuration-context is not set properly.
>to make it work i need to write:
>something = naming.lookup(context, "some://url", creationParent=context)



works correctly; I want to encourage its use as the canonical lookup 
mechanism, because it can lookup relative names as well as absolute ones, 
and it handles properties and utilities too.  And, if 'context' is not a 
component, you can do:


to get the same effect.

In other words, if you want implicit binding (to the context), you must use 
the binding tools.  The naming tools currently require you to be explicit 
about any bindings involved.

>only then, the configuration-machinery works as expected.
>is this wanted in favour to "explicit is better than implicit"??
>it smells like we'll need a FAQ entry for that case ;-) if this
>behaviour stays as is.

It won't.  See below.

>In what situations would one want to lookup something in context
>and not "plugging" it into the configuration-machinery ??
>I'ld expect not having to supply a creation-parent when already
>specifying a context (the possiblity to do it explicit should
>stay .. but if not given one might automagically use the context
>as creation-parent).
>what do you think?

I think it should do as you suggest, and assume the context is the creation 
parent.  And, I thought it already did.

But I think I know why it doesn't, now that you bring it up.  When I first 
introduced the 'creationParent' mechanism there was a separate 
"InitialContext" class that defaulted 'creationParent' to the context's 
parent (which is the object passed to 'naming.lookup()').  Regular naming 
contexts just acquired their creationParent value from their parent 
component.  So it worked without the keyword argument.  Later, I refactored 
to remove the InitialContext class because it was getting in the way of 
something, I forget what.  lookupComponent then still worked as expected, 
because it passed creationParent explicitly.  And, naming.lookup() still 
worked more-or-less okay, because of the old implicit configuration roots.

So, removing the implicit configuration roots exposed this problem, and 
that's good, because it means that prior to now we didn't know what parents 
were being used for things found using naming.lookup()!

Anyway, I'll change 'naming.spi.getInitialContext()' to default 
'creationParent' from 'parentComponent', if it is not supplied.  And, as I 
looked up where to do that, I found that there are several places in the 
naming package where "paramegeddon" wasn't completed, because they are at 
the SPI level rather than the API level.  So, I'll tackle these today as 
well.  :)

More information about the PEAK mailing list