IMO that is a good idea! CDI should get even more attention in other specs!
The only problem I see is, that you might want to define for example which
persistence context you like to inject. The class name of a qualifier can
be configured in persistence.xml. Maybe the qualifiers can also replace
jndi names at all? I dont know much about the technical background, but i
would definitely go into this direction. CDI FTW! :)
Regards,
Christian
Am 31.08.2012 10:41 schrieb "Antonio Goncalves" <antonio.goncalves_at_gmail.com
>:
> Hi all,
>
> At my customers I've never seen a EE 6 application running without CDI, it
> really doesn't make sense. As you said, people where reluctant when
> annotations first came, and now they use it everywhere : same thing should
> happen with CDI. CDI should be enabled by default in EE 7 (even without a
> beans.xml file) and we should encourage the other specs to use it. I would
> even go further : javax.faces.bean.ManagedBean in JSF 2.2 should be
> deprecated as developers get confused with @Named. With CDI enabled by
> default, we could use more implicit producers :
>
> @Inject PersistenceContext em;
> @Inject ConnectionFactory conn;
> @Inject Queue q;
> @Inject Principal loggedInUser
>
> and who knows, one day, @Inject Logger log;
>
> As for JAX-RS not willing to embrace CDI, I will try to sell (again) my
> idea of a minimal profile. I've talked about it many times in this mailing
> list, but what about creating a minimal profil with Servlet/JSP/EL and CDI
> ? That will maybe encourage web containers such as Tomcat, Jetty to
> implement this profile. This would also encourage people to use CDI. JAX-RS
> could then run on any "Minimal Profile" container out of the box with CDI
> enabled.
>
> To summarize, CDI should become central to EE 7 and spread to the other
> specs (even dormant one such as JAX-WS)
>
> My 2 cents
> Antonio
>
> On Thu, Aug 30, 2012 at 10:58 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
>
>> From many of our recent discussions, it seems clear that CDI is
>> becoming more central to the Java EE programming model. For example:
>>
>> - The expanded use of @Stereotype in my previous message.
>>
>> - The use of CDI interceptors to provide container managed
>> transaction support beyond EJB.
>>
>> - The potential future use of CDI interceptors to provide container
>> managed security support beyond EJB.
>>
>> - The use of CDI interceptors to support Bean Validation method
>> level validation.
>>
>> - The discussion of "implicit producers" to allow use of @Inject
>> instead of @Resource to inject Java EE resources.
>>
>> - The discussion around alignment of CDI managed beans and the
>> separate @ManagedBean spec.
>>
>> - The introduction of a transaction scope and its use in the JMS
>> spec to simplify the programming model.
>>
>> - The change being considered by the CDI expert group to enable
>> CDI by default, making it more attractive to use it for all
>> the items above.
>>
>>
>> At the same time we're finding that some specs, e.g., JAX-RS, are
>> hesitant to introduce a hard, or even soft, dependency on CDI,
>> instead insisting that all their new features must work in an
>> environment where there is no CDI.
>>
>> In many ways this parallels what we saw with annotations. In
>> the beginning we found many people who didn't want to use annotations
>> and wanted us to make sure everything worked without use of
>> annotations. Now we're seeing many things that *only* work with
>> annotations, and annotations are well accepted by Java EE developers.
>> I suppose there's a natural lifecycle to acceptance of new
>> technologies, and I wonder where we are in that lifecycle with CDI?
>> Has CDI become a mature and accepted technology that we should use
>> widely?
>>
>>
>> I'd like to get a sense from this group as to what direction we
>> should provide to all the Java EE specs in regards to their use
>> of CDI. Here's a few obvious options:
>>
>> A. Technologies that see a significant standalone (non-Java EE) use
>> should be fully functional without CDI. If necessary, any
>> required features that are similar to CDI features should be
>> defined and implemented in a way that doesn't depend on CDI.
>>
>> B. Technologies should provide all major features in a way that
>> works without CDI. Some features may also be provided in a
>> different way that works well with CDI. Some less essential
>> features may only work with CDI. The implementation should
>> only have a soft dependency on CDI at most.
>>
>> C. Technologies should provide features that work well with CDI
>> without duplicating any functionality in CDI. Use CDI wherever
>> it fits. The implementation may have a hard dependency on CDI
>> and may require CDI even when used in a standalone environment.
>>
>> I'm sure you can think of other options as well.
>>
>> What advice do you think we should give to other Java EE specs?
>>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
> LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> |
> Devoxx France <http://www.devoxx.fr>
>