Oki, that makes perfect sense! The passivation capability mentioned in 7.3.6 also explains why we need a ResourceBean!
txs and LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Di, 16.2.2010: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: Reservation EntityManagerUtil > An: [email protected] > Datum: Dienstag, 16. Februar, 2010 14:42 Uhr > Mark, > > I skim over JSR-299 specification, and it supports two > style of injection . > As it states in 3.5 via ResourceBean and direct injection > of resources that > are defined within Java EE specification. > > Section 7.3.6 explains lifecycle of the resources. And it > states that if you > inject resources with @Inject annotation for example, > "@Inject EntityManager > ", container does not inject entity manager instance > directly, it must > inject proxy instance (created from ResourceBean#create > method). > > But same section last paragraph says that "The container > must perform > ordinary Java EE component injections (without > @Injection)". Therefore I > will update our resource handling this afternoon with > supporting > > 1* @Inject @Qualifier *EntityManager manger > 2* @PersistenceContext EntitityManager manager; > > In first situation, OWB injects proxy for the resource, > however in second > case it directly inject resource that is get from Resource > Plugin. > > I will work on those afternoon; > > Thanks; > > --Gurkan > > * > > 2010/2/16 Mark Struberg <[email protected]> > > > Hi Gurkan! > > > > It seems we have a different understanding on 3.5.1 > and I beg you to stop > > changing this parts until Gavin or Pete answers our > question. We must get a > > clear understanding on these points before releasing > M4 at least! > > > > Imho 3.5.1 is only meant as an example and directly > injecting > > @PersistenceContext is still perfectly valid (as it > was since the > > beginning). > > > > If you remember, the original section explicitly > stated that EXTENDED > > EntityManagers must not be used. This got dropped to > allow it's use in an SE > > environment. The @Dependent soft-restriction > (otherwise non portable > > behaviour) is still a left over from this period, > because this will only > > work with JTA aware transactional EntityManagers, > whereas for an extended > > EntityManager, something like @RequestScoped is > appropriate (otherwise our > > Transactional logic would not work!) > > > > Writing something like > > > private @Produces > @PersistenceContext(unitName="reservation") > > EntityManager entityManager; > > > > > > @Produces @RequestScoped > > > @org.apache.webbeans.reservation.bindings.EntityManagerQualifier > > > public EntityManager createEntityManager() > > > { > > > return entityManager; > > > } > > > > as we have now in the reservation example actually > HAVE to result in an > > AmbigousResolutionException. > > 1st bean: the producer field with type EntityManager > > 2nd bean: the producer method with type EntityManager > > > > I have not yet a final response from Gavin, but a > pre-commitment that our > > old behaviour was correct. > > > > Please let's discuss this in the afternoon and collect > arguments pro/con > > for both theories to jointly figure out which way we > need to go in the end. > > > > txs and LieGrue, > > strub > > > > __________________________________________________ > > Do You Yahoo!? > > Sie sind Spam leid? Yahoo! Mail verfügt über einen > herausragenden Schutz > > gegen Massenmails. > > http://mail.yahoo.com > > > > > > -- > Gurkan Erdogdu > http://gurkanerdogdu.blogspot.com > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
