Re: [hibernate-dev] Releasing another CR for Search?
Yes I think you are right. It's better to release a CR this week. If only to release our stress ;) HSEARCH-1054 is pending, is there anything you wanted in before this CR? Emmanuel On 12 mars 2012, at 11:44, Sanne Grinovero wrote: There was a plan to release Hibernate Search 4.1.0.Final today, but we've been thinking to slip it as it's currently unclear if we should upgrade to Hibernate ORM 4.1.x or stay with the current 4.0.x, as that's what the current version of AS 7.1.1.Final is using: there is a change in ORM which makes it hard for Search to support both 4.1.x and 4.0.x. So the Final won't happen today. Shall we release another CR ? I think we need a release, and there are still quite some changes in it so a CR would be healthy. Sanne ___ 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] [JPAModelgen] MixedConfigurationTest failing
Hi Guillaume,
first off, thanks for your pull requests for Modelgen. I applied both :-)
I did not realize that the issue you are describing here is still in issue. Are
you reproduce
this problem with the current master? I don't have any test failures against
master.
What is your environment? JDK and maven version. Here is mine:
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /opt/java/maven
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.7.3, arch: x86_64, family: mac
--Hardy
On Mar 14, 2012, at 12:41 AM, Guillaume Smet wrote:
Hi Hardy,
Any feedback about this issue?
Thanks.
On Sun, Mar 11, 2012 at 3:20 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
Hi,
While working on Hibernate JPA Modelgen, I noticed that there are test
failures in MixedConfigurationTest . I thought it was because of my
own changes but I also have this problem with a fresh git clone from
the official repo:
Running org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest
Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 2.494
sec FAILURE!
Results :
Failed tests:
testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest):
org.hibernate.jpamodelgen.test.mixedmode.Coordinates_ was not
generated.
testDefaultAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest):
org.hibernate.jpamodelgen.test.mixedmode.Vehicle_ was not generated.
testExplicitXmlConfiguredAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest):
org.hibernate.jpamodelgen.test.mixedmode.Vehicle_ was not generated.
testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest):
org.hibernate.jpamodelgen.test.mixedmode.RentalCar_ was not generated.
Tests run: 4, Failures: 4, Errors: 0, Skipped: 0
From what I can see, there is at least a problem with
AnnotationMetaEntity.mergeInMembers: the merged in members aren't
really affected to the new entity as the hostingEntity of the
attribute is still the original entity.
In the case of the ZeroCoordinates entity, it leads to a compilation
error as the SingularAttribute import isn't added to the right context
(it's added to the original XmlMetaEmbeddable context instead of the
AnnotationEmbeddable context this attribute is attached to at the end
of the annotation processing). The content of the generated class is
as follows:
package org.hibernate.jpamodelgen.test.mixedmode;
import javax.annotation.Generated;
import javax.persistence.metamodel.StaticMetamodel;
@Generated(value = org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor)
@StaticMetamodel(ZeroCoordinates.class)
public abstract class ZeroCoordinates_ {
public static volatile SingularAttributeZeroCoordinates,
Float longitude;
public static volatile SingularAttributeZeroCoordinates,
Float latitude;
}
I was wondering if providing the way to overwrite the hostingEntity
(via removing the final and adding a setter) would be acceptable or
not?
Even if I do so (draft patch attached), I still have a test failing
claiming that ZeroCoordinates shouldn't have any attributes generated.
I'm not really sure the test is accurate as the fields are defined
explicitely in the coordinates.xml mapping file so I would have
expected them to be generated.
I would like to have some feedback before I open a bug.
Thanks.
--
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
Hi Hardy, On Wed, Mar 14, 2012 at 9:35 AM, Hardy Ferentschik ha...@hibernate.org wrote: first off, thanks for your pull requests for Modelgen. I applied both :-) Thanks. I did not realize that the issue you are describing here is still in issue. Are you reproduce this problem with the current master? I don't have any test failures against master. Yes, this problem has nothing to do with my previous patches. I found it surprising to have test failures on master just after a release so I preferred having a discussion on the list before creating a bug. I run it several times on a fresh master without my patches and I just did it one more time with a fresh clone from this morning. What is your environment? JDK and maven version. Here is mine: gsmet@gsmet:/tmp/hibernate-metamodelgen$ mvn -v Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/apache-maven-3.0.3 Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: /opt/jdk1.6.0_31/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: linux, version: 2.6.38-13-generic-pae, arch: i386, family: unix That said, I don't think it has anything to do with the environment. I'm not sure you've seen my preliminary patch as I don't see it in any archives so I suppose the list is filtering the attachments. I posted it here: https://share.openwide.fr/share/zone/gsmet/367583861 . I really think there's something here that should be fixed. But I don't understand why you don't see any error as, in my case, the generated class for ZeroCoordinates doesn't compile at all due to a missing import. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
Hi Guillaume, That said, I don't think it has anything to do with the environment. I'm not sure you've seen my preliminary patch as I don't see it in any archives so I suppose the list is filtering the attachments. I posted it here: https://share.openwide.fr/share/zone/gsmet/367583861 . I really think there's something here that should be fixed. Thanks. I got the patch now. I have indeed not seen it before. I need to have a closer look though, because as I said, I don't see this test failure. As you suspect, I would not intentionally keep a failing test on master ;-) --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
On Wed, Mar 14, 2012 at 11:22 AM, Hardy Ferentschik ha...@hibernate.org wrote: Thanks. I got the patch now. I have indeed not seen it before. I need to have a closer look though, because as I said, I don't see this test failure. As you suspect, I would not intentionally keep a failing test on master ;-) I'm pretty sure it's easy to write a test which demonstrates the problem. If you have an XML entity which defines attributes, you have the same entity with an annotation and thus the attributes are merged into the new annotated entity, the resulting metamodel class can't compile because the imports aren't added to the annotated entity but to the XML one. That said, can you send me offlist your ZeroCoordinates_ file generated by the test? I'm quite curious to see it. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
BTW, tests also fails here with Maven 3.0.4. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Releasing another CR for Search?
Ideally I wanted HSEARCH-499, but after a drive failure over the weekend I'm still unable to stress test any fix. So *maybe* I can have a proposal for it in 2 days. We could go ahead without it, we have enough changes already? HSEARCH-1054 would be needed, so that I can update other projects in two steps.. updating pull request now. Sanne On 14 March 2012 08:10, Emmanuel Bernard emman...@hibernate.org wrote: Yes I think you are right. It's better to release a CR this week. If only to release our stress ;) HSEARCH-1054 is pending, is there anything you wanted in before this CR? Emmanuel On 12 mars 2012, at 11:44, Sanne Grinovero wrote: There was a plan to release Hibernate Search 4.1.0.Final today, but we've been thinking to slip it as it's currently unclear if we should upgrade to Hibernate ORM 4.1.x or stay with the current 4.0.x, as that's what the current version of AS 7.1.1.Final is using: there is a change in ORM which makes it hard for Search to support both 4.1.x and 4.0.x. So the Final won't happen today. Shall we release another CR ? I think we need a release, and there are still quite some changes in it so a CR would be healthy. Sanne ___ 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] [JPAModelgen] MixedConfigurationTest failing
Hi,
just double checked. ZeroCoordinates gets generated and compiles:
package org.hibernate.jpamodelgen.test.mixedmode;
import javax.annotation.Generated;
import javax.persistence.metamodel.StaticMetamodel;
@Generated(value = org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor)
@StaticMetamodel(ZeroCoordinates.class)
public abstract class ZeroCoordinates_ {
}
Is this how yours looks as well?
--Hardy
On Mar 14, 2012, at 11:29 AM, Guillaume Smet wrote:
On Wed, Mar 14, 2012 at 11:22 AM, Hardy Ferentschik ha...@hibernate.org
wrote:
Thanks. I got the patch now. I have indeed not seen it before.
I need to have a closer look though, because as I said, I don't see
this test failure. As you suspect, I would not intentionally keep a failing
test on master ;-)
I'm pretty sure it's easy to write a test which demonstrates the
problem. If you have an XML entity which defines attributes, you have
the same entity with an annotation and thus the attributes are merged
into the new annotated entity, the resulting metamodel class can't
compile because the imports aren't added to the annotated entity but
to the XML one.
That said, can you send me offlist your ZeroCoordinates_ file
generated by the test? I'm quite curious to see it.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
On Wed, Mar 14, 2012 at 12:53 PM, Hardy Ferentschik ha...@hibernate.org wrote:
@Generated(value = org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor)
@StaticMetamodel(ZeroCoordinates.class)
public abstract class ZeroCoordinates_ {
}
Nope. I have attributes in it (and SingularAttribute import is missing
as it's added to the wrong MetaEntity).
From the test case, I saw that it wasn't supposed to but as they are
defined in the XML files, I am not so surprised they are generated.
I don't know why I have this behaviour...
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
Hi,
fyi, seems Sanne is backing you up :-( He tried to build as well and got also
failures - http://fpaste.org/xuOr/
The actual test failures are misleading in this case, because each tests
processes all test resources prior the assertions.
If any of the test classes cannot be processed you get a lot of false
positives. It seems you already digged a deeper
when you make ZeroCoordinates the culprit.
I think it would be time to track this via a proper Jira issue. Do you mind
creating one? You can also attach the patch
you've sent me.
I will dig deeper asap.
--Hardy
On Mar 14, 2012, at 1:05 PM, Guillaume Smet wrote:
On Wed, Mar 14, 2012 at 12:53 PM, Hardy Ferentschik ha...@hibernate.org
wrote:
@Generated(value = org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor)
@StaticMetamodel(ZeroCoordinates.class)
public abstract class ZeroCoordinates_ {
}
Nope. I have attributes in it (and SingularAttribute import is missing
as it's added to the wrong MetaEntity).
From the test case, I saw that it wasn't supposed to but as they are
defined in the XML files, I am not so surprised they are generated.
I don't know why I have this behaviour...
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [JPAModelgen] MixedConfigurationTest failing
On Wed, Mar 14, 2012 at 1:20 PM, Hardy Ferentschik ha...@hibernate.org wrote: I think it would be time to track this via a proper Jira issue. Do you mind creating one? You can also attach the patch you've sent me. OK, I'll do it later today. -- Guillaume ___ 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
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 guillaume.schei...@gmail.com 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 emman...@hibernate.org On 13 mars 2012, at 20:19, Sanne Grinovero wrote: Hi, I'm answering inline: On 13 March 2012 16:39, Guillaume SCHEIBEL guillaume.schei...@gmail.com 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.TestableGridDialect and edit org.hibernate.ogm.test.utils.TestHelper at line 42 to add your knownTestDialects. To see how to implement a TestableGridDialect, I guess your best guide is to look into the EHCache and Infinispan implementations for examples. You're beta-testing these instructions, feel free to ask more details I might have forgotten, so I can make a good wiki page out of this. Let's open a wiki page to document these discoveries that will help wannabe datastore contributors. Title: How to write a Datastore in Hibernate OGM in the hibernate ogm subspace. BTW, in eclipse and in intellij, you can say that you run a given (set of) test based on the classpath of a specific module. That will let you run the test with the mongodb settings stored in your hibernate.properties file. ___ 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
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 guillaume.schei...@gmail.com 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 guillaume.schei...@gmail.com 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 emman...@hibernate.org On 13 mars 2012, at 20:19, Sanne Grinovero wrote: Hi, I'm answering inline: On 13 March 2012 16:39, Guillaume SCHEIBEL guillaume.schei...@gmail.com 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.TestableGridDialect and edit org.hibernate.ogm.test.utils.TestHelper at line 42 to add your knownTestDialects. To see how to implement a TestableGridDialect, I guess your best guide is to look into the EHCache and Infinispan implementations for examples. You're beta-testing these instructions, feel free to ask more details I might have forgotten, so I can make a good wiki page out of this. Let's open a wiki page to document these discoveries that will help wannabe datastore contributors. Title: How to write a Datastore in Hibernate OGM in the hibernate ogm subspace. BTW, in eclipse and in intellij, you can say that you run a given (set of) test based on the classpath of a specific module. That will let you run the test with the mongodb settings stored in your hibernate.properties file. ___ hibernate-dev mailing list
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 Ebersolest...@hibernate.org 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] Fwd: Jenkins build became unstable: hibernate-core-master-matrix » mssql2008R1,java16_default,hibernate #185
I am not able to produce this failure locally just using H2 and I do not see how my change that would seem to cause this chaned the output SQL in this particular case. So I tried to go back to the last successful builds but I found nothing to help me. I wanted to check whether I am missing something on the Jenkins servers? Job #185 was the first to start failing. Job #184 has no test reports. Job #185 had test results but no SQL was captured??? - http://hudson.qa.jboss.com/hudson/job/hibernate-core-master-matrix/database=mssql2008R1,jdk=java16_default,label=hibernate/183/testReport/org.hibernate.ejb.test.query/ComponentJoinsTest/testComponentJoins/ Original Message Subject: Jenkins build became unstable: hibernate-core-master-matrix » mssql2008R1,java16_default,hibernate #185 Date: Wed, 14 Mar 2012 08:53:53 -0400 (EDT) From: jboss-qa-inter...@redhat.com To: st...@hibernate.org, eric.dalqu...@gmail.com, zroub...@redhat.com, st...@hibernate.org, lukasz.anton...@gmail.com See http://hudson.qa.jboss.com/hudson/job/hibernate-core-master-matrix/./database=mssql2008R1,jdk=java16_default,label=hibernate/185/changes ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Covariant returns
Hi Steve, On Wed, Mar 14, 2012 at 4:46 PM, Steve Ebersole st...@hibernate.org wrote: 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. I'm not the OP. It works perfectly on my side, as reported yesterday. 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. The new APIs are really nice from a DSL point of view, especially the natural id stuff. Thanks for your work on this. IMHO, even if it's not a problem by itself, I think byId() should be consistent with the rest of the API and return an interface. I don't see any advantages to return the Impl in this case. Have a nice day. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Covariant returns
Ah, that was Guenther that reported the problem... Sorry On Wed 14 Mar 2012 11:51:30 AM CDT, Guillaume Smet wrote: Hi Steve, On Wed, Mar 14, 2012 at 4:46 PM, Steve Ebersolest...@hibernate.org wrote: 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. I'm not the OP. It works perfectly on my side, as reported yesterday. 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. The new APIs are really nice from a DSL point of view, especially the natural id stuff. Thanks for your work on this. IMHO, even if it's not a problem by itself, I think byId() should be consistent with the rest of the API and return an interface. I don't see any advantages to return the Impl in this case. Have a nice day. -- 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] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 6 Mar 2012, at 14:45, Scott Marlow wrote: - Medium term: Have a way to pass in marshalling configurations per cache manager and per-cache (or an abstraction of it), which allows the right class resolver to be passed in. (***) https://issues.jboss.org/browse/ISPN-1367 ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release date for that? I'm curious as to which AS release it might align with. Definitely post EAP 6. -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/14/2012 02:13 PM, Manik Surtani wrote: On 6 Mar 2012, at 14:45, Scott Marlow wrote: - Medium term: Have a way to pass in marshalling configurations per cache manager and per-cache (or an abstraction of it), which allows the right class resolver to be passed in. (***) https://issues.jboss.org/browse/ISPN-1367 ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release date for that? I'm curious as to which AS release it might align with. Definitely post EAP 6. The ISPN-1367 jira changed a bit since I asked this question. A few days ago, Galder said that he was working on addressing ISPN-1367 for AS 7.1.2 (so we can specify the AS7 ModularClassResolver as a global configuration setting passed into Infinispan). I probably asked the wrong question above (I don't really want to bring 5.2 into As 7.1.2). Can we fix ISPN-1367 in a 5.1.x.FINAL build, that could be brought into AS 7.1.2? -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.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] @Entity and inheritance with annotations
Can someone help me understand whether this is valid annotation mapping:
@Entity
class A {
}
@Entity
class B extends A {
}
?
My understanding was that an @Entity extending an @Entity had to specify
an inheritance strategy? And that this example is really the point of
@MappedSuperclass:
@MappedSuperclass
class A {
}
@Entity
class B extends A {
}
--
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] @Entity and inheritance with annotations
On Mar 14, 2012, at 9:17 PM, Steve Ebersole wrote:
Can someone help me understand whether this is valid annotation mapping:
@Entity
class A {
}
@Entity
class B extends A {
}
That's valid. The @Inheritance annotation is optional. If not specified
InheritanceType.SINGLE_TABLE is used.
My understanding was that an @Entity extending an @Entity had to specify
an inheritance strategy? And that this example is really the point of
@MappedSuperclass:
@MappedSuperclass
class A {
}
@Entity
class B extends A {
}
Citing from the spec here:
An entity may inherit from a superclass that provides persistent entity state
and mapping information,
but which is not itself an entity. Typically, the purpose of such a mapped
superclass is to define state
and mapping information that is common to multiple entity classes.
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jenkins build became unstable: hibernate-core-master-matrix » mssql2008R1,java16_default,hibernate #185
On Mar 15, 2012, at 12:31 AM, Steve Ebersole wrote: I am not able to produce this failure locally just using H2 and I do not see how my change that would seem to cause this chaned the output SQL in this particular case. H2 is fine, since our main master job finishes w/o any failure So I tried to go back to the last successful builds but I found nothing to help me. I wanted to check whether I am missing something on the Jenkins servers? maybe Jenkins doesn't store those history info? not sure Job #185 was the first to start failing. Job #184 has no test reports. Job #185 had test results but no SQL was captured??? - http://hudson.qa.jboss.com/hudson/job/hibernate-core-master-matrix/database=mssql2008R1,jdk=java16_default,label=hibernate/183/testReport/org.hibernate.ejb.test.query/ComponentJoinsTest/testComponentJoins/ Original Message Subject: Jenkins build became unstable: hibernate-core-master-matrix » mssql2008R1,java16_default,hibernate #185 Date: Wed, 14 Mar 2012 08:53:53 -0400 (EDT) From: jboss-qa-inter...@redhat.com To: st...@hibernate.org, eric.dalqu...@gmail.com, zroub...@redhat.com, st...@hibernate.org, lukasz.anton...@gmail.com See http://hudson.qa.jboss.com/hudson/job/hibernate-core-master-matrix/./database=mssql2008R1,jdk=java16_default,label=hibernate/185/changes ___ 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
