Just for the record, upgrading to Java 1.7.0_51 fixed the build for me.
- Original Message -
> From: "Steve Ebersole"
> To: "Gail Badner"
> Cc: "Hibernate"
> Sent: Friday, March 28, 2014 4:22:35 AM
> Subject: Re: [hibernate-dev] Build failure executing
> :hibernate-core:runAnnotationPr
What we choose as a separator after the "pivot" is irrelevant to a degree,
especially in terms of the compatibility concern. I think you understood
that, just being clear. Meaning that calls like:
sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell"
)
will fail whethe
This is not quite the same thing as what I am asking about.
I'd much rather check for the execution of a specific method
(CoreMessageLogger#idClassHadMappingAnnotations, e.g.) as opposed to a
generic method and checking one of its String arguments. We have already
had quite a bit of trouble in 5.
It seems we are all ok except on the SearchFactory shuffling. Not we we agree
(or disagree) on that one.
On 28 Mar 2014, at 12:41, Hardy Ferentschik wrote:
> Have we by now reached a consensus on wether or not to address the package
> split?
> Anyone against generally against it?
>
> —Hardy
>
No strong feeling about it.
It will break the OGM dialects that make use of the collection role though. So
we need to anticipate.
To me . looks more like the code being used and is a natural notation even
beyond Java. But I get that # offers some additional info.
Have you considered?
org.h.
XWiki solved that with a JUnit rule and an in-memory log appender. I beleive
their test adds the log appender programmatically during the tests.
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-test/xwiki-commons-test-simple/src/main/java/org/xwiki/test/LogRule.
Hi,
Here is a fix for the Eclipse formatter posted on the community site.
Currently, it changes:
x.foo();
to
x. foo();
which doesn't respect the checkstyle rules.
Thought it might be useful to report it as it's quite painful to have
a build broken because of that.
Thanks!
--
Guillaume
__
Hi again,
I posted a pull request for the 4.5 branch:
https://github.com/hibernate/hibernate-search/pull/590 . Comments
welcome!
I included a rather large test case I have extracted from our app.
It's simplified but I think you should get the idea by looking at it.
All tests passes.
FWIW, I fin
On 28 March 2014 12:35, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
>
>> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>>
>>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>>
I'd then remove Log4J from our test dependencies to primarily rely on
>>>
On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote:
>
>
> On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
>
> > Given the problems using byteman is causing in CI
>
> What problem is that?
Port contention of some sort
>
> > and the fact that our
> > reliance on it is pretty light at the moment,
On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>
>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>
>>> I'd then remove Log4J from our test dependencies to primarily rely on
>>> assertions only;
>>
>> Why would you do that? I would e
On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
> Given the problems using byteman is causing in CI
What problem is that?
> and the fact that our
> reliance on it is pretty light at the moment, I wanted to reach out for
> some other ideas/proposals for ways to handle this testing requirement.
Hi Sanne,
On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero wrote:
> However - I might not have fully grasped this yet - but I'm thinking
> that this is a feature request and not a bugfix that should be hastily
> applied on 4.4.
It's not a feature request. 4.4 changed this behavior. It was worki
On 28 March 2014 12:15, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>
>> I'd then remove Log4J from our test dependencies to primarily rely on
>> assertions only;
>
> Why would you do that? I would expect whatever solution we come up with to
> just delegate to th
On Fri, Mar 28, 2014 at 7:06 AM, Hardy Ferentschik wrote:
>
> On 27 Jan 2014, at 23:54, Steve Ebersole wrote:
>
> > This is a bit of a potentially insidious one. Not the best way to start
> > off a discussion, I know :)
> >
> > The premise is this... Until now Hibernate has represented attribute
> Even better, internally I have now Object-ified the notion of path and role:
> AttributePath and AttributeRole.
+100
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
> I'd then remove Log4J from our test dependencies to primarily rely on
> assertions only;
Why would you do that? I would expect whatever solution we come up with to
just delegate to the underlying logger.
> or for debugging purposes to have it
On 27 Jan 2014, at 23:54, Steve Ebersole wrote:
> This is a bit of a potentially insidious one. Not the best way to start
> off a discussion, I know :)
>
> The premise is this... Until now Hibernate has represented attribute roles
> using dots. For an attribute named 'department' on the com.a
I had the same thoughts recently!
My idea would be to have a Logger implementation which logs into an
in-memory buffer, which you can lookup somehow. For my own test needs,
even a static accessor would do. It could be a simple text
representation, or it could store a smarter event-list with some
a
On 28 March 2014 11:37, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote:
>
>> We could use either a different annotation or a flag
>>
>>@ContainedIn(someVerySmartName=SomeVerySmartValue)
>
> I was also wondering whether a whole new annotation would make sense, bu
I again have in mind adding some test assertions that a particular logging
(WARN) message gets triggered. We have already one such test in place,
which is one of the places where our usage of byteman comes in.
Given the problems using byteman is causing in CI and the fact that our
reliance on it
Have we by now reached a consensus on wether or not to address the package
split?
Anyone against generally against it?
—Hardy
On 27 Jan 2014, at 14:17, Emmanuel Bernard wrote:
> On Thu 2014-03-27 12:40, Hardy Ferentschik wrote:
>>> the tricky part is that today SearchFactoryIntegrator extends
On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote:
> We could use either a different annotation or a flag
>
>@ContainedIn(someVerySmartName=SomeVerySmartValue)
I was also wondering whether a whole new annotation would make sense, but
nothing intuitive
came to mind right away. I guess @Con
Nope, but this would local to your system. It works for me and it is
working in CI
On Fri, Mar 28, 2014 at 12:52 AM, Gail Badner wrote:
> After pulling, I am getting a failure executing
> :hibernate-core:runAnnotationProcessors.
>
> I tried building with --debug and it looks like the
> hiberna
We could use either a different annotation or a flag
@ContainedIn(someVerySmartName=SomeVerySmartValue)
On Fri 2014-03-28 11:44, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 10:52, Guillaume Smet wrote:
>
> > This one is really a blocker for us as we have to put something into
> > produ
On 28 Jan 2014, at 10:52, Guillaume Smet wrote:
> This one is really a blocker for us as we have to put something into
> production really soon with 4.4.2 and we can't do it atm. I take the
> liberty to open a JIRA issue so that I can start working on a PR with
> a test showing what we do and a
On 27 Jan 2014, at 14:46, Guillaume Smet wrote:
> I don't think a test would be useful to understand what we do. Here
> are a few additional information about our business case.
Not sure. I think it always helps to see the whole picture.
> The fact is that we have complex business rules which
Hardy,
This one is really a blocker for us as we have to put something into
production really soon with 4.4.2 and we can't do it atm. I take the
liberty to open a JIRA issue so that I can start working on a PR with
a test showing what we do and a fix.
While it looks like it was not an intented fe
hello,i am chinese ,so my english is not good ,sorry! i use hibernate orm +
jdts.13 connection sqlserver 2008 , and there are a class of User .
class User
{
private Blob pictureImg;
..
}
when i save user ,i got a problem "
net.sourceforge.jtds.jdbc.JtdsPrep
29 matches
Mail list logo
