Yeah aligning the resolution mechanism would certainly help. @EMC with EntityManagerResolver was actually something introduced in the import to align it with the JSF module (MessageResolver) so we might consider adapting @Tx.
Anyway: 1) Is making PartialBeans interceptor-ready something feasible for the release 2) or do we go with the quick workaround on AbstractEntityRepository (that will probably not hurt too much once interceptors work) 3) or just leave tx on concrete repository methods for now until we have 1) in a later release On Thu, Feb 20, 2014 at 5:39 PM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote: > Ok got, that's because @Tx and@EMC doesn't use same syntax. If both > uses qualifier it would work > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-20 17:15 GMT+01:00 Thomas Hug <thomas....@gmail.com>: > > Basically that's the case I'm referring to > > > > @Repository > > @EntityManagerConfig( ... ) > > public abstract class SimpleRepository extends > > AbstractEntityRepository<Simple, Long> { > > > > @Transactional > > public List<Simple> findByName(String name) { > > String query = "select s from Simple s where s.name = :name"; > > return entityManager().createQuery(query, Simple.class) > > .setParameter("name", name) > > .setLockMode(READ) // needs a tx > > .getResultList(); > > } > > ... > > > > currently this triggers neither the InvocationHandler nor the interceptor > > (and if it does then the interceptor should deal with > @EntityManagerConfig). > > > > Another pragmatic variant could be to add something like that to > > AbstractEntityRepository: > > public abstract V transactional(Callable<V> callable) > > which would then run again in the InvocationHandler, but seems like a > > rather clunky workaround compared to the version above. > > > > > > On Thu, Feb 20, 2014 at 4:45 PM, Romain Manni-Bucau > > <rmannibu...@gmail.com>wrote: > > > >> it is since you use the handled (interface for instance) as metadata, > no? > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > >> > >> > >> 2014-02-20 16:32 GMT+01:00 Thomas Hug <thomas....@gmail.com>: > >> > The more conceptual issue in this concrete case is that @Transactional > >> > isn't really independent from the handler class (namely EntityManager > >> > resolution). But I guess that's something we can deal with. > >> > > >> > So given the release time frame - anything we can do here or shall we > >> park > >> > this case for now? > >> > > >> > > >> > > >> > On Thu, Feb 20, 2014 at 2:17 PM, Romain Manni-Bucau > >> > <rmannibu...@gmail.com>wrote: > >> > > >> >> I think so too > >> >> > >> >> Romain Manni-Bucau > >> >> Twitter: @rmannibucau > >> >> Blog: http://rmannibucau.wordpress.com/ > >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> >> Github: https://github.com/rmannibucau > >> >> > >> >> > >> >> > >> >> 2014-02-20 13:05 GMT+01:00 Gerhard Petracek < > gerhard.petra...@gmail.com > >> >: > >> >> > imo we "just" need to support interceptors. > >> >> > > >> >> > regards, > >> >> > gerhard > >> >> > > >> >> > > >> >> > > >> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <thomas....@gmail.com>: > >> >> > > >> >> >> While looking at transactional repositories, I realized that > >> >> PartialBeans > >> >> >> invoke concrete methods directly. That doesn't give the invocation > >> >> handler > >> >> >> a chance to hook into the call (and in the data case to control > the > >> tx). > >> >> >> > >> >> >> What about creating an additional handler interface which also > >> allows to > >> >> >> pass in the proceeding method? Or is there a better alternative? > >> >> >> > >> >> > >> >
