Re: [weld-dev] spec question on 3.5 Resource Beans
Mark,
On Mon, Feb 15, 2010 at 7:01 PM, Mark Struberg <struberg(a)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
--
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
Attachments:
- attachment.html (text/html — 4.0 KB)