Jason Greene wrote on 03/20/15 11:34:
>
>> On Mar 16, 2015, at 3:39 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>>
>>> - Resource annotations should only create bindings on component classes
>>> (and their supertypes). This avoids optional or disabled code from
>>> creating bindings.
>>>
>>> - Either the existing all classes scanning mode in beans.xml, or applying
>>> a component annotation can be used to expand this to almost everything.
>>
>> I'm really torn on the two above. My original goal was that deployment did
>> *NOT* need to run any application code. Running CDI bootstrapping during
>> deployment really messes that up. I should be able to deploy an
>> application without starting it, and not have to create any class loaders
>> or initialize any containers for the application.
>>
>> The disadvantage of this approach is that the deployment process doesn't
>> have access to all the information that CDI collects, and so can't tell
>> which beans are actually usable. Again, our original plan was to expose
>> some of these capabilities in the deployment descriptors. We probably need
>> it there anyway for lots of cases that don't involve CDI.
>>
>> So, while I see the attraction of using the results of the CDI bootstrap at
>> deployment time, I think it's simpler if we don't have to do that. I need
>> feedback from the expert group on what the right approach is here.
>
> I went through the thread again, and reexamined all of the various arguments.
> I think what this comes down to is whether or note we view resource injection
> and CDI as integrated or an orthogonal common facility. The former has the
> benefit in that you get things declared in one place with some consistency.
> Following my previous example, if you veto a bean then not getting the
> resource bindings it defines feels intuitive. However, thinking it over again
> I am not sure such benefits will be fully realized by users, since the whole
> advantage of using CDI is that you have injection facilities available, and
> there is really no need to define JNDI bindings. The latter has the benefit
> in that you can have a consistent independent behavior with and without the
> presence of CDI.
And part of that was the desire to be able to @Inject the platform-defined
resources, without the need for the producer method bridge. We really
need to revisit that issue and see if we can come up with an acceptable
and compatible approach.
> While I stated a preference for the integrated approach, I would be ok with
> just keeping them independent and thereby expanding the set of available
> classes for it, provided that:
>
> A) We provide an exclusion facility for EE resource injection (i.e. class
> name globing and perhaps jar exclusions)
Do we need a general exclusion facility, or should we tie this to some sort
of deployment profile/stage facility that describes when to use which
resources?
> B) We come up with a graceful way to handle non-component classes that have
> comp names.
>
> There are two forms of B) that we need to care about.
>
> 1) Defaulted names (e.g. @Resource DataSource blah, @Resurce(name=“foo”)
> DataSource foo) which should just work
>
> 2) Usage of explicit comp names on a non-component class, which was
> previously allowed by many if not all implementations in one way or another,
> and was typically used as a (potentially optional) base class that when
> combined with a component subclass creates a valid binding.
>
> I had originally suggested addressing (B) by just having the class location
> determine the default scope. For example, if a non-component class is in an
> ejb-jar, then it would create bindings in the module namespace. However, the
> addition of processing non-component classes means that this could very well
> be a new source of conflicts, in particular with case (2) when used on an
> ejb-jar, since component namespaces are fully independent.
>
> I am proposing that we instead do three things to address (B) (assuming we
> decide to go the all-classes route):
>
> X) Treat all comp bindings on non-component classes which are not in a war as
> valid but unbound. This addresses (1) and (2) fully, allowing a great deal of
> past code, including snippets in the CDI specification itself to work
> unchanged. The RI already seems to be doing some form of this.
What do you mean by "unbound"?
> Y) Enhance the relevant deployment descriptors to support redefining the
> binding, perhaps by reusing injection-target-class for class bindings. I
> think this fits the original intentions you highlighted in past emails.
Is this more than letting you specify resource references in an ejb-jar
file at the module level?
> The one case this does not address is what happens when a non-war
> non-component lookup class specifies comp in its lookup attribute. However,
> (Y) and (A) could be used to correct such occurrences.
I'm not sure exactly what your example is, but it sounds like this should
be an error case. Is that your proposal, and that the deployer can correct
the error by overriding the mapping?