[
https://issues.apache.org/jira/browse/XBEAN-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed XBEAN-125.
------------------------------
Resolution: Fixed
Fix Version/s: 3.5
Assignee: David Jencks
Problems appear to have been only in WritableContext. Fixed in rev 761803.
FIx basically involves constructing a subcontext's nameInNamespace from the
parent context's nameInNamespace rather than the master context's value.
> getNameInNamespace() is wrong
> -----------------------------
>
> Key: XBEAN-125
> URL: https://issues.apache.org/jira/browse/XBEAN-125
> Project: XBean
> Issue Type: Bug
> Components: naming
> Affects Versions: 3.5
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: 3.5
>
>
> NameInNamespace handling seems to be completely wrong. After a lot of poking
> around I found out from the jndi tutorial book p. 339 discussion of fully
> qualified names that getNameInNamespace is supposed to be the complete
> hierachical name in the namespace. Currently it is the name in which a
> subcontext is bound into its parent. Previously I've been confused about
> what a "namespace" is.... on p.13 its defined to be the set of all names in a
> naming system. This appears to mean the names starting at a root context,
> not at a subcontext.
> A related problem is that the nameInNamespace is stripped off a lookup in
> AbstractContext:
> if (stringName.startsWith(nameInNamespace)) {
> stringName = stringName.substring(nameInNamespace.length());
> }
> I'm not sure what should be happening here if anything but the result of the
> current code is that if you create subcontexts to bind
> a/b/c
> and
> a/a/b/c
> the two "b" subcontexts end up being the same object and the second bind
> attempt fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
