[weld-dev] spec question on 3.5 Resource Beans

[Mark Struberg]

Thanks Dan!

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.

Common guess was that this is only for making them Serializable. Is there another reason? Because (after working with OWB on a real world project for 3 months now) I know a lot usecases where this feature would be _really_ nice for other @Dependent beans too.

Remember my Logger question from today? This may also make sense to have something like

private @Inject Logger log;

where the producer looks something like
  public @Dependent(proxied=true) Logger makeLogger(InjectionPoint)...

Or even introduce an own annotation which can be applied at the injection point:

private @Inject @Reinject Logger log;

just a few random ideas.

LieGrue,
strub

--- Dan Allen <dan.j.allen at gmail.com> schrieb am Di, 16.2.2010:

> Von: Dan Allen <dan.j.allen at gmail.com>
> Betreff: Re: [weld-dev] spec question on 3.5 Resource Beans
> An: "Mark Struberg" <struberg at yahoo.de>
> CC: "Gavin King" <gavin.king at gmail.com>, weld-dev at lists.jboss.org
> Datum: Dienstag, 16. Februar, 2010 23:37 Uhr
> 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
> 
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com