Von: Dan Allen <dan.j.allen(a)gmail.com&gt; Betreff: Re: [weld-dev] spec question on 3.5 Resource Beans An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: "Gavin King" <gavin.king(a)gmail.com&gt;, weld-dev(a)lists.jboss.org Datum: Dienstag, 16. Februar, 2010 23:37 Uhr Mark, On Mon, Feb 15, 2010 at 7:01 PM, Mark Struberg <struberg(a)yahoo.de&gt; 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? I'm quite certain that normal injections defined in JSR-250 are supported by any managed bean. Combining it with @Produces and an optional qualifier is merely the recommended approach to confine the string-based lookups into a single point so that you can leverage the type-safe mapping everywhere else in the code base. 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 think it's merely the recommended pattern, based on the assumption that the developer wants to avoid non-type-safe injections as much as possible.   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; Hmm, I'm not sure about this one. My guess the restriction is to discourage the pattern of injecting beans by name, but I really can only guess.   It would also be perfectly possible to provide a EntityManager via a producer method btw, isn't? Of course.   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? I suppose it could be that simple. Perhaps you could use that language in an article. The spec clearly goes the extra step to suggest the resource bean pattern. No necessarily a bad thing to include to encourage a move away from the status quo. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

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

> 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;

> There is maybe a very subtle (and imho inconsistent) detail. In section 7.3.6 is stated that such a > 'Resource Bean' producer field has to wrap (==proxy?) those EE resources even if they are > @Dependent scoped. This is different to a standard producer field, since @Dependent scoped > beans usually don't get proxied at all. It doesn't say anything of the sort. The internal implementation of the container *might* do something like that, but that would never be visible to the application.

From the spec:

Accessing a resource using EL is a really bad idea.

So is using @Named as a qualifier.

Von: Dan Allen <dan.j.allen(a)gmail.com&gt; Betreff: Re: [weld-dev] spec question on 3.5 Resource Beans An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: weld-dev(a)lists.jboss.org Datum: Donnerstag, 18. Februar, 2010 07:40 Uhr 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. Don't apologize or be intimidated to ask for a clarification. That's one of the main reasons we communicate. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen