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

[Eric B]

On Wed, Oct 18, 2017 at 3:37 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

>
>
>> 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.
>

Am I missing something in my understanding of JEE specs?  I thought the
entire principle of the @Singleton was to ensure only a single EJB in the
entire cluster.  Hence the Singleton subsystem?  As per the docs (
https://docs.jboss.org/author/display/WFLY10/HA+Singleton+Features):

In general, an HA or clustered singleton is a service that exists on
multiple nodes in a cluster, but is active on just a single node at any
given time. If the node providing the service fails or is shut down, a new
singleton provider is chosen and started.


Is it as simple as setting in the deployment descriptor not to cluster the
@Singleton?   ie: in a jboss-ejb3.xml:

<?xml version="1.1" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:c="urn:clustering:1.0"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
               version="3.1"
               impl-version="2.0">
    <assembly-descriptor>
        <c:clustering>
            <ejb-name>AspectJWeaverLoader</ejb-name>
            <c:clustered>false</c:clustered>
        </c:clustering>
    </assembly-descriptor>
</jboss:ejb-jar>


Thanks!

Eric







> 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 at 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 at 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/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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171018/5b5480a0/attachment-0001.html