Marina,
Responses below:
On 9/27/2011 11:44 PM, Marina Vatkina wrote:
>> The CDI/enablement question is actually a very interesting one. Per
>> se, you don't actually "need" CDI for any of this since we are just
>> talking about the JSR 330 annotations. The only issue is that in a
>> Java EE environment, currently only CDI recognizes the JSR 330
>> annotations, including @Inject. That being said, binding this to CDI
>> does have some very good advantages:
>>
>> 1. The jar scanning is already figured out via META-INF/beans.xml.
>> 2. CDI already defines integration points with all managed beans
>> (conceivably including Servlets).
>> 3. CDI does the "grunt" work of component scanning, proxying,
>> life-cycle management, scoping, injection, etc for you.
>> 4. Leveraging the CDI SPI can make implementations relatively
>> portable (I say relatively because there is bound to be requirements
>> for deep container integration for JCA, JTA, thread pools,
>> monitoring, etc).
>> 5. You could conceivably leverage the META-INF/beans.xml for XML
>> based configuration.
> But you won't put JMS info there, right? In particular with the
> Platform EG discussion on standardized resources definition...
I think the resource definitions should be allowable in all XML
descriptors, including beans.xml. However, I was talking more about the
messaging metadata. The CDI based XML syntax allows for placing flexible
meta-data on beans quite nicely (including @Inject qualifiers).
>>
>> If you have a different view on this, I would certainly like to hear
>> it. I think the main issue of making this completely CDI agnostic is
>> figuring out the jar scanning.
>
> All pre-CDI containers know how to scan Java EE applications. So
> scanning shouldn't be the reason to use CDI.
The issue here is that in this case, I think we are talking about a
post-CDI "container" (or more precisely lack thereof). That being said,
I suppose in theory you could do this via @ManagedBean and somehow have
whatever container processes @ManagedBean also process JSR 330
annotations (personally I was never too sure what the purpose of
@ManagedBean was and what jars it is supposed to belong inside).
However, to Pete's point, why bother doing that when one could utilize
the CDI container that's already available in the environment? In fact,
Resin basically consolidates all component life-cycle management to it's
core CDI engine for this reason instead of having a bunch of
infrastructure code (aka "containers") that basically do the exact same
things. We really don't have separate Servlet, EJB, etc "containers". We
just have a bunch of services that build on a common IoC core...
Cheers,
Reza