[weld-dev] spec question on 3.5 Resource Beans

[Dan Allen]

Mark,

On Mon, Feb 15, 2010 at 7: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?
>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100216/d2e58156/attachment.html