[Hibernate-JIRA] Created: (HHH-6639) Error using dynamic-component with JPA
by Wölfle (JIRA)
Error using dynamic-component with JPA
--------------------------------------
Key: HHH-6639
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6639
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.7
Environment: MySQL 5.0.1, Java 1.6.0_26
Reporter: Wölfle
Attachments: testJPA.tar.gz
Hi,
there seems to be a bug when using dynamic-components and an EntityManager.
When using hibernate directly, everything works fine. If using the EntityManager, the following exception is thrown, because for the dynamic attributes no members in the Entity class exist (which is the intention of dynamic-attributes, as far as I understood them).
Exception in thread "main" java.lang.IllegalArgumentException: Cannot determine java-type from given member [null]
at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:608)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:696)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:686)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:559)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:93)
at org.hibernate.ejb.metamodel.AttributeFactory.getMetaModelType(AttributeFactory.java:225)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:102)
at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:187)
at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:84)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at test.Test.main(Test.java:24)
Attached is a tar.tz file with a sample hibernate project and a junit test that reproduces the problem.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-6280) JPA criteria API don't bind numeric field
by gwa (JIRA)
JPA criteria API don't bind numeric field
-----------------------------------------
Key: HHH-6280
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6280
Project: Hibernate Core
Issue Type: Improvement
Components: entity-manager
Affects Versions: 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1
Reporter: gwa
When you use JPA criteria API, the numeric value are not binded but are directly set in the SQL instead.
eq: you have a generated SQL like:
select ... from ... where age=12;
instead of
select ... from ... where age=?;
With '12' as parameter.
when you test the following code:
{code:java}
@Entity
public class User {
@Id
private int id;
private int age;
...
}
{code}
{code:java}
CriteriaBuilder builder=em.getCriteriaBuilder();
CriteriaQuery<User> query=builder.createQuery(User.class);
Root<User> root=query.from(User.class);
query.select(root).where(builder.equal(root.get("age"),12));
em.createQuery(query).getResultList();
{code}
--
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
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-5798) Is it really necessary to explicitly specifiy discriminatorValue for abstract classes?
by Oleksandr Alesinskyy (JIRA)
Is it really necessary to explicitly specifiy discriminatorValue for abstract classes?
--------------------------------------------------------------------------------------
Key: HHH-5798
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5798
Project: Hibernate Core
Issue Type: Improvement
Components: entity-manager
Affects Versions: 3.6.0
Reporter: Oleksandr Alesinskyy
At the time being if the SINGLE_TABLE inheritance strategy is used, the discriminator type is set to char and some abstract classes in the hierarchy do not have an explicit discriminator value specified the following error occurs:
{quote}
Caused by: org.hibernate.AnnotationException: Using default @DiscriminatorValue for a discriminator of type CHAR is not safe
at org.hibernate.cfg.annotations.EntityBinder.bindDiscriminatorValue(EntityBinder.java:373)
at org.hibernate.cfg.annotations.EntityBinder.bindEntity(EntityBinder.java:200)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:586)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3977)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3931)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1368)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1345)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1477)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1096)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:685)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
{quote}
At the same time it is clear that no one row in the corresponding table may represent the abstract class, so it is absolutely safe to completely ignore abstract classes when decision is made which class is represented by a row.
--
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
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7309) Natural-id not cached in shared cache after insert
by Guenther Demetz (JIRA)
Natural-id not cached in shared cache after insert
---------------------------------------------------
Key: HHH-7309
URL: https://hibernate.onjira.com/browse/HHH-7309
Project: Hibernate ORM
Issue Type: Bug
Components: caching (L2), testsuite
Affects Versions: 4.1.3
Environment: EHCache as 2L-cache implementation (or another 2L-cache implementation with default strict READ_WRITE access strategy)
Reporter: Guenther Demetz
Priority: Minor
Problem:
when using a 2L-cache implementation with default strict READ_WRITE access strategy,
then after inserting/updating a new entity and committing, the concerning Natural-id is not cached in shared cache.
Cause:
With strict READ_WRITE access strategy the improvement HHH-7279 "Prevent identical re-cachings in natural-id shared cache",
fails to prevent identical recachings for in-transaction-created entities, because with strict READ_WRITE the actual put is defered to transaction completition.
Recaching of identical natural-id-key, finally leaves the shared cache with valid entry.
Solution description(see following pullrequest):
To prove this in a hibernate matrix testcase, first I needed to enhance org.hibernate.testing.cache.CachingRegionFactory in manner that it also can return strict READ_WRITE as default access strategy, instead to always non-strict READ_WRITE.
Going deeper, I saw that org.hibernate.testing.cache.NonstrictReadWriteNaturalIdRegionAccessStrategy under some aspects was reflecting more a strict than a non-strict strategy,
this I fixed this and had finally convert CachingRegionFactory's default access type to strict READ_WRITE in order to have not a lot of matrix-testcases failing.
Further detail in following pullrequest...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-7155) Cleanup HibernateTypeHelper
by John Verhaeg (JIRA)
Cleanup HibernateTypeHelper
---------------------------
Key: HHH-7155
URL: https://hibernate.onjira.com/browse/HHH-7155
Project: Hibernate ORM
Issue Type: Task
Components: metamodel
Reporter: John Verhaeg
Assignee: John Verhaeg
Fix For: 5.0.0
Need to reduce the duplicate code in that class, as was done with Binder. Most of the methods deal with plural attributes. If it turns out the code reduces to just a couple of methods, and since Binder has been cleaned up to use consistent method names and has very little code for type resolution related to singular attributes, may want to consider once again merging the code back into Binder.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[Hibernate-JIRA] Created: (HHH-6066) Postgresql can not work with @Lob type
by Steve Ni (JIRA)
Postgresql can not work with @Lob type
--------------------------------------
Key: HHH-6066
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6066
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.6.1
Environment: Postgresql 8.x and JDBC driver 9.0-801.jdbc4
Reporter: Steve Ni
My application needs compatible with some major database such as Oracle, Mysql and Postgresql. I also use hibernatetool ant task to generate DDL. I use @Type(type="text") for string. Before 3.5 version, everything is OK. However, after 3.5 Oracel uses long instead clob type. As Long is deprecated type and the Oracle JDBC driver also has bug to read Long type with hibernate (Stream closed exception). So I try to use @Lob replaces @Type(type=text). The problem is this annotation doesn't work with postgresql.
Regarding to this issue, I did some research. The better fix could be Oracle use clob instead of Long. There is not good reason use deprecated type...
Here is exception:
org.springframework.dao.DataIntegrityViolationException: could not load an entity: [com.edgenius.core.model.Configuration#7]; nested exception is org.hibernate.exception.DataException: could not load an entity: [com.edgenius.core.model.Configuration#7]
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:639)
at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:424)
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374)
at org.springframework.orm.hibernate3.HibernateTemplate.find(HibernateTemplate.java:921)
at org.springframework.orm.hibernate3.HibernateTemplate.find(HibernateTemplate.java:917)
at com.edgenius.core.dao.hibernate.UserDAOHibernate.getUserByName(UserDAOHibernate.java:145)
at com.edgenius.core.dao.hibernate.UserDAOHibernate.loadUserByUsername(UserDAOHibernate.java:192)
at com.edgenius.wiki.security.acegi.TokenBasedRememberMeServices.processAutoLoginCookie(TokenBasedRememberMeServices.java:67)
at org.springframework.security.ui.rememberme.AbstractRememberMeServices.autoLogin(AbstractRememberMeServices.java:85)
at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:74)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:277)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at com.edgenius.wiki.security.acegi.CaptchaValidationProcessingFilter.doFilter(CaptchaValidationProcessingFilter.java:76)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:175)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.edgenius.core.webapp.filter.LocaleFilter.doFilterInternal(LocaleFilter.java:147)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.edgenius.wiki.webapp.filter.InstallFilter.doFilterInternal(InstallFilter.java:50)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.hibernate.exception.DataException: could not load an entity: [com.edgenius.core.model.Configuration#7]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:102)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.loadEntity(Loader.java:2041)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1038)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:630)
at org.hibernate.type.EntityType.resolve(EntityType.java:438)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:139)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:982)
at org.hibernate.loader.Loader.doQuery(Loader.java:857)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.doList(Loader.java:2533)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
at org.hibernate.loader.Loader.list(Loader.java:2271)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:452)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1268)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.springframework.orm.hibernate3.HibernateTemplate$30.doInHibernate(HibernateTemplate.java:930)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
... 51 more
Caused by: org.postgresql.util.PSQLException: Bad value for type long
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019)
at org.postgresql.jdbc4.Jdbc4ResultSet.getClob(Jdbc4ResultSet.java:43)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getClob(AbstractJdbc2ResultSet.java:384)
at org.apache.commons.dbcp.DelegatingResultSet.getClob(DelegatingResultSet.java:568)
at org.apache.commons.dbcp.DelegatingResultSet.getClob(DelegatingResultSet.java:568)
at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$4.doExtract(ClobTypeDescriptor.java:104)
at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:249)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:229)
at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:330)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2283)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1527)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1455)
at org.hibernate.loader.Loader.getRow(Loader.java:1355)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:611)
at org.hibernate.loader.Loader.doQuery(Loader.java:829)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.loadEntity(Loader.java:2037)
--
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
13 years, 7 months