Use the "temp classloader" model to always build hibernate-models
Description
Activity
Show:
Steve Ebersole
updated the Description4 days agoCurrently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes.
In JPA EE environments we are given a potential way to handle this via JPA’s {{PersistenceUnitInfo#getNewTempClassLoader}}. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputs
To alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader.
We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward -
{code:java}interface ClassDetails {
...
<J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context);
}
interface MemberDetails {
...
Member toJavaMember(Class declaringClass, SourceModelContext context);
}
interface FieldDetails extends MemberDetails {
...
@Override
Method toJavaMember(Class declaringClass, SourceModelContext context);
}
...{code}
Currently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes.
In JPA EE environments we are given a potential way to handle this via JPA’s {{PersistenceUnitInfo#getNewTempClassLoader}}. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputs
To alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader.
We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward -
{code:java}interface ClassDetails {
...
<J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context);
}
interface MemberDetails {
...
Member toJavaMember(Class declaringClass, SourceModelContext context);
}
interface FieldDetails extends MemberDetails {
...
@Override
Method toJavaMember(Class declaringClass, SourceModelContext context);
}
...{code}
Of course, the throw-away classloader should always use the form in the parent classloader _if_ the Class is already loaded there. Otherwise, wed load and resolve it into the throw-away classloader.
Steve Ebersole
created the Issue4 days agoDetails
Details
Assignee
Unassigned
UnassignedReporter
Steve Ebersole
Steve EbersolePriority
MajorCreated 4 days ago
Updated 4 days ago
Currently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes.
In JPA EE environments we are given a potential way to handle this via JPA’s
PersistenceUnitInfo#getNewTempClassLoader. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputsTo alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader.
We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward -
interface ClassDetails { ... <J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context); } interface MemberDetails { ... Member toJavaMember(Class declaringClass, SourceModelContext context); } interface FieldDetails extends MemberDetails { ... @Override Method toJavaMember(Class declaringClass, SourceModelContext context); } ...Of course, the throw-away classloader should always use the form in the parent classloader if the Class is already loaded there. Otherwise, wed load and resolve it into the throw-away classloader.