+1 for #3 regards, gerhard
2014-02-20 20:35 GMT+01:00 Thomas Hug <thomas....@gmail.com>: > 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? > > >> >> >> > > >> >> > > >> > > >
