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
