Re: PartialBeans and concrete methods
While you can use @tx in you custome methods whatever solution is used is fine (even a temp hack). Api just shouldnt change imo Le 20 févr. 2014 20:39, "Gerhard Petracek" a écrit : > +1 for #3 > > regards, > gerhard > > > > 2014-02-20 20:35 GMT+01:00 Thomas Hug : > > > 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 > > 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 : > > > > Basically that's the case I'm referring to > > > > > > > > @Repository > > > > @EntityManagerConfig( ... ) > > > > public abstract class SimpleRepository extends > > > > AbstractEntityRepository { > > > > > > > > @Transactional > > > > public List 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 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 > > > > 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 : > > > >> > 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 > > > >> > 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 : > > > >> >> > > > > >> >> >> 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? > > > >> >> >> > > > >> >> > > > >> > > > > > >
Re: PartialBeans and concrete methods
+1 for #3 regards, gerhard 2014-02-20 20:35 GMT+01:00 Thomas Hug : > 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 > 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 : > > > Basically that's the case I'm referring to > > > > > > @Repository > > > @EntityManagerConfig( ... ) > > > public abstract class SimpleRepository extends > > > AbstractEntityRepository { > > > > > > @Transactional > > > public List 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 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 > > > 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 : > > >> > 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 > > >> > 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 : > > >> >> > > > >> >> >> 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? > > >> >> >> > > >> >> > > >> > > >
Re: PartialBeans and concrete methods
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 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 : > > Basically that's the case I'm referring to > > > > @Repository > > @EntityManagerConfig( ... ) > > public abstract class SimpleRepository extends > > AbstractEntityRepository { > > > > @Transactional > > public List 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 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 > > 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 : > >> > 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 > >> > 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 : > >> >> > > >> >> >> 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? > >> >> >> > >> >> > >> >
Re: PartialBeans and concrete methods
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 : > Basically that's the case I'm referring to > > @Repository > @EntityManagerConfig( ... ) > public abstract class SimpleRepository extends > AbstractEntityRepository { > > @Transactional > public List 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 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 > 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 : >> > 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 >> > 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 > >: >> >> > imo we "just" need to support interceptors. >> >> > >> >> > regards, >> >> > gerhard >> >> > >> >> > >> >> > >> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug : >> >> > >> >> >> 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? >> >> >> >> >> >>
Re: PartialBeans and concrete methods
Basically that's the case I'm referring to @Repository @EntityManagerConfig( ... ) public abstract class SimpleRepository extends AbstractEntityRepository { @Transactional public List 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 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 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 : > > 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 > > 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 >: > >> > imo we "just" need to support interceptors. > >> > > >> > regards, > >> > gerhard > >> > > >> > > >> > > >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug : > >> > > >> >> 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? > >> >> > >> >
Re: PartialBeans and concrete methods
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 : > 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 > 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 : >> > imo we "just" need to support interceptors. >> > >> > regards, >> > gerhard >> > >> > >> > >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug : >> > >> >> 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? >> >> >>
Re: PartialBeans and concrete methods
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 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 : > > imo we "just" need to support interceptors. > > > > regards, > > gerhard > > > > > > > > 2014-02-20 12:20 GMT+01:00 Thomas Hug : > > > >> 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? > >> >
Re: PartialBeans and concrete methods
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 : > imo we "just" need to support interceptors. > > regards, > gerhard > > > > 2014-02-20 12:20 GMT+01:00 Thomas Hug : > >> 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? >>
Re: PartialBeans and concrete methods
imo we "just" need to support interceptors. regards, gerhard 2014-02-20 12:20 GMT+01:00 Thomas Hug : > 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? >
PartialBeans and concrete methods
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?