12:47 p.m.
Hi all, I have been looking at whole code of service based naming stores, and we have
several more issues (beyond the injection without lookup), some which may motivate deep
changes on the logic:
1. Subcontext created not stored
InitialContext context = new InitialContext();
context.createSubcontext("a");
Context a = (Context) context.lookup("a");
The lookup above fails, and this due to not creating sub contexts on the store. I
discussed this briefly with David last week, seems a bug, but it could also be done this
way as a feature. As it is now implemented, a context only exists if there a child entry.
Obviously by not having sub contexts we also fail on managing sub contexts environments,
it is always null, when it should start as the parent context's one, and store changes
on its own.
Note that this implementation choice was clearly made on purpose, there is no
destroyContext() impl at all (other than name validation and check for writable store
type).
This implementation choice saves the storing of a few msc services, but that also means no
dependencies to contexts will exist
2. (Re)Bind without parent context
Context a = null;
InitialContext context = new InitialContext();
try {
a = (Context) context.lookup("a");
} catch (NameNotFoundException e) {
context.bind("a/b",new Object());
}
The bind above will succeed, i.e. we allow binds without parent context, but according to
Context javadocs bind or rebind require that the parent context exists.
3. Linkrefs madness
Currently the lookup logic, wrt links is more or less: lookup a msc service with the
provided name, and if nothing found look for a parent msc service, which if exists and is
a link then we try again with link value + remaining name. Then on bind we do not follow
links, we bind directly to the provided name, so:
InitialContext context = new InitialContext();
context.bind("a1",new LinkRef("a2"));
context.bind(new CompositeName("a2","b"),new Object());
context.bind(new CompositeName("a1","b"),new Object());
context.lookup(new CompositeName("a1","b"));
context.lookup(new CompositeName("a2","b"));
This will bind 2 values to the same "logic" name, and both lookups will work,
yet return the different values. To fix this on bind we should first lookup the parent
context, which if follows links correctly, would have failed context.bind(new
CompositeName("a1","b"),new Object())
There are also obvious link related issues on msc deps: if something is bound using a name
that contains a link, lookup deps will only work if use the name used in bind. Fixing this
part may be scary, msc would need to know that when a link is bound, deps to both
linksource/x and linktarget/y may become satisfied. Still on msc topic, rebind support is
also a problem.
4. Other issues
There are other issues, for instance rebind does unbind+bind, and this would mean that any
state (such as env on the old entry) is lost, msc deps get screwed, etc. but I did not
check these with testing yet, and we can probably target these later.
5. So, how do we fix all of this?
Well, for a start should we fix it? I know some people may want to avoid these kind of
changes, but naming is not quite something that is going away any soon, and imho our
naming is broken at so many ways...
IF we go for fixing it, start by adding and requiring the missing contexts, while at same
time provide an option for create these automatically on bind, to be used on everything
besides direct jndi app code, avoiding changes on binding code everywhere on AS projects.
And then reverse the bind/lookup logic wrt links, first lookup the parent, to follow links
properly, and only then bind/lookup the terminal part of the name. Wrt implementation this
would also mean that we probably would make it much faster by having each context with a
map of terminal name childs, dunno about memory... Currently we have in each store a
ConcurrentSkipListSet, and use lower/ceiling functionally to navigate through it.
Wrt MSC, we could for a start try to not fix all at once, as I have been saying to David,
thus ignore the existence of links targets, BUT ensuring all understand the limitations
for dependencies if links are used. Anyway I believe David wants to go further on this so
I will just leave it for him to comment.
--E