You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Thomas Hug <th...@gmail.com> on 2014/02/20 12:20:20 UTC
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?
Re: PartialBeans and concrete methods
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ge...@gmail.com>:
> imo we "just" need to support interceptors.
>
> regards,
> gerhard
>
>
>
> 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
>>
Re: PartialBeans and concrete methods
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <th...@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
> <rm...@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 <ge...@gmail.com>:
>> > imo we "just" need to support interceptors.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
>> >>
>>
Re: PartialBeans and concrete methods
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <th...@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
> <rm...@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 <th...@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
>> > <rm...@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.petracek@gmail.com
>> >:
>> >> > imo we "just" need to support interceptors.
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> >
>> >> >
>> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
>> >> >>
>> >>
>>
Re: PartialBeans and concrete methods
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <ge...@gmail.com> a
écrit :
> +1 for #3
>
> regards,
> gerhard
>
>
>
> 2014-02-20 20:35 GMT+01:00 Thomas Hug <th...@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
> > <rm...@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 <th...@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
> > > > <rm...@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 <th...@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
> > > >> > <rm...@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.petracek@gmail.com
> > > >> >:
> > > >> >> > imo we "just" need to support interceptors.
> > > >> >> >
> > > >> >> > regards,
> > > >> >> > gerhard
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
> > > >> >> >>
> > > >> >>
> > > >>
> > >
> >
>
Re: PartialBeans and concrete methods
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for #3
regards,
gerhard
2014-02-20 20:35 GMT+01:00 Thomas Hug <th...@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
> <rm...@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 <th...@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
> > > <rm...@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 <th...@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
> > >> > <rm...@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.petracek@gmail.com
> > >> >:
> > >> >> > imo we "just" need to support interceptors.
> > >> >> >
> > >> >> > regards,
> > >> >> > gerhard
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
> > >> >> >>
> > >> >>
> > >>
> >
>
Re: PartialBeans and concrete methods
Posted by Thomas Hug <th...@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
<rm...@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 <th...@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
> > <rm...@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 <th...@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
> >> > <rm...@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.petracek@gmail.com
> >> >:
> >> >> > imo we "just" need to support interceptors.
> >> >> >
> >> >> > regards,
> >> >> > gerhard
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
> >> >> >>
> >> >>
> >>
>
Re: PartialBeans and concrete methods
Posted by Thomas Hug <th...@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
<rm...@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 <th...@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
> > <rm...@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.petracek@gmail.com
> >:
> >> > imo we "just" need to support interceptors.
> >> >
> >> > regards,
> >> > gerhard
> >> >
> >> >
> >> >
> >> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
> >> >>
> >>
>
Re: PartialBeans and concrete methods
Posted by Thomas Hug <th...@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
<rm...@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 <ge...@gmail.com>:
> > imo we "just" need to support interceptors.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
> >>
>
Re: PartialBeans and concrete methods
Posted by Gerhard Petracek <ge...@gmail.com>.
imo we "just" need to support interceptors.
regards,
gerhard
2014-02-20 12:20 GMT+01:00 Thomas Hug <th...@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?
>