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