Doc: Load-time weaving limitations with Tomcat and Hibernate [SPR-7440]

[spring-projects-issues]

Juergen Zimmermann opened SPR-7440 and commented

When I use Hibernate to persist an object of a class which inherits from an abstract (entity) class: nothing happens if version=3.0" inside web.xml

If I change version="2.5" then everything works fine. I'll attach a testcase. The war file is missing all Spring JARs and hibernate3.jar which can be downloaded at http://sourceforge.net/projects/hibernate/files/hibernate3/3.6.0.Beta2

When you enable logging for Hibernate and set org.hibernate.SQL to level DEBUG, then you'll see that there is a SQL INSERT statement when web.xml has version="2.5", but there is no INSERT statement when changing to version="3.0".

The issue described at https://jira.springframework.org/browse/SPR-7350 is gone. This is a new one.

---

Attachments:

• testcase.src.zip (12.15 kB)
• testcase.war (6.13 MB)

Issue Links:

• Test Spring 3.1 compatibility with Hibernate 3.6.x [SPR-8111] #12765 Test Spring 3.1 compatibility with Hibernate 3.6.x
• Proper load-time weaving support for Hibernate 5 [SPR-13886] #18459 Proper load-time weaving support for Hibernate 5

2 votes, 6 watchers

[spring-projects-issues]

Juergen Zimmermann commented

In testcase.war the file META-INF/context.xml the context's name is "hska".

[spring-projects-issues]

Costin Leau commented

What version of tomcat are you actually using? The latest Tomcat is 7.0.0.beta (no 7.0.1 or 7.0.2) and 6.0.29.
Considering the previous class loading problem (#12009) I would test this against 7.0.1, once it gets released.

[spring-projects-issues]

Costin Leau commented

JuergenZ, I've tried to reproduce the problem without success. Could you post a very minimal test case (just like you did in SRP-7350) with a minimal WAR, a minimal class hierarchy/Hibernate mapping that exposes the problem?

Thanks,

[spring-projects-issues]

Juergen Zimmermann commented

7.0.2 isn't officially released yet, but you can get it from http://people.apache.org/~markt/dev/tomcat-7/v7.0.2.

Sorry, that I didn't mention how to reproduce:

1. Start the WAR
2. Open a webbrowser with the index page
3. Click a the left menu bar at the item "Create Customer" (you only can enter a customer's name)
   4a) When using version="3.0" you'll see in the Tomcat console, that the object is null
   4b) When using version="2.5" you can click at the menu item "Find Customer", and you can find it.

The configured database is HSQLDB in "mem" mode, superuser "SA" without password.

[spring-projects-issues]

Juergen Zimmermann commented

If you're interested in the voting please see http://old.nabble.com/-VOTE--Release-Apache-Tomcat-7.0.2-td29341592.html

[spring-projects-issues]

Costin Leau commented

Juergen, I still have issues reproducing the problem. Also debugging is difficult with the JSF layer on top. Can you please trim down the war and leave just basic Hibernate usage + Spring (no LTW, no AspectJ, no JSF, etc...)?
Thanks,

[spring-projects-issues]

Juergen Zimmermann commented

I migrated JSF to SpringMVC (which I had to learn first), and kept LTW and also AspectJ: everything works fine now. The difference is only: either JSF2/Mojarra or SpringMVC.

I've no idea how to proceed.

[spring-projects-issues]

Juergen Zimmermann commented

Since I'm not a native English speaker I'm not sure whether I made clear when the issue occurs:
a) NOT when the web app is loaded
b) The issue occurs at runtime when an object shall be persisted which belongs to a concrete class in an inheritance hierarchy.of Hibernate's entity classes.

[spring-projects-issues]

Costin Leau commented

Juergen, as I've mentioned before I'm unable to reproduce this problem. Could you please remove all the unnecessary 'craft' from you app and leave a very basic page (ideally html) with a button/form that can trigger the problem? In its current form, there are simply too many things that might cause this outside Spring - from JSF to business logic.
The slimmer the application is, the easier it is to spot the problem.
Thanks,

[spring-projects-issues]

Chris Beams commented

Guys, is this issue still relevant? Juergen, do you continue to see this behavior against recent Spring 3.1 snapshots?

[spring-projects-issues]

Chris Beams commented

Resolving as "cannot reproduce" after one month of waiting for user feedback.

Juergen, if you still wish to pursue this, please reopen the issue and submit a project that reproduces the behavior following the instructions at https://github.com/SpringSource/spring-framework-issues#readme

Thanks!

[spring-projects-issues]

Scott Van Wart commented

It seems that if you set version="3.0" in web.xml, Tomcat handles classloading differently, and it completely breaks load time weaving. I'm assuming the original submitter is using a similar setup. I can reproduce this with a demo project someone was kind enough to publish a few years ago; I only updated Tomcat to version 7.0.25, and Spring to 3.1 (replacing the JARs packaged in the ltwdemo project), changed version to 3.0 in web.xml (and updated the schema location), and noticed AnnotationBeanConfigurerAspect.configureBean() wasn't getting called when my @Configurable class was instantiated. This also broke transaction support if mode="aspectj" was set.

[spring-projects-issues]

Costin Leau commented

Scott, do you have a basic sample application that exhibits this problem that you attach to this issue or upload somewhere? I tried reproducing the problem before (as you can tell from the comments) to no avail.

[spring-projects-issues]

Scott Van Wart commented

Absolutely, it's the only reason I was able to comment on this. Apparently in my excitement I forgot to include the link ("...demo project someone was kind enough to publish a few years ago") :).

http://fadishei.wordpress.com/2010/01/05/spring-load-time-weaving-on-tomcat-does-it-really-work/

I only had to rebind the JRE and Tomcat containers through Eclipse, and the example worked. I updated to Spring 3.1 and the example still worked. I changed 'version="2.5"' to 'version="3.0"' and it broke.

[spring-projects-issues]

Costin Leau commented

Hi Scott,

I've been able to reproduce the problem and find the culprit. Basically with web.xml 3.0+ as long as there's a HandleType registered (Spring MVC does register one) Tomcat 7 will load all classes under WEB-INF/classes (the jars as well I think). This happens before the app is started, as part of the web app initialization.
So the classes (including your own) are loaded before AspectJ or Spring (and its LTW) are configured and can weave bytecode. There's frankly not much we can do and I'm taking offline with some of the Tomcat team to try to alleviate this problem.
For now you need to stick either with web.xml 2.5 or add metadata-complete to your web.xml. Hopefully this won't be needed in long run - I'll keep you posted.

[spring-projects-issues]

Costin Leau commented

Tomcat issue raised here: https://issues.apache.org/bugzilla/show_bug.cgi?id=52549

[spring-projects-issues]

Adib Saikali commented

Hi Costin,

I have spent the past week trying to figure out why Spring LTW does not work with Tomcat 7.0.25, finally I know why. I think it would be great to put a note in the LTW setup guide in the manual to warn people about the issue with Tomcat LTW.

[spring-projects-issues]

Martin Tuzinsky commented

Hi, it seems to me also related to the Tomcat 8. Is there any workaround?

[spring-projects-issues]

Juzer Ali commented

@Adib, agreed totally. I wasted 3 days before landing up on this page to understand that LTW doesn't work with servlet 3.0. Wish I could figure this out earlier. There should be a warning about this in Chapter 10.

[spring-projects-issues]

Andrei Ivanov commented

You should create a minimal project to reproduce the issue then: https://github.com/spring-projects/spring-framework-issues