From: Scott M. (JIRA) <no...@at...> - 2006-07-18 12:44:20
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23652 ] Scott Marlow commented on HHH-1293: ----------------------------------- 1. No, javassist is already just as optimized. the javassist class.newInstance() works correctly, so we do not need to create the instance of the class that will be used to create the proxy instance (the object returned by class.newInstance works fine). 2. I'm still trying to answer this question. Clearly, the classloader early in both cases to load the generated proxy class. I need to compare the old code versus the new code. The old code was something like: Class proxyFactoryClass=...; // completed early in getProxyFactory() // we need to understand the classloader use // in the following call. Object proxy = proxyFactoryClass.newInstance(); // completed late in getProxy() The new code is: Class proxyFactoryClass=...; // completed early in getProxyFactory() Object proxyFactory = proxyFactoryClass.newInstance(); // completed early in getProxyFactory // we need to understand the classloader use // in the following call. Object proxy = proxyFactory.newInstance(Callback[]); // completed late in getProxy() I'm currently trying to understand how to follow the classloader use in the old and new cases illustrated above. Clearly, the proxyFactory.newInstance(Callback[]) is hitting code that we generated in the proxy class. What is not clear is where the code for proxyFactoryClass.newInstance() lives. Is it the standard Class.newInstance() implementation code or do we somehow overide newInstance() in our generated proxy class. By the way, I talked briefly to Sun support about this issue and they are not aware of the jvm bug mentioned above. I would like to get more information about the failure case that could be relayed to Sun. If this issue is caused by a Sun bug, we should give them a standalone test case that reproduces the issue. We can lobby them to fix it then. If this has already be been done by someone, please let me know. I think that the same issue was reported on cglib forum http://sourceforge.net/forum/forum.php?thread_id=1441197&forum_id=190809 > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Assignee: Scott Marlow > Priority: Blocker > Fix For: 3.2.0.ga > Attachments: CGLIBLazyInitializer.patch, CGLIBLazyInitializer.patch, CGLIBLazyInitializer.patch3, CGLIBProxyFactory.patch3, hibernate3.jar, manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35) > at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130) > at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48) > at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |