11:12 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev