subject:"Re\: Override bean from library on TomEE"

Re: Override bean from library on TomEE

2018-11-20 Thread Bruno Baptista

Thanks for the help Romain

Bruno Baptista
http://twitter.com/brunobat_

On 19/11/18 17:39, Romain Manni-Bucau wrote:

Le lun. 19 nov. 2018 17:58, Bruno Baptista a écrit :

Thanks Romain,

It's good to know. Where is that configuration?

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/resources/default.exclusions
and
https://github.com/apache/tomee/commit/23f44b17e6ab504561f32aa4ae92f2521e07261e

However, the problem is before that... The test with the interceptor,
somehow fails to load the alternative, which has me very puzzled.

Cheers.

Bruno Baptista
http://twitter.com/brunobat_

On 19/11/18 16:45, Romain Manni-Bucau wrote:

Le lun. 19 nov. 2018 à 16:59, Roberto Cortez
Hi,

We had that project before, and we ended up dropping with the
justification that the libs should handle all of that.

Not saying not to do it and I just don’t want to see code being blocked
again for the same reason :)

Cheers,
Roberto

On 19 Nov 2018, at 15:31, Bruno Baptista wrote:

Hi Romain,

In relation to the name of the lib to be /geronimo-safeguard-tomee/

instead of /tomee-microprofile-common/ I would advise against it

because we

can put other overrides and utility classes on it instead of creating a
single lib for every particular spec/need.

Point was more that geronimo-* are scanned and not tomee-*, so was more
technical than semantic ;) - i'm almost happy if you call it
"makeitwork.jar" :D.

Feedback is appreciated on the intended scope and name of that library.

Let's see what's the opinion of the community over it.

In relation to the /DefaultManagedScheduledExecutorService/

configuration, you are right. Will add it as soon as the injection

mystery

is solved. Any feedback on the injection of the alternative bean will be
appreciated because I'm kind of stuck now.

Cheers

Bruno Baptista
http://twitter.com/brunobat_

On 19/11/18 15:13, Romain Manni-Bucau wrote:

rename the lib geronimo-safeguard-tomee or include the common MP jar

the

scanned modules?

side note: i mentionned it @geronimo: you likely don't want to

hardcode

default name which will either be replaced by another one, not be the
default one or not be controllable by the user (
DefaultManagedScheduledExecutorService) so probably use tomee to

inject

configuration (@Resource MicroprofileConfiguration config; in your

common

module) and then lookup the instance using tomee internal

(containersystem

-> jndicontext? for instance). Not a big thing but if not done users

will

have to code this bean themselves to control it I think.

Romain Manni-Bucau
@rmannibucau | Blog
| Old Blog
| Github <

https://github.com/rmannibucau> |

LinkedIn | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance

Le lun. 19 nov. 2018 à 15:24, Bruno Baptista a

écrit :

Hi All,

I created a PR to make the discussion easier. It's here:
https://github.com/apache/tomee/pull/201

There's another problem with the alternative bean implementation.

After

including the SafeguardInterceptor in the test, the bean,
FailsafeContainerExecutionManagerProvider, is never picked up.

I've played a bit with the priorities of both the interceptor and the
alternative without success.

We still need to figure out a CDI extension to activate the code on
TomEE, but first, the existing test has to work on it's own.

Cheers.

Bruno Baptista
http://twitter.com/brunobat_

On 19/11/18 10:56, Bruno Baptista wrote:

Hi Jon,

I'm not sure what would be the right way to load that code.

But now that you mention it, a CDI extension sounds the proper way

do it. The code now loads properly. Thanks!

Will create a PR soon.

Bruno Baptista
http://twitter.com/brunobat_

On 19/11/18 10:41, Jonathan Gallimore wrote:

I haven't seen the code, so its difficult to suggest anything -

where

would you expect it to be loaded - in a CDI extension?

On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista <

bruno...@gmail.com

> wrote:

Hi all,

I've created a jira for this task to properly track the

commits:

https://issues.apache.org/jira/browse/TOMEE-2278

Right now I have a problem activating the code... The code is

the lib folder but it's not being loaded into the classpath.

Do I need to create some kind of a service like this?

Or am I missing to declare it in some xml file?

Cheers

Bruno Baptista
http://twitter.com/brunobat_

On 18/11/18 12:55, Bruno Baptista wrote:

Hi All,

I came up with a test that successfully overrides the

original

/FailsafeExecutionManagerProvider/ Safeguard class.

It was a bit of a surprise but, in this case, beans.xml is
useless because "The alternatives that you specify in the
|beans.xml| file apply only to classes in

Re: Override bean from library on TomEE

2018-11-19 Thread Romain Manni-Bucau

Le lun. 19 nov. 2018 17:58, Bruno Baptista  a écrit :

> Thanks Romain,
>
> It's good to know. Where is that configuration?
>

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/resources/default.exclusions
and
https://github.com/apache/tomee/commit/23f44b17e6ab504561f32aa4ae92f2521e07261e


> However, the problem is before that... The test with the interceptor,
> somehow fails to load the alternative, which has me very puzzled.
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 19/11/18 16:45, Romain Manni-Bucau wrote:
> > Le lun. 19 nov. 2018 à 16:59, Roberto Cortez  >
> > a écrit :
> >
> >> Hi,
> >>
> >> We had that project before, and we ended up dropping with the
> >> justification that the libs should handle all of that.
> >>
> >> Not saying not to do it and I just don’t want to see code being blocked
> >> again for the same reason :)
> >>
> >> Cheers,
> >> Roberto
> >>
> >>> On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:
> >>>
> >>> Hi Romain,
> >>>
> >>> In relation to the name of the lib to be /geronimo-safeguard-tomee/
> >> instead of /tomee-microprofile-common/ I would advise against it
> because we
> >> can put other overrides and utility classes on it instead of creating a
> >> single lib for every particular spec/need.
> >>
> > Point was more that geronimo-* are scanned and not tomee-*, so was more
> > technical than semantic ;) - i'm almost happy if you call it
> > "makeitwork.jar" :D.
> >
> >
> >>> Feedback is appreciated on the intended scope and name of that library.
> >> Let's see what's the opinion of the community over it.
> >>> In relation to the /DefaultManagedScheduledExecutorService/
> >> configuration, you are right. Will add it as soon as the injection
> mystery
> >> is solved. Any feedback on the injection of the alternative bean will be
> >> appreciated because I'm kind of stuck now.
> >>> Cheers
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 19/11/18 15:13, Romain Manni-Bucau wrote:
>  rename the lib geronimo-safeguard-tomee or include the common MP jar
> in
> >> the
>  scanned modules?
> 
>  side note: i mentionned it @geronimo: you likely don't want to
> hardcode
> >> a
>  default name which will either be replaced by another one, not be the
>  default one or not be controllable by the user (
>  DefaultManagedScheduledExecutorService) so probably use tomee to
> inject
> >> a
>  configuration (@Resource MicroprofileConfiguration config; in your
> >> common
>  module) and then lookup the instance using tomee internal
> >> (containersystem
>  -> jndicontext? for instance). Not a big thing but if not done users
> >> will
>  have to code this bean themselves to control it I think.
> 
>  Romain Manni-Bucau
>  @rmannibucau  |  Blog
>   | Old Blog
>   | Github <
> >> https://github.com/rmannibucau> |
>  LinkedIn  | Book
>  <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
>  Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a
> >> écrit :
> > Hi All,
> >
> > I created a PR to make the discussion easier. It's here:
> > https://github.com/apache/tomee/pull/201
> >
> > There's another problem with the alternative bean implementation.
> After
> > including the SafeguardInterceptor in the test, the bean,
> > FailsafeContainerExecutionManagerProvider, is never picked up.
> >
> > I've played a bit with the priorities of both the interceptor and the
> > alternative without success.
> >
> > We still need to figure out a CDI extension to activate the code on
> > TomEE, but first, the existing test has to work on it's own.
> >
> > Cheers.
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 19/11/18 10:56, Bruno Baptista wrote:
> >> Hi Jon,
> >>
> >> I'm not sure what would be the right way to load that code.
> >>
> >> But now that you mention it, a CDI extension sounds the proper way
> to
> >> do it. The code now loads properly. Thanks!
> >>
> >> Will create a PR soon.
> >>
> >> Bruno Baptista
> >> http://twitter.com/brunobat_
> >>
> >>
> >> On 19/11/18 10:41, Jonathan Gallimore wrote:
> >>> I haven't seen the code, so its difficult to suggest anything -
> where
> >>> would you expect it to be loaded - in a CDI extension?
> >>>
> >>> On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista <
> bruno...@gmail.com
> >>> > wrote:
> >>>
> >>>  Hi all,
> >>>
> >>>  I've created a jira for this task to properly track the
> commits:
> >>>  https://issues.apache.org/jira/browse/TOMEE-2278
> >>>
> >>>  Right now I have a

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Thanks Romain,

It's good to know. Where is that configuration?

However, the problem is before that... The test with the interceptor, 
somehow fails to load the alternative, which has me very puzzled.


Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 16:45, Romain Manni-Bucau wrote:

Le lun. 19 nov. 2018 à 16:59, Roberto Cortez 
a écrit :


Hi,

We had that project before, and we ended up dropping with the
justification that the libs should handle all of that.

Not saying not to do it and I just don’t want to see code being blocked
again for the same reason :)

Cheers,
Roberto


On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:

Hi Romain,

In relation to the name of the lib to be /geronimo-safeguard-tomee/

instead of /tomee-microprofile-common/ I would advise against it because we
can put other overrides and utility classes on it instead of creating a
single lib for every particular spec/need.


Point was more that geronimo-* are scanned and not tomee-*, so was more
technical than semantic ;) - i'm almost happy if you call it
"makeitwork.jar" :D.



Feedback is appreciated on the intended scope and name of that library.

Let's see what's the opinion of the community over it.

In relation to the /DefaultManagedScheduledExecutorService/

configuration, you are right. Will add it as soon as the injection mystery
is solved. Any feedback on the injection of the alternative bean will be
appreciated because I'm kind of stuck now.

Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 15:13, Romain Manni-Bucau wrote:

rename the lib geronimo-safeguard-tomee or include the common MP jar in

the

scanned modules?

side note: i mentionned it @geronimo: you likely don't want to hardcode

a

default name which will either be replaced by another one, not be the
default one or not be controllable by the user (
DefaultManagedScheduledExecutorService) so probably use tomee to inject

a

configuration (@Resource MicroprofileConfiguration config; in your

common

module) and then lookup the instance using tomee internal

(containersystem

-> jndicontext? for instance). Not a big thing but if not done users

will

have to code this bean themselves to control it I think.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance


Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a

écrit :

Hi All,

I created a PR to make the discussion easier. It's here:
https://github.com/apache/tomee/pull/201

There's another problem with the alternative bean implementation. After
including the SafeguardInterceptor in the test, the bean,
FailsafeContainerExecutionManagerProvider, is never picked up.

I've played a bit with the priorities of both the interceptor and the
alternative without success.

We still need to figure out a CDI extension to activate the code on
TomEE, but first, the existing test has to work on it's own.

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:56, Bruno Baptista wrote:

Hi Jon,

I'm not sure what would be the right way to load that code.

But now that you mention it, a CDI extension sounds the proper way to
do it. The code now loads properly. Thanks!

Will create a PR soon.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:41, Jonathan Gallimore wrote:

I haven't seen the code, so its difficult to suggest anything - where
would you expect it to be loaded - in a CDI extension?

On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista mailto:bruno...@gmail.com>> wrote:

 Hi all,

 I've created a jira for this task to properly track the commits:
 https://issues.apache.org/jira/browse/TOMEE-2278

 Right now I have a problem activating the code... The code is in
 the lib folder but it's not being loaded into the classpath.

 Do I need to create some kind of a service like this?

 Or am I missing to declare it in some xml file?

 Cheers

 Bruno Baptista
 http://twitter.com/brunobat_


 On 18/11/18 12:55, Bruno Baptista wrote:

 Hi All,

 I came up with a test that successfully overrides the original
 /FailsafeExecutionManagerProvider/ Safeguard class.

 It was a bit of a surprise but, in this case, beans.xml is
 useless because "The alternatives that you specify in the
 |beans.xml| file apply only to classes in the same archive."
 see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

 Because the beans are in different jar files, priority has to be
 used instead:

 @Priority(Interceptor.Priority.APPLICATION+10)

 The precise priority might need to be fine tuned because of the
 fault tolerance interceptor... Will have to test the final
 behavior.

 Also, we probably need to

Re: Override bean from library on TomEE

2018-11-19 Thread Romain Manni-Bucau

Le lun. 19 nov. 2018 à 16:59, Roberto Cortez 
a écrit :

> Hi,
>
> We had that project before, and we ended up dropping with the
> justification that the libs should handle all of that.
>
> Not saying not to do it and I just don’t want to see code being blocked
> again for the same reason :)
>
> Cheers,
> Roberto
>
> > On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:
> >
> > Hi Romain,
> >
> > In relation to the name of the lib to be /geronimo-safeguard-tomee/
> instead of /tomee-microprofile-common/ I would advise against it because we
> can put other overrides and utility classes on it instead of creating a
> single lib for every particular spec/need.
>

Point was more that geronimo-* are scanned and not tomee-*, so was more
technical than semantic ;) - i'm almost happy if you call it
"makeitwork.jar" :D.


> >
> > Feedback is appreciated on the intended scope and name of that library.
> Let's see what's the opinion of the community over it.
> >
> > In relation to the /DefaultManagedScheduledExecutorService/
> configuration, you are right. Will add it as soon as the injection mystery
> is solved. Any feedback on the injection of the alternative bean will be
> appreciated because I'm kind of stuck now.
> >
> > Cheers
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 19/11/18 15:13, Romain Manni-Bucau wrote:
> >> rename the lib geronimo-safeguard-tomee or include the common MP jar in
> the
> >> scanned modules?
> >>
> >> side note: i mentionned it @geronimo: you likely don't want to hardcode
> a
> >> default name which will either be replaced by another one, not be the
> >> default one or not be controllable by the user (
> >> DefaultManagedScheduledExecutorService) so probably use tomee to inject
> a
> >> configuration (@Resource MicroprofileConfiguration config; in your
> common
> >> module) and then lookup the instance using tomee internal
> (containersystem
> >> -> jndicontext? for instance). Not a big thing but if not done users
> will
> >> have to code this bean themselves to control it I think.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>
> >>
> >> Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a
> écrit :
> >>
> >>> Hi All,
> >>>
> >>> I created a PR to make the discussion easier. It's here:
> >>> https://github.com/apache/tomee/pull/201
> >>>
> >>> There's another problem with the alternative bean implementation. After
> >>> including the SafeguardInterceptor in the test, the bean,
> >>> FailsafeContainerExecutionManagerProvider, is never picked up.
> >>>
> >>> I've played a bit with the priorities of both the interceptor and the
> >>> alternative without success.
> >>>
> >>> We still need to figure out a CDI extension to activate the code on
> >>> TomEE, but first, the existing test has to work on it's own.
> >>>
> >>> Cheers.
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 19/11/18 10:56, Bruno Baptista wrote:
>  Hi Jon,
> 
>  I'm not sure what would be the right way to load that code.
> 
>  But now that you mention it, a CDI extension sounds the proper way to
>  do it. The code now loads properly. Thanks!
> 
>  Will create a PR soon.
> 
>  Bruno Baptista
>  http://twitter.com/brunobat_
> 
> 
>  On 19/11/18 10:41, Jonathan Gallimore wrote:
> > I haven't seen the code, so its difficult to suggest anything - where
> > would you expect it to be loaded - in a CDI extension?
> >
> > On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  > > wrote:
> >
> > Hi all,
> >
> > I've created a jira for this task to properly track the commits:
> > https://issues.apache.org/jira/browse/TOMEE-2278
> >
> > Right now I have a problem activating the code... The code is in
> > the lib folder but it's not being loaded into the classpath.
> >
> > Do I need to create some kind of a service like this?
> >
> > Or am I missing to declare it in some xml file?
> >
> > Cheers
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 18/11/18 12:55, Bruno Baptista wrote:
> >> Hi All,
> >>
> >> I came up with a test that successfully overrides the original
> >> /FailsafeExecutionManagerProvider/ Safeguard class.
> >>
> >> It was a bit of a surprise but, in this case, beans.xml is
> >> useless because "The alternatives that you specify in the
> >> |beans.xml| file apply only to classes in the same archive."
> >> see:

Re: Override bean from library on TomEE

2018-11-19 Thread Roberto Cortez

Hi,

We had that project before, and we ended up dropping with the justification 
that the libs should handle all of that.

Not saying not to do it and I just don’t want to see code being blocked again 
for the same reason :)

Cheers,
Roberto

> On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:
> 
> Hi Romain,
> 
> In relation to the name of the lib to be /geronimo-safeguard-tomee/ instead 
> of /tomee-microprofile-common/ I would advise against it because we can put 
> other overrides and utility classes on it instead of creating a single lib 
> for every particular spec/need.
> 
> Feedback is appreciated on the intended scope and name of that library. Let's 
> see what's the opinion of the community over it.
> 
> In relation to the /DefaultManagedScheduledExecutorService/ configuration, 
> you are right. Will add it as soon as the injection mystery is solved. Any 
> feedback on the injection of the alternative bean will be appreciated because 
> I'm kind of stuck now.
> 
> Cheers
> 
> Bruno Baptista
> http://twitter.com/brunobat_
> 
> 
> On 19/11/18 15:13, Romain Manni-Bucau wrote:
>> rename the lib geronimo-safeguard-tomee or include the common MP jar in the
>> scanned modules?
>> 
>> side note: i mentionned it @geronimo: you likely don't want to hardcode a
>> default name which will either be replaced by another one, not be the
>> default one or not be controllable by the user (
>> DefaultManagedScheduledExecutorService) so probably use tomee to inject a
>> configuration (@Resource MicroprofileConfiguration config; in your common
>> module) and then lookup the instance using tomee internal (containersystem
>> -> jndicontext? for instance). Not a big thing but if not done users will
>> have to code this bean themselves to control it I think.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github  
>> |
>> LinkedIn  | Book
>> 
>> 
>> 
>> Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a écrit :
>> 
>>> Hi All,
>>> 
>>> I created a PR to make the discussion easier. It's here:
>>> https://github.com/apache/tomee/pull/201
>>> 
>>> There's another problem with the alternative bean implementation. After
>>> including the SafeguardInterceptor in the test, the bean,
>>> FailsafeContainerExecutionManagerProvider, is never picked up.
>>> 
>>> I've played a bit with the priorities of both the interceptor and the
>>> alternative without success.
>>> 
>>> We still need to figure out a CDI extension to activate the code on
>>> TomEE, but first, the existing test has to work on it's own.
>>> 
>>> Cheers.
>>> 
>>> Bruno Baptista
>>> http://twitter.com/brunobat_
>>> 
>>> 
>>> On 19/11/18 10:56, Bruno Baptista wrote:
 Hi Jon,
 
 I'm not sure what would be the right way to load that code.
 
 But now that you mention it, a CDI extension sounds the proper way to
 do it. The code now loads properly. Thanks!
 
 Will create a PR soon.
 
 Bruno Baptista
 http://twitter.com/brunobat_
 
 
 On 19/11/18 10:41, Jonathan Gallimore wrote:
> I haven't seen the code, so its difficult to suggest anything - where
> would you expect it to be loaded - in a CDI extension?
> 
> On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  > wrote:
> 
> Hi all,
> 
> I've created a jira for this task to properly track the commits:
> https://issues.apache.org/jira/browse/TOMEE-2278
> 
> Right now I have a problem activating the code... The code is in
> the lib folder but it's not being loaded into the classpath.
> 
> Do I need to create some kind of a service like this?
> 
> Or am I missing to declare it in some xml file?
> 
> Cheers
> 
> Bruno Baptista
> http://twitter.com/brunobat_
> 
> 
> On 18/11/18 12:55, Bruno Baptista wrote:
>> Hi All,
>> 
>> I came up with a test that successfully overrides the original
>> /FailsafeExecutionManagerProvider/ Safeguard class.
>> 
>> It was a bit of a surprise but, in this case, beans.xml is
>> useless because "The alternatives that you specify in the
>> |beans.xml| file apply only to classes in the same archive."
>> see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
>> 
>> Because the beans are in different jar files, priority has to be
>> used instead:
>> 
>> @Priority(Interceptor.Priority.APPLICATION+10)
>> 
>> The precise priority might need to be fine tuned because of the
>> fault tolerance interceptor... Will have to test the final
>> behavior.
>> 
>> Also, we probably need to

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Hi Romain,

In relation to the name of the lib to be /geronimo-safeguard-tomee/ 
instead of /tomee-microprofile-common/ I would advise against it because 
we can put other overrides and utility classes on it instead of creating 
a single lib for every particular spec/need.


Feedback is appreciated on the intended scope and name of that library. 
Let's see what's the opinion of the community over it.


In relation to the /DefaultManagedScheduledExecutorService/ 
configuration, you are right. Will add it as soon as the injection 
mystery is solved. Any feedback on the injection of the alternative bean 
will be appreciated because I'm kind of stuck now.


Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 15:13, Romain Manni-Bucau wrote:

rename the lib geronimo-safeguard-tomee or include the common MP jar in the
scanned modules?

side note: i mentionned it @geronimo: you likely don't want to hardcode a
default name which will either be replaced by another one, not be the
default one or not be controllable by the user (
DefaultManagedScheduledExecutorService) so probably use tomee to inject a
configuration (@Resource MicroprofileConfiguration config; in your common
module) and then lookup the instance using tomee internal (containersystem
-> jndicontext? for instance). Not a big thing but if not done users will
have to code this bean themselves to control it I think.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a écrit :


Hi All,

I created a PR to make the discussion easier. It's here:
https://github.com/apache/tomee/pull/201

There's another problem with the alternative bean implementation. After
including the SafeguardInterceptor in the test, the bean,
FailsafeContainerExecutionManagerProvider, is never picked up.

I've played a bit with the priorities of both the interceptor and the
alternative without success.

We still need to figure out a CDI extension to activate the code on
TomEE, but first, the existing test has to work on it's own.

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:56, Bruno Baptista wrote:

Hi Jon,

I'm not sure what would be the right way to load that code.

But now that you mention it, a CDI extension sounds the proper way to
do it. The code now loads properly. Thanks!

Will create a PR soon.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:41, Jonathan Gallimore wrote:

I haven't seen the code, so its difficult to suggest anything - where
would you expect it to be loaded - in a CDI extension?

On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista mailto:bruno...@gmail.com>> wrote:

 Hi all,

 I've created a jira for this task to properly track the commits:
 https://issues.apache.org/jira/browse/TOMEE-2278

 Right now I have a problem activating the code... The code is in
 the lib folder but it's not being loaded into the classpath.

 Do I need to create some kind of a service like this?

 Or am I missing to declare it in some xml file?

 Cheers

 Bruno Baptista
 http://twitter.com/brunobat_


 On 18/11/18 12:55, Bruno Baptista wrote:

 Hi All,

 I came up with a test that successfully overrides the original
 /FailsafeExecutionManagerProvider/ Safeguard class.

 It was a bit of a surprise but, in this case, beans.xml is
 useless because "The alternatives that you specify in the
 |beans.xml| file apply only to classes in the same archive."
 see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

 Because the beans are in different jar files, priority has to be
 used instead:

 @Priority(Interceptor.Priority.APPLICATION+10)

 The precise priority might need to be fine tuned because of the
 fault tolerance interceptor... Will have to test the final
 behavior.

 Also, we probably need to reorganize the
 tomee-microprofile-webapp project...
 This is needed because the code overriding the bean needs to be
 in a library and this project only creates a war file, which is
 in fact a container for the bundled libraries. The classes we
 place in there will not be in the final server.

 I'm thinking on something like:

 tomee
 |
 --- tomee-microprofile
|
 --- tomee-microprofile-common (The
 JAR to be included in .../lib)
|
 --- tomee-microprofile-webapp (The
 same as now with an additional dependency)

 Cheers.

 Bruno Baptista
 http://twitter.com/brunobat_


 On 16/11/18 16:26, Bruno Baptista wrote:

 Hi Romain,

Re: Override bean from library on TomEE

2018-11-19 Thread Romain Manni-Bucau

rename the lib geronimo-safeguard-tomee or include the common MP jar in the
scanned modules?

side note: i mentionned it @geronimo: you likely don't want to hardcode a
default name which will either be replaced by another one, not be the
default one or not be controllable by the user (
DefaultManagedScheduledExecutorService) so probably use tomee to inject a
configuration (@Resource MicroprofileConfiguration config; in your common
module) and then lookup the instance using tomee internal (containersystem
-> jndicontext? for instance). Not a big thing but if not done users will
have to code this bean themselves to control it I think.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a écrit :

> Hi All,
>
> I created a PR to make the discussion easier. It's here:
> https://github.com/apache/tomee/pull/201
>
> There's another problem with the alternative bean implementation. After
> including the SafeguardInterceptor in the test, the bean,
> FailsafeContainerExecutionManagerProvider, is never picked up.
>
> I've played a bit with the priorities of both the interceptor and the
> alternative without success.
>
> We still need to figure out a CDI extension to activate the code on
> TomEE, but first, the existing test has to work on it's own.
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 19/11/18 10:56, Bruno Baptista wrote:
> >
> > Hi Jon,
> >
> > I'm not sure what would be the right way to load that code.
> >
> > But now that you mention it, a CDI extension sounds the proper way to
> > do it. The code now loads properly. Thanks!
> >
> > Will create a PR soon.
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 19/11/18 10:41, Jonathan Gallimore wrote:
> >> I haven't seen the code, so its difficult to suggest anything - where
> >> would you expect it to be loaded - in a CDI extension?
> >>
> >> On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  >> > wrote:
> >>
> >> Hi all,
> >>
> >> I've created a jira for this task to properly track the commits:
> >> https://issues.apache.org/jira/browse/TOMEE-2278
> >>
> >> Right now I have a problem activating the code... The code is in
> >> the lib folder but it's not being loaded into the classpath.
> >>
> >> Do I need to create some kind of a service like this?
> >>
> >> Or am I missing to declare it in some xml file?
> >>
> >> Cheers
> >>
> >> Bruno Baptista
> >> http://twitter.com/brunobat_
> >>
> >>
> >> On 18/11/18 12:55, Bruno Baptista wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I came up with a test that successfully overrides the original
> >>> /FailsafeExecutionManagerProvider/ Safeguard class.
> >>>
> >>> It was a bit of a surprise but, in this case, beans.xml is
> >>> useless because "The alternatives that you specify in the
> >>> |beans.xml| file apply only to classes in the same archive."
> >>> see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
> >>>
> >>> Because the beans are in different jar files, priority has to be
> >>> used instead:
> >>>
> >>> @Priority(Interceptor.Priority.APPLICATION+10)
> >>>
> >>> The precise priority might need to be fine tuned because of the
> >>> fault tolerance interceptor... Will have to test the final
> >>> behavior.
> >>>
> >>> Also, we probably need to reorganize the
> >>> tomee-microprofile-webapp project...
> >>> This is needed because the code overriding the bean needs to be
> >>> in a library and this project only creates a war file, which is
> >>> in fact a container for the bundled libraries. The classes we
> >>> place in there will not be in the final server.
> >>>
> >>> I'm thinking on something like:
> >>>
> >>> tomee
> >>> |
> >>> --- tomee-microprofile
> >>>|
> >>> --- tomee-microprofile-common (The
> >>> JAR to be included in .../lib)
> >>>|
> >>> --- tomee-microprofile-webapp (The
> >>> same as now with an additional dependency)
> >>>
> >>> Cheers.
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 16/11/18 16:26, Bruno Baptista wrote:
> 
>  Hi Romain,
> 
>  Yeah... @Resource would be the right thing to use in order to
>  inject the managed resource. Something like this:
> 
>  @Resource(name = "DefaultManagedScheduledExecutorService")
>  private ManagedScheduledExecutorService executor;
> 
>  Creating the test now.
>

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Hi All,

I created a PR to make the discussion easier. It's here: 
https://github.com/apache/tomee/pull/201


There's another problem with the alternative bean implementation. After 
including the SafeguardInterceptor in the test, the bean, 
FailsafeContainerExecutionManagerProvider, is never picked up.


I've played a bit with the priorities of both the interceptor and the 
alternative without success.


We still need to figure out a CDI extension to activate the code on 
TomEE, but first, the existing test has to work on it's own.


Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:56, Bruno Baptista wrote:


Hi Jon,

I'm not sure what would be the right way to load that code.

But now that you mention it, a CDI extension sounds the proper way to 
do it. The code now loads properly. Thanks!


Will create a PR soon.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:41, Jonathan Gallimore wrote:
I haven't seen the code, so its difficult to suggest anything - where 
would you expect it to be loaded - in a CDI extension?


On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista > wrote:


Hi all,

I've created a jira for this task to properly track the commits:
https://issues.apache.org/jira/browse/TOMEE-2278

Right now I have a problem activating the code... The code is in
the lib folder but it's not being loaded into the classpath.

Do I need to create some kind of a service like this?

Or am I missing to declare it in some xml file?

Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 18/11/18 12:55, Bruno Baptista wrote:


Hi All,

I came up with a test that successfully overrides the original
/FailsafeExecutionManagerProvider/ Safeguard class.

It was a bit of a surprise but, in this case, beans.xml is
useless because "The alternatives that you specify in the
|beans.xml| file apply only to classes in the same archive."
see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

Because the beans are in different jar files, priority has to be
used instead:

@Priority(Interceptor.Priority.APPLICATION+10)

The precise priority might need to be fine tuned because of the
fault tolerance interceptor... Will have to test the final
behavior.

Also, we probably need to reorganize the
tomee-microprofile-webapp project...
This is needed because the code overriding the bean needs to be
in a library and this project only creates a war file, which is
in fact a container for the bundled libraries. The classes we
place in there will not be in the final server.

I'm thinking on something like:

tomee
|
--- tomee-microprofile
                           |
                            --- tomee-microprofile-common (The
JAR to be included in .../lib)
                           |
                            --- tomee-microprofile-webapp (The
same as now with an additional dependency)

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:26, Bruno Baptista wrote:


Hi Romain,

Yeah... @Resource would be the right thing to use in order to
inject the managed resource. Something like this:

@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
 @Override
 @Produces
 @Specializes
 @ApplicationScoped
 public ExecutionManager createExecutionManager() {
 return new FailsafeExecutionManager() {
 @Override // hardcoded impl for testing purposes
 public Object execute(final InvocationContext 
invocationContext) {
 return "replaced";
 }
 };
 }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  
  |  Blog
    | 
Old Blog
    | 
Github    |
LinkedIn  
  | Book
  



Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  
  a
écrit :


Hi Bruno,

I assume the alternative is

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Hi Jon,

I'm not sure what would be the right way to load that code.

But now that you mention it, a CDI extension sounds the proper way to do 
it. The code now loads properly. Thanks!


Will create a PR soon.

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:41, Jonathan Gallimore wrote:
I haven't seen the code, so its difficult to suggest anything - where 
would you expect it to be loaded - in a CDI extension?


On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista > wrote:


Hi all,

I've created a jira for this task to properly track the commits:
https://issues.apache.org/jira/browse/TOMEE-2278

Right now I have a problem activating the code... The code is in
the lib folder but it's not being loaded into the classpath.

Do I need to create some kind of a service like this?

Or am I missing to declare it in some xml file?

Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 18/11/18 12:55, Bruno Baptista wrote:


Hi All,

I came up with a test that successfully overrides the original
/FailsafeExecutionManagerProvider/ Safeguard class.

It was a bit of a surprise but, in this case, beans.xml is
useless because "The alternatives that you specify in the
|beans.xml| file apply only to classes in the same archive." see:
https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

Because the beans are in different jar files, priority has to be
used instead:

@Priority(Interceptor.Priority.APPLICATION+10)

The precise priority might need to be fine tuned because of the
fault tolerance interceptor... Will have to test the final behavior.

Also, we probably need to reorganize the
tomee-microprofile-webapp project...
This is needed because the code overriding the bean needs to be
in a library and this project only creates a war file, which is
in fact a container for the bundled libraries. The classes we
place in there will not be in the final server.

I'm thinking on something like:

tomee
|
--- tomee-microprofile
                           |
                            --- tomee-microprofile-common (The
JAR to be included in .../lib)
                           |
                            --- tomee-microprofile-webapp (The
same as now with an additional dependency)

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:26, Bruno Baptista wrote:


Hi Romain,

Yeah... @Resource would be the right thing to use in order to
inject the managed resource. Something like this:

@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
 @Override
 @Produces
 @Specializes
 @ApplicationScoped
 public ExecutionManager createExecutionManager() {
 return new FailsafeExecutionManager() {
 @Override // hardcoded impl for testing purposes
 public Object execute(final InvocationContext 
invocationContext) {
 return "replaced";
 }
 };
 }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  
  |  Blog
    | 
Old Blog
    | 
Github    |
LinkedIn  
  | Book
  



Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  
  a
écrit :


Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try adding
a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer) to
check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  
  |  Blog
    | 
Old Blog
    | 
Github
    | 
LinkedIn

Re: Override bean from library on TomEE

2018-11-19 Thread Jonathan Gallimore

I haven't seen the code, so its difficult to suggest anything - where would
you expect it to be loaded - in a CDI extension?

On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  wrote:

> Hi all,
>
> I've created a jira for this task to properly track the commits:
> https://issues.apache.org/jira/browse/TOMEE-2278
>
> Right now I have a problem activating the code... The code is in the lib
> folder but it's not being loaded into the classpath.
>
> Do I need to create some kind of a service like this?
>
> Or am I missing to declare it in some xml file?
>
> Cheers
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 18/11/18 12:55, Bruno Baptista wrote:
>
> Hi All,
>
> I came up with a test that successfully overrides the original
> *FailsafeExecutionManagerProvider* Safeguard class.
>
> It was a bit of a surprise but, in this case, beans.xml is useless because
> "The alternatives that you specify in the beans.xml file apply only to
> classes in the same archive." see:
> https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
>
> Because the beans are in different jar files, priority has to be used
> instead:
>
> @Priority(Interceptor.Priority.APPLICATION+10)
> The precise priority might need to be fine tuned because of the fault
> tolerance interceptor... Will have to test the final behavior.
>
> Also, we probably need to reorganize the tomee-microprofile-webapp
> project...
> This is needed because the code overriding the bean needs to be in a
> library and this project only creates a war file, which is in fact a
> container for the bundled libraries. The classes we place in there will not
> be in the final server.
>
> I'm thinking on something like:
>
> tomee
> |
> --- tomee-microprofile
>|
> --- tomee-microprofile-common (The JAR
> to be included in .../lib)
>|
> --- tomee-microprofile-webapp (The
> same as now with an additional dependency)
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 16/11/18 16:26, Bruno Baptista wrote:
>
> Hi Romain,
>
> Yeah... @Resource would be the right thing to use in order to inject the
> managed resource. Something like this:
>
> @Resource(name = "DefaultManagedScheduledExecutorService")
> private ManagedScheduledExecutorService executor;
> Creating the test now.
> Thanks for the help Romain.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 16/11/18 16:07, Romain Manni-Bucau wrote:
>
> FYI this works:
>
>
> @ApplicationScoped
> public class CustomProvider extends FailsafeExecutionManagerProvider {
> @Override
> @Produces
> @Specializes
> @ApplicationScoped
> public ExecutionManager createExecutionManager() {
> return new FailsafeExecutionManager() {
> @Override // hardcoded impl for testing purposes
> public Object execute(final InvocationContext invocationContext) {
> return "replaced";
> }
> };
> }
> }
>
>
> Side note: did you want to use @Resource for the executor injection?
>
> Romain Manni-Bucau
> @rmannibucau  
>  |  Blog 
>  | Old 
> Blog  | 
> Github   |
> LinkedIn  
>  | 
> Book
>  
>
>
> Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  
>  a
> écrit :
>
>
> Hi Bruno,
>
> I assume the alternative is activated in the beans.xml? (if not try adding
> a @Priority maybe or just drop the annotation which should be useless)
>
> If it is i'd start by writing a small test (with application composer) to
> check if it is a bug in tomee cause this is how it must work
>
> Romain Manni-Bucau
> @rmannibucau  
>  |  Blog 
>  | Old 
> Blog  | 
> Github  | 
> LinkedIn 
>  | 
> Book
>  
>
>
> Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  
>  a
> écrit :
>
>
> Hi Roman,
>
> This is what I did and it doesn't work. The original bean is always
> picked up:
>
> @Specializes@Alternative@ApplicationScopedpublic class 
>

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Thanks Jon

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 10:10, Jonathan Gallimore wrote:

I say go for it and create your module. Looking forward to reviewing the PR.

Jon

On Mon, Nov 19, 2018 at 10:08 AM Bruno Baptista  wrote:


Hi Jon,

Well, 2 classes for the module. One doing the work and a test.

We have other modules with just 2 classes, like /tomee-overlay-runner/,
/tomee-util/ and other.

There's probably margin for consolidating some of them, but that's
probably a discussion for another thread.

Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 09:49, Jonathan Gallimore wrote:

I'd be ok with creating a module to include your class file. We'd

probably

just want to keep an eye on it so it doesn't become a bucket of random
stuff - so I could see it becoming tomee-microprofile-fault-tolerance, or
something like that. Is it just one class file for the module?

Jon

On Sun, Nov 18, 2018 at 12:55 PM Bruno Baptista 

wrote:

Hi All,

I came up with a test that successfully overrides the original
/FailsafeExecutionManagerProvider/ Safeguard class.

It was a bit of a surprise but, in this case, beans.xml is useless
because "The alternatives that you specify in the |beans.xml| file apply
only to classes in the same archive." see:
https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

Because the beans are in different jar files, priority has to be used
instead:

@Priority(Interceptor.Priority.APPLICATION+10)

The precise priority might need to be fine tuned because of the fault
tolerance interceptor... Will have to test the final behavior.

Also, we probably need to reorganize the tomee-microprofile-webapp
project...
This is needed because the code overriding the bean needs to be in a
library and this project only creates a war file, which is in fact a
container for the bundled libraries. The classes we place in there will
not be in the final server.

I'm thinking on something like:

tomee
|
--- tomee-microprofile
  |
   --- tomee-microprofile-common (The
JAR to be included in .../lib)
  |
   --- tomee-microprofile-webapp (The
same as now with an additional dependency)

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:26, Bruno Baptista wrote:

Hi Romain,

Yeah... @Resource would be the right thing to use in order to inject
the managed resource. Something like this:

@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
   @Override
   @Produces
   @Specializes
   @ApplicationScoped
   public ExecutionManager createExecutionManager() {
   return new FailsafeExecutionManager() {
   @Override // hardcoded impl for testing purposes
   public Object execute(final InvocationContext

invocationContext) {

   return "replaced";
   }
   };
   }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github<

https://github.com/rmannibucau>  |

LinkedIn  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance

Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau<

rmannibu...@gmail.com>

a

écrit :


Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try

adding

a @Priority maybe or just drop the annotation which should be

useless)

If it is i'd start by writing a small test (with application

composer)

to

check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance

Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
écrit :


Hi Roman,

This is what I did and it doesn't work. The original bean is always
picked up:

@Specializes@Alternative@ApplicationScopedpublic class

FailsafeContainerExecutionManagerProvider extends
FailsafeExecutionManagerProvider {

   @Injectprivate ManagedScheduledExecutorService executor;

   @Produces@ApplicationScoped@Overridepublic

ExecutionManager createExecutionManager() throws Exception {

   final MicroprofileAnnotationMapper mapper =

Re: Override bean from library on TomEE

2018-11-19 Thread Jonathan Gallimore

I say go for it and create your module. Looking forward to reviewing the PR.

Jon

On Mon, Nov 19, 2018 at 10:08 AM Bruno Baptista  wrote:

> Hi Jon,
>
> Well, 2 classes for the module. One doing the work and a test.
>
> We have other modules with just 2 classes, like /tomee-overlay-runner/,
> /tomee-util/ and other.
>
> There's probably margin for consolidating some of them, but that's
> probably a discussion for another thread.
>
> Cheers
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 19/11/18 09:49, Jonathan Gallimore wrote:
> > I'd be ok with creating a module to include your class file. We'd
> probably
> > just want to keep an eye on it so it doesn't become a bucket of random
> > stuff - so I could see it becoming tomee-microprofile-fault-tolerance, or
> > something like that. Is it just one class file for the module?
> >
> > Jon
> >
> > On Sun, Nov 18, 2018 at 12:55 PM Bruno Baptista 
> wrote:
> >
> >> Hi All,
> >>
> >> I came up with a test that successfully overrides the original
> >> /FailsafeExecutionManagerProvider/ Safeguard class.
> >>
> >> It was a bit of a surprise but, in this case, beans.xml is useless
> >> because "The alternatives that you specify in the |beans.xml| file apply
> >> only to classes in the same archive." see:
> >> https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
> >>
> >> Because the beans are in different jar files, priority has to be used
> >> instead:
> >>
> >> @Priority(Interceptor.Priority.APPLICATION+10)
> >>
> >> The precise priority might need to be fine tuned because of the fault
> >> tolerance interceptor... Will have to test the final behavior.
> >>
> >> Also, we probably need to reorganize the tomee-microprofile-webapp
> >> project...
> >> This is needed because the code overriding the bean needs to be in a
> >> library and this project only creates a war file, which is in fact a
> >> container for the bundled libraries. The classes we place in there will
> >> not be in the final server.
> >>
> >> I'm thinking on something like:
> >>
> >> tomee
> >> |
> >> --- tomee-microprofile
> >>  |
> >>   --- tomee-microprofile-common (The
> >> JAR to be included in .../lib)
> >>  |
> >>   --- tomee-microprofile-webapp (The
> >> same as now with an additional dependency)
> >>
> >> Cheers.
> >>
> >> Bruno Baptista
> >> http://twitter.com/brunobat_
> >>
> >>
> >> On 16/11/18 16:26, Bruno Baptista wrote:
> >>> Hi Romain,
> >>>
> >>> Yeah... @Resource would be the right thing to use in order to inject
> >>> the managed resource. Something like this:
> >>>
> >>> @Resource(name = "DefaultManagedScheduledExecutorService")
> >>> private ManagedScheduledExecutorService executor;
> >>>
> >>> Creating the test now.
> >>> Thanks for the help Romain.
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 16/11/18 16:07, Romain Manni-Bucau wrote:
>  FYI this works:
> 
> 
>  @ApplicationScoped
>  public class CustomProvider extends FailsafeExecutionManagerProvider {
>    @Override
>    @Produces
>    @Specializes
>    @ApplicationScoped
>    public ExecutionManager createExecutionManager() {
>    return new FailsafeExecutionManager() {
>    @Override // hardcoded impl for testing purposes
>    public Object execute(final InvocationContext
> >> invocationContext) {
>    return "replaced";
>    }
>    };
>    }
>  }
> 
> 
>  Side note: did you want to use @Resource for the executor injection?
> 
>  Romain Manni-Bucau
>  @rmannibucau  |  Blog
>    | Old Blog
>    | Github<
> >> https://github.com/rmannibucau>  |
>  LinkedIn  | Book
>  <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
>  Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau<
> rmannibu...@gmail.com>
> >> a
>  écrit :
> 
> > Hi Bruno,
> >
> > I assume the alternative is activated in the beans.xml? (if not try
> >> adding
> > a @Priority maybe or just drop the annotation which should be
> useless)
> >
> > If it is i'd start by writing a small test (with application
> composer)
> >> to
> > check if it is a bug in tomee cause this is how it must work
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >   | Old Blog
> >   | Github
> >   | LinkedIn
> >   | Book
> > <
> >>
>

Re: Override bean from library on TomEE

2018-11-19 Thread Bruno Baptista


Hi Jon,

Well, 2 classes for the module. One doing the work and a test.

We have other modules with just 2 classes, like /tomee-overlay-runner/, 
/tomee-util/ and other.


There's probably margin for consolidating some of them, but that's 
probably a discussion for another thread.


Cheers

Bruno Baptista
http://twitter.com/brunobat_


On 19/11/18 09:49, Jonathan Gallimore wrote:

I'd be ok with creating a module to include your class file. We'd probably
just want to keep an eye on it so it doesn't become a bucket of random
stuff - so I could see it becoming tomee-microprofile-fault-tolerance, or
something like that. Is it just one class file for the module?

Jon

On Sun, Nov 18, 2018 at 12:55 PM Bruno Baptista  wrote:


Hi All,

I came up with a test that successfully overrides the original
/FailsafeExecutionManagerProvider/ Safeguard class.

It was a bit of a surprise but, in this case, beans.xml is useless
because "The alternatives that you specify in the |beans.xml| file apply
only to classes in the same archive." see:
https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm

Because the beans are in different jar files, priority has to be used
instead:

@Priority(Interceptor.Priority.APPLICATION+10)

The precise priority might need to be fine tuned because of the fault
tolerance interceptor... Will have to test the final behavior.

Also, we probably need to reorganize the tomee-microprofile-webapp
project...
This is needed because the code overriding the bean needs to be in a
library and this project only creates a war file, which is in fact a
container for the bundled libraries. The classes we place in there will
not be in the final server.

I'm thinking on something like:

tomee
|
--- tomee-microprofile
 |
  --- tomee-microprofile-common (The
JAR to be included in .../lib)
 |
  --- tomee-microprofile-webapp (The
same as now with an additional dependency)

Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:26, Bruno Baptista wrote:

Hi Romain,

Yeah... @Resource would be the right thing to use in order to inject
the managed resource. Something like this:

@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
  @Override
  @Produces
  @Specializes
  @ApplicationScoped
  public ExecutionManager createExecutionManager() {
  return new FailsafeExecutionManager() {
  @Override // hardcoded impl for testing purposes
  public Object execute(final InvocationContext

invocationContext) {

  return "replaced";
  }
  };
  }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github<

https://github.com/rmannibucau>  |

LinkedIn  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance


Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau

a

écrit :


Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try

adding

a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer)

to

check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance


Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
écrit :


Hi Roman,

This is what I did and it doesn't work. The original bean is always
picked up:

@Specializes@Alternative@ApplicationScopedpublic class

FailsafeContainerExecutionManagerProvider extends
FailsafeExecutionManagerProvider {

  @Injectprivate ManagedScheduledExecutorService executor;

  @Produces@ApplicationScoped@Overridepublic

ExecutionManager createExecutionManager() throws Exception {


  final MicroprofileAnnotationMapper mapper =

MicroprofileAnnotationMapper.getInstance();

  final DefaultExecutorServiceProvider executorServiceProvider

= new DefaultExecutorServiceProvider(executor);

  final BulkheadManagerImpl bulkheadManager = new

BulkheadManagerImpl();

  final FailsafeCircuitBreakerManager

Re: Override bean from library on TomEE

2018-11-19 Thread Jonathan Gallimore

I'd be ok with creating a module to include your class file. We'd probably
just want to keep an eye on it so it doesn't become a bucket of random
stuff - so I could see it becoming tomee-microprofile-fault-tolerance, or
something like that. Is it just one class file for the module?

Jon

On Sun, Nov 18, 2018 at 12:55 PM Bruno Baptista  wrote:

> Hi All,
>
> I came up with a test that successfully overrides the original
> /FailsafeExecutionManagerProvider/ Safeguard class.
>
> It was a bit of a surprise but, in this case, beans.xml is useless
> because "The alternatives that you specify in the |beans.xml| file apply
> only to classes in the same archive." see:
> https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
>
> Because the beans are in different jar files, priority has to be used
> instead:
>
> @Priority(Interceptor.Priority.APPLICATION+10)
>
> The precise priority might need to be fine tuned because of the fault
> tolerance interceptor... Will have to test the final behavior.
>
> Also, we probably need to reorganize the tomee-microprofile-webapp
> project...
> This is needed because the code overriding the bean needs to be in a
> library and this project only creates a war file, which is in fact a
> container for the bundled libraries. The classes we place in there will
> not be in the final server.
>
> I'm thinking on something like:
>
> tomee
> |
> --- tomee-microprofile
> |
>  --- tomee-microprofile-common (The
> JAR to be included in .../lib)
> |
>  --- tomee-microprofile-webapp (The
> same as now with an additional dependency)
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 16/11/18 16:26, Bruno Baptista wrote:
> >
> > Hi Romain,
> >
> > Yeah... @Resource would be the right thing to use in order to inject
> > the managed resource. Something like this:
> >
> > @Resource(name = "DefaultManagedScheduledExecutorService")
> > private ManagedScheduledExecutorService executor;
> >
> > Creating the test now.
> > Thanks for the help Romain.
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 16/11/18 16:07, Romain Manni-Bucau wrote:
> >> FYI this works:
> >>
> >>
> >> @ApplicationScoped
> >> public class CustomProvider extends FailsafeExecutionManagerProvider {
> >>  @Override
> >>  @Produces
> >>  @Specializes
> >>  @ApplicationScoped
> >>  public ExecutionManager createExecutionManager() {
> >>  return new FailsafeExecutionManager() {
> >>  @Override // hardcoded impl for testing purposes
> >>  public Object execute(final InvocationContext
> invocationContext) {
> >>  return "replaced";
> >>  }
> >>  };
> >>  }
> >> }
> >>
> >>
> >> Side note: did you want to use @Resource for the executor injection?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>   | Old Blog
> >>   | Github<
> https://github.com/rmannibucau>  |
> >> LinkedIn  | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>
> >>
> >> Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau
> a
> >> écrit :
> >>
> >>> Hi Bruno,
> >>>
> >>> I assume the alternative is activated in the beans.xml? (if not try
> adding
> >>> a @Priority maybe or just drop the annotation which should be useless)
> >>>
> >>> If it is i'd start by writing a small test (with application composer)
> to
> >>> check if it is a bug in tomee cause this is how it must work
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>   | Old Blog
> >>>   | Github
> >>>   | LinkedIn
> >>>   | Book
> >>> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>>
> >>>
> >>> Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
> >>> écrit :
> >>>
>  Hi Roman,
> 
>  This is what I did and it doesn't work. The original bean is always
>  picked up:
> 
>  @Specializes@Alternative@ApplicationScopedpublic class
> FailsafeContainerExecutionManagerProvider extends
> FailsafeExecutionManagerProvider {
> 
>   @Injectprivate ManagedScheduledExecutorService executor;
> 
>   @Produces@ApplicationScoped@Overridepublic
> ExecutionManager createExecutionManager() throws Exception {
> 
> 
>   final MicroprofileAnnotationMapper mapper =
> MicroprofileAnnotationMapper.getInstance();
>   final DefaultExecutorServiceProvider executorServiceProvider
> = new DefaultExecutorServiceProvider(executor);
>   final

Re: Override bean from library on TomEE

2018-11-18 Thread Bruno Baptista


Hi All,

I came up with a test that successfully overrides the original 
/FailsafeExecutionManagerProvider/ Safeguard class.


It was a bit of a surprise but, in this case, beans.xml is useless 
because "The alternatives that you specify in the |beans.xml| file apply 
only to classes in the same archive." see: 
https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm


Because the beans are in different jar files, priority has to be used 
instead:


@Priority(Interceptor.Priority.APPLICATION+10)

The precise priority might need to be fine tuned because of the fault 
tolerance interceptor... Will have to test the final behavior.


Also, we probably need to reorganize the tomee-microprofile-webapp 
project...
This is needed because the code overriding the bean needs to be in a 
library and this project only creates a war file, which is in fact a 
container for the bundled libraries. The classes we place in there will 
not be in the final server.


I'm thinking on something like:

tomee
|
--- tomee-microprofile
                                   |
                                    --- tomee-microprofile-common (The 
JAR to be included in .../lib)

                                   |
                                    --- tomee-microprofile-webapp (The 
same as now with an additional dependency)


Cheers.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:26, Bruno Baptista wrote:


Hi Romain,

Yeah... @Resource would be the right thing to use in order to inject 
the managed resource. Something like this:


@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
 @Override
 @Produces
 @Specializes
 @ApplicationScoped
 public ExecutionManager createExecutionManager() {
 return new FailsafeExecutionManager() {
 @Override // hardcoded impl for testing purposes
 public Object execute(final InvocationContext invocationContext) {
 return "replaced";
 }
 };
 }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  a
écrit :


Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try adding
a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer) to
check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book



Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
écrit :


Hi Roman,

This is what I did and it doesn't work. The original bean is always
picked up:

@Specializes@Alternative@ApplicationScopedpublic class 
FailsafeContainerExecutionManagerProvider extends 
FailsafeExecutionManagerProvider {

 @Injectprivate ManagedScheduledExecutorService executor;

 @Produces@ApplicationScoped@Overridepublic ExecutionManager 
createExecutionManager() throws Exception {


 final MicroprofileAnnotationMapper mapper = 
MicroprofileAnnotationMapper.getInstance();
 final DefaultExecutorServiceProvider executorServiceProvider = new 
DefaultExecutorServiceProvider(executor);
 final BulkheadManagerImpl bulkheadManager = new BulkheadManagerImpl();
 final FailsafeCircuitBreakerManager circuitBreakerManager = new 
FailsafeCircuitBreakerManager();
 final FailsafeRetryManager retryManager = new FailsafeRetryManager();

 return new FailsafeExecutionManager(
 mapper,
 bulkheadManager,
 circuitBreakerManager,
 retryManager,
 new ExecutionPlanFactory(circuitBreakerManager, retryManager, 
bulkheadManager, mapper,
 executorServiceProvider),
 executorServiceProvider);
 }
}


I feel that this needs to be done in a different way... Would you be able
to point me to a similar override currently being done?

Cheers
Bruno Baptista
https://twitter.com/brunobat_
http://tomitribe.com
https://tribestream.io
Bruno

Re: Override bean from library on TomEE

2018-11-16 Thread Bruno Baptista


Hi Romain,

Yeah... @Resource would be the right thing to use in order to inject the 
managed resource. Something like this:


@Resource(name = "DefaultManagedScheduledExecutorService")
private ManagedScheduledExecutorService executor;

Creating the test now.
Thanks for the help Romain.

Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 16:07, Romain Manni-Bucau wrote:

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
 @Override
 @Produces
 @Specializes
 @ApplicationScoped
 public ExecutionManager createExecutionManager() {
 return new FailsafeExecutionManager() {
 @Override // hardcoded impl for testing purposes
 public Object execute(final InvocationContext invocationContext) {
 return "replaced";
 }
 };
 }
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  a
écrit :


Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try adding
a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer) to
check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github
 | LinkedIn
 | Book



Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
écrit :


Hi Roman,

This is what I did and it doesn't work. The original bean is always
picked up:

@Specializes@Alternative@ApplicationScopedpublic class 
FailsafeContainerExecutionManagerProvider extends 
FailsafeExecutionManagerProvider {

 @Injectprivate ManagedScheduledExecutorService executor;

 @Produces@ApplicationScoped@Overridepublic ExecutionManager 
createExecutionManager() throws Exception {


 final MicroprofileAnnotationMapper mapper = 
MicroprofileAnnotationMapper.getInstance();
 final DefaultExecutorServiceProvider executorServiceProvider = new 
DefaultExecutorServiceProvider(executor);
 final BulkheadManagerImpl bulkheadManager = new BulkheadManagerImpl();
 final FailsafeCircuitBreakerManager circuitBreakerManager = new 
FailsafeCircuitBreakerManager();
 final FailsafeRetryManager retryManager = new FailsafeRetryManager();

 return new FailsafeExecutionManager(
 mapper,
 bulkheadManager,
 circuitBreakerManager,
 retryManager,
 new ExecutionPlanFactory(circuitBreakerManager, retryManager, 
bulkheadManager, mapper,
 executorServiceProvider),
 executorServiceProvider);
 }
}


I feel that this needs to be done in a different way... Would you be able
to point me to a similar override currently being done?

Cheers
Bruno Baptista
https://twitter.com/brunobat_
http://tomitribe.com
https://tribestream.io
Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 10:28, Romain Manni-Bucau wrote:

Hi Bruno,

it is a palin bean so @Specializes works, did you put it on the method?

Romain Manni-Bucau
@rmannibucau   |  
Blog  | Old 
Blog  | Github 
  |
LinkedIn  
 | 
Book 



Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  
 a écrit :


Hi all,

We have a problem with the integration of the Safeguard Fault Tolerance
library on TomEE 8 and I need help to solve it. This is a follow up to
the original email thread, from Oct 3, in the Geronimo mailing list,
where we decided to do perform the override in the container side.

I need to override the starting point for the library, originally here:

https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java

Because it's not using a managed executor service from TomEE... Like
this one:

Re: Override bean from library on TomEE

2018-11-16 Thread Romain Manni-Bucau

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
@Override
@Produces
@Specializes
@ApplicationScoped
public ExecutionManager createExecutionManager() {
return new FailsafeExecutionManager() {
@Override // hardcoded impl for testing purposes
public Object execute(final InvocationContext invocationContext) {
return "replaced";
}
};
}
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  a
écrit :

> Hi Bruno,
>
> I assume the alternative is activated in the beans.xml? (if not try adding
> a @Priority maybe or just drop the annotation which should be useless)
>
> If it is i'd start by writing a small test (with application composer) to
> check if it is a bug in tomee cause this is how it must work
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
> écrit :
>
>> Hi Roman,
>>
>> This is what I did and it doesn't work. The original bean is always
>> picked up:
>>
>> @Specializes@Alternative@ApplicationScopedpublic class 
>> FailsafeContainerExecutionManagerProvider extends 
>> FailsafeExecutionManagerProvider {
>>
>> @Injectprivate ManagedScheduledExecutorService executor;
>>
>> @Produces@ApplicationScoped@Overridepublic ExecutionManager 
>> createExecutionManager() throws Exception {
>>
>>
>> final MicroprofileAnnotationMapper mapper = 
>> MicroprofileAnnotationMapper.getInstance();
>> final DefaultExecutorServiceProvider executorServiceProvider = new 
>> DefaultExecutorServiceProvider(executor);
>> final BulkheadManagerImpl bulkheadManager = new 
>> BulkheadManagerImpl();
>> final FailsafeCircuitBreakerManager circuitBreakerManager = new 
>> FailsafeCircuitBreakerManager();
>> final FailsafeRetryManager retryManager = new FailsafeRetryManager();
>>
>> return new FailsafeExecutionManager(
>> mapper,
>> bulkheadManager,
>> circuitBreakerManager,
>> retryManager,
>> new ExecutionPlanFactory(circuitBreakerManager, 
>> retryManager, bulkheadManager, mapper,
>> executorServiceProvider),
>> executorServiceProvider);
>> }
>> }
>>
>>
>> I feel that this needs to be done in a different way... Would you be able
>> to point me to a similar override currently being done?
>>
>> Cheers
>> Bruno Baptista
>> https://twitter.com/brunobat_
>> http://tomitribe.com
>> https://tribestream.io
>> Bruno Baptista
>> http://twitter.com/brunobat_
>>
>>
>> On 16/11/18 10:28, Romain Manni-Bucau wrote:
>>
>> Hi Bruno,
>>
>> it is a palin bean so @Specializes works, did you put it on the method?
>>
>> Romain Manni-Bucau
>> @rmannibucau  
>>  |  Blog 
>>  | Old 
>> Blog  | 
>> Github   |
>> LinkedIn  
>>  | 
>> Book
>>  
>> 
>>
>>
>> Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  
>>  a écrit :
>>
>>
>> Hi all,
>>
>> We have a problem with the integration of the Safeguard Fault Tolerance
>> library on TomEE 8 and I need help to solve it. This is a follow up to
>> the original email thread, from Oct 3, in the Geronimo mailing list,
>> where we decided to do perform the override in the container side.
>>
>> I need to override the starting point for the library, originally here:
>>
>> https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java
>>
>> Because it's not using a managed executor service from TomEE... Like
>> this one: "java:comp/DefaultManagedScheduledExecutorService"
>>
>> I Expect to do the wiring in here
>>

Re: Override bean from library on TomEE

2018-11-16 Thread Romain Manni-Bucau

Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try adding
a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer) to
check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a écrit :

> Hi Roman,
>
> This is what I did and it doesn't work. The original bean is always picked
> up:
>
> @Specializes@Alternative@ApplicationScopedpublic class 
> FailsafeContainerExecutionManagerProvider extends 
> FailsafeExecutionManagerProvider {
>
> @Injectprivate ManagedScheduledExecutorService executor;
>
> @Produces@ApplicationScoped@Overridepublic ExecutionManager 
> createExecutionManager() throws Exception {
>
>
> final MicroprofileAnnotationMapper mapper = 
> MicroprofileAnnotationMapper.getInstance();
> final DefaultExecutorServiceProvider executorServiceProvider = new 
> DefaultExecutorServiceProvider(executor);
> final BulkheadManagerImpl bulkheadManager = new BulkheadManagerImpl();
> final FailsafeCircuitBreakerManager circuitBreakerManager = new 
> FailsafeCircuitBreakerManager();
> final FailsafeRetryManager retryManager = new FailsafeRetryManager();
>
> return new FailsafeExecutionManager(
> mapper,
> bulkheadManager,
> circuitBreakerManager,
> retryManager,
> new ExecutionPlanFactory(circuitBreakerManager, retryManager, 
> bulkheadManager, mapper,
> executorServiceProvider),
> executorServiceProvider);
> }
> }
>
>
> I feel that this needs to be done in a different way... Would you be able
> to point me to a similar override currently being done?
>
> Cheers
> Bruno Baptista
> https://twitter.com/brunobat_
> http://tomitribe.com
> https://tribestream.io
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 16/11/18 10:28, Romain Manni-Bucau wrote:
>
> Hi Bruno,
>
> it is a palin bean so @Specializes works, did you put it on the method?
>
> Romain Manni-Bucau
> @rmannibucau  
>  |  Blog 
>  | Old 
> Blog  | 
> Github   |
> LinkedIn  
>  | 
> Book
>  
>
>
> Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  
>  a écrit :
>
>
> Hi all,
>
> We have a problem with the integration of the Safeguard Fault Tolerance
> library on TomEE 8 and I need help to solve it. This is a follow up to
> the original email thread, from Oct 3, in the Geronimo mailing list,
> where we decided to do perform the override in the container side.
>
> I need to override the starting point for the library, originally here:
>
> https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java
>
> Because it's not using a managed executor service from TomEE... Like
> this one: "java:comp/DefaultManagedScheduledExecutorService"
>
> I Expect to do the wiring in here
> .../apache-tomee/tomee/tomee-microprofile-webapp/src
>
> Like using a @Specializes bean or something, but I think we cannot do
> that there. Could someone help me wire up this new bean?
>
> I had a PR to fix this the lib itself but it was decided not to move
> with it. For the curious, it's 
> here:https://github.com/apache/geronimo-safeguard/pull/2
>
> Cheers
> --
> Bruno Baptistahttp://twitter.com/brunobat_
>
>
>

Re: Override bean from library on TomEE

2018-11-16 Thread Bruno Baptista


Hi Roman,

This is what I did and it doesn't work. The original bean is always 
picked up:


@Specializes @Alternative @ApplicationScoped public class 
FailsafeContainerExecutionManagerProvider extends 
FailsafeExecutionManagerProvider { @Inject private 
ManagedScheduledExecutorService executor; @Produces @ApplicationScoped 
@Override public ExecutionManager createExecutionManager() throws 
Exception { final MicroprofileAnnotationMapper mapper = 
MicroprofileAnnotationMapper.getInstance(); final 
DefaultExecutorServiceProvider executorServiceProvider = new 
DefaultExecutorServiceProvider(executor); final BulkheadManagerImpl 
bulkheadManager = new BulkheadManagerImpl(); final 
FailsafeCircuitBreakerManager circuitBreakerManager = new 
FailsafeCircuitBreakerManager(); final FailsafeRetryManager retryManager 
= new FailsafeRetryManager(); return new FailsafeExecutionManager( 
mapper, bulkheadManager, circuitBreakerManager, retryManager, new 
ExecutionPlanFactory(circuitBreakerManager, retryManager, 
bulkheadManager, mapper, executorServiceProvider), 
executorServiceProvider); } }



I feel that this needs to be done in a different way... Would you be 
able to point me to a similar override currently being done?


Cheers

Bruno Baptista
https://twitter.com/brunobat_
http://tomitribe.com
https://tribestream.io
Bruno Baptista
http://twitter.com/brunobat_


On 16/11/18 10:28, Romain Manni-Bucau wrote:

Hi Bruno,

it is a palin bean so @Specializes works, did you put it on the method?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  a écrit :


Hi all,

We have a problem with the integration of the Safeguard Fault Tolerance
library on TomEE 8 and I need help to solve it. This is a follow up to
the original email thread, from Oct 3, in the Geronimo mailing list,
where we decided to do perform the override in the container side.

I need to override the starting point for the library, originally here:


https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java

Because it's not using a managed executor service from TomEE... Like
this one: "java:comp/DefaultManagedScheduledExecutorService"

I Expect to do the wiring in here
.../apache-tomee/tomee/tomee-microprofile-webapp/src

Like using a @Specializes bean or something, but I think we cannot do
that there. Could someone help me wire up this new bean?

I had a PR to fix this the lib itself but it was decided not to move
with it. For the curious, it's here:
https://github.com/apache/geronimo-safeguard/pull/2

Cheers
--
Bruno Baptista
http://twitter.com/brunobat_

Re: Override bean from library on TomEE

2018-11-16 Thread Romain Manni-Bucau

Hi Bruno,

it is a palin bean so @Specializes works, did you put it on the method?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  a écrit :

> Hi all,
>
> We have a problem with the integration of the Safeguard Fault Tolerance
> library on TomEE 8 and I need help to solve it. This is a follow up to
> the original email thread, from Oct 3, in the Geronimo mailing list,
> where we decided to do perform the override in the container side.
>
> I need to override the starting point for the library, originally here:
>
>
> https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java
>
> Because it's not using a managed executor service from TomEE... Like
> this one: "java:comp/DefaultManagedScheduledExecutorService"
>
> I Expect to do the wiring in here
> .../apache-tomee/tomee/tomee-microprofile-webapp/src
>
> Like using a @Specializes bean or something, but I think we cannot do
> that there. Could someone help me wire up this new bean?
>
> I had a PR to fix this the lib itself but it was decided not to move
> with it. For the curious, it's here:
> https://github.com/apache/geronimo-safeguard/pull/2
>
> Cheers
> --
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
>

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

Re: Override bean from library on TomEE

20 matches

Site Navigation

Mail list logo

Footer information