[jboss-as7-dev] Naming Issues

[Eduardo Martins]

Hi, just a clarification inline, I will send another mail gathering some
points you and Stuart made for an easier discussion.

On Mon, 2013-04-01 at 16:05 -0500, Jason Greene wrote:
> Hi Eduardo, 
> 
> Se my commends inline:
> 
> On Apr 1, 2013, at 12:47 PM, Eduardo Martins <emartins at redhat.com> wrote:
> 
> > 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.
> 
> It was certainly a design choice. Keep in mind that the EE contexts are read-only, so supporting this kind of thing wasn't required (although it would be better if we threw exceptions or something like that to say you can't do this). The one exception is of course the writable areas that we allowed as an additional feature (where we let users call bind).
> 
> In the case of a writable bind area, at the time it was decided to allow users to place dependancies on things they bind. That way you could have something like an @Resource pointing to something that a user manually creates. We should validate whether or not that is still important. If it's not important, we could switch the writable areas to a non-service based JNDI mechanism.
> 
> If we do keep the service backing approach we could just fix the bug by having createSubcontext return a temporary Context (this is exactly what we do if you pull a context that does have leafs).
> 
> > 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.
> 
> I don't follow this point, can you explain in more detail?

You can pass an env properties map, and for subcontexts it inherits the
one from its parent. You can go further and then set env properties
specific to that subcontext (see
http://docs.oracle.com/javase/1.5.0/docs/api/javax/naming/Context.html#addToEnvironment(java.lang.String, java.lang.Object) or simply retrieve that map. We currently do not support any of this, cause like I said, there is no state stored for subcontexts.