[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
14 years, 11 months
[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
14 years, 11 months
[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
14 years, 11 months
[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
14 years, 11 months
[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
14 years, 11 months