http://opensource.atlassian.com/projects/hibernate/browse/HHH-5375
In attempting this I ran into the difference between Configuration and
AnnotationConfiguration of processing mapping files (hbm.xml).
Configuration tries to process these immediately, whereas
AnnotationConfiguration delays that att
For the sake of posterity (by which I mean my awful memory)...
We discussed this on IRC and really we have 2 discussions here, both
related to how the Hibernate Transaction API treats registered syncs:
1) The choice of whether to ignore/rethrow exceptions from the syncs
2) The problem with envers
Great. Deprecating the default constructor in FullTextIndexEventListener
and the
properties discussion are indeed orthogonal. I start with committing the
upgrade to
Core 3.6 together with the FullTextIndexEventListener changes.
We can take the properties discussion separate.
--Hardy
On Wed,
and http://opensource.atlassian.com/projects/hibernate/browse/HHH-5382
(linked)
On Wed, 2010-07-14 at 14:56 +0100, Emmanuel Bernard wrote:
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-559
>
> On 14 juil. 2010, at 14:45, Galder Zamarreño wrote:
>
> > Emmanuel,
> >
> > I've
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-559
On 14 juil. 2010, at 14:45, Galder Zamarreño wrote:
> Emmanuel,
>
> I've created https://jira.jboss.org/browse/ISPN-541 to revisit current query
> module dependencies when Hibernate Search upgrades to SLF4J 1.6.
>
> If you c
Sorry for the delay,
Good idea, with a useful exception if possible on the deprecated constructor.
Exposing properties is a different matter altogether, I'd rather separate these
discussions.
On 12 juil. 2010, at 10:49, Hardy Ferentschik wrote:
> Hi Sanne,
>
> I guess you are referring to HSEA
Emmanuel,
I've created https://jira.jboss.org/browse/ISPN-541 to revisit current query
module dependencies when Hibernate Search upgrades to SLF4J 1.6.
If you create a jira for that, let me know so that I can keep track of it and
find out when an updated HBS is released.
Cheers,
On Jul 14, 20
Noted. Thanks.
I was more thinking of 3.6 which we plan to start releasing next week.
We try to avoid upgrades of dependencies in a series for just this
reason.
On Wed, 2010-07-14 at 14:23 +0200, Ceki Gülcü wrote:
> On 14/07/2010 1:41 PM, Steve Ebersole wrote:
> > Ah we are using 1.5.8 currently
On 14/07/2010 1:41 PM, Steve Ebersole wrote:
> Ah we are using 1.5.8 currently. We should upgrade to 1.6 then.
Yes, you should upgrade to 1.6.0.
You should also be aware that slf4j-api 1.6. will *not* work with
bindings from the 1.5 series. So, if the next version of hibernate,
say 3.5.4 uses SL
Ah we are using 1.5.8 currently. We should upgrade to 1.6 then.
On Wed, 2010-07-14 at 13:24 +0200, Ceki Gülcü wrote:
>
> Galder Zamarreño wrote:
>
> > Hmmm, these looks like a problem in Hibernate Search since they're the
> > ones using slf4j.
> >
> > I don't see why Infinispan Query should
Galder Zamarreño wrote:
> Hmmm, these looks like a problem in Hibernate Search since they're the
> ones using slf4j.
>
> I don't see why Infinispan Query should explicitly declare a
> dependency on slf4j.
>
Hello Galder,
The issue reported by Israel Lacerra, that is the NoClassDefFoundEr
Hi,
Seems the solution is to upgrade to slf4j 1.6.0 -
http://bugzilla.slf4j.org/show_bug.cgi?id=159
In 1.6.0 no exception is thrown when there is just the api jar and no
binding jar.
Btw, Hibernate Core also uses slf4j and there was a major discussion
around this which lead
in the end to th
Right, but that means that your app does not work out of the box because
logging has not been determined. This is silly IMO.
I'm glad Infinispan itself does not use slf4j.
I'll add an faq on this
On Jul 14, 2010, at 11:13 AM, Hardy Ferentschik wrote:
> That's right. Hibernate Search only defin
That's right. Hibernate Search only defines a dependency to the slf4j api.
The slf4j-log4j dependency, because we use log4j logging in our tests, but
the
whole idea of slf4j is to give the user the choice of which logging
framework to use.
On Wed, 14 Jul 2010 11:02:46 +0200, Emmanuel Bernard
I believe that's the proper way.
We do have a dependency on slf4j the API / facade.
Then a user needs to decide which underlying implementation it wants to use. To
do that he embeds the right binder (eg slf4j-log4j). If you force slf4j-log4j
in HSearch dependencies, you force choice to people. Th
Hmmm, these looks like a problem in Hibernate Search since they're the ones
using slf4j.
I don't see why Infinispan Query should explicitly declare a dependency on
slf4j.
Emmanuel, wdyt?
http://anonsvn.jboss.org/repos/hibernate/search/tags/v3_2_0_Final/hibernate-search/src/main/java/org/hibern
16 matches
Mail list logo
