https://bz.apache.org/bugzilla/show_bug.cgi?id=58143
Rainer Jung <rainer.j...@kippdata.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #10 from Rainer Jung <rainer.j...@kippdata.de> ---
Reopening this for TC 7.
My situation:
- not using Springs TomcatInstrumentableClassLoader but instead relying on the
normal Tomcat WebappClassLoader (and WebappClassLoaderBase) implementing
InstrumentableClassLoader
- using Spring load time weaving
That combination works starting with the implementation of
InstrumentableClassLoader in 7.0.64 but is broken again since 7.0.70.
Reason is the reorganization of the resourceEntries cache. During context
initialization the class which should get woven is loaded two times. Once as a
resource (and at a time when the weaver was not yet added to the class loader)
and then again as a class with the weaver in place. Starting with 7.0.70 the
loading as a resource and as a class use the same key in the resourceEntries
cache. Since the weaving does not happen when a class is served from the cache,
this breaks it.
In TC 8, 8.5 and 9 there was a later change in WebappClassLoaderBase which
makes it work again. The weaving was moved from close to the place were
resources get added to resourceEntries in findResourceInternal() to
findClassInternal().
That change also does quite a few other things, so I isolated it moving the
weaver call and tested it in TC 7 with the unit tests. This did not show any
problems.
Originally the problem was observed using Spring 3.0, but the behavior is
unchanged for at least of Spring 3.0-4.3.9.
I will attach a suggested patch and also a simple example webapp named "weave".
Calling the URI /weave/ will respond with "Hello World!" if weaving succeeds,
and with "Unwoven" if not. See the trivial class Greeting, the beans file
weave.xml, its declaration in web.xml and the index.jsp, all of which are very
small. Unfortunately the war file is 6 MB due to the size of the included
Spring jar files.
Regards,
Rainer
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
