Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc: JBossLoadTimeWeaver on JBoss 6.0 [SPR-7887] #12543

Closed
spring-issuemaster opened this Issue Jan 14, 2011 · 14 comments

Comments

Projects
None yet
1 participant
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jan 14, 2011

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:

Referenced from: commits 44b5df0, 0c5a13c

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 27, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 27, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 27, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

Costin Leau commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

Jens Reimann commented

I am using "default".

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 28, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 31, 2011

Costin Leau commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 31, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 31, 2011

Costin Leau commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 31, 2011

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

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jul 21, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.