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
> > >>>>>> <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
--
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
