Re: Override bean from library on TomEE

Mon, 19 Nov 2018 08:59:09 -0800 

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 <radcor...@yahoo.com.invalid>
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 <bruno...@gmail.com> 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 <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <

https://github.com/rmannibucau> |

LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<

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


Le lun. 19 nov. 2018 à 15:24, Bruno Baptista <bruno...@gmail.com> 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
<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,

     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<https://twitter.com/rmannibucau>  <

https://twitter.com/rmannibucau>  |  Blog

     <https://rmannibucau.metawerx.net/>  <

https://rmannibucau.metawerx.net/>  | Old Blog

     <http://rmannibucau.wordpress.com>  <

http://rmannibucau.wordpress.com>  | Github<

https://github.com/rmannibucau>

<https://github.com/rmannibucau>  |

     LinkedIn<https://www.linkedin.com/in/rmannibucau>  <

https://www.linkedin.com/in/rmannibucau>  | Book

     <

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

<


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

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

rmannibu...@gmail.com>  <mailto: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<https://twitter.com/rmannibucau>  <

https://twitter.com/rmannibucau>  |  Blog

     <https://rmannibucau.metawerx.net/>  <

https://rmannibucau.metawerx.net/>  | Old Blog

     <http://rmannibucau.wordpress.com>  <

http://rmannibucau.wordpress.com>  | Github

     <https://github.com/rmannibucau>  <

https://github.com/rmannibucau>  | LinkedIn

     <https://www.linkedin.com/in/rmannibucau>  <

https://www.linkedin.com/in/rmannibucau>  | Book

     <

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

<


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

     Le ven. 16 nov. 2018 à 12:44, Bruno Baptista<

bruno...@gmail.com>

<mailto:bruno...@gmail.com>  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 {

          @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<https://twitter.com/rmannibucau>  <

https://twitter.com/rmannibucau>  <https://twitter.com/rmannibucau>  <
https://twitter.com/rmannibucau>  |  Blog<
https://rmannibucau.metawerx.net/>  <https://rmannibucau.metawerx.net/>

<

https://rmannibucau.metawerx.net/>  <https://rmannibucau.metawerx.net/
| Old Blog<http://rmannibucau.wordpress.com>  <
http://rmannibucau.wordpress.com>  <http://rmannibucau.wordpress.com>

<

http://rmannibucau.wordpress.com>  | Github<

https://github.com/rmannibucau>

<https://github.com/rmannibucau>  <https://github.com/rmannibucau>  <
https://github.com/rmannibucau>  |

     LinkedIn<https://www.linkedin.com/in/rmannibucau>  <

https://www.linkedin.com/in/rmannibucau>  <
https://www.linkedin.com/in/rmannibucau>  <
https://www.linkedin.com/in/rmannibucau>  | Book<


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

<


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

<


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

<


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

     Le ven. 16 nov. 2018 à 11:00, Bruno Baptista<

bruno...@gmail.com>  <mailto:bruno...@gmail.com>  <bruno...@gmail.com>
<mailto:bruno...@gmail.com>  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_  <

http://twitter.com/brunobat_>

Reply via email to