[weld-dev] spec question on 3.5 Resource Beans

[Mark Struberg]

> JSR-299 does not define the behavior
> of @PersistenceContext,
> @Resource, etc for non-static fields.

it does. 7.3.6 strongly indicates that a CDI managed bean should react the same like an EE managed bean in that respect:

7.3.6. Lifecycle of resources
The container must perform ordinary Java EE component environment injection upon any non-static field that functions as
a resource declaration, as defined by the Java EE platform and Common Annotations for the Java platform specifications.
The container is not required to perform Java EE component environment injection upon a static field.

The problem is that this may contradict 3.5.1, which a few people did read like injecting e.g. @PersistenceContext into a CDI managed bean is _only_ applicable through the 'Resource bean' producer field way.


So it really comes down to be one question. Should the following line work in a CDI managed bean, yes or no?
private @PersistenceContext(unitName="myUnit") EntityManager myUnitEm;

I talked to a lot of people before writing my mail, but noone could answer this simple question, that's why I asked for clarification. 

strub

--- Gavin King <gavin.king at gmail.com> schrieb am Mi, 17.2.2010:

> Von: Gavin King <gavin.king at gmail.com>
> Betreff: Re: spec question on 3.5 Resource Beans
> An: "Mark Struberg" <struberg at yahoo.de>
> CC: weld-dev at lists.jboss.org
> Datum: Mittwoch, 17. Februar, 2010 20:50 Uhr
> JSR-299 does not define the behavior
> of @PersistenceContext,
> @Resource, etc for non-static fields. So why are you asking
> this
> question here? Refer to the EE spec and the managed bean
> spec to see
> what the requirements are.
> 
> The *only* thing 299 defines is what happens when @Produces
> is
> combined with one of these annotations.
> 
> On Mon, Feb 15, 2010 at 6:01 PM, Mark Struberg <struberg at yahoo.de>
> wrote:
> > Hi!
> >
> > I don't get it if section 3.5 is only meant as an
> example on how to map between e.g. a named persistence unit
> to a @Qualifier defined injection, or if this is now the
> ONLY way to inject @PersistenceUnits, etc.
> >
> > In the older versions of the spec it was explicitly
> defined that (at least in an EE environment) normal
> injections defined in JSR-250 et al must be supported,
> e.g.:
> >
> > private @PersistenceContext(unitName="myUnit")
> EntityManager myUnitEm;
> > private
> @Ressource(lookup="java:global/env/jdbc/CustomerDatasource")
> Datasource customerDs;
> >
> > have been perfectly valid and functional in older spec
> versions.
> >
> > Is this still allowed/has to be supported (in an EE
> environment)? Argument for this: "A resource MAY be declared
> by..."
> > Or will writing this annotations (without @Produces!)
> into a bean will not cause any injection by a JSR-299
> container?
> >
> > In case of injecting @PersistenceContext, adding
> @Produces and a Qualifier imho simply makes them a producer
> field, so I don't understand why there is any need for a
> special 'resource bean' in this case. I also do not
> understand the restriction for disallowing @Named. Of course
> @Named in the EL sense doesn't make much sense for _any_
> @Dependent scoped bean, but @Named is a perfectly valid
> qualifier also! So it would be perfectly valid to write
> > private @Inject @Named("specialEm") EntityManager em;
> >
> > It would also be perfectly possible to provide a
> EntityManager via a producer method btw, isn't?
> >
> > Is there any reason why we cannot simply say that
> injecting EE resources must be provided in an EE container?
> Then all your neat tricks should simply just work?
> >
> > txs 4 clarifying,
> > strub
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Sie sind Spam leid? Yahoo! Mail verfügt über einen
> herausragenden Schutz gegen Massenmails.
> > http://mail.yahoo.com
> >
> 
> 
> 
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com