On Tue 07 Aug 2012 01:01:37 AM CDT, Gail Badner wrote:
>>> IIRC, there were some tests that were annotated with
>>> @FailureExpected that were only expected to fail using some
>>> dialects. This was causing what looked like failures on the
>>> dialects where the test was expected to pass. When we
Perhaps we should actually hook in the new schema management code
before we start worrying about missing DDL bits? ;)
As it is right now, building the SessionFactory through the Metamodel
is still just using SchemaExport to the hacked-together
Database#generateSchemaCreationScript and
Database
On 7 Aug 2012, at 15:02, Steve Ebersole wrote:
>> I'm not sure I understand what you mean? Do you mean that the
>> FailureExpected code is not intended to expect failures in @Before,
>> @BeforeClass, and @BeforeClassOnce callbacks?
>
> That is exactly what I am saying. You have to step back
On Tue 07 Aug 2012 11:08:27 AM CDT, Hardy Ferentschik wrote:
>
> Exactly what I was trying to say a :-) And this is exactly why I
> rewrote the tests we have been discussed in this thread. Most of them
> were not even doing/asserting anything when reaching the second phase.
> The "test" was just re
Hello all,
I have implemented basic proof of concept regarding JTA platform recognition.
You can find the initial suggestion here:
https://github.com/lukasz-antoniak/hibernate-core/commit/3df34efad32ceed98a98d2af2c831119b4261773.
Implementation notes:
1) Defining JAR archives in classes extend
Why did you decide to check jar names, rather than perform a known class
lookup?
1) Jar names can be changed.
2) System.getProperty( "java.class.path" ) is only going to work in very
specific environments (and unfortunately often not the environments that
you want to do JTA).
3) Class path scann
On Tue 07 Aug 2012 11:24:34 AM CDT, Steve Ebersole wrote:
>>> What John and I discussed when we worked out the
>>> @FailureExpectedWithNewMetamodel was to possibly "store" start up
>>> failures (exceptions) and use them for each grouped test method. I
>>> think that is not unreasonable, even lon
I'm seeing lots of infinispan test failures, I guess mostly relate to the
jgroups, propbaly an environment issue, wondering anyone has a workaround?
java.lang.IllegalStateException: Cache at address server-15967 had 3 members;
expecting 2. Members were (server-64288, server-15967, server-6121)