Our msc based naming store is truly bound to msc not only wrt dependencies, after all each entry's value is stored in a msc service, which needs to be managed. Beyond that if at the msc naming store we don't support creation/destruction of contexts, do not support link refs (at least targeting contexts), and allow binds without parent, etc., then it can't be a store fulfilling full jndi contract, and instead user/apps looking for that would rely on the new store available at the new special namespace. By assuming that the msc naming store is to be on a special jndi contract allows us also to tune features and performance. Finally like I mentioned earlier, this new naming store can also be used for the distributed naming store requested on AS7-6605. 

--E

On Apr 9, 2013, at 11:01 PM, Stuart Douglas <stuart.w.douglas@gmail.com> wrote:

The additional naming store should actually be easy. We do not actually need a new naming store, it is just a matter of registering another namespace using our existing store implementation.

Then in the lookup injection source we just don't setup a dependency if the lookup is in that namespace. It should actually be a fairly trivial amount of code.

Stuart

Eduardo Martins wrote:
No grand refactoring here, these below are short/quick fixes, probably less code than what I wrote in the related mail threads already :)

...except the additional naming store (point 4), which I have no plans to implement in the near future (yet a JIRA should be open for possible contributions).

--E

On Apr 9, 2013, at 5:32 PM, David M. Lloyd<david.lloyd@redhat.com>  wrote:

I have thoughts on it :)

As always the priority is on bug fixes, and then EE 7; grand
refactorings are to be minimized for AS 8.

That said if this *must* be fixed *now* (does it, really?), I'd prefer
to go with the most minimal/simple fixes possible.  We'll have plenty of
opportunity to revisit this code when we integrate MSC 2 (probably in
the AS 9 timeframe).

On 04/09/2013 11:12 AM, Eduardo Martins wrote:
No more thoughts about this? Should I then follow the directions below and kick off JIRAs for impl?

Beyond what is below, I think that wrt 5. we could probably support link-refs that dod not involve contexts, so binding sets up a msc del between src and target, and we don't need to navigate back on lookups. This would permit usage on a<link/>  feature of management ops on the naming subsystem. We should probably also remove rebind support on the msc based naming store, it's not used afaik, and would remove the pains wrt to readd the msc services.

--E

On Apr 2, 2013, at 7:52 PM, Eduardo Martins<emartins@redhat.com>  wrote:

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

_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev