• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • Byte Code Transform
  • interfaces
  • Reporter: wharley
  • May 07, 2009
  • 0
  • Watchers: 2
  • December 16, 2011

Description

The user in FORGE-460 declared both tim-ehcache-1.4.1 and tim-hibernate-3.2.5 in his tc-config, in version 3.0. Since tim-hibernate-3.2.5 has a POM dependency on tim-ehcache-1.3, both tim-ehcache versions got resolved. However, both tim-ehcaches define adapters for net.sf.ehcache.Cache, and they replace that class with different versions of TCCache. So which won? No way to know, but evidence suggests it was the wrong one. It would have been better for this to be an error or at the very least a warning in the log.

Comments

Puneet Bhardwaj 2009-05-29

Liferay is facing a similar issue. They need support for tim-ehcache-1.4.1 and tim-hibernate-3.2.5. This results in the following error on starting a second liferay instance -

java.lang.NullPointerException
net.sf.ehcache.Cache.removeAll(CacheTC.java:1437)
net.sf.ehcache.Cache.removeAll(CacheTC.java:1420)
org.hibernate.cache.EhCache.clear(EhCache.java:164)
com .liferay .portal.dao.orm.hibernate.CacheWrapper.invalidate(CacheWrapper.java: 128)
com .liferay.portal.kernel.cache.CacheRegistry.clear(CacheRegistry.java: 40)
com .liferay .portal.kernel.cache.CacheRegistry.setActive(CacheRegistry.java:69)
com.liferay.portal.events.StartupAction.doRun(StartupAction.java: 119) com.liferay.portal.events.StartupAction.run(StartupAction.java: 72) com.liferay.portal.servlet.MainServlet.init(MainServlet.java: 141) javax.servlet.GenericServlet.init(GenericServlet.java:212)
org .apache .catalina .authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
org .apache .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org .terracotta .modules.tomcat.tomcat_5_5.SessionValve55.invoke(SessionValve55.java: 52)
org .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286)
org .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 844) org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 447) java.lang.Thread.run(Thread.java:637)

The current workaround that they are using, is to change the dependency of tim-ehcache in the pom.xml for tim-hibernate-3.2.5-1.3.1.

Alex Miller 2009-06-25

Puneet, I believe your comment belongs with the more specific FORGE-460 instead of here - this jira is a more generic problem with class adapters that is being exposed by FORGE-460.

Geert Bevin 2009-06-25

I can understand that conflicting replacements should create an error, however I would actually be in favor of adding support for multiple adapters. At the moment only the adapter of the last registered TIM will be used for a class. Imho it would be better to build up a chain of adapters.

Geert Bevin 2009-07-08

I implemented support for multiple custom class adapters for the same class in r13051, this should solve this issue. However, QA would do well to test that the intended behavior is achieved now.

Alex Miller 2009-07-08

Actually, the original problem was an *undesired* conflict when having both tim-ehcache-1.3 and tim-ehcache-1.4 both loaded and adapting some of the same classes. So the original problem should not be expected to work. Really need a separate use case to test this.

Tim Eck 2009-07-08

Yep. I think the spirit of this JIRA was specifically to make this an error condition somehow, not to just allow it to happen. Of course it seems we have times when we want more than one adapter so generating an error at that level doesn’t seem appropriate for this scenario. The ehcache TIMs will need to detect each other through some other means

Walter Harley 2009-07-09

Tim is correct: I was looking for a way to ensure that when two conflicting adapters are loaded, the customer can discover the situation.

If “the ehcache TIMs will need to detect each other through some other means”, then the same will be true for practically all other versioned TIMs, and we should provide an API that TIMs can call to discover this, rather than have each TIM reinvent the wheel (or, worse, forget to reinvent the wheel).

Perhaps the right solution is to support cumulative class adapters (per Geert’s fix) but warn or error on multiple TIM versions (i.e., same artifact ID but different version number)?

Geert Bevin 2009-07-13

I think we should indeed warn when for the same TIM artifact ID different versions are loaded, that seems like a logical and intuitive approach.

Walter Harley 2009-07-13

Although, that wouldn’t have helped in this case; tim-ehcache-1.3 and tim-ehcache-1.4 have different artifact IDs.

It is hard to tell when a second class adapter is intended to supplement an existing adapter, versus when that is a sign of a violated assumption. Another possibility would be to have class adapters be more proactive about verifying that the bytecode being modified corresponds to what is expected. This is tied to the question of how flexible one wants to be about instrumenting slightly different versions of a class.

Geert Bevin 2009-07-14

Yeah, I was wondering about that too. Initially it actually occurred to me that we should maybe introduce ‘features’ that TIMs expose. These would be independent from the naming. It would then only be possible to install one TIM for a particular feature.