12:47 p.m.
Hi all, I have been looking at whole code of service based naming stores, and we have
several more issues (beyond the injection without lookup), some which may motivate deep
changes on the logic:
1. Subcontext created not stored
InitialContext context = new InitialContext();
context.createSubcontext("a");
Context a = (Context) context.lookup("a");
The lookup above fails, and this due to not creating sub contexts on the store. I
discussed this briefly with David last week, seems a bug, but it could also be done this
way as a feature. As it is now implemented, a context only exists if there a child entry.
Obviously by not having sub contexts we also fail on managing sub contexts environments,
it is always null, when it should start as the parent context's one, and store changes
on its own.
Note that this implementation choice was clearly made on purpose, there is no
destroyContext() impl at all (other than name validation and check for writable store
type).
This implementation choice saves the storing of a few msc services, but that also means no
dependencies to contexts will exist
2. (Re)Bind without parent context
Context a = null;
InitialContext context = new InitialContext();
try {
a = (Context) context.lookup("a");
} catch (NameNotFoundException e) {
context.bind("a/b",new Object());
}
The bind above will succeed, i.e. we allow binds without parent context, but according to
Context javadocs bind or rebind require that the parent context exists.
3. Linkrefs madness
Currently the lookup logic, wrt links is more or less: lookup a msc service with the
provided name, and if nothing found look for a parent msc service, which if exists and is
a link then we try again with link value + remaining name. Then on bind we do not follow
links, we bind directly to the provided name, so:
InitialContext context = new InitialContext();
context.bind("a1",new LinkRef("a2"));
context.bind(new CompositeName("a2","b"),new Object());
context.bind(new CompositeName("a1","b"),new Object());
context.lookup(new CompositeName("a1","b"));
context.lookup(new CompositeName("a2","b"));
This will bind 2 values to the same "logic" name, and both lookups will work,
yet return the different values. To fix this on bind we should first lookup the parent
context, which if follows links correctly, would have failed context.bind(new
CompositeName("a1","b"),new Object())
There are also obvious link related issues on msc deps: if something is bound using a name
that contains a link, lookup deps will only work if use the name used in bind. Fixing this
part may be scary, msc would need to know that when a link is bound, deps to both
linksource/x and linktarget/y may become satisfied. Still on msc topic, rebind support is
also a problem.
4. Other issues
There are other issues, for instance rebind does unbind+bind, and this would mean that any
state (such as env on the old entry) is lost, msc deps get screwed, etc. but I did not
check these with testing yet, and we can probably target these later.
5. So, how do we fix all of this?
Well, for a start should we fix it? I know some people may want to avoid these kind of
changes, but naming is not quite something that is going away any soon, and imho our
naming is broken at so many ways...
IF we go for fixing it, start by adding and requiring the missing contexts, while at same
time provide an option for create these automatically on bind, to be used on everything
besides direct jndi app code, avoiding changes on binding code everywhere on AS projects.
And then reverse the bind/lookup logic wrt links, first lookup the parent, to follow links
properly, and only then bind/lookup the terminal part of the name. Wrt implementation this
would also mean that we probably would make it much faster by having each context with a
map of terminal name childs, dunno about memory... Currently we have in each store a
ConcurrentSkipListSet, and use lower/ceiling functionally to navigate through it.
Wrt MSC, we could for a start try to not fix all at once, as I have been saying to David,
thus ignore the existence of links targets, BUT ensuring all understand the limitations
for dependencies if links are used. Anyway I believe David wants to go further on this so
I will just leave it for him to comment.
--E
4:05 p.m.
Hi Eduardo,
Se my commends inline:
On Apr 1, 2013, at 12:47 PM, Eduardo Martins <emartins(a)redhat.com> wrote:
Hi all, I have been looking at whole code of service based naming
stores, and we have several more issues (beyond the injection without lookup), some which
may motivate deep changes on the logic:
1. Subcontext created not stored
InitialContext context = new InitialContext();
context.createSubcontext("a");
Context a = (Context) context.lookup("a");
The lookup above fails, and this due to not creating sub contexts on the store. I
discussed this briefly with David last week, seems a bug, but it could also be done this
way as a feature. As it is now implemented, a context only exists if there a child entry.
It was certainly a design choice. Keep in mind that the EE contexts are read-only, so
supporting this kind of thing wasn't required (although it would be better if we threw
exceptions or something like that to say you can't do this). The one exception is of
course the writable areas that we allowed as an additional feature (where we let users
call bind).
In the case of a writable bind area, at the time it was decided to allow users to place
dependancies on things they bind. That way you could have something like an @Resource
pointing to something that a user manually creates. We should validate whether or not that
is still important. If it's not important, we could switch the writable areas to a
non-service based JNDI mechanism.
If we do keep the service backing approach we could just fix the bug by having
createSubcontext return a temporary Context (this is exactly what we do if you pull a
context that does have leafs).
Obviously by not having sub contexts we also fail on managing sub
contexts environments, it is always null, when it should start as the parent context's
one, and store changes on its own.
I don't follow this point, can you explain in more detail?
Note that this implementation choice was clearly made on purpose, there is no
destroyContext() impl at all (other than name validation and check for writable store
type).
This implementation choice saves the storing of a few msc services, but that also means
no dependencies to contexts will exist
Right all service based injectable components are not contexts, they are leaf nodes.
Maintaining branch nodes means additional locking and memory usage.
2. (Re)Bind without parent context
Context a = null;
InitialContext context = new InitialContext();
try {
a = (Context) context.lookup("a");
} catch (NameNotFoundException e) {
context.bind("a/b",new Object());
}
The bind above will succeed, i.e. we allow binds without parent context, but according to
Context javadocs bind or rebind require that the parent context exists.
Right this is a "feature" side effect when you don't have branches. I
don't think its a big deal.
3. Linkrefs madness
Currently the lookup logic, wrt links is more or less: lookup a msc service with the
provided name, and if nothing found look for a parent msc service, which if exists and is
a link then we try again with link value + remaining name. Then on bind we do not follow
links, we bind directly to the provided name, so:
InitialContext context = new InitialContext();
context.bind("a1",new LinkRef("a2"));
context.bind(new CompositeName("a2","b"),new Object());
context.bind(new CompositeName("a1","b"),new Object());
context.lookup(new CompositeName("a1","b"));
context.lookup(new CompositeName("a2","b"));
This will bind 2 values to the same "logic" name, and both lookups will work,
yet return the different values. To fix this on bind we should first lookup the parent
context, which if follows links correctly, would have failed context.bind(new
CompositeName("a1","b"),new Object())
There are also obvious link related issues on msc deps: if something is bound using a
name that contains a link, lookup deps will only work if use the name used in bind. Fixing
this part may be scary, msc would need to know that when a link is bound, deps to both
linksource/x and linktarget/y may become satisfied. Still on msc topic, rebind support is
also a problem.
This is another "feature" of not having contexts and having names reflect
services. There is no way to fix it without introducing branches and fat locks. This I
think goes back to the question of whether user directed bind() is service based and has
dependencies or if it's not and is just a locked tree.
4. Other issues
There are other issues, for instance rebind does unbind+bind, and this would mean that
any state (such as env on the old entry) is lost, msc deps get screwed, etc. but I did not
check these with testing yet, and we can probably target these later.
5. So, how do we fix all of this?
Well, for a start should we fix it? I know some people may want to avoid these kind of
changes, but naming is not quite something that is going away any soon, and imho our
naming is broken at so many ways…
Well first of all, we can't make changes like this in EAP 6.x due to all of the
compatibility implications. Second of all the primary purpose of service-backed naming is
not to be a fully complete writable JNDI implementation. That is of lesser concern because
the primary purpose is to support dependency wiring concurrently with decent CPU and
memory efficiency. As mentioned above though I'm open to using a different
implementation for bindable contexts (which would not allow for dependencies expressed
against them).
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
10:21 a.m.
Hi, just a clarification inline, I will send another mail gathering some
points you and Stuart made for an easier discussion.
On Mon, 2013-04-01 at 16:05 -0500, Jason Greene wrote:
Hi Eduardo,
Se my commends inline:
On Apr 1, 2013, at 12:47 PM, Eduardo Martins <emartins(a)redhat.com> wrote:
> Hi all, I have been looking at whole code of service based naming stores, and we
have several more issues (beyond the injection without lookup), some which may motivate
deep changes on the logic:
>
> 1. Subcontext created not stored
>
> InitialContext context = new InitialContext();
> context.createSubcontext("a");
> Context a = (Context) context.lookup("a");
>
> The lookup above fails, and this due to not creating sub contexts on the store. I
discussed this briefly with David last week, seems a bug, but it could also be done this
way as a feature. As it is now implemented, a context only exists if there a child entry.
It was certainly a design choice. Keep in mind that the EE contexts are read-only, so
supporting this kind of thing wasn't required (although it would be better if we threw
exceptions or something like that to say you can't do this). The one exception is of
course the writable areas that we allowed as an additional feature (where we let users
call bind).
In the case of a writable bind area, at the time it was decided to allow users to place
dependancies on things they bind. That way you could have something like an @Resource
pointing to something that a user manually creates. We should validate whether or not that
is still important. If it's not important, we could switch the writable areas to a
non-service based JNDI mechanism.
If we do keep the service backing approach we could just fix the bug by having
createSubcontext return a temporary Context (this is exactly what we do if you pull a
context that does have leafs).
> Obviously by not having sub contexts we also fail on managing sub contexts
environments, it is always null, when it should start as the parent context's one, and
store changes on its own.
I don't follow this point, can you explain in more detail?
You can pass an env properties map, and for subcontexts it inherits the
one from its parent. You can go further and then set env properties
specific to that subcontext (see
http://docs.oracle.com/javase/1.5.0/docs/api/javax/naming/Context.html#ad...,
java.lang.Object) or simply retrieve that map. We currently do not support any of this,
cause like I said, there is no state stored for subcontexts.
1:52 p.m.
New subject: Naming Issues - Part 2
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
11:12 a.m.
New subject: Naming Issues - Part 2
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
11:32 a.m.
New subject: Naming Issues - Part 2
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(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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
11:46 a.m.
New subject: Naming Issues - Part 2
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(a)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(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
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)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
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:50 a.m.
New subject: Naming Issues - Part 2
Sounds good then.
On 04/09/2013 11:46 AM, 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(a)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(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
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)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
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
5:01 p.m.
New subject: Naming Issues - Part 2
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(a)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(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
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)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
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:42 a.m.
New subject: 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.
--E
On Apr 9, 2013, at 11:01 PM, Stuart Douglas <stuart.w.douglas(a)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(a)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(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
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)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
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:41 p.m.
New subject: Naming Issues - Part 2
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(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<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<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
4277
days inactive
4287
days old
10 comments
4 participants
participants (4)
-
David M. Lloyd -
Eduardo Martins -
Jason Greene -
Stuart Douglas