Mark,<br><br><div class="gmail_quote">On Mon, Feb 15, 2010 at 7:01 PM, Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi!<br>
<br>
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.<br>
<br>
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.:<br>
<br>
private @PersistenceContext(unitName="myUnit") EntityManager myUnitEm;<br>
private @Ressource(lookup="java:global/env/jdbc/CustomerDatasource") Datasource customerDs;<br>
<br>
have been perfectly valid and functional in older spec versions.<br>
<br>
Is this still allowed/has to be supported (in an EE environment)? Argument for this: "A resource MAY be declared by..."<br>
Or will writing this annotations (without @Produces!) into a bean will not cause any injection by a JSR-299 container?<br></blockquote><div><br><br>
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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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<br>
private @Inject @Named("specialEm") EntityManager em;<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It would also be perfectly possible to provide a EntityManager via a producer method btw, isn't?<br></blockquote><div><br>Of course. <br></div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br></blockquote><div><br>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.<br>
<br>-Dan<br><br></div></div>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>