> RE: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860
>
> This dealt with cleaning up all the overloaded openSession methods from
> SessionFactory and SessionFactoryImplementor.
>
> The new main method for obtaining a Session is SessionFactory.withOptions()
> which returns a
session.sessionWithOptions().connection().openSession()
says *exactly* what you just said: "open a session using the same connection
as an existing session".
Like I said, I do not think that is enough as I think that if you get the
connection, you also need the "transaction context" holding tha
> We can do it either way. Of the ones I converted to using Integrators,
> search
> and envers both have "skip" settings defined.
>
> search: hibernate.search.autoregister_listeners
> envers: hibernate.listeners.envers.autoRegister
> (should really standardize these names)
Individual "skippin
Hi,
just upgrading now to Lucene 3.1 and go directly Final seems wrong to me
as well.
I agree that in this case we should do a CR2 first.
If other deadlines are more important I think we have to defer the upgrade.
--Hardy
On Mon, 04 Apr 2011 00:08:44 +0200, Sanne Grinovero
wrote:
> Hello,
Sorry - didn't get the mail thread in proper order (damn VPN!)
>From reading the whole thread I guess the answer is:
session.sessionWithOptions().connection().openSession()
or even
session.sessionWithOptions().transactionContext().openSession()
I'm still a bit fuzzy about where the lifecycle bo
2011/4/4 Hardy Ferentschik :
> Hi,
>
> just upgrading now to Lucene 3.1 and go directly Final seems wrong to me as
> well.
> I agree that in this case we should do a CR2 first.
>
> If other deadlines are more important I think we have to defer the upgrade.
of course, just I don't know how much the
+1 but you've realized that you've volunteered yourself.
On 4 avr. 2011, at 00:08, Sanne Grinovero wrote:
> Hello,
> I'm sure you all have heard all the noise about the Lucene 3.1
> release, it has indeed some interesting changes [1]; it's almost
> drop-in compatible with Lucene 3.0.x but providi
So it looks like this might be workaround-able...
-- Forwarded message --
From: "Szczepan Faber (JIRA)"
Date: Apr 4, 2011 10:46 AM
Subject: [issues.gradle.org] Commented: (GRADLE-1174) The IdeaPlugin defines
all of $buildDir as excluded
To:
[
http://issues.gradle.org/browse/G
Sanne,
I've added a comment to HSEARCH-679 that includes the instructions necessary
to add the attached unit test to the hibernate-search code base. Let me
know if you need anything more to check in the fix for HSEARCH-679.
Tom
On Tue, Mar 22, 2011 at 12:17 PM, Tom Waterhouse wrote:
> Sanne, t
Hi Tom,
thank you, I'm playing with it right now.
As I mentioned on JIRA, the main reason for which I didn't fix this
yet is that my proposed solution is incomplete, I'm working on a real
solution and a good test would help a lot.
I'm having some problems with your code:
1) The test is always gr
Hi,
it's sometimes useful from the test packages to be able to get
package-level visibility to classes in the main code.
All Hibernate Search tests are organized in a
"org.hibernate.search.test.X" package;
I'd like to move them to "org.hibernate.search.X.Y", i.e. give test
implementors the freedom
If I remember right we didn't initially have the additional 'test' level
in the code.
I was also a proponent of not having it, but I think the argument was that
it helps
to easier distinguish test from production classes. Obviously they are
structurally
separated in different directories, but
What's you actual use case. This explicit separation is something I've always
appreciated to limit "clever" package-level visibility usages.
Let's discuss tomorrow on IRC
.
On 4 avr. 2011, at 21:43, Sanne Grinovero wrote:
> Hi,
> it's sometimes useful from the test packages to be able to get
> p
2011/4/4 Emmanuel Bernard :
> What's you actual use case. This explicit separation is something I've always
> appreciated to limit "clever" package-level visibility usages.
>
> Let's discuss tomorrow on IRC
In preparation to IRC, the use case is what I'm discussing with Tom
Waterhouse in the par
2011/4/4 Hardy Ferentschik :
> If I remember right we didn't initially have the additional 'test' level in
> the code.
> I was also a proponent of not having it, but I think the argument was that
> it helps
> to easier distinguish test from production classes. Obviously they are
> structurally
> se
Sanne,
1) fixed - sequence of checking method interaction was incorrect, that has
been fixed, along with a test to verify that indexing DOES occur as expected
2) fixed - the test was moved to org.hibernate.search.test.event. This
required the registration of an extension of FullTextIndexEventLis
So a slight concern. The javadocs for java.util.ServiceLoader state
that its load(Class) method uses TCCL. Given the recent issues we have
had with TCCL and JBoss AS 7 I wonder if its better to use the explicit
load(Class,ClassLoader) version?
There the question becomes what ClassLoader to us
17 matches
Mail list logo
