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. > 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 > >>>>>> <st...@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@lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> hibernate-dev mailing list > >>>>> hibernate-dev@lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>> > >>>> > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev@lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> -- > >>> Steve Ebersole <st...@hibernate.org> > >>> http://hibernate.org > >>> > >> > > > > -- > > Steve Ebersole <st...@hibernate.org> > > http://hibernate.org > > > -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev