1:47 p.m.
Thanks Stuart - I hadn't thought of that.
It does bring up a couple of questions/concerns though:
1) The AspectJ attach EJB would need to be in an independent module from
the rest of the application (minor detail)
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.
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
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 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/
>> org/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
>>
>
>