[Hibernate-JIRA] Created: (HHH-3502) getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
by Sean Bridges (JIRA)
getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
----------------------------------------------------------------------------------------------------------------------------
Key: HHH-3502
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3502
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Sean Bridges
Priority: Minor
I have an entity interface,
public interface IEntity {
public Object getId();
}
and I have an entity, say User that implements this interface with an id method
@Id
public Long getId() {
return id;
}
I can call getId() on an uninitialized proxy with,
user.getId()
however, if I call getId() in this way,
((IEntity) user)).getId()
I get org.hibernate.LazyInitializationException: could not initialize proxy - no Session
Looking at the code, BasicLazyInitializer has these lines,
else if ( isUninitialized() && method.equals(getIdentifierMethod) ) {
return getIdentifier();
}
the method.equals(getIdentifierMethod) returns false. The methods are not equal() because they have different return types (this is allowed in 1.5 with covariant return types).
Hibernate should not use Method.equals(), but should instead use the code below (modified from Method.equals(Object)),
public boolean equalsIgnoringReturnType(Method m1, Method m2) {
if ((m1.getDeclaringClass() != m2.getDeclaringClass()) {
return false;
}
if (m1.getName() != m2.getName()) {
return false;
}
Class[] params1 = m1.getParameterTypes();
Class[] params2 = m2.getParameterTypes();
if (params1.length != params2.length) {
return false;
}
for (int i = 0; i < params1.length; i++) {
if (params1[i] != params2[i])
return false;
}
return true;
}
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-2744) QueryException raised for valid SQL query - problems with aliases parsing
by Michal Jastak (JIRA)
QueryException raised for valid SQL query - problems with aliases parsing
-------------------------------------------------------------------------
Key: HHH-2744
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2744
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Tomcat 5.5, Hibernate Annotations 3.3.0 ga
Reporter: Michal Jastak
SQLQuery parser dose not parse queries correctly.
Trying to invoke:
session.createSQLQuery("select foo from bar where foo like '{%'");
ends with:
rg.hibernate.QueryException: Unmatched braces for alias path [select foo from bar where foo like '{%']
at org.hibernate.loader.custom.sql.SQLQueryParser.substituteBrackets(SQLQueryParser.java:74)
at org.hibernate.loader.custom.sql.SQLQueryParser.process(SQLQueryParser.java:51)
at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:110)
at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43)
at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114)
at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-5704) New getSubString() handling in ClobProxy is incompatible with MySQL JDBC PS.setClob(int, Clob) for empty CLOB
by Sergey Vladimirov (JIRA)
New getSubString() handling in ClobProxy is incompatible with MySQL JDBC PS.setClob(int, Clob) for empty CLOB
-------------------------------------------------------------------------------------------------------------
Key: HHH-5704
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5704
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.0
Environment: MySQL JDBC 5.1.12 / 5.1.13
Reporter: Sergey Vladimirov
For all empty but not-null CLOBs MySQL drivers do the following (com.mysql.jdbc.PreparedStatement):
String forcedEncoding = this.connection.getClobCharacterEncoding();
if (forcedEncoding == null) {
setString(i, x.getSubString(1L, (int) x.length()));
} else {
try {
setBytes(i, x.getSubString(1L,
(int)x.length()).getBytes(forcedEncoding));
} catch (UnsupportedEncodingException uee) {
throw SQLError.createSQLException("Unsupported character encoding " +
forcedEncoding, SQLError.SQL_STATE_ILLEGAL_ARGUMENT, getExceptionInterceptor());
}
}
As you can see, getSubString is called with first argument (start) equal to 1, even if length of CLOB is 0. Of course, it's not very good, but it worked for previous versions of Hibernate. But in 3.6.0 getSubString() handling in ClobProxy introduces additional checks that prevents the code above from working:
if ( start > getLength() ) {
throw new SQLException( "Start position [" + start + "] cannot exceed overall CLOB length [" + getLength() + "]" );
}
Thus this code will now thrown an exception if content is empty (but not null!) CLOB. Here the part of stack trace:
31.10 16:46:03 .AbstractFlushingEventListener ERROR Could not synchronize database state with session
org.hibernate.exception.GenericJDBCException: could not insert: [ru.arptek.classes.dummy.Article$Content]
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:140)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:128)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2436)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2856)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:795)
at ru.arptek.arpsite.content.WebObjectHome.create(WebObjectHome.java:122)
(...)
Caused by: java.sql.SQLException: Start position [1] cannot exceed overall CLOB length [0]
at org.hibernate.engine.jdbc.ClobProxy.invoke(ClobProxy.java:146)
at $Proxy52.getSubString(Unknown Source)
at com.mysql.jdbc.PreparedStatement.setClob(PreparedStatement.java:3542)
at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.setClob(PreparedStatementWrapper.java:299)
at org.apache.commons.dbcp.DelegatingPreparedStatement.setClob(DelegatingPreparedStatement.java:187)
at org.apache.commons.dbcp.DelegatingPreparedStatement.setClob(DelegatingPreparedStatement.java:187)
at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$1.doBind(ClobTypeDescriptor.java:60)
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:89)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:282)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277)
at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:85)
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2166)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2412)
... 70 more
I believe there should be additional check like:
long start = (Long) args[0];
if ( start < 1 ) {
throw new SQLException( "Start position 1-based; must be 1 or more." );
}
int length = (Integer) args[1];
if ( length < 0 ) {
throw new SQLException( "Length must be great-than-or-equal to zero." );
}
// workaround for MySQL incompatibility
if ( start == 1 && length == 0) {
return "";
} else if ( start > getLength() ) {
throw new SQLException( "Start position [" + start + "] cannot exceed overall CLOB length [" + getLength() + "]" );
}
return getSubString( start-1, length );
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-3826) Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
by Charles Moulliard (JIRA)
Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3826
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3826
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Charles Moulliard
Hi,
I try to use Hibernate 3.3.1.GA in combination with Spring OSGI 1.2.0-rc1. Unfortunately, there is a classloading issue on OSGI :
{code}
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:162)
... 58 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170)
... 59 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
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 javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 60 more
{code}
remark : the package org.hibernate.proxy is defined in the MANIFEST file (section - Import-PAckage)
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HV-409) Provide the possibility to specify parameter names for reporting method level constraint violations
by Gunnar Morling (JIRA)
Provide the possibility to specify parameter names for reporting method level constraint violations
---------------------------------------------------------------------------------------------------
Key: HV-409
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-409
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Gunnar Morling
When reporting a method level constraint violation besides the concerned method the parameter causing the violation is a substantial information. As the Java byte code usually doesn't contain any information on parameter names only the index of the parameter can be returned in the resulting MethodConstraintViolation.
In order to produce expressive constraint violations it is desirable to have the possibility to specify parameter names in some way. One approach for this might be to allow parameter names being specified with the help of an appropriate annotation. Using JSR 330's @Named annotation for instance this could look like this:
{code:java}
someMethod(@Named("param1") @NotNull String param1, @Named("customer") @NotNull @Valid Customer customer) {
//...
}
{code}
In case any of the method's constraints is violated the resulting MethodConstraintViolation would refer to this name in getName() and getPropertyPath():
{code:java}
assertEquals( constraintViolation.getParameterName(), "customer" );
assertEquals(
constraintViolation.getPropertyPath().toString(),
"SomeType#someMethod(customer).name"
);
{code}
This approach was prototyped in https://github.com/gunnarmorling/hibernate-validator/commits/method-level... but was removed for HV 4.2 with [e7e3c5f6e97d850b65579fc542599d4c9241048d|https://github.com/gunnarmorling...] and [8fbc2cca1481563309a03f58ccb4037134772801|https://github.com/gunnarmorling...] to have time for some more considerations.
In especially an algorithm for retrieving the effective name of a method parameter has to be defined. This might look like this:
* If the validated method doesn't override any method from a super type the parameter names are taken from this method (if given)
* If the validated method does override a method from a super type, the closest names found up in the inheritance tree are taken (e.g. when validating A#foo() overriding B#foo() in turn overriding C#foo() and both B and C provide parameter names for foo(), then the names from B#foo() are taken)
* If the name for a parameter is given in two or more equally distant types, the names of any from the closest types are taken, from which of this is not defined (e.g. when validating A#foo() implementing B#foo() and C#foo() and both B and C specify parameter names for foo(), the names either from B or C are taken)
When implementing this feature HV should not require new strict dependencies; so if for instance working with @Named, javax.inject-1.jar should be added in optional scope and the type javax.inject.Named should be accessed only using reflection.
--
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
11 years, 10 months