Need help to fix HHH-1570
by Julien HENRY
Hi Hibernate dev team,
I am working on a patch to fix HHH-1570. The patch is highly inspired from the
old patch attached to the JIRA issue with a few modifications. After applying my
patch the test case (see patch HHH-1570-it.patch attached to the issue) runs
fine but there is a regression on another test: FumTest.testKeyManyToOne()
Here is the error on the test:
testKeyManyToOne(org.hibernate.test.legacy.FumTest) Time elapsed: 0.61 sec <<<
ERROR!
org.hibernate.NonUniqueObjectException: a different object with the same
identifier value was already associated with the session:
[org.hibernate.test.legacy.Middle#org.hibernate.test.legacy.MiddleKey@57def1]
at
org.hibernate.engine.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:637)
at
org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:120)
at
org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:73)
at org.hibernate.impl.SessionImpl.fireDelete(SessionImpl.java:955)
at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:933)
at org.hibernate.test.legacy.FumTest.testKeyManyToOne(FumTest.java:677)
Can someone review my patch (attached) and help me to fix the regression as I
don't understand the error.
Thanks
Julien
15 years, 11 months
[HSEARCH] Error building trunk
by Gustavo Fernandes
Hello, I came across a problem when building the integration-test module:
[ERROR] BUILD ERROR
...
Reason: POM 'org.jboss.jbossas:jboss-as-component-matrix' not found in repository: Unable to download the artifact from any repository
---
It's because of the dependency org.jboss.jbossts:jbossjta:4.11.0.Final which in turn depends on org.jboss.jbossas:jboss-as-component-matrix using scope "import".
Any known work arounds for this bug [1] ?
[1] http://jira.codehaus.org/browse/MNG-3537
Thanks,
Gustavo
16 years
jDocBook help
by Emmanuel Bernard
Hi Steve and guys,
I am trying to release Hibernate Search following http://community.jboss.org/wiki/ContributingtoHibernateSearch#Releasing_H...
I can't seem to be able to create the documentation.
mvn javadoc:javadoc org.jboss.maven.plugins:maven-jdocbook-plugin:2.2.3:resources org.jboss.maven.plugins:maven-jdocbook-plugin:2.2.3:resources org.jboss.maven.plugins:maven-jdocbook-plugin:2.2.3:generate assembly:assembly
(I tried with 2.2.0, 2.2.1 and 2.3.0, same kind of result)
I receive
[INFO] One or more required plugin parameters are invalid/missing for 'jdocbook:resources'
[0] Inside the definition for plugin 'maven-jdocbook-plugin' specify the following:
<configuration>
...
<formats>VALUE</formats>
</configuration>.
[1] Inside the definition for plugin 'maven-jdocbook-plugin' specify the following:
<configuration>
...
<sourceDocumentName>VALUE</sourceDocumentName>
</configuration>.
What can I do to get the documentation built?
Emmanuel
16 years
[HSEARCH] Maintenance version 3.2.1
by Emmanuel Bernard
Since 3.3 is not out yet (likely an end of summer target), I'm thinking on releasing a maintenance version of the 3.2 series.
HSEARCH-540 is a pretty nasty bug (due to lack of Synchronization execution ordering - see Re: [hibernate-dev] Exceptions thrown in a tx synchronization are eaten by Steve on July 14th).
Any other bug you think cannot wait and should be back-ported?
16 years
HSEARCH 3.3 alpha / M1
by Emmanuel Bernard
Hey guys,
The folks at Infinispan want us to cut a release of Hibernate Search.
We have a couple of choice:
- say no but that's not really being team players ;)
- cut an alpha release and not advertise it
- cut a release and advertise it
- cut a milestone 1 and advertise it
The code is stable (bug-wise): I'm not concerned about bugs very much but the release lacks a couple of things:
- some of the SearchFactory API changes I have done are not dry yet and will possibly change
- there is no documentation on the new stuffs (DSL, new (im)mutable API
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-563
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-564
I'm leaning towards the alpha release to get the code to the Infinispan team right away but we should do a beta release quite soon afterwards with HSEARCH-563 and HSEARCH-564 resolved.
WDYT?
PS: I should be the one documenting these changes but if anybody has time to take that off me, that would be cool as I am on the critical path here.
16 years
HHH-5375 - Move AnnotationConfiguration-added methods to Configuration and deprecate AnnotationConfiguration
by Steve Ebersole
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5375
In attempting this I ran into the difference between Configuration and
AnnotationConfiguration of processing mapping files (hbm.xml).
Configuration tries to process these immediately, whereas
AnnotationConfiguration delays that attempt. So merging these 2 would
require changing the behavior in Configuration to delay attempts to
process/bind hbm.xml files to match what is done in
AnnotationConfiguration.
What's the ramification?
Well previously Configuration would allow a developer to do, as an
example, stuff like:
Configuation cfg = ...;
cfg.setProperty( "hibernate.default_schema", "ABC" );
cfg.addResource( "SomeEntity.hbm.xml" );
cfg.setProperty( "hibernate.default_schema", "XYZ" );
cfg.addResource( "AnotherEntity.hbm.xml" );
When "SomeEntity.hbm.xml" gets processed, the default schema in effect
is "ABC"; when "AnotherEntity.hbm.xml" gets processed, it is "XYZ". Now
this has never been explicitly supported, but it is a side effect of the
lack of a "lifecycle" to how configurations are built (this will be
addresses in 4.x).
Now I am pretty sure we have consistently said that the above is not
supported and that user should not expect the "added" metadata to be
available until after buildMappings() has been called. In fact, what
those calls should look like would be:
Configuation cfg = ...;
cfg.setProperty( "hibernate.default_schema", "ABC" );
cfg.addResource( "SomeEntity.hbm.xml" );
cfg.buildMappings();
cfg.setProperty( "hibernate.default_schema", "XYZ" );
cfg.addResource( "AnotherEntity.hbm.xml" );
cfg.buildMappings();
which has the same effect today as the code above, and will continue to
have the same effect moving forward even if we have Configuation delay
the processing/binding.
So I'd like to get input on whether we make this change today (for 3.6)
and merge Configuration+AnnotationConfiguation into a single class[1],
or if we push this back until 4.x when we begin the rest of the
configuration changes.
[1] Really the intent is move methods/fields from AnnotationConfiguation
up to Configuation and deprecate AnnotationConfiguation. That way
existing code can, for s short time, continue to use
AnnotationConfiguration without change.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
16 years
