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

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(a)gmail.com <mailto: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&lt;david.lloyd(a)redhat.com >> <mailto: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&lt;emartins(a)redhat.com >>>> <mailto: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(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev