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

Wed Apr 10 21:41:26 EDT 2013

We can actually use org.jboss.as.naming.InMemoryNamingStore, the naming 
store we used before the MSC naming store.

Stuart

Eduardo Martins wrote:
> 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
> <https://issues.jboss.org/browse/AS7-6605>.
>
> --E
>
> On Apr 9, 2013, at 11:01 PM, Stuart Douglas <stuart.w.douglas at gmail.com
> <mailto: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
>>> <mailto: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
>>>>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>