java.lang.VerifyError, Bad access to protected data at .crea

[bahata]

Hi
I am getting the following error, while trying to use JBoss pojo cache Alegrias (2.1.0 GA) , in the process of attaching my complex object model in the cache.




java.lang.VerifyError: (class: ft/oots/adt/dao/BedType$BedTypeInstanceAdvisor, method: initialiseInfosForInstance signature: ()V) Bad access to protected data
at ft.oots.adt.dao.BedType$BedTypeAdvisor.createInstanceAdvisor(BedType$BedTypeAdvisor.java)
at ft.oots.adt.dao.BedType._getInstanceAdvisor(BedType.java)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.isMultipleReferencedPut(PojoCacheDelegate.java:382)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:154)
at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:137)
at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:102)
at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.attach3085019539260813833(PojoCacheImpl$PojoCacheImplAdvisor.java)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
at org.jboss.cache.pojo.collection.CachedListImpl.attach(CachedListImpl.java:128)
at org.jboss.cache.pojo.collection.CachedListImpl.add(CachedListImpl.java:117)
at org.jboss.cache.pojo.collection.CachedListAbstract.add(CachedListAbstract.java:65)
at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.cache.pojo.collection.CollectionInterceptorUtil.invoke(CollectionInterceptorUtil.java:195)
at org.jboss.cache.pojo.interceptors.dynamic.CachedListInterceptor.invoke(CachedListInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at AOPClassProxy$1.add(AOPClassProxy$1.java)
at org.jboss.cache.pojo.impl.CollectionClassHandler.put(CollectionClassHandler.java:166)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:174)
at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:137)
at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:102)
at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.attach3085019539260813833(PojoCacheImpl$PojoCacheImplAdvisor.java)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
at org.jboss.cache.pojo.collection.CachedMapImpl.attach(CachedMapImpl.java:71)
at org.jboss.cache.pojo.collection.CachedMapImpl.put(CachedMapImpl.java:99)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.cache.pojo.collection.CollectionInterceptorUtil.invoke(CollectionInterceptorUtil.java:195)
at org.jboss.cache.pojo.interceptors.dynamic.CachedMapInterceptor.invoke(CachedMapInterceptor.java:178)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at AOPClassProxy$0.put(AOPClassProxy$0.java)
at org.jboss.cache.pojo.impl.CollectionClassHandler.put(CollectionClassHandler.java:132)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:174)
at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:137)
at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:116)
at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.attach_N_6020276434135444173(PojoCacheImpl$PojoCacheImplAdvisor.java)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
at org.jboss.cache.pojo.impl.AdvisedPojoHandler.put(AdvisedPojoHandler.java:154)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:170)
at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:137)
at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:102)
at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.attach3085019539260813833(PojoCacheImpl$PojoCacheImplAdvisor.java)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:94)
at ft.oots.controller.ServerController.loadDataModel(ServerController.java:242)
at ft.oots.controller.SynchronizationController.loadDataModel(SynchronizationController.java:62)
at ft.oots.Application.(Application.java:130)
at ft.oots.Application.main(Application.java:522)

[jason.greene]

This is either a bug in AOP or javassist. Can you first try replacing your AOP jar with the latest update:

http://repository.jboss.com/maven2/jboss/aop/jboss-aop-jdk50/2.0.0.CR8/jboss-aop-jdk50-2.0.0.CR8.jar

If it still fails then could you create a POJO Cache jira issue and attach the code of the class (BedType) that triggers this problem?

Thanks

[bahata]

Thanks. I have now replaced the jboss-aop with jboss-aop-jdk50-2.0.0.CR8.jar . But still getting the problem. I would be creating a JIRA issue soon.

BUT JUST TO CLARIFY A POINT:
Say if all these errors do not show up. Still , would AOPC help to solve my problem or must I do load time instrumentation only? My doubt is that, the last problem I had was , when I needed to send copies of some of my aspectized classes to my fat clients, I needed to serialize them . When they were serialized with AOPC, as the class-interceptor was becoming a field of the class , a part of its bytecode, I had the not-serializable exception!

So can I really use AOPC (compile time instrumentation) at all , if I need to send the classes to my FAT clients? Or is it must that I use the load time one?

[jason.greene]

Hi Bahata,

I am having difficulty reproducing this. However, I am missing the _Base class, which could somehow trigger the problem. Any chance you could upload something equivalent to the issue?

Regarding the difference between aopc and load-time output. There should be no difference. Are you sure you werent using classes that were generated using aopc from the aop version included with pojo cache 2.0.0 (1.5)? This version defaulted to the "ClassicInstrumentor", which did not mark AOP fields as transient.

We generally recommend load-time since it prevents accidental usage of old classes, as well as potential binary compatibility issues (since the output of aopc is tied to the aop jar that was used).

-Jason

[bahata]

Hi
Thank you so much for looking into my pronlem. In JIRA pcahe-64 I have attached the _Base class. Actually all our data types are extending the _Base class. I have found that actually all of them are having the same problem if I try to attach them one by one. If you can not reproduce the problem, kindly consider using hibernate to load the classes. May be it would create the exception. Thanks a lot. Waiting with hope to get this solved!

[jason.greene]

Hibernate shouldn't be related since this error indicates that an AOP generated class is not valid (or consistent with) it's class hierarchy. I tried the classes you uploaded, and could not reproduce the problem.

One thing that could cause this error, would be the bundling of old AOP generated classes (from an old aopc run) in your jar files. I would recommend switching to load-time weaving, and removing any trace of aopc from your build process, and doing a full jar rebuild of your app.

Once this is done, you should not see classes like this in your jar:
BaseBedType$BaseBedTypeAdvisor$threshold_w_$aop.

Also, this is unrelated to the problem, but I wanted to comment on the combined use of hibernate and POJO Cache. It is generally not recommended to share the same objects in hibernate and POJO Cache, since both frameworks expect to be in control of your object model. As an example, hibernate will, at times, return a proxy object (instead of the real object) in certain situations regarding collections and inheritence. POJO Cache will not know what to do with these proxies, since they are not the same class that was attached.

In most cases, using jboss cache as a second level cache is really what is desired. If not, and you must share the object models between the two frameworks, then you need to make sure you don't work with the same object instances. This means you need to have deep copy constructors (clone won't work since you might clone a proxy instead of the real object) on all of your classes. Then you can make sure you truly have separate instance trees.