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

Wed Apr 10 06:42:51 EDT 2013

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130410/14f3066e/attachment-0001.html 