January 2010 - hibernate-dev - Jboss List Archives

implement criteria query collection-of-component and collection-of-value against latest 3.5.0-Beta-3

by David Mansfield

Hi All, Attached is a series of patches which implements the missing functionality for Criteria queries, namely being able to use Criteria queries for collections of components or scalars. The patch series includes documentation changes and test cases. I'd love for this to get into the project, and would appreciate any feedback or questions and will work to resolve any issues. The first two patches are necessary groundwork and bugfixes for the real code. This code (against 3.3.1 and previous) has been in production for a long time here and has no known issues. Here's some info about the patches as a series: Patch 0001: In the JoinWalker, we assemble an SQL select list fragment from a list of Joinables. Reading the existing code, we see it's possible for the fragment generated to be empty. However if the LAST joinable generates an empty fragment, we put a spurious comma into the fragment. Fix this by only prepending a comma when necessary. Patch 0002: In the CriteriaQueryTranslator, we process the path given by a SubCriteria object looking for the entity name for the property. If the SubCriteria was mistakenly created on a component type, we will exit the loop using the owning entity, and will eventually end up failing (throwing an exception) trying to lookup up the restricted property against the entity, instead of against the component. Fix this by throwing a more informative exception, and modify the documentation to be explicit about how to do this properly. Patch 0003: Implement the enhancement named. This includes the documentation changes. The general approach is: - create an interface called the CriteriaInfoProvider which abstracts the operations that are different for the different types of Criteria targets. - change the getPathEntityName method to be a factory method for creating the proper implementation of the interface - change the rest of CriteriaQueryTranslator to use the interface instead of using the previous entity-only implementation - implementations of the interface exist for Entity: this implements the same code as currently exists ComponentCollection: for collection-of-component ScalarCollection: for collection-of-value Component: for components - update the logic in CriteriaJoinWalker which has to be very careful about how it works since the walker walks certain property paths twice. Patch 0004: the test case for collection-of-value Patch 0005: the test case for collection-of-component Thanks, David Mansfield Cobite INC.

14 years, 3 months

2
3
0 / 0

PATCH 1/5 implement criteria query collection-of-component and collection-of-value against latest 3.5.0-Beta-3

by David Mansfield

I'm attempting to resend this "complete" patch set, which includes documentation and test cases in a series of 5 patches, the first two of which are independent bug fixes. My previous attempt seemed to have patch stripped so I'm going to try one at a time. Patch 0001: In the JoinWalker, we assemble an SQL select list fragment from a list of Joinables. Reading the existing code, we see it's possible for the fragment generated to be empty. However if the LAST joinable generates an empty fragment, we put a spurious comma into the fragment. Fix this by only prepending a comma when necessary.

14 years, 3 months

1
1
0 / 0

envers tests

by Steve Ebersole

Anyone else seeing lots of failures in envers tests? I am getting this even after a full update. Just trying to see if I have a local issue with maven repo, etc. -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org

14 years, 3 months

3
6
0 / 0

Search: limitations in mapping structured entities on Lucene

by Sanne Grinovero

Hello, there's a limitation in Hibernate Search's capabilities of mapping structured objects, there's a good explanation of this problem here: https://forum.hibernate.org/viewtopic.php?f=9&t=1001551 This is something I'm aware of since my first use of Search, I was assuming you know about it? I couldn't think of a good solution so far, besides the awful workaround I suggested in the forums. Better ideas? Sanne

14 years, 3 months

2
2
0 / 0

AUTO: Christian Hartmann ist im Urlaub (Mo, 25.01.2010 wird zurückgegeben)

by christian.hartmann＠extern.steria-mummert.de

Ich bin von Mo, 18.01.2010 bis Mo, 25.01.2010 abwesend. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht " hibernate-dev Digest, Vol 43, Issue 17" gesendet am 19.01.2010 18:00:11. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. Steria Mummert Consulting AG Vorsitzender des Aufsichtsrates: Jürgen Sponnagel - Vorstand: Oliver Nazet (Vors.), Dr. Fritz Moser Gesellschaftssitz: Hamburg - HR B 61 116 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351 Bitte denken Sie an Ihre Verantwortung gegenüber der Umwelt: Jede ausgedruckte E-Mail verursacht ca. 0,3 Gramm CO2. Diese Nachricht kann vertrauliche Informationen enthalten und ist allein für den Adressaten bestimmt. Wenn Sie nicht der rechtmäßige Empfänger sind, ist der Zugriff, die Weiterleitung, das Kopieren, die Veröffentlichung oder anderweitige Verwendung des Inhalts untersagt. In diesem Fall bitten wir Sie den Absender unverzüglich zu informieren und diese E-Mail sowie sämtliche Kopien dieser Email zu löschen. Der Inhalt von E-Mails innerhalb des Netzwerks kann überprüft werden, um die Übereinstimmung mit den geltenden Firmenrichtlinien und Vorgehens-weisen zu gewährleisten. E-Mails können auf dem Transportweg von Dritten verändert werden, so dass deren Vollständigkeit und Echtheit nicht garantiert werden kann. This Email communication may contain confidential information and is intended only for the recipient. If you are not the intended recipient you are not allowed to read, copy, distribute, publicize or use the content of this Email in any way. Please notify the sender and delete the Email and any copies of it. The content of Emails within our network may be monitored to ensure compliance with company policies and procedures. Emails can be alterated by third parties in transit. Therefore any Email is susceptible to alteration and its integrity cannot be assured.

14 years, 3 months

1
0
0 / 0

Query cache inefficiencies over longer Sessions

by Galder Zamarreno

Let's see if I can send this properly now to the list. ----- Forwarded Message ----- From: "Galder Zamarreno" <gzamarre(a)redhat.com> To: "Steve Ebersole" <sebersol(a)redhat.com> Cc: "Brian Stansberry" <bstansbe(a)redhat.com>, hibernate-dev(a)lists.jboss.org Sent: Monday, January 18, 2010 1:52:54 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: Query cache inefficiencies over longer Sessions Had the wrong hibernate-dev list email on CC. Fixing it now. ----- Original Message ----- From: "Galder Zamarreno" <gzamarre(a)redhat.com> To: "Steve Ebersole" <sebersol(a)redhat.com> Cc: "Brian Stansberry" <bstansbe(a)redhat.com>, hibernate-dev(a)jboss.org Sent: Monday, January 18, 2010 1:51:29 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Query cache inefficiencies over longer Sessions Hi Steve, I'm looking into a post by Guenther (http://community.jboss.org/message/519752#519752) where he explains issues he's encountering with query cache. He's already entered two JIRAs before related to this: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4551 http://opensource.atlassian.com/projects/hibernate/browse/HHH-4577 He had initially complained about the lack of precision of nextTimestamp in JBC/Infinispan cache providers, but this precision deficiency is justified in a clustered environment, so we're not planning to change it for the time being. Looking at his last comment, it seems to me that his real problem is the fact that the timestamp query cache uses to store the queries, or to check whether a query is up to date comes from timestamp of when the session is created. The longer the sessions are, the least advantageous it is to use query cache in the current form. Now, my question is, why not use Region.nextTimestamp() as timestamp when queries are to be cached rather than when the session was opened? This would most probably solve problems like the ones this user has because by the time a query and its resulset had been calculated, more than 100ms would have passed, assuming you don't use an in-memory database, which is what's recommended anyway. Also, why not use Region.nextTimestamp() as timestamp when a query is actually executed when comparing with update timestamps rather than when session was opened? I'm not an authority on Hibernate code, but I suspect the reason why the decision was taken to use the timestamp when session is created might be because due to potential isolation problems between concurrent sessions updating query/entity caches on non-transactional cache providers. By using the timestamp when session was opened, you guarantee that queries will be invalid from the moment that you started that session, hence any partial updates that might have happened to caches between session open and query execution won't be used by other sessions. I don't think this would be a problem with transactional cache providers though, i.e. infinispan/jbc. The fact that updates happen on commit time and transaction isolation would protect from such situations. I think it might be worth adding some configuration option that allows for more precision for query caches used with transactional cache providers. Such option could force Region.nextTimestamp() to be used to mark when queries are executed, and when these are updated, rather when session was opened. Thoughts? Galder

14 years, 3 months

1
0
0 / 0

Weird backref issue within the AttributeFactory (Was Re: Some code questions)

by Emmanuel Bernard

On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote: > I have a couple of question regarding some recent code changes. The first one seems to be the cause of a > test failure in VersionsJoinTableRangeComponentNamingTest (Envers). It actually causes a NullPointerException. > Have a look at: http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main... Right, I fixed the problem, sorry about that. Though it uncovered a weird problem. When I run the entire envers test suite, I pass with flags up. When I specifically run VersionsJoinTableRangeComponentNamingTest I've got a java.lang.IllegalArgumentException: Cannot determine java-type from given member [null] at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:591) at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:671) at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:661) at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:542) at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:81) at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:177) at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66) at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:79) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:752) at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:94) at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:82) The member is null because the "property" has a backref getter and hence no member is returned by NORMAL_MEMBER_RESOLVER. I think we should ignore backref properties Does that make sense? If we agree, I will go and apply a fix. http://opensource.atlassian.com/projects/hibernate/browse/HHH-4797 > > > Also have a look at http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main... > You create a AssertionFailure, but then don't throw it? I guess this is just missing a 'throw' before the new. yep, fixed.

14 years, 3 months

4
10
0 / 0

Fwd: 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended?

by Emmanuel Bernard

Begin forwarded message: > From: Emmanuel Bernard <emmanuel(a)hibernate.org> > Date: 15 janvier 2010 13:58:19 HNEC > To: Guenther Demetz <guenther.demetz(a)wuerth-phoenix.com> > Subject: Re: [hibernate-dev] 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended? > > All should be fixed in trunk now. > http://opensource.atlassian.com/projects/hibernate/browse/HHH-4806 > http://opensource.atlassian.com/projects/hibernate/browse/HHH-4807 > > > On 15 janv. 2010, at 13:41, Guenther Demetz wrote: > >> Emmanuel Bernard schrieb: >>> >>> ... >>> So I imagine you don't use bean validation and the DB raises a constraint failure. >> Yes! >>> >>> >>> I will get that fixed either tonight or tomorrow. >> N.B.: You can fix the bug with just one line change: >> TransactionImpl.java line 84: >> < throw new entityManager.convert( (HibernateException)e ); >> --- >> > wrappedException = entityManager.convert( (HibernateException)e ); >> >> I tested it and my test-suite works. >> >> I like to notice you another behaviour change problem between Hiberante 3.3 and 3.5: >> In class BeanValidationActivator version 3.5.beta3 on line 34 you set Environment.CHECK_NULLABILITY explicitly to "false" >> even if I not using any BeanValidation (mode is resulting ValidationMode.AUTO to me). >> This goes in contrast to CHECK_NULLABILITY api-documentations, which tells that is Defaults to true. >> >> /** >> * Enable nullability checking. >> * Raises an exception if a property marked as not-null is null. >> * Default to true. >> */ >> public static final String CHECK_NULLABILITY = "hibernate.check_nullability"; >> >> In poor words: users which migrate to Hiberante3.5 and don't use BeanValidation must now explicitely set >> hibernate.check_nullability=true >> in order to have the same behavior as before. >> >> best regards >> G.D. >> >

14 years, 3 months

1
0
0 / 0

Re: [hibernate-dev] hibernate-dev Digest, Vol 43, Issue 11

by Saad Rathore

Unsubscribe On Jan 14, 2010, at 10:27 AM, hibernate-dev-request(a)lists.jboss.org wrote: Send hibernate-dev mailing list submissions to hibernate-dev(a)lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/hibernate-dev or, via email, send a message with subject or body 'help' to hibernate-dev-request(a)lists.jboss.org You can reach the person managing the list at hibernate-dev-owner(a)lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of hibernate-dev digest..." Today's Topics: 1. Re: Weird backref issue within the AttributeFactory (Was Re: Some code questions) (Emmanuel Bernard) 2. Re: Weird backref issue within the AttributeFactory (Was Re: Some code questions) (Adam Warski) 3. Re: [hibernate-announce] Hibernate 3.5.0-Beta-3 release (Hardy Ferentschik) 4. Re: Solution for failing Isolated query cache tests in Hibernate trunk (Steve Ebersole) 5. Re: Weird backref issue within the AttributeFactory (Was Re: Some code questions) (Steve Ebersole) 6. Re: [hibernate-announce] Hibernate 3.5.0-Beta-3 release (Steve Ebersole) 7. Re: [hibernate-announce] Hibernate 3.5.0-Beta-3 release (Steve Ebersole) 8. 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended? (Guenther Demetz) 9. Re: [hibernate-announce] Hibernate 3.5.0-Beta-3 release (Chris Bredesen) 10. Re: Weird backref issue within the AttributeFactory (Was Re: Some code questions) (Emmanuel Bernard) 11. Re: 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended? (Emmanuel Bernard) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Jan 2010 13:57:40 +0100 From: Emmanuel Bernard <emmanuel(a)hibernate.org> Subject: Re: [hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions) To: Hardy Ferentschik <hibernate(a)ferentschik.de> Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org> Message-ID: <4813641E-9302-4F7A-85D8-B63135E71A54(a)hibernate.org> Content-Type: text/plain; charset=us-ascii Right, I tried to explain the failure in the first email. But AFAIK the bug has been there for a little while (ie before the work i've done in the last couple of days). On 14 janv. 2010, at 13:54, Hardy Ferentschik wrote: We disabled the test yesterday in order to do the release. It was failing in w/ and w/o a fix to Emmanuel's code. --Hardy On Thu, 14 Jan 2010 09:24:23 -0300, Adam Warski <adam(a)warski.org> wrote: Hello, Though it uncovered a weird problem. When I run the entire envers test suite, I pass with flags up. When I specifically run VersionsJoinTableRangeComponentNamingTest That's probably because the test is disabled in the suite :). ------------------------------ Message: 2 Date: Thu, 14 Jan 2010 14:04:07 +0100 From: Adam Warski <adam(a)warski.org> Subject: Re: [hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions) To: Emmanuel Bernard <emmanuel(a)hibernate.org> Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org> Message-ID: <BAD821FC-0A63-43F5-9699-F6D7B600BEC6(a)warski.org> Content-Type: text/plain; charset=us-ascii Hello, Right, I tried to explain the failure in the first email. But AFAIK the bug has been there for a little while (ie before the work i've done in the last couple of days). yes, it's there for at least two weeks. I mentioned it on IRC before but I guess it didn't draw any attention. I didn't create a JIRA issue as it's in the new metamodel stuff so I figured that you're actively working on it. But at least it serves as a good testcase for it :) -- Adam ------------------------------ Message: 3 Date: Thu, 14 Jan 2010 10:17:20 -0300 From: "Hardy Ferentschik" <hibernate(a)ferentschik.de> Subject: Re: [hibernate-dev] [hibernate-announce] Hibernate 3.5.0-Beta-3 release To: "Emmanuel Bernard" <emmanuel(a)hibernate.org>, "Steve Ebersole" <steve(a)hibernate.org> Cc: hibernate-dev(a)lists.jboss.org Message-ID: <op.u6ixu6b2qxbac6(a)aleppo.lan> Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes I think we could do the same with the version string as we do in Validator ( and maybe Search, not sure ). There we read the version string from the MANIFEST file. The nice things about this is that the version in the MANIFEST is dynamically created during the build. Generally there are quite a few things we can do in the build configuration for annotations and entitymanager. The plugin configuration should be better synced with the parent pom and there are quite a few obsolete docbook resources checked in. Maybe the whole docbook stuff should be moved into the documentation directory. I will try to sort a few of these things out for the next release. --Hardy On Thu, 14 Jan 2010 07:34:50 -0300, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote: Yeah! I've just noticed one glitch (except the NPE I managed to add ;) ). The Version numbers in the logs are not updated for annotations and entity manager. We should add them to the release procedure. Or simply remove them now that ANN and HEM are part of Core. The only drawback I see is that HEM runs before Core but I guess we could trigger the call to the static version display from HEM to Core. ------------------------------ Message: 4 Date: Thu, 14 Jan 2010 08:31:56 -0600 From: Steve Ebersole <steve(a)hibernate.org> Subject: Re: [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk To: Emmanuel Bernard <emmanuel(a)hibernate.org> Cc: hibernate-dev(a)lists.jboss.org, "JBoss.org development list" <jboss-development(a)lists.jboss.org> Message-ID: <1263479516.2706.444.camel(a)localhost.localdomain> Content-Type: text/plain Oddly it does that already. Its just that only Serailaizable.class is ever passed http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/o... This has to do with the "static" nature of the type system. On Thu, 2010-01-14 at 11:19 +0100, Emmanuel Bernard wrote: On 13 janv. 2010, at 19:10, Steve Ebersole wrote: So, getReturnedClass().getClassLoader() is not the answer here. There is the only answer unfortunately. Really you'd want the Class of the class implementing Serializable, but given how Hibernate's "type system" works currently, that's not an option. Well it could be an option if you do like Annotations does for EnumType and pass the returned class as a parameter of SerializableType but frankly that's a bit painful. -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org ------------------------------ Message: 5 Date: Thu, 14 Jan 2010 08:35:06 -0600 From: Steve Ebersole <steve(a)hibernate.org> Subject: Re: [hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions) To: Emmanuel Bernard <emmanuel(a)hibernate.org> Cc: hibernate-dev(a)lists.jboss.org Message-ID: <1263479706.2706.446.camel(a)localhost.localdomain> Content-Type: text/plain Ah, backrefs! Just disregarding them makes the most sense for sure from the JPA perspective since they are "virtual attributes" and solely a hibernate construct. On Thu, 2010-01-14 at 11:29 +0100, Emmanuel Bernard wrote: On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote: I have a couple of question regarding some recent code changes. The first one seems to be the cause of a test failure in VersionsJoinTableRangeComponentNamingTest (Envers). It actually causes a NullPointerException. Have a look at: http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main... Right, I fixed the problem, sorry about that. Though it uncovered a weird problem. When I run the entire envers test suite, I pass with flags up. When I specifically run VersionsJoinTableRangeComponentNamingTest I've got a java.lang.IllegalArgumentException: Cannot determine java-type from given member [null] at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:591) at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:671) at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:661) at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:542) at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:81) at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:177) at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66) at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:79) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:752) at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:94) at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:82) The member is null because the "property" has a backref getter and hence no member is returned by NORMAL_MEMBER_RESOLVER. I think we should ignore backref properties Does that make sense? If we agree, I will go and apply a fix. http://opensource.atlassian.com/projects/hibernate/browse/HHH-4797 Also have a look at http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main... You create a AssertionFailure, but then don't throw it? I guess this is just missing a 'throw' before the new. yep, fixed. -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org ------------------------------ Message: 6 Date: Thu, 14 Jan 2010 08:35:58 -0600 From: Steve Ebersole <steve(a)hibernate.org> Subject: Re: [hibernate-dev] [hibernate-announce] Hibernate 3.5.0-Beta-3 release To: Emmanuel Bernard <emmanuel(a)hibernate.org> Cc: hibernate-dev(a)lists.jboss.org Message-ID: <1263479758.2706.447.camel(a)localhost.localdomain> Content-Type: text/plain We should probably just remove them I think. Pretty annoying to see the same version output over and over and over. On Thu, 2010-01-14 at 11:34 +0100, Emmanuel Bernard wrote: Yeah! I've just noticed one glitch (except the NPE I managed to add ;) ). The Version numbers in the logs are not updated for annotations and entity manager. We should add them to the release procedure. Or simply remove them now that ANN and HEM are part of Core. The only drawback I see is that HEM runs before Core but I guess we could trigger the call to the static version display from HEM to Core. On 14 janv. 2010, at 06:28, Steve Ebersole wrote: JPA support is coming along nicely! See the highlights and links to all the goodies at http://in.relation.to/Bloggers/Hibernate350Beta3Release -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org _______________________________________________ hibernate-announce mailing list hibernate-announce(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-announce -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org ------------------------------ Message: 7 Date: Thu, 14 Jan 2010 08:41:51 -0600 From: Steve Ebersole <steve(a)hibernate.org> Subject: Re: [hibernate-dev] [hibernate-announce] Hibernate 3.5.0-Beta-3 release To: Hardy Ferentschik <hibernate(a)ferentschik.de> Cc: hibernate-dev(a)lists.jboss.org Message-ID: <1263480111.2706.453.camel(a)localhost.localdomain> Content-Type: text/plain On Thu, 2010-01-14 at 10:17 -0300, Hardy Ferentschik wrote: I think we could do the same with the version string as we do in Validator ( and maybe Search, not sure ). There we read the version string from the MANIFEST file. The nice things about this is that the version in the MANIFEST is dynamically created during the build. We do this with core as well in terms of dynamic. We use that bytecode injjection maven plugin i wrote. Generally there are quite a few things we can do in the build configuration for annotations and entitymanager. The plugin configuration should be better synced with the parent pom and there are quite a few obsolete docbook resources checked in. Maybe the whole docbook stuff should be moved into the documentation directory. We have this "unclean" problem even in core: http://fisheye.jboss.org/browse/Hibernate/core/trunk/documentation/manual... and others. I had just been waiting till we get around to actually concolidating all the docs to go through that all at once. Feel free to do it or piece of it now though. -- Steve Ebersole <steve(a)hibernate.org> Hibernate.org ------------------------------ Message: 8 Date: Thu, 14 Jan 2010 15:51:37 +0100 From: Guenther Demetz <guenther.demetz(a)wuerth-phoenix.com> Subject: [hibernate-dev] 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended? To: "hibernate-dev(a)lists.jboss.org" <hibernate-dev(a)lists.jboss.org> Message-ID: <4B4F2F79.7020109(a)wuerth-phoenix.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed -until 3.5.0-Beta-2 a ConstraintViolationException during commit caused an implicite rollback and the exception was wrapped into a javax.persistence.RollbackException -now with 3.5.0-Beta-3 the same ConstraintViolationException during commit is wrapped into a javax.persistence.PersistenceException without implicite rollback Is this a wanted behavior change? If yes, where it is documented? best regards G.D. ------------------------------ Message: 9 Date: Thu, 14 Jan 2010 09:57:58 -0500 From: Chris Bredesen <cbredesen(a)redhat.com> Subject: Re: [hibernate-dev] [hibernate-announce] Hibernate 3.5.0-Beta-3 release To: hibernate-dev(a)lists.jboss.org Message-ID: <4B4F30F6.6090301(a)redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/14/2010 05:34 AM, Emmanuel Bernard wrote: Or simply remove them now that ANN and HEM are part of Core. The only drawback I see is that HEM runs before Core but I guess we could trigger the call to the static version display from HEM to Core. They're still separate jars though, right? If so, I'd prefer to leave the version info there so that we can rule out mismatched distros by looking at logging. -CB ------------------------------ Message: 10 Date: Thu, 14 Jan 2010 16:12:33 +0100 From: Emmanuel Bernard <emmanuel(a)hibernate.org> Subject: Re: [hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions) To: Steve Ebersole <steve(a)hibernate.org> Cc: hibernate-dev(a)lists.jboss.org Message-ID: <EE63F97C-172B-4EB3-9576-E19A4F74DCB8(a)hibernate.org> Content-Type: text/plain; charset=us-ascii On 14 janv. 2010, at 15:35, Steve Ebersole wrote: Ah, backrefs! Something you want to confess Steve? ;) ------------------------------ Message: 11 Date: Thu, 14 Jan 2010 16:26:55 +0100 From: Emmanuel Bernard <emmanuel(a)hibernate.org> Subject: Re: [hibernate-dev] 3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended? To: Guenther Demetz <guenther.demetz(a)wuerth-phoenix.com> Cc: "hibernate-dev(a)lists.jboss.org" <hibernate-dev(a)lists.jboss.org> Message-ID: <1BA17F7B-A55E-4440-A831-BE326263D01F(a)hibernate.org> Content-Type: text/plain; charset=us-ascii Hello, I cannot reproduce what you are describing. Here are the two tests I have on the subject. http://fisheye.jboss.org/browse/Hibernate/core/trunk/entitymanager/src/te... How is your configuration different? On 14 janv. 2010, at 15:51, Guenther Demetz wrote: -until 3.5.0-Beta-2 a ConstraintViolationException during commit caused an implicite rollback and the exception was wrapped into a javax.persistence.RollbackException -now with 3.5.0-Beta-3 the same ConstraintViolationException during commit is wrapped into a javax.persistence.PersistenceException without implicite rollback Is this a wanted behavior change? If yes, where it is documented? best regards G.D. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ------------------------------ _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev End of hibernate-dev Digest, Vol 43, Issue 11 *********************************************

14 years, 3 months

1
0
0 / 0

Solution for failing Isolated query cache tests in Hibernate trunk

by Galder Zamarreno

Hi all, In Hibernate trunk, the following tests are failing: In JBC 2LC provider: MVCCIsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion MVCCIsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache In Infinispan 2LC provider: IsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion IsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache They're failing because AccountHolder is being loaded with the system classloader rather than the SelectedClassnameClassLoader. The reason for this is that as a result of http://opensource.atlassian.com/projects/hibernate/browse/HHH-2990, SerializationHelper.CustomObjectInputStream now takes the classloader in the constructor. And during the test, SerializableType.fromBytes passes null as classloader to this constructor. The null comes from getReturnedClass().getClassLoader() below, which has been added as a result of 2990. private Object fromBytes(byte[] bytes) throws SerializationException { return SerializationHelper.deserialize( bytes, getReturnedClass().getClassLoader() ); } Now, shouldn't we use Thread.currentThread().getContextClassLoader() instead of getReturnedClass().getClassLoader()? Previously, that's what would have happened. I dunno why getReturnedClass().getClassLoader() was added though. I've just tested using Thread.currentThread().getContextClassLoader() change and the tests pass now. Steve? Cheers,

14 years, 3 months

4
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-dev January 2010