Hi Svetlin, Many thanks for the writeup - really helpful. I'm reviewing now.
Jon On Fri, Jul 21, 2017 at 12:43 PM, Svetlin Zarev < [email protected]> wrote: > Hi, > > Yesterday the topic was hijaced by unrelated issues, so I'd like to restart > the discussion. > > > The issue is that bind() may create alternative NameNodes for the very same > JNDI name, which results in issues such as being able to bind to objects to > the same JNDI name, or being unable to lookup an object although it is > bound, or getting different objects uppon lookup() depending on the current > IvmContext (i.e. NameNode) from which the lookup is being executed. > > The simplest example is: > > IvmContext root = IvmContext.createRootContext(); > root.bind("a/b/c, "first"); > > IvmContext b = (IvmContext) root.lookup("a/b"); > b.bind("c", "second"); //must fail with NameAlreadyBound, yet it succeeds. > > So if you do the lookup() for "c" from root, you'll get "first", but if you > do it relatively from "b", then you'll get "second". > > The issue is that in the first bind, bind() recursively creates the > NameNodes in the subTree of the previous one (except for the toplevel > context - in this case "a" which is bound to either "lessTree" ot > "grtrTree"). But when doing bind relatively to "b", object is not bound in > the subTree, but either in less/grtrTree, so as a result we end up having > two separate NameNodes for "c". > > I have more cases covered in the unit tests in the first commit in my PR > [1]. > I also prepared a short intro [2] into the IvmContext/NameNode logic, which > I consider essential to understanding the issue and my PR. > > [1] https://github.com/apache/tomee/pull/94 > [2] https://gist.github.com/SvetlinZarev/81eb26ea37072634d76fe3721b9509eb > > Best regards, > Svetlin >
