[Hibernate-JIRA] Created: (HHH-5142) Exception when initializing lazy @ManyToMany indexed collection containing not audited entities
by Vladimir Klyushnikov (JIRA)
Exception when initializing lazy @ManyToMany indexed collection containing not audited entities
-----------------------------------------------------------------------------------------------
Key: HHH-5142
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5142
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.1
Environment: Hibernate Core 3.5.1
Reporter: Vladimir Klyushnikov
Priority: Blocker
Attachments: testcase.zip
Hi,
I am getting exception when executing following code:
{code}
@Entity
@Audited
public class M2MIndexedListEntity {
...
@ManyToMany(cascade = CascadeType.ALL)
@OrderColumn(name="sortOrder")
@Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)
private List<NotAuditedEntity> list = new ArrayList<NotAuditedEntity>();
}
@Entity
public class NotAuditedEntity {
...
}
...
M2MIndexedListEntity entity = (M2MIndexedListEntity) auditReader.createQuery()
.forRevisionsOfEntity(M2MIndexedListEntity.class, true, false)
.getSingleResult();
assertEquals(1,entity.getList().size());
{code}
Stack trace is the following:
{code}
java.lang.ClassCastException: testapp.NotAuditedEntity cannot be cast to java.util.Map
at org.hibernate.envers.entities.mapper.relation.lazy.initializor.ListCollectionInitializor.addToCollection(ListCollectionInitializor.java:67)
at org.hibernate.envers.entities.mapper.relation.lazy.initializor.ListCollectionInitializor.addToCollection(ListCollectionInitializor.java:39)
at org.hibernate.envers.entities.mapper.relation.lazy.initializor.AbstractCollectionInitializor.initialize(AbstractCollectionInitializor.java:67)
at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.checkInit(CollectionProxy.java:50)
at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.size(CollectionProxy.java:55)
{code}
I've attached a full test case. Unzip it, run *mvn test* and see test failing
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-3334) Cascading breaks if parent table doesn't have Auto-inc
by Wallace Wadge (JIRA)
Cascading breaks if parent table doesn't have Auto-inc
------------------------------------------------------
Key: HHH-3334
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3334
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1
Environment: tested on MySql, and hibernate versions (with annotations) v3.2.4 to 3.3.0CR1
Reporter: Wallace Wadge
(reposting here from forum)
Consider:
- a table with an assigned PK (i.e. not auto-increment), let's call this "A"
- Another table ("B") linked to the table listed above but with it's PK set to auto-increment.
Now if you try to save B with cascading switched on, it will break. From the little debugging I've done it looks like:
a) hibernate detects that A needs to be saved first, but puts it into some sort of queue.
b) when it hits B, it short-circuits this save queue and tries to save B immediately so as to obtain a PK reference for B. This fails since A hasn't been yet been saved so it's link is still null.
Schema used is listed below (MySQL):
----
CREATE DATABASE `jira` /*!40100 DEFAULT CHARACTER SET latin1 */;
DROP TABLE IF EXISTS `jira`.`parent`;
CREATE TABLE `jira`.`parent` (
`parent_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS `jira`.`child`;
CREATE TABLE `jira`.`child` (
`child_id` int(10) unsigned NOT NULL auto_increment,
`parent_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`child_id`),
KEY `FK_child_1` (`parent_id`),
CONSTRAINT `FK_child_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-5048) @Type ignored by envers?, whole transaction rollbacked, but applcation continues, without warning
by Donovan (JIRA)
@Type ignored by envers?,whole transaction rollbacked, but applcation continues, without warning
------------------------------------------------------------------------------------------------
Key: HHH-5048
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5048
Project: Hibernate Core
Issue Type: Bug
Components: envers
Reporter: Donovan
Priority: Blocker
Attachments: EuroTypeTest_for_envers.patch
Following problem occurs when i audited my entity with a custom type:
Testcase included, as a svn-patch on the current envers - trunk.
Envers does not use my @Type to save the revision, because it is not a org.hibernate.usertype.UserType, but a extension of org.hibernate.type.DoubleType.
This give me a readable exception, i can live with that, but still a bug. Implementing my EuroType as a org.hibernate.usertype.UserType resolves my immediate problem.
The worst is that a exception is thrown, transaction is rollbacked, but the exception does not reach my application.
As in the testcase, the problem is detected(too late) by query on the entity and you get NULL;
Thats why i gave it the prio blocker.
Adding @NotAudited on "Euro component" gives you a green test, Envers SHOULD NOT influent this, or at least throw a exception, so i get notified that my entity is not saved or created.
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (BVAL-207) Hibernate 3.5.1-Final cannot parse order-by fragment
by Vladimir Kobetic (JIRA)
Hibernate 3.5.1-Final cannot parse order-by fragment
----------------------------------------------------
Key: BVAL-207
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-207
Project: Bean Validation
Issue Type: Bug
Environment: Hibernate 3.5.1-Final
MySQL 5.0
Spring 2.5
Reporter: Vladimir Kobetic
Priority: Critical
When upgrading from Hibernate 3.2.5.ga to the newest Hibernate 3.5.1-Final with the newest build-with dependent libraries an error occurs during initial phase of launching application.
I tried to build and run with all libraries from lib directory from Hibernate zip download.
The order-by clause is configured in hbm.xml:
<hibernate-mapping>
<class name="com.test.Object" table="err">
<id name="id" type="java.lang.Long">
<generator class="native" />
</id>
<set name="history" table="history" lazy="true" order-by="timestamp desc" cascade="all-delete-orphan">
<key column="object_id" />
<one-to-many class="com.test.Event" />
</set>
</class>
</hibernate-mapping>
The exception is:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [applicationContext-dao-hibernate.xml]: Invocation of init method failed; nested exception is org.hibernate.HibernateException: Unable to parse order-by fragment
Caused by: org.hibernate.HibernateException: Unable to parse order-by fragment
at org.hibernate.sql.ordering.antlr.OrderByFragmentTranslator.render(OrderByFragmentTranslator.java:66)
at org.hibernate.sql.Template.renderOrderByStringTemplate(Template.java:310)
at org.hibernate.persister.collection.AbstractCollectionPersister.<init>(AbstractCollectionPersister.java:557)
at org.hibernate.persister.collection.OneToManyPersister.<init>(OneToManyPersister.java:84)
at org.hibernate.persister.PersisterFactory.createCollectionPersister(PersisterFactory.java:104)
and more...
Caused by: java.lang.NullPointerException
at org.hibernate.sql.ordering.antlr.OrderByFragmentParser.resolveFunction(OrderByFragmentParser.java:115)
at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.expression(GeneratedOrderByFragmentParser.java:619)
at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.sortKey(GeneratedOrderByFragmentParser.java:337)
at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.sortSpecification(GeneratedOrderByFragmentParser.java:248)
at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.orderByFragment(GeneratedOrderByFragmentParser.java:192)
at org.hibernate.sql.ordering.antlr.OrderByFragmentTranslator.render(OrderByFragmentTranslator.java:60)
... 38 more
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-4441) SessionImpl serialization violates java serialization spec
by Paul Ferraro (JIRA)
SessionImpl serialization violates java serialization spec
----------------------------------------------------------
Key: HHH-4441
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4441
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0.Beta-1, 3.3.2
Reporter: Paul Ferraro
Attachments: patch.txt
The private serialization methods of org.hibernate.impl.SessionImpl must call default[Read|Write]Object() on the object input/output stream before any custom de/serialization logic.
According to the Java serialization spec:
http://java.sun.com/javase/6/docs/platform/serialization/spec/output.html...
"The class's writeObject method, if implemented, is responsible for saving the state of the class. Either ObjectOutputStream's defaultWriteObject or writeFields method must be called once (and only once) before writing any optional data that will be needed by the corresponding readObject method to restore the state of the object; even if no optional data is written, defaultWriteObject or writeFields must still be invoked once. If defaultWriteObject or writeFields is not invoked once prior to the writing of optional data (if any), then the behavior of instance deserialization is undefined in cases where the ObjectInputStream cannot resolve the class which defined the writeObject method in question."
http://java.sun.com/javase/6/docs/platform/serialization/spec/input.html#...
"The readObject method of the class, if implemented, is responsible for restoring the state of the class. The values of every field of the object whether transient or not, static or not are set to the default value for the fields type. Either ObjectInputStream's defaultReadObject or readFields method must be called once (and only once) before reading any optional data written by the corresponding writeObject method; even if no optional data is read, defaultReadObject or readFields must still be invoked once."
One consequence of this spec violation is that you cannot use JBoss Marshalling to serialize a session. For details, see:
https://jira.jboss.org/jira/browse/JBMAR-67
Patch attached.
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-4443) Allow generic handling of any Hibernate type for post-insert generated identifiers
by Steve Ebersole (JIRA)
Allow generic handling of any Hibernate type for post-insert generated identifiers
----------------------------------------------------------------------------------
Key: HHH-4443
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4443
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.5
See HB-92 for the original request. Much of the discussion unfortunately occurred in a private email thread with the original requester, but here is the proposed solution:
Steve Ebersole <steve(a)hibernate.org> wrote:
The "more correct" solution is along the lines a contract to allow the
type to handle this like you said. I'm thinking something like an
optional interface for the type to publish that fact:
public interface ResultSetIdentifierConsumer {
public Serializable consumeIdentifier(ResultSet resultSet);
}
then IdentifierGeneratorFactory (called IdentifierGeneratorHelper now
btw) can say:
public static Serializable get(ResultSet rs, Type type) ... {
if ( type instanceof ResultSetIdentifierConsumer ) {
return ( ( ResultSetIdentifierConsumer ) type ).consumeIdentifier( rs );
}
Class clazz = type.getReturnedClass();
if ( clazz == Long.class ) {
return new Long( rs.getLong( 1 ) );
}
else if ( clazz == Integer.class ) {
return new Integer( rs.getInt( 1 ) );
}
else if ( clazz == Short.class ) {
return new Short( rs.getShort( 1 ) );
}
else if ( clazz == String.class ) {
return rs.getString( 1 );
}
else {
throw ...
}
}
and you can define a type :
public class MyCustomLongIdType ... implements ResultSetIdentifierConsumer ... {
public Serializable consumeIdentifier(ResultSet resultSet) {
return new MyCustomLongId( resultSet.getLong( 1 ) );
}
...
}
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
by Stefan Hauk (JIRA)
ConcurrentModificationException in AbstractBatcher results in infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements() method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause. However, the iteration may continue infinitely because of the corrupted HashSet. This pegs one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly. Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using Hibernate in a correct way, but I haven't determined the cause for it yet. However, I do think that Hibernate should fail more gracefully than it currently does.
--
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
14 years, 1 month