1:40 p.m.
What do you think of an option that says "enable envers", rather than
explicitly needing to set up each listener?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
1:46 p.m.
Hello!
I think it´s a good idea. There would be fewer user errors setting up
envers.
Regards. Hernán.
2010/9/10 Steve Ebersole <steve(a)hibernate.org>
What do you think of an option that says "enable envers",
rather than
explicitly needing to set up each listener?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:53 p.m.
Well there is also a possibility in this case that we whack a users set
of custom listeners. Or if they define listeners that short-circuit
event processing before envers listeners are processed (assuming we
append the envers listeners to the end of the listeners list).
On Fri, 2010-09-10 at 15:46 -0300, Hernán Chanfreau wrote:
Hello!
I think it´s a good idea. There would be fewer user errors setting up
envers.
Regards. Hernán.
2010/9/10 Steve Ebersole <steve(a)hibernate.org>
What do you think of an option that says "enable envers",
rather than
explicitly needing to set up each listener?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
2:20 a.m.
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(a)hibernate.org>
wrote:
What do you think of an option that says "enable envers",
rather than
explicitly needing to set up each listener?
4:49 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:48 a.m.
I am not a fan of this. For a number of reasons.
First this means added complexity to manage the list of listeners in
regards to (1) not over-writing any explicitly registered listeners and
(b) not duplicating listeners.
Second keep in mind that the hibernate3.jar from the release
distribution we put on SourceForge contains all classes Some anyone
using it would always "have envers on the classpath".
On Mon, 2010-09-13 at 11:49 +0200, 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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
9:31 a.m.
Is anyone aware of a current, valid use-case of allowing the same
listener class to be registered multiple times for the same event? I
know we have many "multi-faceted listeners that listen for many events.
Thats not what I mean. I mean, is there ever a time anyone can think of
when something like this needs to be considered valid:
Configuration.setListeners(
new SaveEventListener[] {
myCustomSaveListener,
...
myCustomSaveListener
}
);
?
On Mon, 2010-09-13 at 08:48 -0500, Steve Ebersole wrote:
I am not a fan of this. For a number of reasons.
First this means added complexity to manage the list of listeners in
regards to (1) not over-writing any explicitly registered listeners and
(b) not duplicating listeners.
Second keep in mind that the hibernate3.jar from the release
distribution we put on SourceForge contains all classes Some anyone
using it would always "have envers on the classpath".
On Mon, 2010-09-13 at 11:49 +0200, 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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
1:13 p.m.
Me neither - auto-registration by putting the jar on the classpath is a bit too much
magic.
So I would make this "bulk registration" (maybe auto is not the best way then)
off by default (for envers and any other hibernate module)
Adam
On Sep 13, 2010, at 3:48 PM, Steve Ebersole wrote:
I am not a fan of this. For a number of reasons.
First this means added complexity to manage the list of listeners in
regards to (1) not over-writing any explicitly registered listeners and
(b) not duplicating listeners.
Second keep in mind that the hibernate3.jar from the release
distribution we put on SourceForge contains all classes Some anyone
using it would always "have envers on the classpath".
On Mon, 2010-09-13 at 11:49 +0200, 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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
4:02 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:47 a.m.
"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.
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
3:43 a.m.
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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
8:47 a.m.
New subject: ClassLoaders [was Re: Envers set up]
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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
3:19 a.m.
New subject: ClassLoaders [was Re: Envers set up]
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
<steve(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> Steve Ebersole <steve(a)hibernate.org>
>> http://hibernate.org
>>
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
7:52 a.m.
New subject: ClassLoaders [was Re: Envers set up]
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
<steve(a)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(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> --
>>> Steve Ebersole <steve(a)hibernate.org>
>>> http://hibernate.org
>>>
>>
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
7:30 a.m.
New subject: ClassLoaders [was Re: Envers set up]
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(a)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(a)lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev(a)lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>> --
> >>> Steve Ebersole <steve(a)hibernate.org>
> >>> http://hibernate.org
> >>>
> >>
> >
> > --
> > Steve Ebersole <steve(a)hibernate.org>
> > http://hibernate.org
> >
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
3:17 p.m.
New subject: ClassLoaders [was Re: Envers set up]
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(a)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(a)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(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>> --
>>>>> Steve Ebersole <steve(a)hibernate.org>
>>>>> http://hibernate.org
>>>>>
>>>>
>>>
>>> --
>>> Steve Ebersole <steve(a)hibernate.org>
>>> http://hibernate.org
>>>
>>
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
3:44 a.m.
note, this is not just all about osgi but more about it not making sense (or causes
conflicts) to run with hibernate search and envers enabled
when the only thing you want to do is to run a query or introspect the
Configuration/SessionFactory object.
/max
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.
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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
8:07 a.m.
Here is my issue with that line of thought... Many of these listeners
alter the things you want to query!
On Wed, 2010-09-15 at 10:44 +0200, Andersen Max wrote:
note, this is not just all about osgi but more about it not making
sense (or causes conflicts) to run with hibernate search and envers enabled
when the only thing you want to do is to run a query or introspect the
Configuration/SessionFactory object.
/max
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.
>
> 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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
8:39 a.m.
On Sep 15, 2010, at 15:07, Steve Ebersole wrote:
Here is my issue with that line of thought... Many of these
listeners
alter the things you want to query!
yes, for envers querying could be different I guess but for Search it is not.
And none of them should affect the reverse engineering side.
/max
On Wed, 2010-09-15 at 10:44 +0200, Andersen Max wrote:
> note, this is not just all about osgi but more about it not making sense (or causes
conflicts) to run with hibernate search and envers enabled
> when the only thing you want to do is to run a query or introspect the
Configuration/SessionFactory object.
>
> /max
>
> 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.
>>
>> 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(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> Steve Ebersole <steve(a)hibernate.org>
>> http://hibernate.org
>>
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
4:35 a.m.
Sounds great. I think that there may be on option to automatically add all the appropriate
listeners, but the users would still have the possibility to add them by hand (in the more
advanced use-cases, but that will probably be rare). Same applies to the HSearch listeners
I suppose.
On Sep 10, 2010, at 8:40 PM, Steve Ebersole wrote:
What do you think of an option that says "enable envers",
rather than
explicitly needing to set up each listener?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
9:48 a.m.
Adam is right! Sometimes the envers default listeners are overriden by user
custom listeners.
2010/9/11 Adam Warski <adam(a)warski.org>
Sounds great. I think that there may be on option to automatically
add all
the appropriate listeners, but the users would still have the possibility to
add them by hand (in the more advanced use-cases, but that will probably be
rare). Same applies to the HSearch listeners I suppose.
On Sep 10, 2010, at 8:40 PM, Steve Ebersole wrote:
> What do you think of an option that says "enable envers", rather than
> explicitly needing to set up each listener?
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:03 p.m.
Sure. I wasn't proposing not allowing users to register listeners at
all, whether it be the supplied envers listeners, the supplied search
ones, or some custom ones. That is core Hibernate functionality to
allow users to be able to do this. No, this would merely be a new flag
users could use *instead* to have the envers listeners automatically
appended.
TBH I do not know exactly what search does to be able to comment on it
specifically. I just know that as I was writing the tutorial it seemed
really inconvenient to *have to* enable all the needed listeners myself.
At any rate I have not heard nor thought of any issues with it, so I'll
work on it.
On Sat, 2010-09-11 at 11:48 -0300, Hernán Chanfreau wrote:
Adam is right! Sometimes the envers default listeners are overriden
by
user custom listeners.
2010/9/11 Adam Warski <adam(a)warski.org>
Sounds great. I think that there may be on option to
automatically add all the appropriate listeners, but the users
would still have the possibility to add them by hand (in the
more advanced use-cases, but that will probably be rare). Same
applies to the HSearch listeners I suppose.
On Sep 10, 2010, at 8:40 PM, Steve Ebersole wrote:
> What do you think of an option that says "enable envers",
rather than
> explicitly needing to set up each listener?
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5209
days inactive
5222
days old
21 comments
6 participants
participants (6)
-
Adam Warski -
Andersen Max -
Emmanuel Bernard -
Hardy Ferentschik -
Hernán Chanfreau -
Steve Ebersole