On Mon, Feb 15, 2010 at 7:01 PM, Mark Struberg
<struberg@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?
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