[wildfly-dev] JNDI and java:comp, slimming the server, and componentless naming contexts

[Eduardo Martins]

On 04 Feb 2014, at 16:10, David M. Lloyd <david.lloyd at redhat.com> wrote:

> On 02/04/2014 09:55 AM, Eduardo Martins wrote:
>> I’m ok with this, but a few comments inline:
>> 
>> On 04 Feb 2014, at 13:39, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>> 
>>> I think we need to look into a small redesign of how we handle
>>> java:comp, java:module, and java:app.  The reasoning comes in
>>> three parts:
>>> 
>>> * Various specs require that certain names be bound globally
>>> across all of java:comp.
>>> 
>>> * Various other specs implicitly expect to be able to query
>>> theseglobally bound names even if there is no actual
>>> component context.
>> 
>> In theory this doesn’t make much sense to me, if that’s the idea in
>> the specs then it would be preferable to additionally specify an
>> entry in java:global too. For instance, there was recently a thread
>> about a JPA PU pointing to a java:comp datasource, bound by a web
>> component, and even if I don’t think that’s a good design the fact
>> is the user idea was truly to have the web component point the way
>> to the PU, but imagine that instead of a web component there was
>> multiple EJBs binding different datasources to the same java:comp
>> name, which one would the PU target?
> 
> Only the components which are globally bound would be visible if there
> was no component context.  In cases like the one you mention, if a
> component's binding is expected to be present, then the component
> context must be active at that time.  If it cannot be active, then we
> cannot support reading component-created bindings - end of story.  There
> is not a third side to this coin. :-)

Just pointing why I think using java:comp outside of the scope of a component doesn’t “look” good.

> 
>> Anyway I think the Java EE 7 RI has this feature implemented, so in
>> the end users would benefit from common behaviour, just wished this
>> was better specified.
> 
> Might as well wish that rain falls upwards.  The spec is the spec; we
> need to support the behaviors that are specified.  No real room for
> argument here either.

Maybe I explained my point badly, what I mean is that if there was the intention for java:comp binds, the ones present in every java:comp, to be accessible out of the scope of a EE component, something that I never found a reference in any spec, then the specs should have defined these binds in java:global instead of java:comp.

> 
>>> * Duplicating these bindings uses more resources than are
>>> necessary.
>>> 
>> 
>> I believe we still need the same individual MSC services due to at
>> least resource injection of component scoped binds, after all, even
>> if there are cases of truly global java:comp binds, there is always
>> the feature where a component is allowed to override java:comp binds
>> through XML and @Resource.
> 
> Possibly.  We can visit that issue if/when it comes up.

My point is that we won’t save much, if any, resources. Note that right now what we usually have is that the java:comp bind is injected with a java:jboss or java:global object, other than the binder services. And if we need the binder services because of resource injection, to point to particular component’s java:comp naming contexts...

> 
>>> Therefore I think we need to make a small change - we should have a
>>> "global" version of the three context-specific namespaces that act
>>> as a sort of fallback if there's no (component|module|app)-specific
>>> name bound at a location.  This allows us to do a few things:
>>> 
>>> * Satisfy the spec issues * Reduce resource overhead * Allow
>>> globally-configured things in the management config to bind to
>>> component/module/app-specific namespaces
>>> 
>> 
>> One could ask what’s wrong with java:global :-)
> 
> Nothing is wrong with java:global.  But do not get confused between
> "what the user should do" and "what we are expected to support".  I'm
> speaking strictly to the latter.  In that context, it doesn't help to
> enter the former into the argument.

But we already satisfy the specs, there is no spec, or even TCK test, that shows otherwise…

Anyway, I said I’m ok with all of this, just wanted to expressed my concerns, and if no one else has these too, then let’s move on and kick off the action.

—E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140204/f1ae7eec/attachment-0001.html