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

[Eduardo Martins]

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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
>> 
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
> 
> 
> -- 
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev