upgrade to gradle 1.0-m9
by Strong Liu
I have pushed my changes [1]
some notes here:
* this upgrade does not resolve the GRADLE-2169 issue, my build still hangs (but with "-i" option, it disappears, needs to dig more )
* the gradle-jdocbook change doesn't compatible with previous gradle release (there is a gradle class renamed)
* I have to change manual's xml to use namespace instead of the old dtd, jdocbook plugin can't resolve those locally, that's why it takes so long to finish [2]
* I haven't created pull request yet, just want to hear feedback first
1. https://github.com/stliu/gradle-jdocbook/tree/upgrade-to-m9
https://github.com/stliu/hibernate-orm/tree/upgrade-to-m9
2.
time gradle :documentation:renderDocBook_manual_en-US_html
----------------------------------------------------------- (mac + m9)
Total time: 1 mins 43.315 secs
real 1m43.546s
user 1m14.794s
sys 0m2.919s
----------------------------------------------------------- (fedora + m8a)
Total time: 2 mins 33.44 secs
real 2m33.527s
user 1m1.912s
sys 0m1.590s
----------------------------------------------------------- (mac + m8a)
Total time: 3 mins 53.628 secs
real 3m53.798s
user 1m12.152s
sys 0m3.037s
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 11 months
multiple/single JGroups channels in Hibernate Search
by Sanne Grinovero
Context:
HSEARCH-1070 JGroups channels need to be shared across multiple backends
I think it makes sense for an Hibernate Search instance to share a
single JGroups channel across multiple backends; there are several
reasons for this:
- Not having to change configuration details such as different ports per index
- A Channel is expensive (slow) to start
- I would very likely want to configure it with a single channel.
- Sharing channels doesn't prevent us to have different backends,
with different masters on different nodes
My question is, should I still make sure we allow for multiple
different channels? Like configuring a different protocol stack /
network options per index?
I'm not liking that as it makes configuration quite complex and tricky
- especially worthless as I'm not seeing any practical use for it.
There is one (annoying) reason to allow that: backwards compatibility.
It seems since version 4.0 we're dealing with it as one channel per
index - but this wasn't really intended to work like that imho, I'm
considering this a bug rather than an API change, but making it unique
across indexes requires a configuration changes: configuration
property would not be "scoped" under the index name:
< hibernate.search.default.worker.backend.jgroups.configurationString
= "jgroups configuration"
> hibernate.search.services.jgroups.configurationString = "jgroups configuration"
thoughts?
Cheers,
Sanne
13 years, 11 months
Fwd: [Hibernate-JIRA] Created: (HHH-7187) envers tests fail on other DBs except the default H2
by Strong Liu
Hi Adam,
any comments?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
Begin forwarded message:
> From: "Strong Liu (JIRA)" <noreply(a)atlassian.com>
> Subject: [Hibernate-JIRA] Created: (HHH-7187) envers tests fail on other DBs except the default H2
> Date: March 20, 2012 2:23:50 AM GMT+08:00
> To: stliu(a)hibernate.org
>
> envers tests fail on other DBs except the default H2
> ----------------------------------------------------
>
> Key: HHH-7187
> URL: https://hibernate.onjira.com/browse/HHH-7187
> Project: Hibernate ORM
> Issue Type: Bug
> Components: envers
> Reporter: Strong Liu
> Fix For: 4.1.2
>
>
> due to the change of HHH-7185, there are some failing tests:
>
> {quote}
> All Failed Tests
>
> Test Name
> Duration
> Age
>>>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testTransactionRollback[0] 0.016 1
>>>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testDataNotPersisted[0] 0.084 1
>>>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testTransactionRollback[1] 0.01 1
>>>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testDataNotPersisted[1] 0.013 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.initData[0] 0.097 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory1[0] 0.0050 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory2[0] 0.0010 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testRevisionsCounts[0] 0.0020 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.initData[1] 0.115 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory1[1] 0.0010 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory2[1] 0.0010 1
>>>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testRevisionsCounts[1] 0.0 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId1[0] 0.048 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId2[0] 0.029 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testRevisionsCounts[0] 0.016 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId1[1] 0.041 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId2[1] 0.025 1
>>>> org.hibernate.envers.test.integration.naming.BasicNaming.testRevisionsCounts[1] 0.03 1
>>>> org.hibernate.envers.test.integration.naming.EstonianTableAlias.testAuditChildTableAlias[0] 0.033 1
>>>> org.hibernate.envers.test.integration.naming.EstonianTableAlias.testAuditChildTableAlias[1] 0.044 1
>>>> org.hibernate.envers.test.integration.naming.VersionsJoinTableNaming.testHistoryOfUniId1[0] 0.108 1
>>>> org.hibernate.envers.test.integration.naming.VersionsJoinTableNaming.testRevisionsCounts[0] 0.031 1
>>>> org.hibernate.envers.test.integration.readwriteexpression.ReadWriteExpressionChange.shouldRespectWriteExpression[0] 0.0030 1
>>>> org.hibernate.envers.test.integration.readwriteexpression.ReadWriteExpressionChange.shouldRespectWriteExpression[1] 0.0040 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testDatesForRevisions[0] 0.0090 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testFindRevision[0] 0.0050 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testRevisionsForDates[0] 0.012 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps[0] 0.0030 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps1[0] 0.0040 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testDatesForRevisions[1] 0.0070 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testFindRevision[1] 0.0040 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testRevisionsForDates[1] 0.027 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps[1] 0.014 1
>>>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps1[1] 0.015 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.initData[0] 0.0090 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testHistoryOfId1[0] 0.0010 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testRevisionsCounts[0] 0.0 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.initData[1] 0.0060 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testHistoryOfId1[1] 0.0090 1
>>>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testRevisionsCounts[1] 0.0 1
>>>> org.hibernate.envers.test.integration.strategy.ValidityAuditStrategyRevEndTsTest.testAllRevEndTimeStamps[0] 0.145 1
>>>> org.hibernate.envers.test.integration.strategy.ValidityAuditStrategyRevEndTsTest.testAllRevEndTimeStamps[1] 0.173 1
> {quote}
>
> this is caused by the _org.hibernate.envers.test.EnversTestingJtaBootstrap#updateConfigAndCreateTM_, this class updates the db connection url and appends a `;AUTOCOMMIT=OFF`, but this property is only valid on H2
>
> do tests using _org.hibernate.envers.test.EnversTestingJtaBootstrap_ are supposed only running on H2?
> if so, we need move those tests into _src/test/main_
>
> or we need to fix these tests
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
13 years, 11 months
HSEARCH and fix version as topic
by Emmanuel Bernard
Sanne has moved the spatial queries issues out of 4.1 (rightly so) but entirely cleared the version number even for issues already fixed.
I have created a temporary version `spatial` to carry issue fixed in the geo branch. We will merge this version with 4.2 or later if it really takes more time.
What do you think of these topic versions for big features / issues that are made of multiple issues and live in a topic branch for a while?
Emmanuel
13 years, 12 months
byteman
by Steve Ebersole
Having some problems getting the recently added byteman stuff to work in
terms of IntelliJ. Basically it comes down to I cannot find the byteman
jars anywhere. I run the compileTestJava task and see gradle/ivy
downloading the jars. But afterwards I cannot find them in
~/.gradle/cache. I also looked in ~/.m2/repository just to make sure,
but did not see them in there either. Thoughts?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 12 months
Proxies and typing
by Steve Ebersole
In regards to the new "load access", a user asked why we don't leverage
generics.
The problem is the existence of @Proxy#proxyClass. We have the same
issue with Session#load/get taking the entity Class. We can't use a
generic sig like:
public <T> T load(Class<T> entityType, ...)
because at times we return objects that are not typed to <T>. I have to
dive back into the specifics, but IIRC the problem is that we don't do
the expected thing and have the generated proxy class extend from the
entity class if @Proxy#proxyClass names an interface. I remember this
change way back when, but the specifics of why escape me at the moment.
IMO I think providing generic signatures would obviously be a great
improvement. Is it enough to change this behavior?
WDYT?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 12 months
OGM: MongoDB integration
by Sanne Grinovero
Hello all,
I'm satisfied with this structure as a good starting point; let's know
hack together from this reference; please discard the previous
branches.
git@github.com:hibernate/hibernate-ogm.git
branch: mongodb
There are some limitations, so I wasn't happy to integrate it in master yet.
The main problems are:
1# It's not passing all tests. This is my current output:
Tests run: 30, Failures: 0, Errors: 16, Skipped: 0
Simply put, the GridDialect is not complete as it's not implementing
all methods.
2# Even passing the tests, it requires a MongoDB instance to connect to.
Not sure yet how we're going to deal with this for continuous
integration.. I guess we need MongoDB installed on the Jenkins
machines, or use some external PAAS.
I've identified some other minor problems too: not all tests cleanup
properly - some of these failures appear to be induced by previous
failures, like uncommitted transactions still bound to the running
thread.
https://hibernate.onjira.com/browse/OGM-138
Last problem, since MongoDB actually remembers state between test runs
we need to make sure we cleanup stored data as well; I'll extend the
core module testsuite for this.
https://hibernate.onjira.com/browse/OGM-139
Regards,
Sanne
13 years, 12 months
[JPAModelgen] MixedConfigurationTest failing
by Guillaume Smet
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 SingularAttribute<ZeroCoordinates,
Float> longitude;
public static volatile SingularAttribute<ZeroCoordinates,
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
13 years, 12 months
