[Hibernate-JIRA] Created: (HHH-4838) 2L-Querycache ImmutableNaturalKeyLookup not properly recognized as hasImmutableNaturalId() is called on wrong EntityMetamodel
by Guenther Demetz (JIRA)
2L-Querycache ImmutableNaturalKeyLookup not properly recognized as hasImmutableNaturalId() is called on wrong EntityMetamodel
-----------------------------------------------------------------------------------------------------------------------------
Key: HHH-4838
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4838
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.0-Beta-3
Environment: 3.5.0-Beta3, HSQLDB, EHCache as 2L cache implementation
Reporter: Guenther Demetz
Attachments: TestImmutableNaturalId.jar
If a entityclass with immutable naturalId has non-lazy properties (for instance a OneToOne association),
then more entityPersisters are involved in the query as it becomes a join-query eager loading the associated entity.
The method Loader#getResultFromQueryCache presumes that the first entityPersister in the array is the main entity class.
boolean isImmutableNaturalKeyLookup = queryParameters.isNaturalKeyLookup()
&& getEntityPersisters()[0].getEntityMetamodel().hasImmutableNaturalId();
Debugging attached testcase you can see indeed that getEntityPersisters()[0] returns SingleTableEntityPersister(hello.D)
which is the persister of the associated entity, not the main one!
Consequently the query is not considered as isImmutableNaturalKeyLookup, despite fullfilling all conditions.
Here my output (with enabled p6spy):
11:53:15,651 INFO Version:37 - Hibernate Annotations 3.5.0.Beta1
11:53:15,690 INFO Environment:563 - Hibernate 3.5.0-Beta-3
11:53:15,694 INFO Environment:596 - hibernate.properties not found
11:53:15,700 INFO Environment:774 - Bytecode provider name : javassist
11:53:15,706 INFO Environment:655 - using JDK 1.4 java.sql.Timestamp handling
11:53:15,863 INFO Version:38 - Hibernate EntityManager 3.5.0.Beta1
11:53:16,356 INFO AnnotationBinder:446 - Binding entity from annotated class: hello.A
11:53:16,424 INFO EntityBinder:471 - Bind entity hello.A on table A
11:53:16,526 INFO AnnotationBinder:446 - Binding entity from annotated class: hello.D
11:53:16,527 INFO EntityBinder:471 - Bind entity hello.D on table D
11:53:16,686 WARN Ejb3Configuration:943 - hibernate.connection.autocommit = false break the EJB3 specification
11:53:16,702 INFO HibernateSearchEventListenerRegister:75 - Unable to find org.hibernate.search.event.FullTextIndexEventListener on the classpath. Hibernate Search is not enabled.
11:53:16,718 INFO DriverManagerConnectionProvider:64 - Using Hibernate built-in connection pool (not for production use!)
11:53:16,719 INFO DriverManagerConnectionProvider:65 - Hibernate connection pool size: 20
11:53:16,720 INFO DriverManagerConnectionProvider:68 - autocommit mode: false
11:53:16,921 INFO DriverManagerConnectionProvider:103 - using driver: com.p6spy.engine.spy.P6SpyDriver at URL: jdbc:hsqldb:hsql://localhost
11:53:16,922 INFO DriverManagerConnectionProvider:109 - connection properties: {user=sa, password=****, autocommit=false, release_mode=after_transaction}
11:53:17,002 INFO SettingsFactory:117 - RDBMS: HSQL Database Engine, version: 1.8.0
11:53:17,004 INFO SettingsFactory:118 - JDBC driver: HSQL Database Engine Driver, version: 1.8.0
11:53:17,068 INFO Dialect:223 - Using dialect: org.hibernate.dialect.HSQLDialect
11:53:17,082 INFO JdbcSupportLoader:79 - Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4
11:53:17,085 INFO TransactionFactoryFactory:62 - Transaction strategy: org.hibernate.transaction.JDBCTransactionFactory
11:53:17,089 INFO TransactionManagerLookupFactory:80 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
11:53:17,090 INFO SettingsFactory:169 - Automatic flush during beforeCompletion(): disabled
11:53:17,091 INFO SettingsFactory:173 - Automatic session close at end of transaction: disabled
11:53:17,097 INFO SettingsFactory:188 - Scrollable result sets: enabled
11:53:17,098 INFO SettingsFactory:196 - JDBC3 getGeneratedKeys(): disabled
11:53:17,099 INFO SettingsFactory:204 - Connection release mode: after_transaction
11:53:17,101 INFO SettingsFactory:231 - Default batch fetch size: 1
11:53:17,103 INFO SettingsFactory:235 - Generate SQL with comments: disabled
11:53:17,104 INFO SettingsFactory:239 - Order SQL updates by primary key: disabled
11:53:17,105 INFO SettingsFactory:243 - Order SQL inserts for batching: disabled
11:53:17,107 INFO SettingsFactory:410 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
11:53:17,114 INFO SettingsFactory:251 - Query language substitutions: {}
11:53:17,115 INFO SettingsFactory:256 - JPA-QL strict compliance: enabled
11:53:17,121 INFO SettingsFactory:261 - Second-level cache: enabled
11:53:17,130 INFO SettingsFactory:265 - Query cache: enabled
11:53:17,143 INFO SettingsFactory:395 - Cache region factory : org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge
11:53:17,144 INFO RegionFactoryCacheProviderBridge:61 - Cache provider: net.sf.ehcache.hibernate.SingletonEhCacheProvider
11:53:17,150 INFO SettingsFactory:275 - Optimize cache for minimal puts: disabled
11:53:17,151 INFO SettingsFactory:284 - Structured second-level cache entries: disabled
11:53:17,151 INFO SettingsFactory:374 - Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
11:53:17,165 INFO SettingsFactory:313 - Statistics: disabled
11:53:17,166 INFO SettingsFactory:317 - Deleted entity synthetic identifier rollback: disabled
11:53:17,166 INFO SettingsFactory:332 - Default entity-mode: pojo
11:53:17,167 INFO SettingsFactory:336 - Named query checking : enabled
11:53:17,167 INFO SettingsFactory:340 - Check Nullability in Core (should be disabled when Bean Validation is on): disabled
11:53:17,240 INFO SessionFactoryImpl:197 - building session factory
11:53:17,260 WARN ConfigurationFactory:131 - No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/home/pb00067/Desktop/ehcache-1.7.1/lib/ehcache-core-1.7.1.jar!/ehcache-failsafe.xml
11:53:17,361 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [hello.A]; using defaults.
11:53:17,566 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [hello.D]; using defaults.
11:53:17,661 INFO SchemaExport:226 - Running hbm2ddl schema export
11:53:17,663 INFO SchemaExport:251 - exporting generated schema to database
p6spy - 1264416797664|0|0|commit||
p6spy - 1264416797670|1|0|statement
alter table A drop constraint FK41F7BDC12E
p6spy - 1264416797672|0|0|statement
drop table A if exists
p6spy - 1264416797673|0|0|statement
drop table D if exists
p6spy - 1264416797674|1|0|statement
drop table hibernate_sequences if exists
p6spy - 1264416797675|1|0|statement
create table A (oid bigint not null, name varchar(255), version integer not null, assSingleD_oid bigint, primary key (oid), unique (name))
p6spy - 1264416797676|0|0|statement
create table D (oid bigint not null, version integer not null, primary key (oid))
p6spy - 1264416797678|1|0|statement
alter table A add constraint FK41F7BDC12E foreign key (assSingleD_oid) references D
p6spy - 1264416797679|1|0|statement
create table hibernate_sequences ( sequence_name varchar(255), sequence_next_hi_value integer )
11:53:17,679 INFO SchemaExport:268 - schema export complete
11:53:17,684 INFO UpdateTimestampsCache:57 - starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache
11:53:17,686 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [org.hibernate.cache.UpdateTimestampsCache]; using defaults.
11:53:17,689 INFO StandardQueryCache:75 - starting query cache at region: org.hibernate.cache.StandardQueryCache
11:53:17,690 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [org.hibernate.cache.StandardQueryCache]; using defaults.
11:53:17,841 DEBUG ConnectionManager:444 - opening JDBC connection
p6spy - 1264416797874|6|1|statement
select
sequence_next_hi_value
from
hibernate_sequences
where
sequence_name = 'A'
p6spy - 1264416797876|0|1|statement
insert
into
hibernate_sequences
(sequence_name, sequence_next_hi_value)
values
('A', 0)
p6spy - 1264416797878|0|1|statement
update
hibernate_sequences
set
sequence_next_hi_value = 1
where
sequence_next_hi_value = 0
and sequence_name = 'A'
p6spy - 1264416797879|0|1|commit||
p6spy - 1264416797915|0|0|statement
insert
into
A
(assSingleD_oid, name, version, oid)
values
('', 'name1', 0, 1)
11:53:17,919 DEBUG UpdateTimestampsCache:66 - Pre-invalidating space [A]
p6spy - 1264416797931|0|0|commit||
11:53:17,934 DEBUG UpdateTimestampsCache:81 - Invalidating space [A], timestamp: 5179051204337665
11:53:17,974 DEBUG StandardQueryCache:127 - checking cached query results in region: org.hibernate.cache.StandardQueryCache
11:53:17,975 DEBUG StandardQueryCache:132 - query results were not found in cache
p6spy - 1264416797978|0|0|statement
select
this_.oid as oid0_1_,
this_.assSingleD_oid as assSingleD4_0_1_,
this_.name as name0_1_,
this_.version as version0_1_,
d2_.oid as oid1_0_,
d2_.version as version1_0_
from
A this_
left outer join
D d2_
on this_.assSingleD_oid=d2_.oid
where
(
this_.name='name1'
)
p6spy - 1264416797981|-1||resultset|oid=1, oid=null
11:53:17,985 DEBUG StandardQueryCache:94 - caching query results in region: org.hibernate.cache.StandardQueryCache; timestamp=5179051204546560
11:53:17,992 DEBUG StandardQueryCache:127 - checking cached query results in region: org.hibernate.cache.StandardQueryCache
11:53:17,993 DEBUG StandardQueryCache:185 - Checking query spaces for up-to-dateness: [A]
11:53:17,994 DEBUG UpdateTimestampsCache:102 - [A] last update timestamp: 5179051204337665, result set timestamp: 5179051204546560
11:53:17,994 DEBUG StandardQueryCache:142 - returning cached query results
11:53:17,997 INFO SessionFactoryImpl:908 - closing
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-6295) @ElementCollection @Lob List<byte[]> fails
by Aleksei Valikov (JIRA)
@ElementCollection @Lob List<byte[]> fails
------------------------------------------
Key: HHH-6295
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6295
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.6.4
Reporter: Aleksei Valikov
I am trying to map a List of {{byte[]}} as a @Lob @ElementCollection with no success.
Below are test cases.
Variant 1 (without targetClass):
{code}
@Entity
public class G {
private String id;
@Id
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
private List<byte[]> bytes;
@ElementCollection
@Lob
public List<byte[]> getBytes() {
return bytes;
}
public void setBytes(List<byte[]> bytes) {
this.bytes = bytes;
}
}
{code}
Stack trace:
{code}javax.persistence.PersistenceException: [PersistenceUnit: org.jvnet.hyperjaxb3.hibernate.tests.hhh] Unable to configure EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:378)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at org.jvnet.hyperjaxb3.hibernate.tests.hhh.EntityManagerFactoryTest.entityManagerFactoryCreated(EntityManagerFactoryTest.java:22)
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:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.hibernate.AnnotationException: Collection has neither generic type or OneToMany.targetEntity() defined: org.jvnet.hyperjaxb3.hibernate.tests.hhh.G.bytes
at org.hibernate.cfg.annotations.CollectionBinder.getCollectionType(CollectionBinder.java:621)
at org.hibernate.cfg.annotations.CollectionBinder.bind(CollectionBinder.java:509)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1979)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:796)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:707)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:4035)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3989)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1398)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1375)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1519)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1100)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:282)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:366)
... 25 more
{code}
Variant 2 (with targetClass):
{code}
@Entity
public class G {
private String id;
@Id
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
private List<byte[]> bytes;
@ElementCollection(targetClass=byte[].class)
@Lob
public List<byte[]> getBytes() {
return bytes;
}
public void setBytes(List<byte[]> bytes) {
this.bytes = bytes;
}
}{code}
Stack trace:
{code}
org.hibernate.annotations.common.AssertionFailure: Fail to process type argument in a generic declaration. Member : org.jvnet.hyperjaxb3.hibernate.tests.hhh.G#getBytes Type: class sun.reflect.generics.reflectiveObjects.GenericArrayTypeImpl
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.getClassFromGenericArgument(AttributeFactory.java:846)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:756)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:731)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:518)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:93)
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)
{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, 1 month
[Hibernate-JIRA] Created: (HHH-5300) Configurable strong and soft reference QueryPlanCache sizes
by Manuel Dominguez Sarmiento (JIRA)
Configurable strong and soft reference QueryPlanCache sizes
-----------------------------------------------------------
Key: HHH-5300
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5300
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.5.2, 3.5.1, 3.5.0-Final
Environment: N/A
Reporter: Manuel Dominguez Sarmiento
Some of our production servers (Hibernate-based apps) have been hanging on full GC sporadically, most of the time after running normally for a few days, sometimes even over a week.
We suspected a memory leak. We used the Eclipse MAT tool to analyze a live heap dump, and found that most of the heap was being used by QueryPlanCache, most specifically, by the soft references held by SoftLimitMRUCache.
We use very large heaps (up to 30 GB in some cases). Since memory is plentiful and the SoftLimitMRUCache is unbounded, the heap eventually fills up until a major stop-the-world GC is necessary to cleanse the SoftLimitMRUCache soft references. We performed several live tests configuring the Concurrent-Mark-Sweep (CMS) GC collector in order to avoid the full GC caused by concurrent mode failures. We played around with the following settings available in the Sun JVM:
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycle=<PCT>
-XX:CMSIncrementalDutyCycleMin=<PCT>
-XX:CMSInitiatingOccupancyFraction=<PCT>
-XX:CMSMarkStackSize=<SIZE>
-XX:CMSMarkStackSizeMax=<SIZE>
-XX:SoftRefLRUPolicyMSPerMB=<MSECS>
-XX:+ParallelRefProcEnabled
Most of these options helped somewhat by allowing soft-reference GC to be performed in parallel, ahead of time before tipping the scales and requiring full GC. However, this did not avoid all problems, and the servers still periodically hang upon concurrent mode failures. These are high-load web servers which process hundreds of hits per second, so full GC is disastrous as garbage cannot be collected fast enough. Full GC would sometimes take over 15 minutes, sometimes it would not even finish doing its job requiring a manual app restart.
Before anyone cries out "well, it's probably the application's fault, why do you have so many different queries? Aren't you using parameterized queries / PreparedStatements?" - the application does in fact produce many, many different queries, but most of them are not reused. Even if the QueryPlanCache is highly effective, most of the absolute number of queries are issued only once. Some use cases are the following:
- Our system allows ad-hoc reporting and searching capabilities. Each query is typically issued once and never reused.
- Many of our parameterized queries use IN clauses with variable-length collection/array parameters. I'm unsure whether this affects the cache hit ratio for HQL query plans, but it sure affects native SQL queries, since multiple collection lengths means multiple "?" in the query string, and thus, multiple similar, if slightly different queries polluting the corresponding plan cache.
I'm sure there are other legitimate cases in which an unbounded query plan cache is also a problem, I'm just enumerating the ones we've run into.
This issue is not new. The same problem is described, in one way or another, by HHH-2431, HHH-3191, and HHH-4627. I created a new issue since we've produced a working patch and it would be made more visible, rather than as comments in the previous ones.
The solution involves giving up the unbounded soft-reference-based cache. We introduced two new configuration options:
- hibernate.query.plan_cache_max_strong_references -> defaults to 128
- hibernate.query.plan_cache_max_soft_references -> defaults to 2048
Entries are evicted using an LRU policy, or by memory pressure from the GC in the case of soft references. We used 2048 as a default for the soft size since it seems pretty reasonable, but of course it can be tuned to suit the user's needs. Users looking to emulate previous behaviour (we don't see the point, but who knows ...) can set this option to Integer.MAX_VALUE
The patch introduces no new dependencies. It uses Apache Commons Collections' LRUMap (just as the released version does), and does away with the ReferenceMap (which does not support LRU eviction) in order to manage soft references manually on top of an LRUMap.
We see this issue as a top priority and should be applied to the trunk ASAP. SoftLimitMRUCache has seen the most "radical" changes. SimpleMRUCache, QueryPlanCache and Environment only contain minor changes.
--
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, 1 month
[Hibernate-JIRA] Created: (HV-345) Run automated diff between project model constraints and database model constraints
by Roman Arkadijovych Muntyanu (JIRA)
Run automated diff between project model constraints and database model constraints
-----------------------------------------------------------------------------------
Key: HV-345
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-345
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Affects Versions: 4.2.0
Reporter: Roman Arkadijovych Muntyanu
Assignee: Hardy Ferentschik
[This feature request has been added to this project due to relation to Java-level constraint validation. Please feel free moving it to appropriate project]
Since constraints validation is added at Java model level, it would be interesting to write a tool, that would do the following during application start-up:
* poll the database for schema;
* poll hibernate for XML/JPA Mappings;
* compare two of the above to constraints defined through validation framework and generate warnings in the logs.
For the initial version this could be simple checks like size of field defined in DB and in the model, field mandatority etc.
This would help a lot in keeping consistency between database and business constraints model.
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-5832) JPA Query and IdClass Causing NullPointerException
by Erich Heard (JIRA)
JPA Query and IdClass Causing NullPointerException
--------------------------------------------------
Key: HHH-5832
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5832
Project: Hibernate Core
Issue Type: Bug
Components: metamodel
Affects Versions: 3.5.1
Environment: Hibernate version 3.5.1 and Oracle 10g.
Reporter: Erich Heard
We had an issue when building queries dynamically with JPA objects when we accessed an @Id property of an entity class that used @IdClass. Under these conditions, Path.get( ) would return null. Here is a short illustration:
The entity was specified like:
@Entity
// snipped more annotations
@IdClass( RetailerId.class )
public class Retailer {
@Id
private String retailerId;
public String getRetailerId( ) { return this.retailerId; }
public void setRetailerId( String value ) { this.retailerId = value; }
@Id
private String divisionCode;
public String getDivisionCode( ) { return this.divisionCode; }
public void setDivisionCode( String value ) { this.divisionCode = value; }
// snipped other attributes
}
And the ID class was specified like:
@Embeddable
public class RetailerId implements Serializable {
private static final long serialVersionUID = -2639451633891197777L;
@Column( name = "RETLR_ID", nullable = false, length = 7 )
private String retailerId;
public String getRetailerId( ) { return this.retailerId; }
public void setRetailerId( String value ) { this.retailerId = value; }
@Column( name = "DIV_CDE", nullable = false, length = 2 )
private String divisionCode;
public String getDivisionCode( ) { return this.divisionCode; }
public void setDivisionCode( String value ) { this.divisionCode = value; }
// snipped implementations of Serializable methods
}
The code that caused the error condition:
CriteriaQuery<RetailerConfigurationPreference> query = cb.createQuery(RetailerConfigurationPreference.class);
Root<RetailerConfigurationPreference> root = query.from(RetailerConfigurationPreference.class);
Predicate predicate = root.get("retailer").get("retailerId").in(retailerIds);
In this case, the 'get("retailerId")' would return null. To get around this issue, I altered the class org.hibernate.ejb.metamodel.AbstractIdentifiableType and overrode its super method getAttribute() to check the ID class for the attribute before deferring to its superclass.
@Override
public Attribute<? super X, ?> getAttribute(String name) {
if( this.idClassAttributes != null ) {
Attribute<? super X, ?> attribute = null;
Iterator<SingularAttribute<? super X, ?>> i = this.idClassAttributes.iterator( );
while( i.hasNext( ) ) {
attribute = i.next( );
if( attribute.getName( ).equals( name ) ) return attribute;
}
}
return super.getAttribute( name );
}
I didn't test this with EmbeddedId - that may work as is or it may need a case of its own. This is the first time I've submitted anything here, so I apologize if it is not to form.
--
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, 1 month
[Hibernate-JIRA] Created: (BVAL-224) Provide a way for accessing default implementations for XML configured bootstrap artifacts
by Gunnar Morling (JIRA)
Provide a way for accessing default implementations for XML configured bootstrap artifacts
------------------------------------------------------------------------------------------
Key: BVAL-224
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-224
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Reporter: Gunnar Morling
Using {{validation.xml}} one can specify custom implementations for constraint validator factory, message interpolator etc. Right now there is no way to delegate from within these custom implementations to the default ones. This would be possible when using the configuration API:
{code}
HibernateValidatorConfiguration configuration = Validation.byProvider(HibernateValidator.class).configure();
ConstraintValidatorFactory defaultFactory = configuration.getDefaultConstraintValidatorFactory();
ConstraintValidatorFactory customFactory = new CustomConstraintValidatorFactory(defaultFactory);
configuration.constraintValidatorFactory(customFactory);
{code}
One idea to allow for such a delegation is to support constructors taking the default implementation as parameter:
{code}
CustomConstraintValidatorFactory implements ConstraintValidatorFactory {
ConstraintValidatorFactory delegate;
CustomConstraintValidatorFactory(ConstraintValidatorFactory defaultFactory) {
this.delegate = defaultFactory;
}
}
{code}
For XML-configured artifacts the runtime could invoke this delegate constructor if existent, otherwise the default constructor could be invoked.
--
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, 1 month
[Hibernate-JIRA] Created: (HV-492) Validation of CGLIB enhanced Objects always return null
by Christian Fehmer (JIRA)
Validation of CGLIB enhanced Objects always return null
-------------------------------------------------------
Key: HV-492
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-492
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.2.0.Beta2, 4.1.0.Final
Environment: Hibernate Validator 4.1.0-final and 4.2.0-BETA2, cglib 2.2
Reporter: Christian Fehmer
A validation of a cglib enhanced object will always validate "null".
The validator (i tested it with an custom validator) always gets "null" as the value in the isValid method. The cglib enhanced object has a field "selection" and a getter/setter pair for this field. The hibernate validator uses the org.hibernate.validator.util.ReflectionHelper to access the field selection directly. That fails on a cglib enhanced object.
My workaround for now: I replaced the org.hibernate.validator.util.ReflectionHelper.getValue method. When object is a cglib enhanced object i invoke the getter method instead of accessing the field directly.
replaced method:
public static Object getValue(Member member, Object object) {
Object value = null;
if (member instanceof Method) {
...
} else if (member instanceof Field) {
// FIX: use getter method on cglib fields
if (object.getClass().getName().contains("$$")) {
String methodName = member.getName();
methodName = "get"+ String.valueOf(methodName.charAt(0)).toUpperCase()+ methodName.substring(1);
try {
Method method = member.getDeclaringClass().getMethod(
methodName);
method.setAccessible(true);
value = method.invoke(object);
} catch (Exception e) {
throw new ValidationException("Unable to access "
+ methodName, e);
}
} else {
...
}
}
return value;
}
--
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, 1 month