Doc: JBossLoadTimeWeaver on JBoss 6.0 [SPR-7887]

[spring-projects-issues]

Jens Reimann opened SPR-7887 and commented

The load time weaver used with AspectJ stopped working with JBoss 6.

I made a plain war file with one aspect written in AspecJ. The compile time weaving is working in JBoss 5.1 and 6. The load time weaving is triggered in JBoss 5.1 but when I deploy the same WAR file to JBoss 6 the load time weaving is not triggered although the load time weaver for JBoss is found and activated by Spring according to the log.

I also found that @Transactional only works using the proxy mode, once aspectj mode used there is no evaluation of @Transactional. So it looks like as if the Spring library suffers the same problem.

I can upload my sample war but since it is 7 MB I would wait until someone needs it.

---

Affects: 3.0.5

Attachments:

• testwebaop1.war (4.21 MB)

Referenced from: commits 44b5df0, 0c5a13c

[spring-projects-issues]

Costin Leau commented

Jens is it AspectJ that causes the problem or LTW in general? Regarding the WAR can you make a very basic jar, no libraries filters or anything like that and simply make it available. W/o any binaries the war should be quite small (max hundred of kbs).
I'll try and look into it as soon as possible.

[spring-projects-issues]

Jens Reimann commented

This seems to be a problem with the LTW implementation of Spring. Using AspectJ with compile time weaving works even with JBoss 6. Using LTW works only with JBoss 5.1.

I try to make a sample tomorrow if find the time.

[spring-projects-issues]

Costin Leau commented

I think we're talking about different things here - I just tried petclinic with Spring 3.0.3 and it seems to be working just fine. I've used the JPA with automatic LTW detection and context and tx config. Anything special in your config?

[spring-projects-issues]

Jens Reimann commented

Well tx might be working fine since it uses Spring AOP by default. Try switching tx support from proxy to aspectj mode. Nothing special I am aware of. The LTW adapter is detecting JBoss and JBoss LTW fine, but it does not perform LTW. I'll try to prepare the sample.

[spring-projects-issues]

Costin Leau commented

No need. I've been able to reproduce this locally myself - indeed the LTW works just fine (registers the class transformer) but it never gets called to intercept the classes. I assume something in the internal JBoss classloading architecture changed though it's not apparent since the LTW registration works just fine.
I'll keep you updated but it might be that we'll be able to address this only in the 3.1.x branch since it doesn't seem to be that trivial to fix.

[spring-projects-issues]

Jens Reimann commented

Output JBoss 5.1.0:
11:39:49,915 INFO [DefaultListableBeanFactory] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@5db5adb0: defining beans [org.springframework.context.weaving.AspectJWeavingEnabler#0,org.springframework.context.config.internalBeanConfigurerAspect,loadTimeWeaver,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,sched1,org.springframework.scheduling.support.MethodInvokingRunnable#0,org.springframework.scheduling.config.ScheduledTaskRegistrar#0,test1]; root of factory hierarchy
11:39:50,120 INFO [ThreadPoolTaskScheduler] Initializing ExecutorService 'sched1'
11:39:50,216 ERROR [STDERR] Init
11:39:50,391 ERROR [STDERR] Before
11:39:50,398 ERROR [STDERR] Tick
11:39:50,399 ERROR [STDERR] Afte
11:39:50,401 INFO [ContextLoader] Root WebApplicationContext: initialization completed in 1223 ms
11:39:50,441 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
11:39:50,457 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
11:39:50,464 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 26s:520ms
11:39:51,351 ERROR [STDERR] Before
11:39:51,351 ERROR [STDERR] Tick
11:39:51,351 ERROR [STDERR] Afte
11:39:52,351 ERROR [STDERR] Before
11:39:52,351 ERROR [STDERR] Tick
11:39:52,351 ERROR [STDERR] Afte

Output JBoss 6.0.0:
11:41:14,062 INFO [DefaultListableBeanFactory] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@9ab9261: defining beans [org.springframework.context.weaving.AspectJWeavingEnabler#0,org.springframework.context.config.internalBeanConfigurerAspect,loadTimeWeaver,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,sched1,org.springframework.scheduling.support.MethodInvokingRunnable#0,org.springframework.scheduling.config.ScheduledTaskRegistrar#0,test1]; root of factory hierarchy
11:41:14,080 INFO [ThreadPoolTaskScheduler] Initializing ExecutorService 'sched1'
11:41:14,088 ERROR [STDERR] Init
11:41:14,127 ERROR [STDERR] Tick
11:41:14,129 INFO [ContextLoader] Root WebApplicationContext: initialization completed in 130 ms
11:41:14,212 INFO [service] Removing bootstrap log handlers
11:41:14,309 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
11:41:14,311 INFO [org.apache.coyote.ajp.AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
11:41:14,312 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.Final "Neo"] Started in 21s:267ms
11:41:15,094 ERROR [STDERR] Tick
11:41:16,094 ERROR [STDERR] Tick
11:41:17,094 ERROR [STDERR] Tick
11:41:18,094 ERROR [STDERR] Tick
11:41:19,094 ERROR [STDERR] Tick

[spring-projects-issues]

Costin Leau commented

What configuration are you using for starting the server? default, minimal, jbossweb-standalone? Just trying to address all target deployments.

[spring-projects-issues]

Jens Reimann commented

I am using "default".

[spring-projects-issues]

Marius Bogoevici commented

Jens, Costin

The LTW registration works fine, the problem is that JBoss' scanning deployer loads the classes before the ApplicationContext is bootstrapping, i.e. before the transformer is added to the classloader.

While we will try to find a better solution for this, a simple workaround that I can think of would be to include a WEB-INF/jboss-scanning.xml file with the following content:

<scanning xmlns="urn:jboss:scanning:1.0">
</scanning>

[spring-projects-issues]

Costin Leau commented

Jens can you confirm whether the workaround fixes the problem on your end?

[spring-projects-issues]

Jens Reimann commented

Costin, yes this seems to solve the issue quite fine.

Seems to be a workaround. Although I had to place it in the WAR file which is packed inside an EAR file. Putting the file in the META-INF of the EAR file did not work (maybe I did something wrong). I am not sure what this means for the packaged JPA JARs in the EAR file. But anyway, for the moment this looks really good.

Thanks for the help!

[spring-projects-issues]

Costin Leau commented

It worked for me if I placed the file as mentioned directly inside WEB-INF (not META-INF).

[spring-projects-issues]

Ales Justin commented

Although I had to place it in the WAR file which is packed inside an EAR file. Putting the file in the META-INF of the EAR file did not work (maybe I did something wrong).

Putting jboss-scanning.xml into EAR' META-INF only controls direct EAR' classpath entries.
e.g. EAR' lib/ jars, non-module jars, ...
Each sub-deployment should have its own jboss-scanning.xml file.

This is current, by default, behavior.
But since deployment is metadata driven (physical files are just one way of expressing this metadata),
this behavior could easily be changed with additional deployer(s).

I am not sure what this means for the packaged JPA JARs in the EAR file.

Like mentioned, it depends how they are defined: true EAR module (aka sub-deployment) vs. plain cp entry

[spring-projects-issues]

Juergen Hoeller commented

I've turned this into a documentation issue, adding a corresponding note to JBossLoadTimeWeaver.

As of Spring 3.1, JBossLoadTimeWeaver also supports JBoss 7. For Spring 3.0.6, it's JBoss 5 and 6 only.

Juergen