Thanks for this Svetlin, I've merged it in. Cheers!
Jon On Mon, Jul 24, 2017 at 10:53 PM, Jonathan Gallimore < [email protected]> wrote: > 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 >> > >
