Re: [wildfly-dev] Dynamically attaching AspectJ LTW weaver from EAR

> 2) The EJB required is of a singleton pattern. How would that work in a > clustered environment? A @Singleton @Startup EJB would only be spawned in > a single JVM - other nodes in the cluster won't trigger the @PostConstruct > method of it and consquently not load the weaver. > Just don't make it clustered, you want one per JVM not one per cluster.

Stuart > > Is there a way to force eager initialization of a @Stateless bean > instead? > > > Baring that, I did run across a blog entry that indicates the use of the > Observer pattern listening for the ApplicationScope ( > https://rmannibucau.wordpress.com/2015/03/10/cdi-and-startup/). But I > suspect that at that point the beans have already been scanned. > > @ApplicationScoped > public class ProvisioningDataForApplicationLifecycle { > private final Map<String, User> users = new HashMap<>(); // + getter > > public void init(@Observes @Initialized(ApplicationScoped.class) > Object init) { > users.put("cdi", new User("cdi", "1.1")); > users.put("deltaspike", new User("deltaspike", "1.3")); > } > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > Object init) { > users.clear(); > } > } > > > > This seems fairly like a complex solution to a fairly simple ask. Or am > I misunderstanding the @Singleton pattern? > > Thanks, > > Eric > > > On Wed, Oct 18, 2017 at 10:55 AM, Stuart Douglas < > stuart.w.douglas(a)gmail.com&gt; wrote: > >> So one possibility that comes to mind would be to create a small >> deployment that does the aspectJ attach on deploy (e.g. in a @PostConstruct >> method of an @Startup EJB). >> >> You could then add an inter-deployment dependency on this deployment to >> all your other deployments, which should ensure that this code is run >> before other modules are created/loaded. >> >> Stuart >> >> On Wed, Oct 18, 2017 at 4:00 AM, Eric B <ebenzacar(a)gmail.com&gt; wrote: >> >>> Hi, >>> >>> I'm looking to use AspectJ Load Time Weaving with Wildfly 10. Looking >>> around at some posts, it is a little complicated to get Wildfly launched >>> properly with the AJ weaver due to the way the AJ library intializes the >>> logging subsystem differently than WF. >>> >>> Digging around, I found a config that actually works. It is documented >>> here (obviously some of the class names/versions have to change): >>> https://github.com/ChienChingLee/How-to-launch-Wild >>> fly-9.0-with-AspectJ-1.8-LTW >>> >>> But I'm not a fan of changing my conf file to something that has >>> hardcoded paths/jar names in it - for example adding: >>> -Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/or >>> g/jboss/logmanager/main/jboss-logmanager-2.0.0.Final.jar >>> >>> >>> Digging around some more in AJ, I saw that as of AJ 1.8.7, there is a >>> way to dynamically attach the weaver to the JVM. Very cool. >>> https://www.eclipse.org/aspectj/doc/released/README-187.html >>> But in order to use the LTW effectively, I need to ensure that the >>> weaver is loaded prior to WF scanning and loading any of my classes (EJB, >>> annotated beans, pojos, etc). But I have no ideas how to do that. >>> >>> In the case of a console application, it is pretty straight forward - >>> make it the first item in the application's main() method. But in the case >>> of a JEE app, I don't know of any main() equivalent. >>> >>> >>> Is there a way to hook into the classloading mechanism of WF instead to >>> tell it to load the weaver if it isn't already loaded? Can this be done >>> from within the EAR deployment? Or is there a single point of entry that >>> WF accesses before scanning any of the classes in the EAR? Or is there a >>> simpler way of configuring or attaching the AJ Weaver? I did find an old >>> ticket (https://issues.jboss.org/browse/WFLY-895) that related to this >>> issue, but it is marked as WONT FIX. >>> >>> Am not sure of the best approach at this point. >>> >>> >>> Thanks, >>> >>> Eric >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >