Re: [hibernate-dev] Covariant returns
>>Was the initial problem you just using SessionImpl directly? Yes, that was the problem, so probably there are no JDK's handling it differently. regards Günther -Original Message- From: hibernate-dev-boun...@lists.jboss.org [mailto:hibernate-dev-boun...@lists.jboss.org] On Behalf Of Steve Ebersole Sent: Wednesday, March 14, 2012 4:46 PM To: Guillaume Smet Cc: hibernate-dev@lists.jboss.org Subject: Re: [hibernate-dev] Covariant returns Hi Guillaume, Was the initial problem you just using SessionImpl directly? Or is it a problem of particular JDK handling the covariant return differently? In the latter case we'd need to change the code. In the former, its a discussion. As for why byId is that way, TBH being new to being able to design APIs with Java 5+ features I tend to try things to see how they work. On 03/13/2012 06:55 PM, Guillaume Smet wrote: > Hi Steve, > > On Tue, Mar 13, 2012 at 10:39 PM, Steve Ebersole wrote: >> As I understood it, when accessed through the Session interface what >> return type is defined by SessionImpl is irrelevant. And indeed I am >> not able to reproduce this when access those methods via Session. My >> IDE gives me errors if I try to cast that reference to SessionImpl >> instead. > > I tested it quickly in the test case I was working on and I confirm it > works (with the Eclipse compiler and directly with Maven and the > Oracle JDK 1.6.30 compiler). > > That said, I don't understand why you return the Impl instead of the > interface: it's not consistent with byNaturalId() and > bySimpleNaturalId() which are just below. Is there any reason why you > treated them differently? > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] OGM - BasicGridBinder log issue
Hello, I have noticed that the BasicGridBinder has a problem when it logs the bindding ( BasicGridBinder.bind(Tuple, X, String[] ) method). Actually, the trace is "binding [$s] to parameter(s) $s" but it should be "binding [thevalue] to parameter(s) theparameter". It can be fixed easily by modifying the two calls to log.tracef() (line 70 and 76) respectively like that: log.tracef( "binding [null] to parameter [%1$s]", name ); and log.tracef( "binding [%1$s] to parameter(s) %2$s", javaDescriptor.extractLoggableRepresentation( value ), Arrays.toString( names ) ); Should a new Jira be opened or I can inclued it into OGM-123 (mongodb implementation) ? Cheers, Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM - BasicGridBinder log issue
Thanks for the catch I am working on OGM-40 and will push that as aprt of the same pull request. On 15 mars 2012, at 10:54, Guillaume SCHEIBEL wrote: > Hello, > > I have noticed that the BasicGridBinder has a problem when it logs the > bindding ( BasicGridBinder.bind(Tuple, X, String[] ) method). > Actually, the trace is "binding [$s] to parameter(s) $s" but it should be > "binding [thevalue] to parameter(s) theparameter". > It can be fixed easily by modifying the two calls to log.tracef() (line 70 > and 76) respectively like that: > > log.tracef( "binding [null] to parameter [%1$s]", name ); > and > log.tracef( "binding [%1$s] to parameter(s) %2$s", > javaDescriptor.extractLoggableRepresentation( value ), Arrays.toString( > names ) ); > > Should a new Jira be opened or I can inclued it into OGM-123 (mongodb > implementation) ? > > Cheers, > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM - BasicGridBinder log issue
OGM-134 On 15 mars 2012, at 10:56, Emmanuel Bernard wrote: > Thanks for the catch I am working on OGM-40 and will push that as aprt of the > same pull request. > > On 15 mars 2012, at 10:54, Guillaume SCHEIBEL wrote: > >> Hello, >> >> I have noticed that the BasicGridBinder has a problem when it logs the >> bindding ( BasicGridBinder.bind(Tuple, X, String[] ) method). >> Actually, the trace is "binding [$s] to parameter(s) $s" but it should be >> "binding [thevalue] to parameter(s) theparameter". >> It can be fixed easily by modifying the two calls to log.tracef() (line 70 >> and 76) respectively like that: >> >> log.tracef( "binding [null] to parameter [%1$s]", name ); >> and >> log.tracef( "binding [%1$s] to parameter(s) %2$s", >> javaDescriptor.extractLoggableRepresentation( value ), Arrays.toString( >> names ) ); >> >> Should a new Jira be opened or I can inclued it into OGM-123 (mongodb >> implementation) ? >> >> Cheers, >> Guillaume >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Closed: (HHH-7160) Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry in naturalIdToPkMap when NaturalId values changed
Hi Steve,
in HHH-7160 we forgot to consider the 2nd-Level-Cache when removing the key
from naturalIdToPkMap:
private static class NaturalIdResolutionCache implements Serializable {
...
final CachedNaturalId initial = pkToNaturalIdMap.get( pk );
if ( initial != null ) {
if ( areSame( naturalIdValues, initial.getValues() ) ) {
return false;
}
naturalIdToPkMap.remove( initial ); // OK for first
level-cache,
// but if persister.hasNaturalIdCache() then
CachedNaturalId must also be evicted from second level cache too
The dilemma:
non-static method evictNaturalIdResolution cannot be called here ( we are in a
static context)
I have already test-case which demonstrates the bug:
session.bySimpleNaturalId(...).load(obsolete_key) resolves and returns object
from 2nd-LevelCache
How should I proceed? Should I open another issue for this?
best regards
Guenther
-Original Message-
From: Steve Ebersole (JIRA) [mailto:nore...@atlassian.com]
Sent: Thursday, March 15, 2012 12:02 AM
To: Demetz, Guenther
Subject: [Hibernate-JIRA] Closed: (HHH-7160) Method
NaturalIdXrefDelegate#cache() misses to remove obsolete entry in
naturalIdToPkMap when NaturalId values changed
[
https://hibernate.onjira.com/browse/HHH-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Ebersole closed HHH-7160.
---
Resolution: Out of Date
This was already addressed as part of another issue
> Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry
> in naturalIdToPkMap when NaturalId values changed
> --
>
>
> Key: HHH-7160
> URL: https://hibernate.onjira.com/browse/HHH-7160
> Project: Hibernate ORM
> Issue Type: Bug
> Components: core
>Affects Versions: 4.1.1
> Environment: Hibernate4.1.1
>Reporter: Guenther Demetz
> Labels: naturalId
> Attachments: TestCaseNaturalIdChangeBetweenPersistAndFlush.jar
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry
> in naturalIdToPkMap when NaturalId values changed, thus NaturalIdAccess
> delivers results even by searching with obsolete values (see attached
> Testcase).
> Cause:
> following instruction is missing in Method NaturalIdXrefDelegate#cache():
> if ( initial != null ) {
> if ( areSame( naturalIdValues, initial.getValues()) ) {
> return false;
> }
> naturalIdToPkMap.remove(initial); // <-- this instruciton is missing
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Closed: (HHH-7160) Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry in naturalIdToPkMap when NaturalId values changed
I reopened it and gave it a more pertinent subject. Working on other
stuff atm, so help here would be appreciated. Only part of
evictNaturalIdResolution needs to be called here. I would look at
extracting a method from the part of evictNaturalIdResolution that
handles the shared cache and using that in NaturalIdXrefDelegate#cache()
On Thu 15 Mar 2012 10:29:44 AM CDT, Demetz, Guenther wrote:
> Hi Steve,
>
> in HHH-7160 we forgot to consider the 2nd-Level-Cache when removing the key
> from naturalIdToPkMap:
>
> private static class NaturalIdResolutionCache implements Serializable {
> ...
> final CachedNaturalId initial = pkToNaturalIdMap.get( pk );
> if ( initial != null ) {
> if ( areSame( naturalIdValues, initial.getValues() ) ) {
> return false;
> }
> naturalIdToPkMap.remove( initial ); // OK for first level-cache,
> // but if persister.hasNaturalIdCache() then
> CachedNaturalId must also be evicted from second level cache too
>
> The dilemma:
> non-static method evictNaturalIdResolution cannot be called here ( we are
> in a static context)
>
> I have already test-case which demonstrates the bug:
>session.bySimpleNaturalId(...).load(obsolete_key) resolves and returns
> object from 2nd-LevelCache
>
> How should I proceed? Should I open another issue for this?
>
> best regards
> Guenther
>
>
> -Original Message-
> From: Steve Ebersole (JIRA) [mailto:nore...@atlassian.com]
> Sent: Thursday, March 15, 2012 12:02 AM
> To: Demetz, Guenther
> Subject: [Hibernate-JIRA] Closed: (HHH-7160) Method
> NaturalIdXrefDelegate#cache() misses to remove obsolete entry in
> naturalIdToPkMap when NaturalId values changed
>
>
> [
> https://hibernate.onjira.com/browse/HHH-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Steve Ebersole closed HHH-7160.
> ---
>
> Resolution: Out of Date
>
> This was already addressed as part of another issue
>
>> Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry
>> in naturalIdToPkMap when NaturalId values changed
>> --
>>
>>
>> Key: HHH-7160
>> URL: https://hibernate.onjira.com/browse/HHH-7160
>> Project: Hibernate ORM
>> Issue Type: Bug
>> Components: core
>> Affects Versions: 4.1.1
>> Environment: Hibernate4.1.1
>> Reporter: Guenther Demetz
>> Labels: naturalId
>> Attachments: TestCaseNaturalIdChangeBetweenPersistAndFlush.jar
>>
>>Original Estimate: 1h
>> Remaining Estimate: 1h
>>
>> Method NaturalIdXrefDelegate#cache() misses to remove obsolete entry
>> in naturalIdToPkMap when NaturalId values changed, thus NaturalIdAccess
>> delivers results even by searching with obsolete values (see attached
>> Testcase).
>> Cause:
>> following instruction is missing in Method NaturalIdXrefDelegate#cache():
>> if ( initial != null ) {
>> if ( areSame( naturalIdValues, initial.getValues()) ) {
>> return false;
>> }
>> naturalIdToPkMap.remove(initial); //<-- this instruciton is missing
>> }
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
TestableGridDialect.associationCacheSize is killing me ! Because it's not possible to perform a query without knowing the field name. So I can forget about "I want to know the amount of document which contain a field (except '_id') whose type is ObjectID" The same query with "contain a field named 'myField' ..." works. I could probable iterator over all collections and all documents but it definitely bursts the tests performances. Any idea ? Thanks & cheers Guillaume 2012/3/14 Sanne Grinovero > That's a good point. This first abstraction was built around > Cache-centric approaches, so that's reflected in the [test]API method > names, but there are no "Cache" types in the interface you have to > implement. > > I think you should be able to ignore the inappropriate names and still > fullfill the contract of > org.hibernate.ogm.test.utils.TestableGridDialect ? > > Taking for example: > > /** > * @param sessionFactory > * @return the number of elements stored in the entity "cache" > */ > int entityCacheSize(SessionFactory sessionFactory); > > You just have to extract the number of entities stored .. > > Considering a Document based NoSQL such as MongoDB you can still think > of each document as a value, so it can conceptually degenerate in to a > Key/Value model. > > If you can just get it to work fine, after you send a pull request we > can then think about improving the method names to be more > appropriate. > > Please let me know if this doesn't fit.. > > Cheers, > Sanne > > On 14 March 2012 15:03, Guillaume SCHEIBEL > wrote: > > Hi, > > > > I'm implementing the MongoDBTestHelper and I have a question > > > > Most of the methods implents are referencing a "Cache". Either for > Infispan > > or for EhCache there is a specific implementation of Cache so should I > > implement mine because I think there isn't any cache into the > > mongodb-java-driver ? > > > > Guillaume > > > > 2012/3/14 Guillaume SCHEIBEL > >> > >> Ok I see, according to what you said guys, I'll first remove all tests I > >> added and run/work with the core test suite. if some mongodb test will > be > >> needed (I think about replica set management or map/reduce but that's > for > >> later) I will create them into the module directly. > >> > >> I think I'll be able to make a new pull request this week (probably > >> tomorrow or friday). What is the best practice about that, making 1 > commit > >> like OGM-123 mongodb support (with the dialect, the TestHelper, etc) or > >> making specific commits like I did (or tried to do) for the previous > pull > >> request ? > >> > >> > >> Guillaume > >> > >> 2012/3/13 Emmanuel Bernard > >>> > >>> > >>> On 13 mars 2012, at 20:19, Sanne Grinovero wrote: > >>> > >>> > Hi, > >>> > I'm answering inline: > >>> > > >>> > On 13 March 2012 16:39, Guillaume SCHEIBEL > >>> > wrote: > >>> >> Hello, > >>> >> > >>> >> About unit tests during the development phase on OGM-mongodb, I'm > >>> >> wondering > >>> >> what is the best way. > >>> >> Actually, I've developped some specific tests (CRUD mainly) because > I > >>> >> was > >>> >> not aware of the existing test suite. So my question is: should I > >>> >> remove > >>> >> all my tests and just use core test or should I let them to test > >>> >> specific > >>> >> points (like @Embdedded into @Embedded) ? > >>> > > >>> > I think it's a good idea to have custom tests as well, currently the > >>> > ones "inherited" from the core module are really testing only the > core > >>> > bits. > >>> > Feel free to add more tests in your custom module, but maybe check > you > >>> > don't have duplicates. > >>> > Also if they are not specific to your module, maybe you should add > >>> > them to the core module instead so that they help covering all > >>> > "dialects". > >>> > >>> My feeling is that most tests should be in core as the "TCK" to make > sure > >>> each dialect is safe or see when it fails. So I would favor to move > tests > >>> into core as much as possible. > >>> In your example, there is nothing MongoDB specific about @Embedded and > we > >>> should make sure we indeed support that for all dialects. > >>> > >>> The tests that could stay in your won modules are tests that ensure > that > >>> the embedded object is properly put in the document and not else > where. That > >>> does not make much sense right now but I imagine that for collection of > >>> embeddable and when we support metadata driven datastore specific > tuning, we > >>> will want to test such things. (ie collections of embeddable are in the > >>> document in mongo and outside in a different key in say Infinispan. > >>> > >>> > > >>> >> And am I wrong if I say that to launch the core test suite I just > have > >>> >> to > >>> >> add a simple hibernate.properties into src/test/resources/ of the > >>> >> mongodb > >>> >> module and launch maven with the test goal ? > >>> > > >>> > You'll have to add a hibernate.properties, but also create an > >>> > implementation of org.hibernate.ogm.test.utils
[hibernate-dev] JtaPlaform classes as internal?
Because you need to know the JtaPaltform class name to fill up hibernate.transaction.jta.platform, I find it curious that these classes are in internal. I might decide to delete one of them and not care as they are in internal but that will impact the user. I see two options: 1. create subclasses in a non internal package 2. create shortcuts for the built-in platforms (weblogic, websphere-5, websphere-6, etc) I like option 2 better as it makes configurations more readable. WDYT? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: > TestableGridDialect.associationCacheSize is killing me ! > Because it's not possible to perform a query without knowing the field name. > So I can forget about "I want to know the amount of document which contain a > field (except '_id') whose type is ObjectID" > > The same query with "contain a field named 'myField' ..." works. > > I could probable iterator over all collections and all documents but it > definitely bursts the tests performances. Does it? Surely we don't have much than 10 elements in these collections for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
Ok, I was affraid of having a lot more data into the DB. The stored data type will be just simple object or some embedded object could be present too (to know if I have to go all over the field map to find relationnal data) ? Guillaume 2012/3/15 Emmanuel Bernard > > On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: > > > TestableGridDialect.associationCacheSize is killing me ! > > Because it's not possible to perform a query without knowing the field > name. So I can forget about "I want to know the amount of document which > contain a field (except '_id') whose type is ObjectID" > > > > The same query with "contain a field named 'myField' ..." works. > > > > I could probable iterator over all collections and all documents but it > definitely bursts the tests performances. > > Does it? Surely we don't have much than 10 elements in these collections > for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
On 15 March 2012 16:58, Guillaume SCHEIBEL wrote: > Ok, I was affraid of having a lot more data into the DB. > The stored data type will be just simple object or some embedded object > could be present too (to know if I have to go all over the field map to find > relationnal data) ? I think that right now you're the only person knowing how OGM is storing that in MongoDB :) If in doubt, please add a test. Sanne > > > Guillaume > > 2012/3/15 Emmanuel Bernard >> >> >> On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: >> >> > TestableGridDialect.associationCacheSize is killing me ! >> > Because it's not possible to perform a query without knowing the field >> > name. So I can forget about "I want to know the amount of document which >> > contain a field (except '_id') whose type is ObjectID" >> > >> > The same query with "contain a field named 'myField' ..." works. >> > >> > I could probable iterator over all collections and all documents but it >> > definitely bursts the tests performances. >> >> Does it? Surely we don't have much than 10 elements in these collections >> for a given test. > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
Yes I know that, but you know way better than me the core suite test :) that's why I'm asking 2012/3/15 Sanne Grinovero > On 15 March 2012 16:58, Guillaume SCHEIBEL > wrote: > > Ok, I was affraid of having a lot more data into the DB. > > The stored data type will be just simple object or some embedded object > > could be present too (to know if I have to go all over the field map to > find > > relationnal data) ? > > I think that right now you're the only person knowing how OGM is > storing that in MongoDB :) > If in doubt, please add a test. > > Sanne > > > > > > > Guillaume > > > > 2012/3/15 Emmanuel Bernard > >> > >> > >> On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: > >> > >> > TestableGridDialect.associationCacheSize is killing me ! > >> > Because it's not possible to perform a query without knowing the field > >> > name. So I can forget about "I want to know the amount of document > which > >> > contain a field (except '_id') whose type is ObjectID" > >> > > >> > The same query with "contain a field named 'myField' ..." works. > >> > > >> > I could probable iterator over all collections and all documents but > it > >> > definitely bursts the tests performances. > >> > >> Does it? Surely we don't have much than 10 elements in these collections > >> for a given test. > > > > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Search 4.1 CR2 is out
We have just released Hibernate Search 4.1 CR2. This is mostly a bug fix release but let's mention better compatibility with JBoss AS 7 and better write throughput. Read more at http://goo.gl/2OV8w Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Infinispan tests
Ok. If the infinispan testsuite takes forever, please send some thread dumps. If you get failures, please indicate the failures. If you get failures often enough that you can easily replicate, add TRACE logging to org.infinispan and org.hibernate.cache.infinispan packages and send me the logs. I have not seen this Hibernate Infinispan testsuite on my machine and neither these failures. So, if any of you has issues, the more info you can send across to me, the easier it'll be to find the root cause. On Mar 13, 2012, at 1:46 PM, Steve Ebersole wrote: > Its just more of the same "sometimes they pass, sometimes they fail". > > On Tue 13 Mar 2012 03:44:25 AM CDT, Galder Zamarreño wrote: >> Do you have more info on these failures? >> >> On Mar 9, 2012, at 7:01 PM, Steve Ebersole wrote: >> >>> Yaay! It ony took slightly over 5 minutes today. But of course: >>> Building> :hibernate-infinispan:test> Resolving dependencies ':hibernate-infinispan:test:hibernate-infinispan:test >>> Test >>> org.hibernate.test.cache.infinispan.entity.InvalidatedTransactionalTestCase >>> FAILED >>> Test org.hibernate.test.cache.infinispan.entity.ReadOnlyTestCase FAILED >>> 101 tests completed, 19 failures >>> >>> FAILURE: Build failed with an exception. >>> >>> * What went wrong: >>> Execution failed for task ':hibernate-infinispan:test'. There were failing tests. See the report at /home/steve/projects/hibernate/4/hibernate-orm/hibernate-infinispan/target/reports/tests. >>> >>> * Try: >>> Run with --stacktrace option to get the stack trace. Run with --info or >>> --debug option to get more log output. >>> >>> BUILD FAILED >>> >>> Total time: 5 mins 6.757 secs >>> >>> >>> On Fri 09 Mar 2012 06:25:42 AM CST, Steve Ebersole wrote: Luckily you get to decide to follow the company line and use inferior tools as part of your project. Considering that part works everywhere I find it funny that you can chalk my issue up to env but this has to be a "gradle/ivy bug" lol. There is also a far easier syntax for how you are trying to pull in infinispan artifacts. I'll work on updating that for you. As for my "env issues", such as? I'd really like my build to finish in less than an hour! :) On Fri 09 Mar 2012 03:51:45 AM CST, Galder Zamarreño wrote: > > On Mar 8, 2012, at 4:46 PM, Strong Liu wrote: > >> >> On Mar 8, 2012, at 6:48 PM, Sanne Grinovero wrote: >> >>> Hi, >>> I found the same files in my workspace as left over from and older >>> build, but deleted them and tried new builds several times, they don't >>> seem to be re-created anymore? >>> Could anyone confirm (after cleaning them up) that it's still a >>> problem, as I can't.. >>> >>> On the build issues, I had to rebuild and install locally >>> infinispan-5.1.2.CR1 as it seems it couldn't find the test jars in >>> Maven repositories. >> >> this also causes our master job fail >> >> Galder, how should we fix it? > > Abandon Gradle and move to Maven? ;) > > On a more serious note, I don't really know. Maybe the maven repository > CI uses is corrupt? > >> >>> >>> @Steve, regarding the upgrade of Infinispan in a minor release; is >>> your concern the fact that it's not a Final version or is it about not >>> changing any dependency version? >>> As Infinispan 5.1.2.FINAL was released as well, so you could move >>> forward. >>> >>> I had no other test failures. >>> >>> -- Sanne >>> >>> On 8 March 2012 10:34, Hardy Ferentschik wrote: Hi, it just took 5 attempts to build everything :-( The first two times I got errors due to unresolved dependencies (first time some docbook stuff, then Infinispan). In both cases the problem went away by restarting the build. The third time around I got a test failure in org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why. The forth time around org.hibernate.envers.test.integration.components.PropertiesGroupTest failed. I've seen this test fail before (also on the metamodel branch I believe). Does anyone else see this test fail at times? The fifth time the build completed successfully. I can confirm that the infinispan module creates some artifacts outside of the build directory ObjectStore and PutObjectStoreDirHere. I don't think the tests ran any slower than they used to. Total build time for me (according to gradle) was 11 mins 1.78 secs I find the "random" test errors worrying though. Anyone experiencing them as well? --Hardy On Mar 8, 2012, at 3:56 AM, Steve Ebe
Re: [hibernate-dev] JtaPlaform classes as internal?
I like #2 as well. There is already a JIRA for that. In addition there is also a JIRA for adding some auto-detection in 5.0 On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: > Because you need to know the JtaPaltform class name to fill up > hibernate.transaction.jta.platform, I find it curious that these classes are > in internal. > I might decide to delete one of them and not care as they are in internal but > that will impact the user. > > I see two options: > > 1. create subclasses in a non internal package > 2. create shortcuts for the built-in platforms (weblogic, websphere-5, > websphere-6, etc) > > > I like option 2 better as it makes configurations more readable. > > WDYT? > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
