SelfDirtinessTracker not found

Description

I upgraded from 4.x to 5.x and noticed that dirty checking first introduced in doesn't have the luxury of being prefilled in javassist class cache a do other bits of enhancer. I'm using OSGi environment with load time weaving so the classloader doesn't yet have access to hibernate packages . Those are made available to weaved class as dynamic imports after transformation. I'm ending up with this, because the classes are not present in the class cache

Environment

None

Activity

Show:
Tuomas Kiviaho
December 8, 2015, 10:59 AM

Sorry for not responding sooner. Your code seems to be refactored version of mine so I give it a try a.s.a.p. but I don't see any reason why it wouldn't work. The reason why classloading didn't work for me is explained more thoroughly later on but I have to state here and now that the real reason for my problems is Apache Aries https://issues.apache.org/jira/browse/ARIES-1447.

EnhancingClassTransformerImpl propagates the given classloader to Javassist classPool and it's used hence forth for classloading of hibernate internals during transformation process. In my case this classloader didn't have access to the hibernate internals, only to the entities themselves, and therefore failed during transformation process when there classes were no prefilled to the classPool by hibernate.

Steve Ebersole
December 8, 2015, 6:02 PM

Isn't this really just the same as and ?

Tuomas Kiviaho
December 9, 2015, 7:40 AM

I'm not (yet at least) using hibernate-osgi and this is one is not about proxies, but you could ask if this is really the concern of Hibernate core or should this be simplified by letting Aries/Hibernate OSGi deal with this alone.

What I first observed was that classPool prefilling was done only halfways so I fixed that first with my original patch. I should have been asking myself why this had to be done in the first place. I'm now mimicking the PersistenceUnitInfo.getNewTempClassLoader that has proper visibility to both hibernate internals and persistence unit so now the original patch has sort of lost it's value.

Before closing this issue I hope that you consider to do something about the loadCtClassFromClass. The test branch at least contains a coherent way of dealing with the loading, but I guess one could live without the method completely. The current approach lead me to believe that there is something wrong in the hibernate internals.

Steve Ebersole
June 9, 2016, 4:14 PM

Applied to upstream master (5.2.1). Thanks again Luis!

this is all ready to go for 5.2; please resolve/close after you apply to 5.0/5.1. Thanks!

Gail Badner
June 10, 2016, 11:21 PM

Fixed in 5.1 and 5.0 branches as well. Thanks Luis!

Assignee

Luis Barreiro

Reporter

Tuomas Kiviaho

Fix versions

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure