CDV ❯ WebappClassloader seems to be corrupting a class that is not DSO
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
-
-
interfaces
-
Reporter: fern
-
August 13, 2008
-
0
-
Watchers: 3
-
February 12, 2014
-
February 12, 2014
Attachments
Description
I am testing out TC 2.6.2/2.6.3-SNAPSHOT and I keep getting this exception, where the classloader is complaining about a corrupted class. It works fine when TC is turned off. This class refers to our JDO implementation and should have nothing to do with DSO.
Attached is the log file with the eceptions, and the tc-config file used.
I got this exception while testing against TC 2.6.2 (http://jira.terracotta.org/jira/browse/CDV-837)
And I just got it while testing with TC 2.6.3-SNAPSHOT (http://s3.amazonaws.com/tcnightly/terracotta-generic-2.6.3-nightly-rev9691.tar.gz?Signature=h20hjarYvutgWtivGag7AnYlVBk%3D&Expires=1218656918&AWSAccessKeyId=1ASD4K6SWEHW65J0HV82)
Comments
Fernando Padilla 2008-08-13
Tim Eck 2008-08-13
Which version of kodo are you using? I can’t find that class in the latest version (4.1.4).
Is kodo.runtime.PersistenceManagerImpl part of your tc-masterRoot bean? The reason I ask is that kodo/runtime/PersistenceManagerImpl is not explicitly included and thus shouldn’t get TC instrumentation (unless it is part of your bean of course)
Fernando Padilla 2008-08-13
Sadly, we’re stuck with 3.3.4 :) (like 4 years old)
And no that is a JDO/ORM class I expect it should never be in TC.
This code has been working with TC 2.5.2 just fine.
And you are correct, I never asked TC nor Spring to modify that class, so I’m confused why the classloader is complaining.
Would TC corrupt classes compiled against JDK 1.4/1.2 or something?? (this is so old, I have no clue what it’s compiled agains)
I’ve been wanting to move to JPOX at some point, but that’s not an option anytime soon :(
Tim Eck 2008-08-13
I wouldn’t think a old (1.4 or less) class file would be problematic, but who knows.
Can you try adding -Dtc.classloader.writeToDisk.initial=true and -Dtc.classloader.writeToDisk=true to the java invocation for tomcat? That setting should dump class bytes before and after instrumentation to “adapted” and “initial” directories in your home directory. It should also print a bunch of messages on the console like “Writing resource: /home/user/adapated/com/example/Foo.class”
If that class isn’t put into the “adapated” directory, then it isn’t being instrumented by TC.
Provided it is in both of the directories, can you maybe attach the classes here?
Fernando Padilla 2008-08-13
I just tried this with 2.7.0-SNAPSHOT and still got the same errors.
I also noticed two other weird errors that might be related.
…. 2008-08-13 13:04:38,384 [main] INFO org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from URL [jar:file:/export/home/fern/servers/jakarta-tomcat/webapps/ROOT/WEB-INF/lib/protrade-common-7.0-SNAPSHOT.jar!/beanRefContext.xml] AW::WARNING - could not load class [org/springframework/aop/config/AopNamespaceUtils] as a resource in loader [WebappClassLoader delegate: false repositories: /WEB-INF/classes/ ———-> Parent Classloader: org.apache.catalina.loader.StandardClassLoader@13e17fc ] AW::WARNING metadata structure could not be build for method [org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary:(Lorg/springframework/beans/factory/xml/ParserContext;Ljava/lang/Object;)V] when parsing method [org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser.parseInternal(..)] ….
….
2008-08-13 13:04:41,778 [main] INFO org.springframework.beans.factory.support.DefaultListableBeanFactory - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@18355aa: defining beans [commentAdmins,appAdmins]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@1841d38
2008-08-13 13:04:41,779 [main] INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization completed in 6120 ms
AW::WARNING - could not load class [com/tcclient/cache/CacheData] as a resource in loader [WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
———-> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@13e17fc
]
AW::WARNING metadata structure could not be build for method [com.tcclient.cache.CacheData.
Fernando Padilla 2008-08-13
This are the tomcat log files for my last run with 2.7.0-SNAPSHOT
Fernando Padilla 2008-08-13
That is a good idea about the writing out the classloader logs. Here are the logs.
What’s interesting is that you can see it writing out that class multiple times..
It looks like the initial/adapted files differ, I’ll post them up after this.
Fernando Padilla 2008-08-13
initial PersistenceManagerImpl
Fernando Padilla 2008-08-13
adapted PersistenceManagerImpl class
Fiona OShea 2008-08-14
Lets loop back around on this later next week…or after 2.7
Hung Huynh 2014-02-12
DSO is discontinued
Here is the summary of the exception that occurs
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘pmf.fandom’ defined in class path resource [fandom-data-conf.xml]: Instantiation of bean failed; nested exception is java.lang.ClassFormatError: Invalid length 65471 in LocalVariableTable in class file kodo/runtime/PersistenceManagerImpl Caused by: java.lang.ClassFormatError: Invalid length 65471 in LocalVariableTable in class file kodo/runtime/PersistenceManagerImpl at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1847) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:873) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1326) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) at java.lang.Class.getDeclaredMethods(Class.java:1763) at java.beans.Introspector$1.run(Introspector.java:1265) at java.security.AccessController.doPrivileged(Native Method) at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1263) at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1129) at java.beans.Introspector.getBeanInfo(Introspector.java:387) at java.beans.Introspector.getBeanInfo(Introspector.java:159) at java.beans.Introspector.getBeanInfo(Introspector.java:220) at java.beans.Introspector.(Introspector.java:368)
at java.beans.Introspector.getBeanInfo(Introspector.java:159)
at org.springframework.beans.CachedIntrospectionResults.(CachedIntrospectionResults.java:244)
at org.springframework.beans.CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:143)
at org.springframework.beans.BeanWrapperImpl.setIntrospectionClass(BeanWrapperImpl.java:236)
at org.springframework.beans.BeanWrapperImpl.setWrappedInstance(BeanWrapperImpl.java:194)
at org.springframework.beans.BeanWrapperImpl.setWrappedInstance(BeanWrapperImpl.java:177)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:350)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:783)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:710)
-----