>Writing something like
> private @Produces @PersistenceContext(unitName="
reservation") EntityManager entityManager;
>
> @Produces @RequestScoped
@org.apache.webbeans.reservation.bindings.EntityManagerQualifier
> public EntityManager createEntityManager()
> {
> return entityManager;
> }
This is not related with discussion. Container always throws
AmbigiousResolutionException because you define 2 producer with same
@Default qualifier. I have eliminated this in Reservation sample via
introducing qualifier.
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
