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
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 si
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 env
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 Ebers
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 Cl
"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 on
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 classloa
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 lik
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
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
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 *in
Adam is right! Sometimes the envers default listeners are overriden by user
custom listeners.
2010/9/11 Adam Warski
> 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
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,
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
wrote:
> What do you think of an option that
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:4
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
> What do you think of an option that says "enable envers", rather than
> explicitly needing to set up each listener?
>
> --
> Steve Ebersole
> http://hibernate.org
16 matches
Mail list logo
