[hibernate-dev] ClassLoaders [was Re: Envers set up]

[Emmanuel Bernard]

According to one glassfish guy, this rule can be problematic in an OSGi env. It seems you could have hibernate in both the lib and the app class loader and you could end up with CCE because the same classes could be loaded by two classloaders and conflict

Some background
 http://opensource.atlassian.com/projects/hibernate/browse/HV-363

I don't have a solution for your dialect case though unless we look at the package name but that's weak. 

On Sep 23, 2010, at 5:30 AM, Steve Ebersole <steve at hibernate.org> wrote:

> On Thu, 2010-09-16 at 07:52 -0500, Steve Ebersole wrote:
>> On Thu, 2010-09-16 at 10:19 +0200, Emmanuel Bernard wrote:
>>> I have a spot spot for (1). If I load an Hib class library, I use hibernate-cl, if I load an app class, I use application-cl etc.
> 
> By the way I am not sure it is as simple as this.  These uses mostly
> revolve around cases where we do not know whether the class is a "Hib
> class" or a "app class".  
> 
> Consider we are loading an explicitly named Dialect class
> ("hibernate.dialect"); do we use hibernate-cl or application-cl?  The
> answer in this case (most likely) is to try both, but to prefer the
> order:
> 1) application-cl
> 2) hibernate-cl
> 3) environment-cl
> 
> If that is invariably true, maybe its valid to only accept a single
> ClassLoader that we except does any needed aggregation
> 
> 
>>> BTW what would be environment-cl?
>> 
>> The ClassLoader we'd use for JDBC classes.  Thats the only use case I
>> can think of at the moment.
>> 
>>> 
>>> On 15 sept. 2010, at 15:47, Steve Ebersole wrote:
>>> 
>>>> 
>>>> We will need access to multiple ClassLoader references though to always
>>>> be able to DoTheRightThing.  Just not sure the right "view" here.  Do
>>>> we:
>>>> 1) categorize these based on the role of the ClassLoader
>>>> (application-cl, hibernate-cl, environment-cl, etc)
>>>> 2) categorize them based on our specific needs (entity-cl, metadata-cl,
>>>> spi-cl, etc)
>>>> 
>>>> (2) sounds appealing but means we'd have many more categories.
>>>> 
>>>> On Wed, 2010-09-15 at 10:43 +0200, Andersen Max wrote:
>>>>> On Sep 14, 2010, at 16:47, Steve Ebersole wrote:
>>>>> 
>>>>>> "osgi land" in general is a problem.  
>>>>>> 
>>>>>> But yeah, I had even added a comment in this code that really we need to
>>>>>> allow passing in the ClassLoader to use.  In fact this is not osgi
>>>>>> specific.  In general JPA says we should use a specific ClassLoader for
>>>>>> these lookups in JEE deployments, namely the one given to use by the
>>>>>> container via PUI.  
>>>>>> 
>>>>>> In the JPA use-case this is not so difficult because we are physically
>>>>>> handed the ClassLoader we are supposed to use.  My (mis)understanding of
>>>>>> osgi is quite the opposite.
>>>>> 
>>>>> If there is an API to pass in the classloader it can be passed in by whatever code
>>>>> that is used to bootstrap the persistence manager.
>>>>> 
>>>>> /max
>>>>> 
>>>>>> 
>>>>>> On Tue, 2010-09-14 at 11:02 +0200, Andersen Max wrote:
>>>>>>> If this is done please make it super easy to disable that behavior - i.e. I don't want envers, search nor validator to be enabled by default when I run queries or reverse engineering from within tooling.
>>>>>>> 
>>>>>>> i.e. I believe Search has a property to disable the behavior which we use to avoid classloading conflicts in osgi land.
>>>>>>> /max
>>>>>>> 
>>>>>>> On Sep 13, 2010, at 11:49, Emmanuel Bernard wrote:
>>>>>>> 
>>>>>>>> I would favor such model ie. an automatic event registration when the lib is in the classpath.
>>>>>>>> We could generalize that actually to let any lib to register its event listeners (maybe something a la service locator).
>>>>>>>> Today Search and Validator have a specific hook in Core.
>>>>>>>> 
>>>>>>>> On 11 sept. 2010, at 09:20, Hardy Ferentschik wrote:
>>>>>>>> 
>>>>>>>>> In Search and Validator we enable the listeners when we detect Search res.  
>>>>>>>>> Validator on the classpath (with an option
>>>>>>>>> to explicitly not enable it). Maybe we could do the same with Envers?
>>>>>>>>> 
>>>>>>>>> --Hardy
>>>>>>>>> 
>>>>>>>>> On Fri, 10 Sep 2010 20:40:04 +0200, Steve Ebersole <steve at hibernate.org>  
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> What do you think of an option that says "enable envers", rather than
>>>>>>>>>> explicitly needing to set up each listener?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> 
>>>>>> -- 
>>>>>> Steve Ebersole <steve at hibernate.org>
>>>>>> http://hibernate.org
>>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> Steve Ebersole <steve at hibernate.org>
>>>> http://hibernate.org
>>>> 
>>> 
>> 
>> -- 
>> Steve Ebersole <steve at hibernate.org>
>> http://hibernate.org
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> -- 
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org
>