[jboss-as7-dev] Naming Issues - Part 2

With the comments from Jason and Stuart all starts to make much more sense, tks both, so trying to refocus: 2. Subcontexts It's good performance and resource wise to not have these stored, and so far users do not seem to need that to happen. Stuart proposed the alternative of reuse what's used for java:comp/env, but unless someone really asks for it and has a good use case I vote for just leave it like it is now. 3. Bind/Lookup Logic I'm with Stuart on the direction to follow here, i.e. just fix the bind() to, even if in a slower process, do a correct binding following links from root context. Note that such change permits that lookup maintains same process of using the lower/ceiling features of the data structure to effectively follow links without the burden of hitting the normal use case, which is lookup hits directly the entry. 4. Additional namespace/store Another proposal from Stuart, if I got it correctly it means we would add another store in a proprietary namespace, and this one would not be bound to msc, yet provide full jndi contract. I like this idea, we could could probably reuse something simple done in the past or just setup the JIRA and allow possible contributions from community if becomes a desirable feature. This store could even be the replicated jndi tree a JIRA is asking for ;) 5. Limitations on MSC based stores. The real deal on this discussion, JIRA issues keep popping up from time to time, mostly asking for changes wrt linkrefs. Linkref is a painful feature to support due to msc dependencies. Everyone needs to understand that right now if you depend on something that was bound with name a1/b, then references that rely on msc must target a1/b too, there is no feature that allows referencing a2/b being a2 a link to a1. I know this limitation is something David wants to target in the future, but personally, in the context of a special limited jndi, I'm not sure it is actually worth to pursuit... Do we really need to have this feature? IMHO we don't, and could probably enforce it is not supported to ensure misuse, rejecting the bind. Note that not supporting linkref would be a significant performance improvement. Any other change to these stores behavior? IMHO we should throw exceptions on unsupported features, such as the ones related to creation/destruction of subcontexts, environments changes, etc. Making it very clear about the limitations wrt full jndi contract. Thoughts? -E