April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3112) Upgrade EhCache dependancy to 1.2.4+

by Stevo Slavic (JIRA)

Upgrade EhCache dependancy to 1.2.4+ ------------------------------------ Key: HHH-3112 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3112 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.2.5 Reporter: Stevo Slavic Priority: Trivial Hibernate is widely used in conjunction with Spring framework. Spring framework as of version 2.0 expects EhCache to be 1.2.4+. When using both EhCache 1.2.4+ and Hibernate 3.2.5.ga as dependency in same maven project but in different sub-projects, older EhCache 1.2.3 (current Hibernate 3.2.5.ga dependency) can overwrite dependency application has for newer EhCache ( http://forum.springframework.org/showthread.php?t=49956 ). If Hibernate would use 1.2.4+ EhCache there would be no need to specify separate EhCache dependency. -- 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, 12 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4630) Criteria join on composite identifier generates wrong alias, SQL error

by Chris Wilson (JIRA)

Criteria join on composite identifier generates wrong alias, SQL error ---------------------------------------------------------------------- Key: HHH-4630 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4630 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: Hibernate trunk from 2009-11-30, Ubuntu 8.04, Sun Java 1.6.0-17, MySQL 5.0.51a-3ubuntu5.4 Reporter: Chris Wilson Attachments: hibernate-invalid-alias-generation.patch Hibernate generates the wrong alias on a Criteria query involving a join on a composite identifier. For example, in the test below without the fix to JoinWalker, it generates this SQL: select this_.role_code as role1_0_1_, this_.is_deleted as is2_0_1_, this_.record_version as record3_0_1_, complexjoi3_.code as code1_0_, complexjoi3_.is_deleted as is2_1_0_, complexjoi3_.record_version as record3_1_0_ from list_action_roles this_ left outer join roles complexjoi3_ on this_.role_code=complexjoi3_.code where this_.is_deleted=? and complexjoi1_.is_deleted=? Which results in this error from the SQL server: Unknown column 'complexjoi1_.is_deleted' in 'where clause' Analysis of the problem: The entity persister class with the composite identifier has a fake property for it, called "_identifierMapper" (see HbmBinder.bindCompositeId() and similarly in Annotations). This property name ends up in the path used by JoinWalker.walkEntityTree() when it calls walkComponentTree(). However that path is used by CriteriaJoinWalker.generateTableAlias() to look up the correct criteria (and hence the alias) from the translator, a CriteriaQueryTranslator. The alias was created in CriteriaQueryTranslator.createCriteriaSQLAliasMap for a Criteria without this extra _identifierMapper path component. So when CriteriaJoinWalker tries to use the path with _identifierMapper to look up the criteria to find the correct alias to use, in generateTableAlias(), it doesn't find one, so it generates a new alias. That new alias no longer matches the one that will be rendered out in the WHERE clause, so the WHERE clause will refer to table names using aliases that are not used anywhere else in the query, and the SQL server will fail to parse the statement. The solution appears to be to exclude "_identifierMapper" components in the alias path when building it. I don't know what other implications that might have, but it seems like an implementation nastiness that shouldn't be exposed. 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

15 years

4
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-35) Look for log and exception strategy

by Emmanuel Bernard (JIRA)

Look for log and exception strategy ----------------------------------- Key: HSEARCH-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-35 Project: Hibernate Search Type: Task Components: mapping, query, engine, directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.beta2 -- 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

15 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-210) Support hbm xml mapping!

by Mark Stewart (JIRA)

Support hbm xml mapping! ------------------------ Key: HSEARCH-210 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-210 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 3.0.1.GA Environment: All. Reporter: Mark Stewart I like annotations as much as the next guy but it's a complete non-starter for our business (and, I suspect, plenty of others) to add full text search to our existing apps via Hibernate Search if it means we must convert all our existing hbm.xml configurations into annotations. The regression testing alone would kill us. The Hibernate project has always been supremely pragmatic which is why I've filed this as a bug rather than a feature request. I don't think Hibernate would have been half as popular if it didn't support things like direct SQL and reverse engineering tools. I think Search would see a big boost if it could be easily added to existing applications. Please consider adding the needed syntax for xml mapping. At the very least an entry in the FAQ that explains the lacking is needed. -- 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

15 years

6
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-373) @AnalyzerDiscriminator applied to _hibernate_class field

by Sanne Grinovero (JIRA)

@AnalyzerDiscriminator applied to _hibernate_class field -------------------------------------------------------- Key: HSEARCH-373 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-373 Project: Hibernate Search Issue Type: Bug Reporter: Sanne Grinovero It appears that implementations of org.hibernate.search.analyzer.Discriminator is also called to identify the Analyzer to be used to index the reserved "id" and "_hibernate_class". I'm not sure if it's a good idea on "id", it probably isn't at all on "_hibernate_class". -- 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

15 years

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-264) Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name)

by Emmanuel Bernard (JIRA)

Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name) -------------------------------------------------------------------------------------- Key: HSEARCH-264 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-264 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Probably more on Hibernate Tools. Would be nice to fix copy/paste bugs too. -- 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

15 years

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-777) Map key column is included in the PK but is not forced not-null

by Emmanuel Bernard (JIRA)

Map key column is included in the PK but is not forced not-null --------------------------------------------------------------- Key: ANN-777 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-777 Project: Hibernate Annotations Issue Type: Bug Components: binder Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik I think forcing not-null is the right approach. This needs some investigation though -- 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

15 years

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements

by Steve Finch (JIRA)

Include "FOR READ ONLY" hint in non-locking DB2 statements ---------------------------------------------------------- Key: HHH-3031 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Environment: 3.2.5, DB2/UDB 8.1+ Reporter: Steve Finch As per the DB2 documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i... The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning. For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements. A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY). The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified. Patch to be uploaded soon. -- 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

15 years

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4975) ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property

by Christian Fritschi (JIRA)

ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property ------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-4975 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4975 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.3.2 Environment: Hibernate version 3.3.2.GA, HSQLDB 1.8.0.10 Reporter: Christian Fritschi Priority: Critical Attachments: startTestDb.rar, ukMapping.rar, UkMappingTest.java Level 1 (superClass) ------- @MappedSuperclass public abstract class AbstractMasterUk ... @Id private int id; .... @Column(name="MASTER_ID", nullable = false, length=50) private String masterId; Level 2 (superClass) ------- @Entity @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @Table(name="MASTER_UK") @DiscriminatorColumn(name="DOMAIN", discriminatorType=DiscriminatorType.STRING) public class MasterUkBase extends AbstractMasterUk .... Parent-Class ------------ @Entity @org.hibernate.annotations.Entity(mutable = false) @DiscriminatorValue(MasterUk1.DOMAIN) public class MasterUk1 extends MasterUkBase ... Child-Class ----------- @Entity @Table(name="DETAIL_UK") public class DetailUk implements Serializable { @Id private int id; @ManyToOne(optional=false) @JoinColumn(name="MASTER", nullable=true, referencedColumnName="MASTER_ID") private MasterUk1 master; Result: org.hibernate.AnnotationException: referencedColumnNames(MASTER_ID) of annotations.playground.delta.ukMapping.DetailUk.master referencing annotations.playground.delta.ukMapping.MasterUk1 not mapped to a single property at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:180) at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:88) at org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456) at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1333) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867) ..... -- 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

15 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3495) CollectionAction instances can consume considerable memory in large transactions unnecessarily

by Tim Downey (JIRA)

CollectionAction instances can consume considerable memory in large transactions unnecessarily ---------------------------------------------------------------------------------------------- Key: HHH-3495 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3495 Project: Hibernate Core Issue Type: Improvement Reporter: Tim Downey Attachments: CollectionActionPatch.zip Hi, We're doing some fairly heavy duty batch processing using Hibernate 3.3.1. In doing so, we're basically paging over large chunks of entities where we flush and clear the session around pages. We do not commit between pages. We may be processing hundreds of thousands of entities over pages of ten to twenty thousand each. We're clearing the session around pages in attempt to free up memory that is no longer necessary. We have found that subtypes of CollectionAction get added to a list of Executable in the ActionQueue when there are collection changes processed. These CollectionActions are held until transaction complete and are not released on flush or clear of the session. Furthermore, the CollectionAction instances hold references to those collections that have changed even after the entities have been evicted from the session. In our case, this was causing Hibernation to hold on to several hundred MB of RAM until transaction commit. I've supplied a small patch that doesn't require the CollectionAction to hang on to the entities themselves until the transaction boundary. We're showing considerably improvement in memory utilization as a result. I'm hoping that you consider this patch for inclusion in a future release. The change was basically to change the ActionQueue's list of Executables used in after transaction completion, to a separate type, AfterTransactionCompletionExecutable. This new type allows some decoupling in the other subclasses of Executable to hold references to fewer resources and save considerable memory when the transaction sizes are quite large. Regards, Tim -- 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

15 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2169) L2 Cache and Long transactions Memory Leak : OutOfMemoryException

by Sami Dalouche (JIRA)

L2 Cache and Long transactions Memory Leak : OutOfMemoryException ----------------------------------------------------------------- Key: HHH-2169 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2169 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: [b]Hibernate version:[/b] Hibernate Entity Manager 3.2.0, with Hibernate Core 3.2.0 and Hibernate Annotations 3.2.0 [b]Mapping documents:[/b] Annotations [b]Full stack trace of any exception that occurs:[/b] Memory Heap Exception [b]Name and version of the database you are using:[/b] PosgreSQL 8.1 Reporter: Sami Dalouche Summary --------- When enabling L2 Cache (with either OScache and EhCache, both with a limitation on the max #of instances, so the problem shouldn't come from the cache manager), Hibernate cannot have long running transactions, otherwise, it results in a Memory Heap Exception... The problem does NOT happen if the L2 Cache is disabled ! Details ---------- - Configure the code to run in ONE transaction - Have a huge loop that inserts 2 million entries that are cacheable (@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)) - flush() and clear() every 1000 entries, to periodically flush the cache => None of the entries are garbage collected. => Using a profiler, it is possible to trace the owning objects of my domain classes to : - org.hibernate.action.EntityInsertAction ("instance" variable) - array / List (variable elementData) - variable "executions" in object .. class org.hibernate.engine.ActionQueue Remarks : - If the Query Cache is disabled, and the objects being inserted are NOT cacheable (no @Cache annotation), there is no problem - If the Query Cache is enabled, then, no matter whether the objects being inserted are cacheable or not, The entries are never garbage collected, and I get an OutOfMemoryException. (I see NO relationship between the Query Cache and my objects. I never query the objects, only save them !!) -- 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

15 years

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3195) session.clear() is not effective when use_query_cache is true

by James Berry (JIRA)

session.clear() is not effective when use_query_cache is true ------------------------------------------------------------- Key: HHH-3195 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3195 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: 3.2.6.ga, MySQL5 Reporter: James Berry As discussed in detail in http://forum.hibernate.org/viewtopic.php?t=944918, performing many inserts while use_query_cache is enabled will eventually cause an out of memory condition, even if the session is periodically flushed and cleared. That forum thread describes a potential root cause for this problem. Nobody from the Hibernate team has responded regarding the forum thread, even though it's been alive for three years now! Note that an answer to "disable the query cache" is not a good solution to the problem, as we need the query cache elsewhere. If it were possible to disable the query cache for a particular session, that would be fine, but I see no way do that. -- 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

15 years

7
9
0 / 0

[Hibernate-JIRA] Created: (HV-315) Create package-level JavaDoc for the AP

by Gunnar Morling (JIRA)

Create package-level JavaDoc for the AP --------------------------------------- Key: HV-315 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-315 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Affects Versions: 4.1.0.Beta1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik Priority: Minor Fix For: 4.1.0 Currently there are no package-level JavaDocs for the AP. These should be added. The top-level doc should contain an overview over the APs architecture in general. -- 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

15 years, 1 month

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2735) Query . setLockMode cannot find the alias when the query defines a select clause

by Tamir Solomon (JIRA)

Query . setLockMode cannot find the alias when the query defines a select clause -------------------------------------------------------------------------------- Key: HHH-2735 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2735 Project: Hibernate3 Issue Type: Bug Reporter: Tamir Solomon I tried to perform the following : Query q1 = session.createQuery("select serverIP.server from ServerIP serverIP where serverIP.ip = :ipStr"); q1.setLockMode("serverIP",LockMode.NONE); q1.setParameter("ipStr", ip); q1.list(); and i get this error : Frame : java.lang.IllegalArgumentException: alias not found: serverIP at org.hibernate.loader.hql.QueryLoader.applyLocks(QueryLoader.java:299) at org.hibernate.loader.Loader.preprocessSQL(Loader.java:189) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1529) at org.hibernate.loader.Loader.doQuery(Loader.java:661) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.doList(Loader.java:2211) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095) at org.hibernate.loader.Loader.list(Loader.java:2090) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) -- 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

15 years, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4582) Repeated column in mapping for entity in composite id

by Franck Bisti (JIRA)

Repeated column in mapping for entity in composite id ----------------------------------------------------- Key: HHH-4582 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4582 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 Reporter: Franck Bisti Priority: Minor Attachments: PersistentClass.java I have a composite-id with 2 manytoone. The two manytoone are composed by 3 columns each. They share 2 columns. @Embeddable public class FooBarId implements Serializable { @ManyToOne() @JoinColumns({ @JoinColumn(name="FOO_BAR1", referencedColumnName="FOO_BAR1",nullable=false, updatable=true, insertable=true), @JoinColumn(name="FOO_BAR2", referencedColumnName="FOO_BAR2",nullable=false, updatable=true, insertable=true), @JoinColumn(name="FOO_ID", referencedColumnName="ID",nullable=false, updatable=true, insertable=true) }) private Foo foo; /** Attribute*/ @ManyToOne() @JoinColumns({ @JoinColumn(name="FOO_BAR1", referencedColumnName="FOO_BAR1",nullable=false, updatable=false, insertable=false), @JoinColumn(name="FOO_BAR2", referencedColumnName="FOO_BAR2",nullable=false, updatable=false, insertable=false), @JoinColumn(name="BAR_ID", referencedColumnName="ID",nullable=false, updatable=false, insertable=false) }) private Bar bar; Exception : Caused by: org.hibernate.MappingException: Repeated column in mapping for entity: com.test.FooBar column: FOO_BAR2 (should be mapped with insert="false" update="false") at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:670) at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:711) at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:468) at org.hibernate.mapping.RootClass.validate(RootClass.java:215) at org.hibernate.cfg.Configuration.validate(Configuration.java:1135) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1320) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:854) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669) I have the "Repeated column in mapping" exception because Hibernate doesn't use the insertable and updtable property in the PersistentClass.checkColumnDuplication for composite-id. I have modified the PersistentClass.checkColumnDuplication() by use of getColumnUpdateability code and it seems to works fine (see attached file) I don't know if that can help -- 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

15 years, 1 month

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3361) LazyInitializationException generate an error message in the logs

by benoit heinrich (JIRA)

LazyInitializationException generate an error message in the logs ----------------------------------------------------------------- Key: HHH-3361 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3361 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1 Reporter: benoit heinrich Priority: Minor Hi, When a LazyInitializationException is thrown a log message is automatically created by the exception class because of the line 19 in the LIE class: LoggerFactory.getLogger( LazyInitializationException.class ).error( msg, this ); An exception should not write log messages, this is part of the application that handle the exception that should decide either or nor a log message should be created. The exception should just carry all information with it and no more. Actually this is causing a serious problem to one of the application I'm working on because LIE is a normal exception and is caught and handled correctly and each time a LIE is thrown by hibernate I'm getting a full stack trace in the logs (which is wrong in my case because the exception is handled correctly). Also I don't want to change the log4j settings to ignore the LIE because I'd like to know when I get a LIE that is not caught. So my suggestion is to simply remove the Log entry from the LIE constructor since normally this message is anyway redundant because if the exception is not caught the application will dump the exception in most of the time. Cheers, /Benoit -- 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

15 years, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2141) problem with JavaAssist

by Ramil Israfilov (JIRA)

problem with JavaAssist ------------------------ Key: HHH-2141 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2141 Project: Hibernate3 Type: Bug Versions: 3.2.0.cr2 Reporter: Ramil Israfilov I have an Java interface: public interface Credentials { public long getId(); public void setId(long id); Object getCredentialsForProtocol(String protocol) throws ProtocolException; } and implementation class: ------- public class BasicCredentials implements Serializable, Credentials { private long id; private String username; private String password; private static final Log log = LogFactory.getLog(BasicCredentials.class); public BasicCredentials() { super(); } public BasicCredentials(String username, String password) { super(); this.username = username; this.password = password; } /** * @return Returns the password. */ public String getPassword() { return password; } /** * @param password * The password to set. */ public void setPassword(String password) { this.password = password; } /** * @return Returns the username. */ public String getUsername() { return username; } /** * @param username * The username to set. */ public void setUsername(String username) { this.username = username; } public Object getCredentialsForProtocol(String protocol) { if (protocol != null && protocol.equalsIgnoreCase("HTTP")) { return new UsernamePasswordCredentials(username, password); } log.error("Unsupported protoco:" + protocol); return null; } public long getId() { return id; } public void setId(long id) { this.id = id; } ---- Also I have an Credentials.hbm.xml file: <hibernate-mapping package="be.certipost.comms.accessclient"> <class name="Credentials" table="COMMS$CREDENTIALS"> <id name="id" type="long" unsaved-value="0"> <generator class="native"/> </id> <discriminator column="CREDENTIALS_TYPE" type="string"/> <subclass name="BasicCredentials" discriminator-value="BC"> <property name="username" lazy="false" generated="never" type="string"></property> <property name="password" lazy="false" generated="never" type="string"></property> </subclass> </class> </hibernate-mapping> I have deployed those claases and mapping to JBOSS 4.0.4GA: I construct EAR file which contains inside JAR file with my classes and hbm file. And during deploying I got error: 2006-10-12 10:37:32,350 INFO [org.hibernate.cfg.Environment] Hibernate 3.2 cr2 2006-10-12 10:37:32,365 INFO [org.hibernate.cfg.Environment] hibernate.properties not found 2006-10-12 10:37:32,381 INFO [org.hibernate.cfg.Environment] Bytecode provider name : javassist 2006-10-12 10:37:32,381 INFO [org.hibernate.cfg.Environment] using JDK 1.4 java.sql.Timestamp handling 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: commons-lang-2.1.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: datatools.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: ejb3-persistence.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jsr173_api.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: CertioneCommsClient.jar 2006-10-12 10:37:32,521 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/DataInstructions.hbm.xml 2006-10-12 10:37:32,771 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.DataInstructions -> COMMS$METADATAS 2006-10-12 10:37:32,818 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Request.hbm.xml 2006-10-12 10:37:32,943 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Request -> COMMS$REQUESTS 2006-10-12 10:37:32,959 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Request.acks -> COMMS$REQ_ACKS 2006-10-12 10:37:33,193 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Response.hbm.xml 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Response -> COMMS$RESPONSES 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Response.acks -> COMMS$RESP_ACKS 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Session.hbm.xml 2006-10-12 10:37:33,506 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Session -> COMMS$SESSIONS 2006-10-12 10:37:33,506 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/accessclient/Credentials.hbm.xml 2006-10-12 10:37:33,600 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.accessclient.Credentials -> COMMS$CREDENTIALS 2006-10-12 10:37:33,771 INFO [org.hibernate.cfg.HbmBinder] Mapping subclass: be.certipost.comms.accessclient.BasicCredentials -> COMMS$CREDENTIALS 2006-10-12 10:37:33,771 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/accessclient/config/ClientProperties.hbm.xml 2006-10-12 10:37:33,818 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.accessclient.config.ClientProperties -> COMMS$CLIENTPROPERTIES 2006-10-12 10:37:33,818 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: hibernate-annotations.jar 2006-10-12 10:37:33,834 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: quartz-all-1.5.2.jar 2006-10-12 10:37:33,834 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jaxb-impl.jar 2006-10-12 10:37:33,850 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jaxb-api.jar 2006-10-12 10:37:33,850 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: activation.jar 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: commons-httpclient-3.0.1.jar 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: tmp38363CertioneCommsClient.ear 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Session.requests -> COMMS$REQUESTS 2006-10-12 10:37:33,959 INFO [org.hibernate.util.NamingHelper] JNDI InitialContext properties:{} 2006-10-12 10:37:33,959 INFO [org.hibernate.connection.DatasourceConnectionProvider] Using datasource: java:/CertioneCommsDS 2006-10-12 10:37:33,975 INFO [org.hibernate.cfg.SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0 2006-10-12 10:37:33,975 INFO [org.hibernate.cfg.SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0 2006-10-12 10:37:34,021 INFO [org.hibernate.dialect.Dialect] Using dialect: org.hibernate.dialect.HSQLDialect 2006-10-12 10:37:34,021 INFO [org.hibernate.transaction.TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory 2006-10-12 10:37:34,037 INFO [org.hibernate.util.NamingHelper] JNDI InitialContext properties:{} 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiated TransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiated TransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Automatic flush during beforeCompletion(): enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Automatic session close at end of transaction: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC batch size: 15 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC batch updates for versioned data: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Scrollable result sets: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC3 getGeneratedKeys(): disabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Connection release mode: after_statement 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Maximum outer join fetch depth: 5 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Default batch fetch size: 1 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Generate SQL with comments: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Order SQL updates by primary key: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory 2006-10-12 10:37:34,053 INFO [org.hibernate.hql.ast.ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query language substitutions: {} 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Second-level cache: enabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query cache: enabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Cache provider: org.hibernate.cache.HashtableCacheProvider 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Optimize cache for minimal puts: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Structured second-level cache entries: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory 2006-10-12 10:37:34,068 INFO [org.hibernate.cfg.SettingsFactory] Statistics: disabled 2006-10-12 10:37:34,084 INFO [org.hibernate.cfg.SettingsFactory] Deleted entity synthetic identifier rollback: disabled 2006-10-12 10:37:34,084 INFO [org.hibernate.cfg.SettingsFactory] Default entity-mode: pojo 2006-10-12 10:37:34,131 INFO [org.hibernate.impl.SessionFactoryImpl] building session factory 2006-10-12 10:37:34,506 ERROR [org.hibernate.proxy.pojo.BasicLazyInitializer] Javassist Enhancement failed: be.certipost.comms.accessclient.Credentials java.lang.RuntimeException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:141) at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:42) at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:159) at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131) at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:50) at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64) at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:256) at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:418) at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(Hibernate.java:231) at org.jboss.hibernate.jmx.Hibernate.startService(Hibernate.java:155) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy37.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:595) Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170) ... 126 more Caused by: java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159) ... 127 more 2006-10-12 10:37:34,615 WARN [org.hibernate.tuple.PojoEntityTuplizer] could not create proxy factory for:be.certipost.comms.accessclient.Credentials org.hibernate.HibernateException: Javassist Enhancement failed: be.certipost.comms.accessclient.Credentials at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:149) at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:42) at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:159) at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131) at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:50) at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64) at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:256) at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:418) at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(Hibernate.java:231) at org.jboss.hibernate.jmx.Hibernate.startService(Hibernate.java:155) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy37.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:141) ... 125 more Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170) ... 126 more Caused by: java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159) ... 127 more Strange thing that tables are created and credentials objects persisted correctly. It is starnge that I got ERROR in log files. -- 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

15 years, 1 month

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3344) DB2Dialect.getLimitString doesn't work for some queries

by Damon Horrell (JIRA)

DB2Dialect.getLimitString doesn't work for some queries ------------------------------------------------------- Key: HHH-3344 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3344 Project: Hibernate3 Issue Type: Bug Reporter: Damon Horrell Priority: Minor If a query uses * but doesn't use a table alias then the modified query created by DB2Dialect.getLimitString is invalid. e.g. select * from mytable becomes select * from ( select rownumber() over() as rownumber_, * from mytable ) as temp_ where rownumber_ <= ? which causes DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: *;ver() as rownumber_,;<select_sublist> I have worked around this for my project by extending DB2Dialect with: public String getLimitString(String sql, boolean hasOffset) { return "select * from ( select rownumber() over() as rownumber_, original_query.* from (" + sql + ") original_query ) as temp_ where rownumber_ <= ?"; } This code will need extending to handle the hasOffset case etc. Real code probably won't be using select * anyway so this probably isn't a big problem. My example allows the user to enter a custom query so I have to handle this situation. -- 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

15 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2176) DB2 setMaxResults problem in Hibernate 3.1.3

by Winter Lau (JIRA)

DB2 setMaxResults problem in Hibernate 3.1.3 -------------------------------------------- Key: HHH-2176 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2176 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: DB2 any version Hibernate 3.1.3 JDK 1.5 Reporter: Winter Lau Priority: Blocker public static List listHotTags(int count){ Session ssn = getSession(); String sql = "SELECT tag_name,COUNT(*) FROM dlog_tag GROUP BY tag_name ORDER BY 2 DESC"; SQLQuery query = ssn.createSQLQuery(sql); query.setMaxResults(count); List tags = new ArrayList(); List results = query.list(); for(int i=0;results!=null && i tags.add(((Object[])results.get(i))[0]); } return tags; } tags.add(((Object[])results.get(i))[0]); this code work fine in other database, but in DB2 , it return the rownumber, i must change to get the second element of array then it return the correct data. -- 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

15 years, 1 month

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4943) ilike support is incomplete

by James Nobis (JIRA)

ilike support is incomplete --------------------------- Key: HHH-4943 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4943 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: 3.3.2GA MySQL/PostgreSQL Reporter: James Nobis ILIKE is currently supported for PostgreSQL in: hibernate-distribution-3.3.2.GA/project/core/src/main/java/org/hibernate/criterion/IlikeExpression.java: if ( dialect instanceof PostgreSQLDialect ) { return columns[0] + " ilike ?"; } else { return dialect.getLowercaseFunction() + '(' + columns[0] + ") like ?"; } //TODO: get SQL rendering out of this package! 1) This should be in the Dialect 2) PostgreSQL isn't the only DB with ILIKE 3) using instanceof for this is just sloppy 4) this implementation using getLowercaseFunction works with MySQL but fails with DBs like Firebird -- 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

15 years, 1 month

3
6
0 / 0

[Hibernate-JIRA] Créée: (HHH-2389) Improving DB2 dialect

by Nicolas Billard (JIRA)

Improving DB2 dialect --------------------- Key: HHH-2389 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2389 Project: Hibernate3 Type: Improvement Components: query-hql Versions: 3.2.1 Environment: Development based on v 3.2.1 Reporter: Nicolas Billard Priority: Minor Attachments: DB2Dialect.java The class joined to this issue overrides the DB2 dialect. The dialect included in hibernate doesn't work very well when you want to limit returned results (when you call setFirstResult and / or setMaxResults on a query) : - the instructions "fetch first XXX row only is not used - a temporary table is used when it's not usefull - when you have subselects, an exception can occur if subselects have order by clause (because of the getRowNumber method, not corrected here). This version of getLimitString() method generates faster requests (tests made on a table of 300000 rows shows that fetching rows from 20 to 30 takes 0.3 seconds with original version, 0.02 with this one). -- 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

15 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5007) Using <formula> within Composite Element inside Collection

by Hepoi Ko (JIRA)

Using <formula> within Composite Element inside Collection ---------------------------------------------------------- Key: HHH-5007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5007 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-CR-2 Environment: 3.5.0-CR2, AS400, Component Reporter: Hepoi Ko Priority: Minor Attachments: JoinWalker.java I was one of the user who use Hibernate in a legacy database schema, and always had a issue on using composite-key (and formula) inside collection. I was able to modify the hibernate source (from 3.3.2) to overcome such issue. I am hoping the new version 3.5.0 would even fix this problem. Anyway, I just leave the fix information here, hope it would help. In /org/hibernate/loader/JoinWalker.java Line 641: String[] aliasedLhsColumns = StringHelper.qualify(alias, lhsColumns); Modify with these: String[] fullAliasedLhsColumns = persister.getElementColumnNames(alias); String[] aliasedLhsColumns = ArrayHelper.slice(fullAliasedLhsColumns, begin, length); Without above change I would get NullPointerException on a mapping as .... <set name="auditRecords" table="OEP40A" order-by="ADAT40 DESC, ATIM40 DESC" mutable="false" inverse="true" outer-join="true"> <key> <column name="CONO40"></column> <column name="ORDN40"></column> </key> <composite-element class="com.ricoh.erp.order.domain.OrderAudit"> <property name="userId"> <column name="AUSR40"></column> </property> <property name="workstationId"> <column name="AWRK40"></column> </property> <many-to-one name="customerEntry" not-found="ignore"> <formula>CONO40</formula>  <column name="CUSN40"></column> <column name="DSEQ40"></column> </many-to-one> </composite-element> With Best Regards, -- 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

15 years, 1 month

3
15
0 / 0

[Hibernate-JIRA] Created: (HHH-4941) Log a message when an update to a mutable one-to-many collection of immutable entities is ignored

by Gail Badner (JIRA)

Log a message when an update to a mutable one-to-many collection of immutable entities is ignored ------------------------------------------------------------------------------------------------- Key: HHH-4941 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4941 Project: Hibernate Core Issue Type: Improvement Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.x An update to a mutable one-to-many collection is ignored when inverse="true" and the associated entity is immutable and already exists (since it cannot be updated). Should this be a debug, info, or warning message? -- 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

15 years, 1 month

2
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4760) NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies

by Erik-Berndt Scheper (JIRA)

NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies ------------------------------------------------------------------------------------------ Key: HHH-4760 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4760 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0-Beta-2 Reporter: Erik-Berndt Scheper NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies In my code I see the following stacktrace if I try to retrieve the revision of a javassist proxy: org.hibernate.envers.exception.NotAuditedException: nl.ibgroep.bap.model.domain.persoon.Ouder_$$_javassist_1 is not versioned! at org.hibernate.envers.reader.AuditReaderImpl.getRevisions(AuditReaderImpl.java:126) at nl.ibgroep.bap.dao.impl.AuditRevisionJpaDaoImpl.getRevisionsFor(AuditRevisionJpaDaoImpl.java:58) Ouder_$$_javassist_1.class is a Hibernate generated javassist proxy for Ouder.class, which is versioned. Code: AuditReader vr = AuditReaderFactory.get(this.entityManager); Class clazz = persistentObject.getClass(); List<Number> revisionNumbers = vr.getRevisions(clazz, persistentObject.getId()); I am able to work around this issue with the following code: AuditReader vr = AuditReaderFactory.get(this.entityManager); Class clazz = persistentObject.getClass(); if (persistentObject instanceof javassist.util.proxy.ProxyObject) { if (LOGGER.isDebugEnabled()) { StringBuilder output = new StringBuilder("Found javassist ProxyObject for revision: class= "); output.append(clazz.getSimpleName()); output.append("; superclass= ").append(clazz.getSuperclass().getSimpleName()); output.append("; interfaces= ").append(Arrays.asList(clazz.getInterfaces()).toString()); LOGGER.debug(output.toString()); } clazz = clazz.getSuperclass(); } List<Number> revisionNumbers = vr.getRevisions(clazz, persistentObject.getId()); However, a fix in envers would be greatly appreciated. -- 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

15 years, 1 month

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5016) Add support for initialValue on sequence generation

by Morten Egelund Rasmussen (JIRA)

Add support for initialValue on sequence generation --------------------------------------------------- Key: HHH-5016 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5016 Project: Hibernate Core Issue Type: Improvement Reporter: Morten Egelund Rasmussen I'm having an entity with a @javax.persistence.SequenceGenerator annotation: {code} @SequenceGenerator(name = "foo.pkseq", sequenceName = "MY_SCHEME.SEQ_FOO_ID", allocationSize=1, initialValue=100) {code} I have set "hibernate.hbm2ddl.auto = create". When the sequence is created, it is created without the initialValue properly set. Referring to the documentation on Hibernate Annotations 3.4, it states that this feature is currently not implemented. I have tried with the H2 and HSQLDB databases. I'm doing some integration tests, where records are created in a RAM-based H2 or HSQLDB test database. The database is already populated with data. -- 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

15 years, 1 month

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-1994) Problem with case sensitive column and tables names and Identity mapping with postgreSQL

by Alex Samad (JIRA)

Problem with case sensitive column and tables names and Identity mapping with postgreSQL ---------------------------------------------------------------------------------------- Key: HHH-1994 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1994 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: Hibernate 3.1.3, Java 1.5.0_07 (sun) windos and linux ( 32 & 64 bit). POstgres SQL 8.1 Windows and linux Reporter: Alex Samad Whilst trying to insert into a table with a primary key (ID mapping) which has a identity generator. And the columns and/or the table has been defined with case sensitivey ie back ticks. It fails to get the next serial number and thus fails any inserts. The problem lies in dialect/PostgreSQLDialect.java public String getIdentitySelectString(String table, String column, int type) { return new StringBuffer().append("select currval('") .append(table) .append('_') .append(column) .append("_seq')") .toString(); } table is inclosed in quotes and column is inclosed in quotes which gives a name like "table"_"Column"_seq - which fails I would suggest a fix is to test each of table or column for " and if it exist then to strip it of both of table and column and encluse the whole name in "". This mighe break some old code where say the table is coded in case insensitive table name and case sensitive column key. Sorry not much of a java programmer. -- 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

15 years, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5025) Support caching audit queries using ehcache's DiskStore.

by Brent Worden (JIRA)

Support caching audit queries using ehcache's DiskStore. -------------------------------------------------------- Key: HHH-5025 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5025 Project: Hibernate Core Issue Type: Improvement Components: envers Reporter: Brent Worden Priority: Minor Enabling audit query caching with a ehcache cache configured as persisting to disk or overflowing to disk. For example, <defaultCache diskPersistent="true" eternal="false" maxElementsInMemory="1000" maxElementsOnDisk="10000" overflowToDisk="true" timeToIdleSeconds="300" timeToLiveSeconds="3600" /> Results in the following exception: java.io.NotSerializableException: org.hibernate.envers.entities.RevisionTypeType at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) The lack of needed serialization prohibits the use of ehcache's DiskStore. -- 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

15 years, 1 month

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2655) SQLServer2005Dialect (ROW_NUMBER for Paging)

by Wells Tiedeman (JIRA)

SQLServer2005Dialect (ROW_NUMBER for Paging) -------------------------------------------- Key: HHH-2655 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2655 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.4, 3.2.3, 3.2.2 Environment: SQLServer 2005, Hibernate 3.2.2+ Reporter: Wells Tiedeman Attachments: SQLServer2005Dialect.java Add a SQLServer2005Dialect class to the product that leverages the new ROW_NUMBER capabilities within SQLServer2005 to do paged result sets more efficiently. See attached source... -- 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

15 years, 1 month

14
25
0 / 0

[Hibernate-JIRA] Created: (HHH-2893) Criteria api does not allow a groupProperty to _NOT_ be included in the selected columns

by Antony Stubbs (JIRA)

Criteria api does not allow a groupProperty to _NOT_ be included in the selected columns ---------------------------------------------------------------------------------------- Key: HHH-2893 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2893 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: n/a Reporter: Antony Stubbs When adding a Projections.groupProperty("prop") to a criteria, the property is added to both the GROUP BY and SELECT parts of the generated SQL query. This is a major problem for using the criteria API for complex subselects that require aggregating by a column while grouping by another column. There is presently no way in the criteria API to group by a column and have it _ONLY_ in the GROUP BY clause. i.e. currently Projections.groupProperty("propOne") causes: SELECT propOne, MAX(propTwo) FROM table GROUP BY prop desired option is to have SELECT MAX(propTwo) FROM table GROUP BY prop There have been several people talking about this, but there appears to have been 'no comment'. http://forum.hibernate.org/viewtopic.php?t=939071&highlight=values+groupp... http://forum.hibernate.org/viewtopic.php?t=950803&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?t=964512&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?t=957671&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?p=2317841#2317841 http://forum.hibernate.org/viewtopic.php?t=961617&highlight=groupproperty... Find a 1st cut patch on it's way - I'm just itching my scratch now... Great work on Hibernate guys! -- 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

15 years, 1 month

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3325) Pagination with Oracle ROWNUM is sub-optimal

by e. wernli (JIRA)

Pagination with Oracle ROWNUM is sub-optimal -------------------------------------------- Key: HHH-3325 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3325 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Reporter: e. wernli Pagination with Oracle ROWNUM is sub-optimal The feature works but result in sub-optimal SQL. The generated SQL is the following: select * from ( select row_.*, rownum rownum_ from ( select this_.id as id3_0_, this_.version as version3_0_, this_.name as name3_0_, this_.type as type3_0_, this_.marketstatus as marketst5_3_0_ from Customer this_ order by this_.id asc ) row_ ) where rownum_ <= ? and rownum_ > ? But this SQL is faster: SELECT * FROM (SELECT row_.*, ROWNUM rownum_ FROM (SELECT this_.ID AS id3_0_, this_.VERSION AS version3_0_, this_.NAME AS name3_0_, this_.TYPE AS type3_0_, this_.marketstatus AS marketst5_3_0_ FROM customer this_ ORDER BY this_.ID ASC) row_ WHERE ROWNUM <= ?) WHERE rownum_ > ? The second solution allows Oracle to use an optimization that can dramatically reduce the time of the query, especially one of the first page is retrieved. See this link for an explanation of this optimization: http://decipherinfosys.wordpress.com/2007/08/09/paging-and-countstopkey-o... -- 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

15 years, 1 month

7
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4956) Native Query returns wrong results

by Akashdeep Saddi (JIRA)

Native Query returns wrong results ---------------------------------- Key: HHH-4956 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4956 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.2 Environment: hibernate 3.3.2.GA , linux, oracle 10g, weblogic 10 Reporter: Akashdeep Saddi Issue: In-case running native queries vai hibernate we have two technical ID's in the select clause from join of two or more tables the value of all the id's is set to one value. Example A.id = 1 B.id =2 select A.Id as A_ID, B.Id as B_ID from A, B where A.B_id = B.id will return 1,1 in the result instead of 1,2 Resolution: Use Alias in-case more than one technical keys are part of select clause. Above query works fine when changed as below select A.Id , B.Id from A, B where A.B_id = B.id will return 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

15 years, 1 month

7
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2473) fetch="join" and property-ref

by David CLEMENT (JIRA)

fetch="join" and property-ref ----------------------------- Key: HHH-2473 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2473 Project: Hibernate3 Type: Improvement Versions: 3.2.1 Environment: Version 3.2.1, not DB dependant Reporter: David CLEMENT When Hibernate does a fetch join with a property-ref in a many-to-one, it issues the join SQL query but needs another select to find the associated entity by property-ref. It should be able to use the entity fetched in the join instead (maybe this has been done to ensure the unicity of the associated entity, but it introduce a performance issue). -- 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

15 years, 1 month

8
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4613) HQL: QuerySyntaxException when parsing any condition containing a colum named "value"

by Guenther Demetz (JIRA)

HQL: QuerySyntaxException when parsing any condition containing a colum named "value" ------------------------------------------------------------------------------------- Key: HHH-4613 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4613 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-2 Environment: 3.5.0-Beta2, Db: HSQLDB Reporter: Guenther Demetz Priority: Minor Attachments: TestCaseQueryWithCondition.jar org.hibernate.hql.ast.QuerySyntaxException: expecting OPEN, found '=' near line 1, column 27 is thrown calling ((org.hibernate.Session) session).createQuery("from hello.A where value = ?"); Please note that until Hibernate3.3.2GA this worked fine! Apparently 'value' unintentionally has become a reserved keyword for HQL conditions. Here the complete stacktrace: --> org.hibernate.hql.ast.QuerySyntaxException: expecting OPEN, found '=' near line 1, column 27 [from hello.A where value = ?] at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54) at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47) at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82) at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:284) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:182) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1586) at hello.TestQueryWithCondition.testQuery(TestQueryWithCondition.java:40) Please consider attached junit-testcase. best regards Guenther Demetz -- 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

15 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2596) Add support for Hypersonic 1.8.0.7

by Gail Badner (JIRA)

Add support for Hypersonic 1.8.0.7 ---------------------------------- Key: HHH-2596 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2596 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.3 Environment: Hibernate 3.2.3, Hypersonic 1.8.0.7 Reporter: Gail Badner The version released with Hibernate 3.2.3 (1.8.0.2) is from 2005. It would be good to move to a more recent version. The following unit tests fail when using Hypersonic 1.8.0.7: org.hibernate.test.jpa.lock.JPALockTest.testLockModeTypeRead: Failure: isolation not maintained expected:<lock test> but was:<updated> org.hibernate.test.legacy.IJ2Test.testUnionSubclass: Error: could not set a field value by reflection setter of org.hibernate.test.legacy.J.amount org.hibernate.test.subclassfilter.UnionSubclassFilterTest.testFiltersWithUnionSubclass: Error: Could not execute JDBC batch update org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclass: Failure: junit.framework.AssertionFailedError org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclassManyToOne Error: attempt to create delete event with null entity -- 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

15 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3839) Using Criteria.setMaxResults gives a MySQLSyntaxErrorException

by Kevin DIMEY (JIRA)

Using Criteria.setMaxResults gives a MySQLSyntaxErrorException -------------------------------------------------------------- Key: HHH-3839 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3839 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: MySQL 5.0.51a Reporter: Kevin DIMEY Attachments: hibernate.cfg.xml Hi, When trying to limit the number of rows returned by Criteria.list() method, exception is thrown about bad SQL grammar. The "limit" SQL statement is put just after the select keyword. It should be placed at the end of the request. Moreover, it seems there is no coma between the start row and the amount of objects to retrieve. Here is the method called : session.createCriteria(Etude.class).setFirstResult(5).setMaxResults(10).list(); I get the same issue while using only setMaxResults, it puts the "top" keyword just after the "select" one. Here is the request generated and the stack trace : Hibernate: select limit ? ? this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confidentielle as confiden2_7_6_, this_.contact_id as contact12_7_6_, this_.created_at as created3_7_6_, this_.date_fin as date4_7_6_, this_.date_signature as date5_7_6_, this_.date_sollicitation as date6_7_6_, this_.entreprise_id as entreprise13_7_6_, this_.etat_code as etat7_7_6_, this_.numero as numero7_6_, this_.sujet as sujet7_6_, this_.updated_at as updated10_7_6_, avortement2_.id as id1_0_, avortement2_.created_at as created2_1_0_, avortement2_.created_by as created3_1_0_, avortement2_.raison as raison1_0_, contact3_.id as id2_1_, contact3_.adresse_id as adresse18_2_1_, contact3_.civilite_code as civilite2_2_1_, contact3_.connu_par_code as connu3_2_1_, contact3_.connu_par_detail as connu4_2_1_, contact3_.created_at as created5_2_1_, contact3_.entreprise_id as entreprise19_2_1_, contact3_.fax as fax2_1_, contact3_.fonction as fonction2_1_, contact3_.mail as mail2_1_, contact3_.news_dernier_envoi as news9_2_1_, contact3_.news_desinscrit as news10_2_1_, contact3_.nom as nom2_1_, contact3_.parti as parti2_1_, contact3_.prenom as prenom2_1_, contact3_.service_code as service14_2_1_, contact3_.tel_fixe as tel15_2_1_, contact3_.tel_portable as tel16_2_1_, contact3_.updated_at as updated17_2_1_, adresse4_.id as id0_2_, adresse4_.adresse1 as adresse2_0_2_, adresse4_.adresse2 as adresse3_0_2_, adresse4_.adresse3 as adresse4_0_2_, adresse4_.code_postal as code5_0_2_, adresse4_.ville as ville0_2_, entreprise5_.id as id5_3_, entreprise5_.adresse_id as adresse14_5_3_, entreprise5_.created_at as created2_5_3_, entreprise5_.disparue as disparue5_3_, entreprise5_.domaine_code as domaine4_5_3_, entreprise5_.effectif_code as effectif5_5_3_, entreprise5_.etat_code as etat6_5_3_, entreprise5_.fax as fax5_3_, entreprise5_.nom as nom5_3_, entreprise5_.num_siret as num9_5_3_, entreprise5_.particulier as particu10_5_3_, entreprise5_.site_web as site11_5_3_, entreprise5_.tel as tel5_3_, entreprise5_.updated_at as updated13_5_3_, adresse6_.id as id0_4_, adresse6_.adresse1 as adresse2_0_4_, adresse6_.adresse2 as adresse3_0_4_, adresse6_.adresse3 as adresse4_0_4_, adresse6_.code_postal as code5_0_4_, adresse6_.ville as ville0_4_, entreprise7_.id as id5_5_, entreprise7_.adresse_id as adresse14_5_5_, entreprise7_.created_at as created2_5_5_, entreprise7_.disparue as disparue5_5_, entreprise7_.domaine_code as domaine4_5_5_, entreprise7_.effectif_code as effectif5_5_5_, entreprise7_.etat_code as etat6_5_5_, entreprise7_.fax as fax5_5_, entreprise7_.nom as nom5_5_, entreprise7_.num_siret as num9_5_5_, entreprise7_.particulier as particu10_5_5_, entreprise7_.site_web as site11_5_5_, entreprise7_.tel as tel5_5_, entreprise7_.updated_at as updated13_5_5_ from etude this_ left outer join avortement avortement2_ on this_.avorte_id=avortement2_.id left outer join contact contact3_ on this_.contact_id=contact3_.id left outer join adresse adresse4_ on contact3_.adresse_id=adresse4_.id left outer join entreprise entreprise5_ on contact3_.entreprise_id=entreprise5_.id left outer join adresse adresse6_ on entreprise5_.adresse_id=adresse6_.id left outer join entreprise entreprise7_ on this_.entreprise_id=entreprise7_.id 29 mars 2009 00:52:29 org.hibernate.util.JDBCExceptionReporter logExceptions ATTENTION: SQL Error: 1064, SQLState: 42000 29 mars 2009 00:52:29 org.hibernate.util.JDBCExceptionReporter logExceptions GRAVE: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 5 10 this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confident' at line 1 29 mars 2009 00:52:29 org.apache.catalina.core.ApplicationDispatcher invoke GRAVE: "Servlet.service()" pour la servlet jsp a lancï¿½ une exception com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 5 10 this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confident' at line 1 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1912) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1808) at org.hibernate.loader.Loader.doQuery(Loader.java:697) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259) at org.hibernate.loader.Loader.doList(Loader.java:2228) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125) at org.hibernate.loader.Loader.list(Loader.java:2120) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306) at easytic.support.EtudesSupport$EtudesList.getList(EtudesSupport.java:41) I've attached my hibernate.cfg.xml. This issue seemed resolved in 3.2.5 : http://opensource.atlassian.com/projects/hibernate/browse/HHH-2954 but I got it with 3.3.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

15 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4770) Wrong class property type, when access="field" is specified. The HbmBinder and the method setTypeUsingReflection() of the interface org.hibernate.mapping.Value does not use the property "access" settings (field/property/etc...)

by Peter Fassev (JIRA)

Wrong class property type, when access="field" is specified. The HbmBinder and the method setTypeUsingReflection() of the interface org.hibernate.mapping.Value does not use the property "access" settings (field/property/etc...) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-4770 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4770 Project: Hibernate Core Issue Type: Bug Components: core, metamodel Affects Versions: 3.5.0-Beta-2, 3.3.2 Reporter: Peter Fassev Attachments: ReflectionTest.zip Hibernate provides a possibility to define different access to the class properties for instance trough class methods (access="property") or directly to fields (access="field"). This information is not used during the initialization of the subclasses of the org.hibernate.mapping.Value (see SimpleValue and ToOne). The Value interface provides a method called setTypeUsingReflection(String className, String propertyName) with only two parameters. Some subclasses like SimpleValue and ToOne are calling the ReflectHelper.reflectedPropertyClass(className, propertyName). The ReflectHelper uses first the BASIC_PROPERTY_ACCESSOR, which always returns the type of the class method. Only if there is no such method, the type of the class field is returned. It does not distinguish between "property" and "field" access. Here is the Method from the ReflectHelper: org.hibernate.util.ReflectHelper: private static Getter getter(Class clazz, String name) throws MappingException { try { return BASIC_PROPERTY_ACCESSOR.getGetter( clazz, name ); } catch ( PropertyNotFoundException pnfe ) { return DIRECT_PROPERTY_ACCESSOR.getGetter( clazz, name ); } } In the case the declared method returns a different type as the declared field Hibernate calculates a wrong type for the fild. Consider the following class with a hidden field "rejected" of type "Date" and a method "isRecected()" of type boolean: class Item { private Date rejected; public void doReject() { rejected = new Date(); } public boolean isRejected() { return rejected != null; } } This type of the rejected field will be recognized by Hibernate as "boolean", even if the field access is defined to be "access=field". By running the ReflectionTestCase you will get an exception: "java.util.Date cannot be cast to java.lang.Boolean". Proposed Resolution: 1) The method org.hibernate.mapping.Value. setTypeUsingReflection needs a new parameter, which provides the access type of the property. 2) The class org.hibernate.mapping.HbmBinder must bind the access attribute of the property prior of calling this method, which is currently not the case (see the method HbmBinder.createProperty()). 3) The classess SimpleValue and ToOne should either use the PropertyAccessorFactory or the ReflectHelper should be extended to handle the access type of the field. Regards PF -- 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

15 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-76) Lazy loaded property isn't indexed properly

by Christian Bauer (JIRA)

Lazy loaded property isn't indexed properly ------------------------------------------- Key: HSEARCH-76 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-76 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.0.0.beta3 Reporter: Christian Bauer @Column(name = "CONTENT") @Length(min = 0, max = 32768) @Basic(fetch = FetchType.LAZY) // Lazy loaded through bytecode instrumentation @org.hibernate.search.annotations.Field(index = org.hibernate.search.annotations.Index.TOKENIZED) private String content; I use fulltextSession.index(o) and I only get two terms indexed "text" and "edit". I don't know where these are coming from actually, no object has these content values. If I trigger an o.getContent() before fulltextSession.index(o), the content is loaded with sequential selects for the lazy property and correctly indexed. -- 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

15 years, 2 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-121) Should optimize set batch to true (for indexWriters)?

by Emmanuel Bernard (JIRA)

Should optimize set batch to true (for indexWriters)? ----------------------------------------------------- Key: HSEARCH-121 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-121 Project: Hibernate Search Issue Type: Bug Components: documentation, engine Reporter: Emmanuel Bernard -- 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

15 years, 2 months

4
14
0 / 0

[Hibernate-JIRA] Created: (HHH-3538) Unnecessary complete select fragment for all associations

by Hauke Rabe (JIRA)

Unnecessary complete select fragment for all associations --------------------------------------------------------- Key: HHH-3538 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3538 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.3.1 Reporter: Hauke Rabe The JoinWalker creates for all given associations a select fragment. An associations should have a flag, if it is necessary to be included on the select fragment. If you need an association only for a specific where fragment why should it be fetched? -- 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

15 years, 2 months

5
25
0 / 0

[Hibernate-JIRA] Created: (HHH-4559) Envers AuditMetadata Generator causes java.lang.ClassCastException: org.hibernate.mapping.Formula cannot be cast to org.hibernate.mapping.Column

by Kevin Schmidt (JIRA)

Envers AuditMetadata Generator causes java.lang.ClassCastException: org.hibernate.mapping.Formula cannot be cast to org.hibernate.mapping.Column ------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-4559 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4559 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0-Beta-2 Environment: Hibernate 3.5.0-Beta-2 RDBMS: Microsoft SQL Server, version: 09.00.4230 JDBC driver: jTDS Type 4 JDBC Driver for MS SQL Server and Sybase, version: 1.2.4 Reporter: Kevin Schmidt Priority: Blocker Dear Hibernate Team, I attempted to enable Envers for a Legacy Hibernate Application which uses hbm.xml based mapping files. The building of the SessionFactory fails due to a class cast exception in the Envers code base. It appears that while generating mapping data in the AuditMetadataGenerator it is assumed that a discriminator is a Column, but it can also be a Formula. This causes a class cast exception to be thrown as is shown below (see the last cause in the exception stack trace). I know the response is going to be attach a test case, but I am not even sure how to create a good test case. Are there instructions on the wiki some where? Some starting project I could use to create the test case? In order to reproduce this issue I think it is as simple as enabling auditing for an entity which has a discriminator based on a formula instead of a column. [2009.11.10 09:33:32.302 XYZ] Failed to initialize due to exception. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scopedTarget.sessionFactory' defined in class path resource [com/xyz/data/spring-config-data.xml]: Invocation of init method failed; nested exception is org.hibernate.HibernateException: could not init listeners at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$2.getObject(AbstractBeanFactory.java:302) at com.XYZ.services.springscope.AbstractXYZSpringScopeStrategy.get(AbstractXYZSpringScopeStrategy.java:87) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:184) at $Proxy6.openSession(Unknown Source) at com.XYZ.data.hibernate.conversation.Conversation.<init>(Conversation.java:59) at com.XYZ.data.hibernate.conversation.ConversationManagerImpl.startConversation(ConversationManagerImpl.java:128) at com.XYZ.data.hibernate.conversation.ConversationManagerImpl.beginConversation(ConversationManagerImpl.java:110) at com.XYZ.core.initialization.AbstractInitializationThread.run(AbstractInitializationThread.java:145) at com.XYZ.services.thread.ThreadsManager$ThreadWrapper.run(ThreadsManager.java:147) at java.lang.Thread.run(Unknown Source) Caused by: org.hibernate.HibernateException: could not init listeners at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:205) at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1378) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1367) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:858) at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:814) at org.springframework.orm.hibernate3.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:732) at org.springframework.orm.hibernate3.AbstractSessionFactoryBean.afterPropertiesSet(AbstractSessionFactoryBean.java:211) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1369) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335) ... 18 more Caused by: java.lang.ClassCastException: org.hibernate.mapping.Formula cannot be cast to org.hibernate.mapping.Column at org.hibernate.envers.configuration.metadata.MetadataTools.addColumns(MetadataTools.java:154) at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateMappingData(AuditMetadataGenerator.java:252) at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:327) at org.hibernate.envers.configuration.EntitiesConfigurator.configure(EntitiesConfigurator.java:87) at org.hibernate.envers.configuration.AuditConfiguration.<init>(AuditConfiguration.java:86) at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:99) at org.hibernate.envers.event.AuditEventListener.initialize(AuditEventListener.java:259) at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198) at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181) at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194) ... 26 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

15 years, 2 months

6
9
0 / 0

[Hibernate-JIRA] Created: (ANN-785) Jboss Har service from annotated class

by Michele Stoduto (JIRA)

Jboss Har service from annotated class --------------------------------------- Key: ANN-785 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-785 Project: Hibernate Annotations Issue Type: New Feature Reporter: Michele Stoduto Attachments: classi.zip Hi All, My problem: deploy har service from Annotated Classes. My Solution is based on org.hibernate.jmx.HibernateService and relative classes. In Attachment new classes for deploing jboss Har service from hibernate annotated classes. Please, can you add in standard release? Thanks. -- 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

15 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5156) Add a Using JPA 2 XML mappings section in Core documentation

by Emmanuel Bernard (JIRA)

Add a Using JPA 2 XML mappings section in Core documentation ------------------------------------------------------------ Key: HHH-5156 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5156 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- 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

15 years, 2 months

4
10
0 / 0

[Hibernate-JIRA] Created: (HHH-4551) Query caching becomes very ineffective on conversations with extended sessions.

by Guenther Demetz (JIRA)

Query caching becomes very ineffective on conversations with extended sessions. ------------------------------------------------------------------------------- Key: HHH-4551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4551 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: 3.3.2 GA Reporter: Guenther Demetz Hibernate's query cache (hibernate.cache.use_query_cache) always takes the initial session timestamp for storing the result-set timestamp. --------------------------------------------- StandardQueryCache.java (put-method): ... Long ts = new Long( session.getTimestamp() ); ... cacheable.add( ts ); --------------------------------------------- When extending a session for a whole conversation (Book "Java Persistence with Hibernate" chapter. 11.2.3), the sessions initial timestamp get's soon rather deferred to the time a new query result set is produced actually. Immagine a long conversation which lasts more than 5 minutes. This leads to the effect, that often still valid result-set-cache entries are considered not up-to-date because of a flushed update action occured during the conversation. Furthermore the new obtained query-resultset (note that this query now considers the last update!) is subsequently again put in cache still with the original and outdated sessions-timestamp: That's for the birds ! Proposal: Why not take the current timestamp instead? For example calling: Long ts = new Long( cacheRegion.nextTimestamp()); best regards Guenther D. -- 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

15 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2578) redesign SessionFactory building

by Steve Ebersole (JIRA)

redesign SessionFactory building -------------------------------- Key: HHH-2578 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2578 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Critical Fix For: cfg-rework Currently a SessionFactory is built by throwing a bunch of stuff into a Configuration object, stirring it, letting it come to a boil, and then pulling out the SessionFactory. In seriousness, there are a few problems with the way we currently operate within a Configuration and how we use it to build a SessionFactory: The general issue that there is no "lifecycle" to when various pieces of information will be available. This is an important omission in a number of ways: 1) consider schema generation. currently we cannot even know the dialect when a lot of db object names are being determined. this would be nice because it would allow us to transparently handle table/column names which are also keywords/reserved-words in the dialect, for example. 2) static-ness of types and the type-mappings. Because we currently have nothing to which to scope them. Ideally a type instance would be aware of the SessionFactory to which it is bound. Instead, what we have now is to change API methods quite a lot of the time to add in the SessionFactory as a passed parameter whenever it is discovered that it is needed. 3) also, most (all?) of the "static" configuration parameters in Hibernate are currently required to be so because of their use from within these static types; thus scoping types would allow us to also scope those config parameters (things like bytecode-provider, use of binary streams, etc). Ideally what I see happening is a scheme where users build a org.hibernate.cfg.Settings (or something similiar) instance themselves. Additionally they would apply metadata to a registry of some sort (lets call it MetadataRegistry for now). Then in order to build a SessionFactory, they would supply these two pieces of information (via ctor? via builder?). The important aspect though is that the information in MetadataRegistry would not be dealt with until that point in time, which would allow us to guarentee that resolving schema object names, types, etc would have access to the runtime Settings (and specifically the dialect) -- 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

15 years, 2 months

3
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2931) Criteria.setMaxResults() filters children with fetch="join"

by Mattias Jiderhamn (JIRA)

Criteria.setMaxResults() filters children with fetch="join" ----------------------------------------------------------- Key: HHH-2931 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2931 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Reporter: Mattias Jiderhamn Assume class Parent with a collection of children that is mapped with fetch="join", then use a Criteria to find a specific Parent using setMaxResults(1).uniqueResult(). The child collection of the returned Parent will only hold 1 element, despite how many actual matching rows the child table has in the databasen. In this case, the fetch="join" needs to be ignored, and a separate query needs to be issued to fetch the children. This issue may very well be related to HHH-2049. -- 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

15 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3807) Adding a restriction to a many-to-one entity in Criteria query causes Join fetching

by Jonathan Gordon (JIRA)

Adding a restriction to a many-to-one entity in Criteria query causes Join fetching ----------------------------------------------------------------------------------- Key: HHH-3807 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3807 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.3.1 Environment: Hibernate 3.3.1GA Sql Server 2005 Reporter: Jonathan Gordon Priority: Minor When performing a criteria query that includes a restriction on a many-to-one entity, the associated entity is fetched eagerly, as if FetchMode were set to "JOIN". Explicitly setting the FetchMode to "SELECT" does not override this behavior. For instance, this criteria query: Criteria criteria = persistenceService.getCriteria(MailingParcel.class) .createAlias("mailingCampaign", "mc") .add(Restrictions.ge("mc.id", 1)) .setMaxResults(10); Yields the following sql: select top 10 this_.ID as ID17_1_, this_.KEYCODE as KEYCODE17_1_, this_.CAMPAIGN_ID as CAMPAIGN3_17_1_, this_.MAILING_LIST_MAILING_ID as MAILING4_17_1_, this_.COUNTRY_LE_ID as COUNTRY5_17_1_, this_.MATCH_ADDRESS as MATCH6_17_1_, this_.ADDRESS as ADDRESS17_1_, this_.MATCH_NAME as MATCH8_17_1_, this_.FIRST_NAME as FIRST9_17_1_, this_.LAST_NAME as LAST10_17_1_, this_.ZIP_CODE asZIP11_17_1_, this_.CITY as CITY17_1_, this_.STATE as STATE17_1_, this_.COMPANY as COMPANY17_1_, mc1_.ID as ID6_0_, mc1_.NOTE as NOTE6_0_, mc1_.NAME as NAME6_0_, mc1_.DATE_CREATED as DATE5_6_0_, mc1_.DATE_MODIFIED as DATE6_6_0_, mc1_.START_DATE as START7_6_0_, mc1_.SOURCE_FILE_NAME as SOURCE8_6_0_, mc1_.ORDINAL as ORDINAL6_0_, mc1_.KEYCODE_SUFFIX as KEYCODE10_6_0_, mc1_.MATCH_CATALOG_ID as MATCH11_6_0_, mc1_.ADDRESS_IMPORT_DATE as ADDRESS12_6_0_ from MATCH_MAILING_CAMPAIGN this_ inner join MATCH_CAMPAIGN_INFO mc1_ on this_.CAMPAIGN_ID=mc1_.ID where mc1_.ID>=1 However, removing the restriction yields the following sql: select top 10 this_.ID as ID17_0_, this_.KEYCODE as KEYCODE17_0_, this_.CAMPAIGN_ID as CAMPAIGN3_17_0_, this_.MAILING_LIST_MAILING_ID as MAILING4_17_0_, this_.COUNTRY_LE_ID as COUNTRY5_17_0_, this_.MATCH_ADDRESS as MATCH6_17_0_, this_.ADDRESS as ADDRESS17_0_, this_.MATCH_NAME as MATCH8_17_0_, this_.FIRST_NAME as FIRST9_17_0_, this_.LAST_NAME as LAST10_17_0_, this_.ZIP_CODE as ZIP11_17_0_, this_.CITY as CITY17_0_, this_.STATE as STATE17_0_, this_.COMPANY as COMPANY17_0_ from MATCH_MAILING_CAMPAIGN this_ Performing the original query in its HQL analog does not have this 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

15 years, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy

by Shawn Clowater (JIRA)

Create the EntityPersisters in order based on Inheritance hierarchy ------------------------------------------------------------------- Key: HHH-2544 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.3 Reporter: Shawn Clowater Priority: Minor I have a bit of what might seem to be an odd request. I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters. In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter. So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister. So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up. This is done like this because by the time it gets to the AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built. So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters. I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself. Now, normally you can't define the filter on the subclass but I can through the persister. What I'd like to do is: Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass. Still have my root class' entity persister adding the filters. But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl. Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder 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

15 years, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4787) AuditProperty.isNull() doesn't generate "tab.col is null" SQL clause as expected

by Eric Citaire (JIRA)

AuditProperty.isNull() doesn't generate "tab.col is null" SQL clause as expected -------------------------------------------------------------------------------- Key: HHH-4787 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4787 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.0.GA Environment: Hibernate 3.3.0.GA, Envers 1.2.2, HSQLDB Database Reporter: Eric Citaire Priority: Critical AuditProperty.isNull() generate a SQL condition like this : "tab.col=?" where the bind variable is mapped to a null value. This doesn't work : most database engines will return false in every case. It should use the "is null" test instead : "tab.col is null" http://en.wikipedia.org/wiki/SQL#Null_and_Three-Valued_Logic_.283VL.29 -- 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

15 years, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2579) scope bytecode provider selection to session factory

by Steve Ebersole (JIRA)

scope bytecode provider selection to session factory ---------------------------------------------------- Key: HHH-2579 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2579 Project: Hibernate3 Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: cfg-rework currently this is one of those "static" config params (classloader wide). -- 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

15 years, 2 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3574) ANY mapping ignores lazy="false"

by Manuel Dominguez Sarmiento (JIRA)

ANY mapping ignores lazy="false" -------------------------------- Key: HHH-3574 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3574 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Manuel Dominguez Sarmiento We have a use case for eager fetching of an <any> association. The DTD accepts lazy="false|true", however at runtime it doesn't make any difference. Digging deeper, we see that org.hibernate.mapping.Any does not have a lazy property, furthermore, it does not extend Fetchable. This explains why it will not work as expected. There are two possible resolutions: 1) Implement eager fetching for <any> associations, unless there is some technical difficulty in doing so. Of course lazy fetching won't be possible using joins because of the nature of this type of associations, however it should be simple enough with a second select. This means that the XML config should handle lazy="false|true" but not fetch="join|select|subselect|etc" 2) Fix the DTD in case this can't be done to avoid confusion (less desirable). -- 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

15 years, 2 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010