[Hibernate-JIRA] Created: (HHH-3529) ConnectionWrapper is not visible from class loader
by Vladimir Kralik (JIRA)
ConnectionWrapper is not visible from class loader
---------------------------------------------------
Key: HHH-3529
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3529
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.2.6
Environment: SpringFramework 2.5.5, Hibernate 3.2.6 / 3.3.1, Tomcat 5.5, CommonJ Timer ( http://www.myfoo.de/commonj/ )
Reporter: Vladimir Kralik
Attachments: hibernate-3.2.6_p2.patch
Hibernate/Spring libraries are in app.war/WEB-INF/lib.
Timer is configured as resources in Tomcat and his libraries are in $CATALINA_HOME/common/lib/.
Function call from GUI works, but the same function called by timers gives this exception :
org.springframework.transaction.CannotCreateTransactionException: Could not openHibernate Session for transaction; nested exception is java.lang.IllegalArgumentException:
interface org.hibernate.jdbc.ConnectionWrapper is not visible from class loader
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:599)
....
Caused by: java.lang.IllegalArgumentException: interface org.hibernate.jdbc.ConnectionWrapper is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at org.hibernate.jdbc.BorrowedConnectionProxy.generateProxy(BorrowedConnectionProxy.java:67)
at org.hibernate.jdbc.ConnectionManager.borrowConnection(ConnectionManager.java:163)
at org.hibernate.jdbc.JDBCContext.borrowConnection(JDBCContext.java:111)
at org.hibernate.impl.SessionImpl.connection(SessionImpl.java:359)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:510)
It's the same bug as was in HHH-2215, but this is not resolved.
I think, that the problem is extracting classloader from currentThread(). This is always not null, so the next test in method getProxyClassLoader() is always false.
I my case, timer thread lives in top class loader, but hibernate libraries are inside application class loader.
Attached patch removes classloader extracting from currentThread(). It works for my case.
--
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
[Hibernate-JIRA] Created: (ANN-748) @JoinColumn overrides scale and percision in ManyToOne map..
by Andrew C. Oliver (JIRA)
@JoinColumn overrides scale and percision in ManyToOne map..
------------------------------------------------------------
Key: ANN-748
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-748
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.4.0.CR1
Environment: Postgresql but not Hypersonic (haven't tried other DBs, but suspect any real non-java db will replicate)
Reporter: Andrew C. Oliver
Attachments: patch.tar.gz
http://forum.hibernate.org/viewtopic.php?t=987527
Since you asked nicely...
This is a patch against your test cases.
Sorry for the not patch style patch. It is against the latest download of Annotations (3.4.0.CR1). I'm on a hotel network that seems to really make SVN angry.
There are 4 files:
1. Bunny has many
2. PointyTooth (teeth)
3. IdTest.java, only "testBlownPrecision" is new and "getMappings" includes the rabid bunny and teeth
4. UUIDGenerator - I wouldn't have included it but I couldn't find a decent way to autogenerate 128-bit keys. (The linked wikipedia article is amusing).
You'll probably want to unzip these into the annotations root directory, then do the svn diff. Following this you may want to pretty print.
As the test notes, it will FAIL with the @JoinColumn mapping and succeed if it is commented out. The failure notes a precision error. Obviously batching must be disabled to read it. If you look at the generated table it will have like NUMBER[19]. With JoinColumn commented out it is the expected NUMBER[128]. Thanks to PaaKow Acquah for finding this.
If you want more details, I'll be a TacoMac having another Aventinus...
--
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
[Hibernate-JIRA] Created: (HHH-3589) Sql generated for criteria intermittently causes "invalid identifier" error by assigning incorrect table alias to query elements
by Todd Currie (JIRA)
Sql generated for criteria intermittently causes "invalid identifier" error by assigning incorrect table alias to query elements
--------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3589
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3589
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate Core 3.3.1.GA
Oracle 10.02.03
JRE Q1.5.0_16-b02
Reporter: Todd Currie
Application is encountering intermittent ORA-00904 "invalid identifier" errors in production and test build environment. Error occurs approximately 1:460 executions in the test build environment. In each occurence it happens with a different test, but when it occurs every criteria query generated for that test class fails. In production typically causes application to crash because of the unexpected exception thrown.
The issue appears to be caused during construction of the CriteriaJoinWalker. The CriteriaLoader creates a CriteriaQueryTranslator that is responsible for the where condition and order by for non-projection queries (or additionally the select and group by for projection queries). The translator constructor is passed the CriteriaQueryTranslator.ROOT_SQL_ALIAS, "this_", which it uses for its rootSQLAlias. But when the CriteriaLoader next creates the CriteriaJoinWalker instance that is responsible for the rest of the query elements, it does not use the constructor that takes the root alias. The CriteriaJoinWalker then calls super(persister, factory, enabledFilters, alias); with a null passed in the alias parameter. The constructor in the parent class, AbstractEntityJoinWalker, calls generateRootAlias when the alias parameter is null. The method generateRootAlias is implemented both in the parent class JoinWalker and the child class CriteriaJoinWalker. To implement this form of polymorphism, java uses dynamic method binding to determine which method to call for the instance at run time. It appears that most of the time it calls the CriteriaJoinWalker implementation of generateRootAlias function which is hard coded to return CriteriaQueryTranslator.ROOT_SQL_ALIAS, "this_". The queries then generated by the CriteriaJoinWalker then execute correctly. But intermittently it calls the JoinWalker implementation which uses the passed in persistor's entityName to generate the table alias. This table alias that is then used for the rest of the query is different then the alias used by the CriteriaQueryTranslator and the resulting sql generates the invalid identifier error seen upon execution.
This can be fixed in a number of ways.
1) pass the CriteriaQueryTranslator.ROOT_SQL_ALIAS into the constructor for the CriteriaJoinWalker.
2) make the generateRootAlias abstract in the JoinWalker (less reliable).
3) use an AbstractFactory pattern to construct the objects (more work).
I have implemented #1 in our environment and am working on generating a clean test case to submit here. But for those who are interested here is the patch:
### Eclipse Workspace Patch 1.0
#P hibernate-core
Index: src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java
===================================================================
--- src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java (revision 15443)
+++ src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java (working copy)
@@ -94,7 +94,8 @@
factory,
criteria,
rootEntityName,
- enabledFilters
+ enabledFilters,
+ CriteriaQueryTranslator.ROOT_SQL_ALIAS
);
initFromWalker(walker);
Example stack trace:
could not execute query; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query
org.springframework.dao.InvalidDataAccessResourceUsageException: could not execute query; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:615)
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.findByCriteria(HibernateTemplate.java:1051)
at org.springframework.orm.hibernate3.HibernateTemplate.findByCriteria(HibernateTemplate.java:1044)
at com.onstation.service.PersistenceServiceImpl.findByCriteria(Unknown Source)
at com.onstation.service.MailingServiceTest.shouldFailToFindStateConversions(MailingServiceTest.java:52)
Caused by: org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.doList(Loader.java:2231)
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 org.springframework.orm.hibernate3.HibernateTemplate$36.doInHibernate(HibernateTemplate.java:1061)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
Caused by: java.sql.SQLException: ORA-00904: "THIS_"."SOURCE": invalid identifier
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:810)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:850)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1134)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3384)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
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)
Example query:
Hibernate:
select
stateconve0_.FAILEDID as FAILEDID311_0_,
stateconve0_.CREATED as CREATED311_0_,
stateconve0_.LOG as LOG311_0_,
stateconve0_.SOURCE as SOURCE311_0_
from
STATECONVERTFAILED stateconve0_
where
this_.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
[Hibernate-JIRA] Created: (ANN-666) @SQLInsert does not work
by Alex (JIRA)
@SQLInsert does not work
-------------------------
Key: ANN-666
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-666
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.2.1
Environment: hibernate-3.2.3.ga.zip, MySQL client version: 5.0.22, MSSQL 2005
Reporter: Alex
http://forum.hibernate.org/viewtopic.php?p=2367176#2367176
@Entity
@Table(name = "CONTACTS")
@SQLInsert(sql="INSERT INTO CONTACT(FIRST_NAME, LAST_NAME) VALUES(upper('aaa'),upper('bbb'))")
public class Contact {
// ...
}
I've tried the both - sql-query and stored procedure inside the @SQLInsert. But the both not work for me. It looks like the @SQLInsert annotation is just ignored for some reason. Usual "insert into CONTACT (FIRST_NAME, LAST_NAME) values (?, ?)" statement is generated despite of the @SQLInsert annotation. At the same time other annotations (@NamedNativeQuery, @Loader) work ok for the class.
How to make it works, please?
Thanks a lot in advance.
Hibernate version:
hibernate-3.2.3.ga.zip
Mapping documents:
sessionFactory = new AnnotationConfiguration()
.addPackage("model")
.addAnnotatedClass(Contact.class)
.addAnnotatedClass(SpaceShip.class)
.setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLMyISAMDialect")
.setProperty("hibernate.connection.url", "jdbc:mysql://localhost/test")
.setProperty("hibernate.connection.driver_class", "com.mysql.jdbc.Driver")
.setProperty("hibernate.connection.username", "usname")
.setProperty("hibernate.connection.password", "1231123")
.setProperty(Environment.HBM2DDL_AUTO, "update")
.setProperty(Environment.SHOW_SQL, "true")
.setProperty("hibernate.cache.provider_class", "org.hibernate.cache.NoCacheProvider")
.buildSessionFactory();
Code between sessionFactory.openSession() and session.close():
session = HibernateUtil.getSession();
session.beginTransaction();
session.saveOrUpdate(newContact);
session.getTransaction().commit();
Full stack trace of any exception that occurs:
None
Name and version of the database you are using:
MySQL client version: 5.0.22
The generated SQL (show_sql=true):
Hibernate: insert into CONTACT (FIRST_NAME, LAST_NAME) values (?, ?)
--
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
[Hibernate-JIRA] Created: (ANN-594) Filters for MappedSuperClass
by Shawn Clowater (JIRA)
Filters for MappedSuperClass
----------------------------
Key: ANN-594
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-594
Project: Hibernate Annotations
Issue Type: New Feature
Components: binder
Affects Versions: 3.3.0.ga
Reporter: Shawn Clowater
Priority: Minor
Based on discussion from
http://forum.hibernate.org/viewtopic.php?t=963539&start=0
Essentially, it would be nice to be able to define filters on a MappedSuperClass and have them 'trickle down' to the subclasses. (at the class level - not sure if property level filters are carried down right now).
I see the MappedSuperClass as a means to define generic behaviour (common columns, etc) and I think it makes sense for the filters to play nicely as well.
In addition, I don' t know if it is already a separate JIRA request, filters off of an Interface would be fantastic as well as our application is using filters heavily and are always looking at ways to reduce the amount of filter annotations that we have to spread around.
Right now, we're either forced to copy filter annotations all over the place OR we've actually been a bit sneaky and have tapped into custom persisters to dynamically apply common filters. However, there is a separate issue based on the order that entity persisters are built.
--
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
[Hibernate-JIRA] Created: (HSEARCH-367) Support only one kind of Similarity per index
by Sanne Grinovero (JIRA)
Support only one kind of Similarity per index
---------------------------------------------
Key: HSEARCH-367
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-367
Project: Hibernate Search
Issue Type: Bug
Reporter: Sanne Grinovero
Fix For: 3.2.0
pasted from the developer's list:
Each time a new Document is added to the index,
the similarity relevant to that entity is looked up from the
pertaining documentBuilder
and set to the indexwriter:
AddWorkDelegate:
Similarity similarity = documentBuilder.getSimilarity();
writer.setSimilarity( similarity );
writer.addDocument( work.getDocument(), analyzer );
So the analyzer is scoped per document, the similarity is globally set
on the indexwriter.
Does this make sense to update the similarity for each add operation type?
This is a problem as I can't use two (more) threads to add documents to
the same index.
Is there a good use case for which someone might need a different
Similarity implementation
for different entities contained in the same index?
I'd like to change that to an "illegal configuration".
--
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