[Hibernate-JIRA] Created: (ANN-612) JavaReflectionManager fails with generic types like MyGenericType<Object[]>
by Aleksei Valikov (JIRA)
JavaReflectionManager fails with generic types like MyGenericType<Object[]>
---------------------------------------------------------------------------
Key: ANN-612
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-612
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: I'm using the latest versions:
Hibernate 3.2.4.ga
Hibernate Entity Manager 3.3.1.ga
Hibernate Commons Annotations 3.0.0.ga
Hibernate Validator 3.0.0.ga
JBoss Archive Browsing 2.0.2.alpha
Reporter: Aleksei Valikov
Attachments: C.java
I have a property of generic type with an array parameter like this one:
public static class J<T> {}
private J<Object[]> e;
@Transient
public J<Object[]> getE() {
return e;
}
public void setE(J<Object[]> e) {
this.e = e;
}
When starting the entity manager, I get the following exception:
javax.persistence.PersistenceException: java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:258)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:120)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at org.jvnet.hyperjaxb3.ejb.test.AbstractEntityManagerTest.createEntityManagerFactory(AbstractEntityManagerTest.java:85)
at org.jvnet.hyperjaxb3.ejb.test.AbstractEntityManagerTest.setUp(AbstractEntityManagerTest.java:44)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.toXType(JavaReflectionManager.java:164)
at org.hibernate.annotations.common.reflection.java.JavaXProperty.create(JavaXProperty.java:20)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.getXProperty(JavaReflectionManager.java:117)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:91)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:984)
at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:833)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:645)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1269)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:150)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:888)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:186)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:246)
... 17 more
The following property makes no problem:
private J<Object> f;
@Transient
public J<Object> getF() {
return f;
}
public void setF(J<Object> f) {
this.f = f;
}
So I believe it's the arrayd type which is problematic.
>From the stack trace, I believe the problem is with hibernate-commons-annotations.
I also attach the class that reproduces the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Commented: (HHH-1961) Schema validation fails with floating point column in Oracle 10g
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961?page=c... ]
Max Rydahl Andersen commented on HHH-1961:
------------------------------------------
the hibernate core dialect doesn't control the reverse engineering. BINARY_DOUBLE is also an oracle specific type and hence can't be done through the jdbc metadata that just returns a value for javax.sql.Types.
current workaround is to add a type-mapping in a reveng.xml file.
> Schema validation fails with floating point column in Oracle 10g
> ----------------------------------------------------------------
>
> Key: HHH-1961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.2.0.cr2
> Environment: 3.2 CR 2, Oracle 10g express edition release 2, Windows XP service pack 2, JDK 1.5.0_06
> Reporter: Daniel Dyer
>
> I have a table (created automatically by Hibernate) for mapping a double field. The table creation from Ant works fine but when starting up JBoss with the hibernate.hbm2ddl.auto property set to validate, I get the following exception:
> Caused by: org.hibernate.HibernateException: Wrong column type: percentage, expected: double precision
> at org.hibernate.mapping.Table.validateColumns(Table.java:219)
> at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:965)
> at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:414)
> at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:575)
> at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:245)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:108)
> at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:260)
> ... 127 more
> Doing a "desc" on the table reveals that the column is of type FLOAT with a length of 22.
> I think this may be related to issue HHH-1566 or HHH-1008.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Commented: (HHH-1961) Schema validation fails with floating point column in Oracle 10g
by Anthony Whitford (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961?page=c... ]
Anthony Whitford commented on HHH-1961:
---------------------------------------
I think I came across another reason why we need an Oracle 10 Dialect... BINARY_DOUBLE is reverse engineered to a "Serializable" instead of a double. Ugh!
(I think there should be a TYPES.FLOAT -> "binary_float" column type too.)
> Schema validation fails with floating point column in Oracle 10g
> ----------------------------------------------------------------
>
> Key: HHH-1961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.2.0.cr2
> Environment: 3.2 CR 2, Oracle 10g express edition release 2, Windows XP service pack 2, JDK 1.5.0_06
> Reporter: Daniel Dyer
>
> I have a table (created automatically by Hibernate) for mapping a double field. The table creation from Ant works fine but when starting up JBoss with the hibernate.hbm2ddl.auto property set to validate, I get the following exception:
> Caused by: org.hibernate.HibernateException: Wrong column type: percentage, expected: double precision
> at org.hibernate.mapping.Table.validateColumns(Table.java:219)
> at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:965)
> at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:414)
> at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:575)
> at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:245)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:108)
> at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:260)
> ... 127 more
> Doing a "desc" on the table reveals that the column is of type FLOAT with a length of 22.
> I think this may be related to issue HHH-1566 or HHH-1008.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Created: (HHH-2630) Hibernate Dialect is not auto-detected for Sybase ASE and DB2
by Emmanuel Bernard (JIRA)
Hibernate Dialect is not auto-detected for Sybase ASE and DB2
-------------------------------------------------------------
Key: HHH-2630
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2630
Project: Hibernate3
Issue Type: Improvement
Components: metamodel
Affects Versions: 3.2.4.sp1
Reporter: Emmanuel Bernard
Assignee: Emmanuel Bernard
The hibernate auto-detection mechanism was tested with the following Databases. DB2 and Sybase ASE - are not automatically detected.
DB2 v8.0:
javax.persistence.PersistenceException: org.hibernate.HibernateException: Hibernate Dialect must be explicitly set for database: DB2/LINUX
NOTE: looks like it will be auto-detected for DB2/NT
Sybase ASE 12.5:
[SettingsFactory] RDBMS: Adaptive Server Enterprise, version: Adaptive Server Enterprise/12.5.3/EBF 13332 ESD#7/P/Linux
Intel/Enterprise Linux/ase1253/1951/32-bit/OPT/Fri Mar 24 00:40:52 2006
16:52:09,234 INFO [SettingsFactory] JDBC driver: jConnect (TM) for JDBC (TM), version: jConnect (TM) for JDBC(TM)/5.5(Build 25827)/P/EBF13045/JDK13/Mon Oct 3 7:31:59 2005
javax.persistence.PersistenceException: org.hibernate.HibernateException:
Hibernate Dialect must be explicitly set for database: Adaptive Server Enterprise
The following were auto-detected:
Oracle 9i:
OLAP and Oracle Data Mining options JServer Release 9.2.0.1.0 - Production
[SettingsFactory] JDBC driver: Oracle JDBC driver, version: 10.1.0.3.0
[Dialect] Using dialect: org.hibernate.dialect.Oracle9Dialect
Oracle 10g:
[org.hibernate.cfg.SettingsFactory] RDBMS: Oracle, version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 -
Production
[org.hibernate.cfg.SettingsFactory] JDBC driver: Oracle JDBC driver, version: 10.1.0.3.0
[org.hibernate.dialect.Dialect] Using dialect: org.hibernate.dialect.Oracle9Dialect
MsSQLServer 2005:
[org.hibernate.cfg.SettingsFactory] RDBMS: Microsoft SQL Server, version:9.00.2047
14:25:23,808 INFO [SettingsFactory] JDBC driver: Microsoft SQL Server 2005
JDBC Driver, version: 1.1.1501.101
[Dialect] Using dialect: org.hibernate.dialect.SQLServerDialect
PostgresSQL 8.1:
[SettingsFactory] RDBMS: PostgreSQL, version: 8.2.3
[SettingsFactory] JDBC driver: PostgreSQL Native Driver,version: PostgreSQL 8.2 JDBC3 with SSL (build 504)
[Dialect] Using dialect: org.hibernate.dialect.PostgreSQLDialect
MySQL 5.0:
SettingsFactory] RDBMS: MySQL, version:5.0.27-standard-log
[SettingsFactory] JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.0.4 ( $Date: 2006-10-19 17:47:48 +0200 (Thu,
19 Oct 2006) $, $Revision: 5908 $ )
[Dialect] Using dialect: org.hibernate.dialect.MySQLDialect
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Resolved: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=c... ]
Steve Ebersole resolved HHH-1569.
---------------------------------
Resolution: Fixed
trunk / 3.2
> Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
> -------------------------------------------------------------------------
>
> Key: HHH-1569
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.2
> Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases
> Reporter: Tom Dunstan
> Assignee: Steve Ebersole
> Priority: Minor
> Fix For: 3.2.5, 3.3
>
> Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip, ImmutableNaturalId-hibernate3.2.2.patch
>
>
> It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug. It added the following lines:
> if ( loaded == null ) {
> loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister );
> }
> Further down, loaded is used thusly:
> int prop = props[i];
> if ( !updateable[prop] ) {
> if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) {
> throw new HibernateException(
> Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays.
> I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable.
> Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used.
> (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Commented: (HHH-663) Enabling filters for get(), load(), ... - please reopen HHH-67
by Eric Rizzo (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-663?page=co... ]
Eric Rizzo commented on HHH-663:
--------------------------------
If the feature won't be implemented, at least the documentation should be updated to eliminate confusion. Chapter 12.3 of the book explains the design intent clearly but chapter 17 of the reference manual makes it seem that filters apply across the entire entity.
Please re-open this as a request to clarify the documentation.
> Enabling filters for get(), load(), ... - please reopen HHH-67
> --------------------------------------------------------------
>
> Key: HHH-663
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-663
> Project: Hibernate3
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.0.5
> Reporter: Michael Wyraz
>
> Hibernate filters apply only to queries, not to load/get by id. This was also postet as bug HHH-67. This bug was rejected with the reason "This is by intent and thus not a bug."
> The Hibernate documentation says for Filters: "Filters can be used like database views, but parameterized inside the application.". The filter is attached to a class or a collection.
> So in my oppinion there's no reason _not_ to use filters with get() or load(). In fact, that's what users expect after reading the documentation.
> So the current behaviour is a bug. Either in hibernate or in the documentation.
> Michael.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-33) batch_size to prevent OutOfMemoryException while inserting many objects
by Stefan (JIRA)
batch_size to prevent OutOfMemoryException while inserting many objects
-----------------------------------------------------------------------
Key: HSEARCH-33
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-33
Project: Hibernate Search
Type: New Feature
Components: engine
Versions: 3.0.0.beta1
Reporter: Stefan
While inserting many objects in a batch the application runs out of memory because the FullTextIndexEventListener for Lucene collects the updates.
This is a tough problem. Today the solution is to apply the work in n transactions rather than 1. Maybe the notion of batch_size at some point to force a "flush" when the queue goes up can help. But it sacrifices the transactional semantic.
hibernate.cfg.xml
<event type="post-insert">
<listener class="org.hibernate.search.event.FullTextIndexEventListener"/>
</event>
Inserting code something like:
Session session = sessionFactory.openSession();
session.setCacheMode(CacheMode.IGNORE);
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Item item = new Item(...);
session.save(item);
if ( i % 100 == 0 ) {
session.flush();
session.clear();
}
}
tx.commit();
session.close();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Commented: (HHH-1961) Schema validation fails with floating point column in Oracle 10g
by Anthony Whitford (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961?page=c... ]
Anthony Whitford commented on HHH-1961:
---------------------------------------
I agree with the Oracle 10 Dialect apprach... This is killing me too, and the type mapping to binary_double should do the trick.
> Schema validation fails with floating point column in Oracle 10g
> ----------------------------------------------------------------
>
> Key: HHH-1961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.2.0.cr2
> Environment: 3.2 CR 2, Oracle 10g express edition release 2, Windows XP service pack 2, JDK 1.5.0_06
> Reporter: Daniel Dyer
>
> I have a table (created automatically by Hibernate) for mapping a double field. The table creation from Ant works fine but when starting up JBoss with the hibernate.hbm2ddl.auto property set to validate, I get the following exception:
> Caused by: org.hibernate.HibernateException: Wrong column type: percentage, expected: double precision
> at org.hibernate.mapping.Table.validateColumns(Table.java:219)
> at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:965)
> at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:414)
> at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:575)
> at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:245)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:108)
> at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:260)
> ... 127 more
> Doing a "desc" on the table reveals that the column is of type FLOAT with a length of 22.
> I think this may be related to issue HHH-1566 or HHH-1008.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[Hibernate-JIRA] Created: (ANN-495) Provide access to IndexWriter.optimize()
by Emmanuel Bernard (JIRA)
Provide access to IndexWriter.optimize()
----------------------------------------
Key: ANN-495
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-495
Project: Hibernate Annotations
Type: New Feature
Components: lucene
Reporter: Emmanuel Bernard
Fix For: 3.3.0.Alpha1
The problem is not solved "automatically" yet. But here is the reason why.
First of all, the elements are properly deleted, and the index file reflect that as soon as IndexReader.close() is called (which is done by Hibernate Search). However, the files containing the document data are not cleaned.
Basically, to physically delete the elements, you need to optimize() your index, this operation typically takes more time and doing it for every single delete is not appropriate.
I see 4 solutions:
1. let the user access the Directory and call the indexWriter.optimize() method. It works today but it sucks.
2. add an FullTextSession.optimize(Class) method, and the application is responsible for the method trigger. This is the easy solution but put more work on the user. And I'm not happy to push a maintenance API to the Session. Esp since this is more of a SessionFactory like API.
2bis. publish this API through JMX
3. optimize every N operations. It is trivial to add a counter per DirectoryProvider and trigger the optimization. N should be customizable
4. optimize every N seconds. either by setting a timer in an additional thread or wait for the next operation and compare the timestamp
2(bis or not) and 3 are my favorites. It's really 2 or 3 hours of work. If someone is interested, ping me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 11 months