geronimo-xbean-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] Closed: (XBEAN-125) getNameInNamespace() is wrong
Date Fri, 03 Apr 2009 21:27:13 GMT

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


Mime
View raw message