2

As part of an structural refactor, we moved our application EAR building technique from a custom, weird Ant script to a full Maven solution.

The final structure used to be a EAR containing a single EJB build by merging two EJBs; the application core and the customer-specific implementation which may define some decorators.

The new structure we wanted to put in place was rather an EAR containing the two EJBs side-by-side. This works mostly as expected except for the interceptors and decorators.

In the customer-specific implementation, we define decorators that looks like this:

import javax.annotation.Priority;
import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;
import javax.interceptor.Interceptor;

@Decorator
@Priority(Interceptor.Priority.APPLICATION)
public class ServiceDecorator implements ServiceInterface {

    @Inject
    @Delegate
    ServiceBean delegate;

Upon startup on Wildfly 10.1, Weld (2.3.5-Final, shipped with Wildfly) reports that the decorator is indeed enabled but it never seems to be able to bind the decorator to the service which reside in the core implementation.

DEBUG [org.jboss.weld.Bootstrap] (MSC service thread 1-6) WELD-000104: Enabled decorator types for Weld BeanManager for /opt/wildfly/standalone/deployments/app.ear/core.jar [bean count=2]: 
  - class ServiceDecorator
[...]
DEBUG [org.jboss.weld.Bootstrap] (MSC service thread 1-6) WELD-000108: Decorator: Decorator [class ServiceDecorator] decorates [Service] with delegate type [ServiceBean] and delegate qualifiers [@Default]

We even tracked down the code in Weld core and we have indeed seen that the decorator is globally enabled () but never bound to the service since the core implementation bean manager does not see the decorator bean.

We also tried moving the decorator in a regular lib jar and got the same result. Interceptors were also attempted as well as using the @Specialize annotation, all to no avail...

So, in summary, is there any way to define a decorator or interceptor in an EJB to enhance the behavior of a service located in another EJB when both are contained in the same EAR?

Dominique Toupin
  • 411
  • 3
  • 11
  • Did you already try to put those jar-files (including beans.xml) into one war instead of an ear? Or did you decide consciously against it? – aschoerk Aug 24 '17 at 17:32
  • @aschoerk I am not sure what your suggestion means; are you saying that I should replace my "EAR" container by a "WAR" container? If that is the case, I don't believe that would be an option as I put my EJB jar-files in an EAR to provide only Service Beans and we do not serve any web content... – Dominique Toupin Aug 24 '17 at 19:48
  • 1
    Yes I do. The WARs can also provide remote beans. There is no difference. Ok, it depends on your container see [accessing-ejb-in-war-from-remote-standalone-client](https://stackoverflow.com/questions/11199704/accessing-ejb-in-war-from-remote-standalone-client) it works on wildfly. – aschoerk Aug 24 '17 at 22:27
  • @aschoerk I will give it a try and let you know but it indeed looks like a viable solution... – Dominique Toupin Aug 25 '17 at 12:01
  • Are the two EJBs in different jar files? – Steve C Aug 28 '17 at 07:57
  • 1
    I think you are bumping into EE specification limitations on "visibility". E.g. one EJB archive cannot "see" the beans (or decorators for that matter) of the other EJB archive. If you were to merge them into one EJB archive or put in into one WAR file, this would IMO work. Please note that these limitations are not coming from Weld/CDI, it is implied by EE umbrella spec (JSR-342). – Siliarus Aug 28 '17 at 08:07
  • @SteveC Yes the two EJBs are in different files in other to separate the core implementation from the customer-specific elements – Dominique Toupin Aug 28 '17 at 17:50
  • @aschoerk I successfully turned the EAR into a WAR with more-or-less major adjustments: 1. the JNDI remoting string are differents in that there there is no longer a "module" part (now ejb:/war-name.war/Service!ServiceRemote, used to be ejb:/ear-name.ear/ejb-name.jar/Service!ServiceRemote) 2. automatic discovery of entities (JPA) no longer occurs; I had to add lib/core.jar for the discovery to be performed. I am still having some issues with a singleton Startup bean that call another bean annotated with RolesAllowed that used to work ok; any other thoughts? – Dominique Toupin Aug 28 '17 at 18:01

0 Answers0