Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-09-25 10:29:55
|
The following issue has been updated:
Updater: Klaus Zimmermann (mailto:kla...@xc...)
Date: Thu, 25 Sep 2003 5:29 AM
Comment:
Sorry, previous patch was buggy.
Use this one.
Changes:
Attachment changed to hbm2java_length-fixed.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-361&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-361
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-361
Summary: Have hbm2java.Field provide the Length information via easy accessor to renderer
Type: Improvement
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Klaus Zimmermann
Created: Thu, 25 Sep 2003 4:37 AM
Updated: Thu, 25 Sep 2003 5:29 AM
Description:
It was nice to have the information of the length attribute of your
average property element available to a custom renderer via a simple
accessor in the net.sf.hibernate.tools.hbm2java.Field class.
We need this information for a BeanInfo-renderer we have in house.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-25 09:37:58
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-361 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-361 Summary: Have hbm2java.Field provide the Length information via easy accessor to renderer Type: Improvement Status: Unassigned Priority: Major Project: Hibernate2 Assignee: Reporter: Klaus Zimmermann Created: Thu, 25 Sep 2003 4:37 AM Updated: Thu, 25 Sep 2003 4:37 AM Description: It was nice to have the information of the length attribute of your average property element available to a custom renderer via a simple accessor in the net.sf.hibernate.tools.hbm2java.Field class. We need this information for a BeanInfo-renderer we have in house. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-25 09:37:58
|
The following issue has been updated:
Updater: Klaus Zimmermann (mailto:kla...@xc...)
Date: Thu, 25 Sep 2003 4:37 AM
Comment:
Patch attached
Changes:
Attachment changed to hbm2java_length.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-361&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-361
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-361
Summary: Have hbm2java.Field provide the Length information via easy accessor to renderer
Type: Improvement
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Klaus Zimmermann
Created: Thu, 25 Sep 2003 4:37 AM
Updated: Thu, 25 Sep 2003 4:37 AM
Description:
It was nice to have the information of the length attribute of your
average property element available to a custom renderer via a simple
accessor in the net.sf.hibernate.tools.hbm2java.Field class.
We need this information for a BeanInfo-renderer we have in house.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-24 18:52:55
|
The following comment has been added to this issue:
Author: John Kristian
Created: Wed, 24 Sep 2003 1:52 PM
Body:
This patch would also fix HB-337, I imagine.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-360
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-360
Summary: WebLogic DataSource doesn't permit conn.getWarnings after commit
Type: Patch
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: John Kristian
Created: Wed, 24 Sep 2003 1:49 PM
Updated: Wed, 24 Sep 2003 1:49 PM
Environment: WebLogic 7, Windows 2000, Microsoft SQL Server
Description:
SessionFactoryImpl.closeConnection fails to close the JDBC conection, because an exception propagates from conn.getWarnings, because the connection is already closed (as a side-effect of commiting the JTA transaction, I suppose). This patch solves the problem:
==== src/net/sf/hibernate/impl/SessionFactoryImpl.java ====
@@ -403,6 +403,11 @@
try {
JDBCExceptionReporter.logWarnings( conn.getWarnings() );
conn.clearWarnings();
+ }
+ catch (SQLException sqle) {
+ log.warn("Cannot log warnings: " + sqle.getMessage());
+ }
+ try {
connections.closeConnection(conn);
}
catch (SQLException sqle) {
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-24 18:49:54
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-360 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-360 Summary: WebLogic DataSource doesn't permit conn.getWarnings after commit Type: Patch Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.2 Assignee: Reporter: John Kristian Created: Wed, 24 Sep 2003 1:49 PM Updated: Wed, 24 Sep 2003 1:49 PM Environment: WebLogic 7, Windows 2000, Microsoft SQL Server Description: SessionFactoryImpl.closeConnection fails to close the JDBC conection, because an exception propagates from conn.getWarnings, because the connection is already closed (as a side-effect of commiting the JTA transaction, I suppose). This patch solves the problem: ==== src/net/sf/hibernate/impl/SessionFactoryImpl.java ==== @@ -403,6 +403,11 @@ try { JDBCExceptionReporter.logWarnings( conn.getWarnings() ); conn.clearWarnings(); + } + catch (SQLException sqle) { + log.warn("Cannot log warnings: " + sqle.getMessage()); + } + try { connections.closeConnection(conn); } catch (SQLException sqle) { --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-24 17:55:55
|
The following comment has been added to this issue:
Author: Peter Spiess
Created: Wed, 24 Sep 2003 12:55 PM
Body:
I too have seen a similar issue. I think your problem is that there isn't a transaction started for Hibernate to registerSyncronization with. At least I was able to resolve the issue by starting a transaction.
However, my confusion is that Hibernate does this only once per connection. I start a transaction, do a session.load, then rollback the transaction. Then, I do another load which works fine. Hibernate seems to assume that once the a connection is open it has only one transaction associated with it. That does not make intuitive sense to me.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-349
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-349
Summary: NullPointerException in SessionImpl.connect under jboss
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Versions:
2.1 beta 3
Assignee:
Reporter: toby cabot
Created: Fri, 19 Sep 2003 12:58 PM
Updated: Fri, 19 Sep 2003 12:58 PM
Environment: win2k, jboss 3.2.1, sun vm 1.4.1-b21
Description:
Thanks for Hibernate, it's very nice.
I'm using the version labelled "2.1beta3b" from sourceforge. I get a NullPointerException under jboss when I try to use a session where Hibernate got the connection from a DataSource. Hibernate 2.0 works fine, and 2.1beta3b works fine in a standalone JVM.
My code is:
Session s = hFactory.openSession();
Query q = s.createQuery("from com.nlg.dps.teo.booking.db.ItineraryLineItem as ili where ili.booking=:id and ili.origin!=ili.destination");
q.setProperties(key);
List lineItems = q.list(); <-- crash site
Stack trace:
11:14:13,280 DEBUG [BatcherImpl] about to open: 0 open PreparedStatements, 0 open ResultSets
11:14:13,280 ERROR [STDERR] com.nlg.dps.tpl.mgt.PostBookingManagerException: Exception while trying to retrieve booking 6
11:14:13,280 ERROR [STDERR] at com.nlg.dps.tpl.mgt.ejb.PostBookingManagerHibernate.getAirDetails(PostBookingManagerHibernate.java:665)
11:14:13,280 ERROR [STDERR] at com.nlg.dps.tpl.mgt.ejb.PostBookingManagerEJB.getAirDetails(PostBookingManagerEJB.java:119)
11:14:13,280 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:14:13,280 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
11:14:13,280 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
11:14:13,280 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:629)
11:14:13,280 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:273)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:674)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:353)
11:14:13,280 ERROR [STDERR] at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
11:14:13,280 ERROR [STDERR] at $Proxy466.getAirDetails(Unknown Source)
11:14:13,280 ERROR [STDERR] at com.nlg.dps.operationsui.businessdelegates.BookingBusinessDelegate.getAirDetails(BookingBusinessDelegate.java:100)
11:14:13,280 ERROR [STDERR] at com.nlg.dps.operationsui.actions.RetrieveBookingFromMultipleAction.execute(RetrieveBookingFromMultipleAction.java:59)
11:14:13,280 ERROR [STDERR] at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
11:14:13,280 ERROR [STDERR] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
11:14:13,280 ERROR [STDERR] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
11:14:13,280 ERROR [STDERR] at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
11:14:13,280 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
11:14:13,280 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
11:14:13,280 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
11:14:13,280 ERROR [STDERR] at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
11:14:13,280 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
11:14:13,280 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
11:14:13,280 ERROR [STDERR] at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
11:14:13,280 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
11:14:13,280 ERROR [STDERR] at org.mortbay.http.HttpServer.service(HttpServer.java:863)
11:14:13,280 ERROR [STDERR] at org.jboss.jetty.Jetty.service(Jetty.java:460)
11:14:13,280 ERROR [STDERR] at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
11:14:13,280 ERROR [STDERR] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
11:14:13,295 ERROR [STDERR] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
11:14:13,295 ERROR [STDERR] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
11:14:13,295 ERROR [STDERR] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
11:14:13,295 ERROR [STDERR] at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
11:14:13,295 ERROR [STDERR] Caused by: net.sf.hibernate.TransactionException: could not register synchronization with JTA TransactionManager
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.SessionImpl.connect(SessionImpl.java:3175)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.SessionImpl.connection(SessionImpl.java:3155)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:60)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:559)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:167)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.loader.Loader.doFind(Loader.java:113)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.loader.Loader.find(Loader.java:736)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.hql.QueryTranslator.find(QueryTranslator.java:959)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1366)
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:41)
11:14:13,295 ERROR [STDERR] at com.nlg.dps.tpl.mgt.ejb.PostBookingManagerHibernate.lookupAirDetails(PostBookingManagerHibernate.java:705)
11:14:13,295 ERROR [STDERR] at com.nlg.dps.tpl.mgt.ejb.PostBookingManagerHibernate.lookupAirDetails(PostBookingManagerHibernate.java:682)
11:14:13,295 ERROR [STDERR] at com.nlg.dps.tpl.mgt.ejb.PostBookingManagerHibernate.getAirDetails(PostBookingManagerHibernate.java:661)
11:14:13,295 ERROR [STDERR] ... 41 more
11:14:13,295 ERROR [STDERR] Caused by: java.lang.NullPointerException
11:14:13,295 ERROR [STDERR] at net.sf.hibernate.impl.SessionImpl.connect(SessionImpl.java:3171)
11:14:13,295 ERROR [STDERR] ... 53 more
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-24 16:17:55
|
The following comment has been added to this issue:
Author: Ethan Wolf
Created: Wed, 24 Sep 2003 11:16 AM
Body:
I don't think lazy loading of the mapping files gets around the problem I experienced. (Just to be sure, I tried to incorporate the patch into my project last night and gave it a test. Assuming that I did it coreectly, the ManagedConnectionFactory still didn't find the mapping files.)
The way I understand it, the non-lazy strategy causes the class loader from the component deployer thread to be used in the initialize method, while lazy loading causes the class loader from the application thread to get used.
Unfortunately, neither of these class loaders works in my deployment. (I tried to summarize my deployment in http://forum.hibernate.org/viewtopic.php?p=2187#2187 ). Since my mapping files are deployed with the connector (a .rar in WebLogic and a -ds configuration in JBoss that refers to hibernate.rar), I need them to be loaded by a class loader associated with the connector itself. I had success getting the class loader from the ManagedConnectionFactoryImpl class itself, and to be honest, I'm not sure whether there is a thread associated with the connector rather than a connector client or a deployer.)
While I think it is a cool idea to do the lazy loading of the mapping files. I worry that it means the client application is configuring the connector (instead of making it part of the connector deployment). It seems to me that the configuration one gets when doing a JNDI lookup would depend on random things like which application happens to call the connector first. (This works fine when the .rar is packaged as part of the ear, but in the case that the rar is a utility used by multiple application it gets a bit wacky.)
From what I've read, I'm not entirely sure what the correct deployment is, but I certainly think that it seems much cooler to make the hibernate connector a configured utility that gets used by multiple applications (like a configured datasource).
If you need any more information about my deployment, let me know. I've written an ant script to package and deploy my version of hibernate.rar and a connector configuration. I have deployments for both JBoss and WebLogic. I'd be very happy to share the script with you/the community if you give me a few days to clean up a bit and extract it from my project specific stuff. That way you can replicate my way of deploying and see if it makes sense or is moronic.
Let me know if that would be useful. (Feedback would certainly be useful for me!)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-330
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-330
Summary: Loading mapping files from ManagedConnectionFactoryImpl in WebLogic
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee:
Reporter: Ethan Wolf
Created: Fri, 12 Sep 2003 1:31 PM
Updated: Fri, 12 Sep 2003 1:31 PM
Environment: Windows 2000, WebLogic 8.1 (on windows 2000)
Description:
ManagedConnectionFactoryImpl.initialize() passes the contextClassLoader from the thread to load the mapping files in Configuration.addResource.
This works fine (in both JBoss and WebLogic) IF the mapping files are on the class path of the application server.
It also works on JBoss when the mapping files are packaged with the connector deployment (-ds.xml). (The mapping files are found through JBoss' UnifiedClassLoader architecture.)
However, in WebLogic, the configuration files are not found when they are packaged with the individual deployment. This seems to be because the thread that deploys the component corresponds to the root thread on the application server, and therefore uses the Launcher$AppClassLoader. The actual class loader used to load the deployed connector (GenericClassLoader) is managed by the deploymer components of weblogic.
Changin the class loader passed to Configuration.addResource by the ManagedConnectionFactoryImpl to getClass().getClassLoader() seems to result in the desired ability to load the mapping files from the deployment directory.
Since the ManagedConnectionFactoryImpl is only used when deploying to an application server, I would assume that this has no adverse affects and it seems correct, but these class loader issues are quite mind boggling.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-24 11:27:28
|
The following comment has been added to this issue:
Author: jason zhang
Created: Wed, 24 Sep 2003 1:09 AM
Body:
Could you nicely make your performance test coding available for me? I think I could learn somethinge from your performance testing code.
My email is jas...@ya...
Help is appreciated.
jason
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-355
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-355
Summary: only save the explicitly mentioned object during flush
Type: New Feature
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: jason zhang
Created: Tue, 23 Sep 2003 4:31 AM
Updated: Tue, 23 Sep 2003 9:44 AM
Description:
When the session is commit, hibernate does a dirty check on every object in the session cache. Although it is claimed that the dirty check is effecient, it costs more than 1 second somtime to dirty check 600 objects in session in my system. I tried various of performance tuning, but no luck.
I'd rather to see the dirty check behavior can be turned on or off through a configuration parameter or session attribute. For example, if I set the hibernate.dirtyCheck=false in hibernate.cfg.xml, the hibernate would not check the objects in session cache, but only perform persistence for the objects which user metioned explicitly through session.save(), session.update(), session.saveOrUpdate() and session.delete(), and the objects that are cascaded from these objects.
If given appropriate instruction/direction, I would like to implement this feature.
jason
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 23:38:55
|
Message:
The following issue has been re-assigned.
Assignee: Daniel Bradby (mailto:db...@ci...)
Assigner: Daniel Bradby (mailto:db...@ci...)
Date: Tue, 23 Sep 2003 6:38 PM
Comment:
Starting to test now in BEA, WAS5 and JBoss
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-168
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-168
Summary: JCA delayed session factory initialization
Type: Patch
Status: Assigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee: Daniel Bradby
Reporter: Mike Mosiewicz
Created: Wed, 9 Jul 2003 5:43 PM
Updated: Tue, 23 Sep 2003 6:38 PM
Description:
By delaying session factory creation we can use the runtime classloader, not the resource-configuration-time classloader. Thus we are able to configure hibernate for proper set of classes.
This enables connector to deal with multiple or changing classloaders.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 23:38:55
|
The following comment has been added to this issue:
Author: Daniel Bradby
Created: Tue, 23 Sep 2003 6:37 PM
Body:
There is a patch already in JIRA (http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-168) that should cover this by allowing the user to lazyily create the SessionFactory which would then (hopefully) use the callers ClassLoader. This should end up to being the applications classloader, not the server. I'm am about to test it in BEA, WAS5, and JBoss. But I wondered if you had any comments on this solution Ethan?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-330
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-330
Summary: Loading mapping files from ManagedConnectionFactoryImpl in WebLogic
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee:
Reporter: Ethan Wolf
Created: Fri, 12 Sep 2003 1:31 PM
Updated: Fri, 12 Sep 2003 1:31 PM
Environment: Windows 2000, WebLogic 8.1 (on windows 2000)
Description:
ManagedConnectionFactoryImpl.initialize() passes the contextClassLoader from the thread to load the mapping files in Configuration.addResource.
This works fine (in both JBoss and WebLogic) IF the mapping files are on the class path of the application server.
It also works on JBoss when the mapping files are packaged with the connector deployment (-ds.xml). (The mapping files are found through JBoss' UnifiedClassLoader architecture.)
However, in WebLogic, the configuration files are not found when they are packaged with the individual deployment. This seems to be because the thread that deploys the component corresponds to the root thread on the application server, and therefore uses the Launcher$AppClassLoader. The actual class loader used to load the deployed connector (GenericClassLoader) is managed by the deploymer components of weblogic.
Changin the class loader passed to Configuration.addResource by the ManagedConnectionFactoryImpl to getClass().getClassLoader() seems to result in the desired ability to load the mapping files from the deployment directory.
Since the ManagedConnectionFactoryImpl is only used when deploying to an application server, I would assume that this has no adverse affects and it seems correct, but these class loader issues are quite mind boggling.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 23:33:56
|
Message:
The following issue has been re-assigned.
Assignee: Daniel Bradby (mailto:db...@ci...)
Assigner: Daniel Bradby (mailto:db...@ci...)
Date: Tue, 23 Sep 2003 6:33 PM
Comment:
Thanks for this. I'll take a look at it. There is a few casts to JCASessionImpl that I'll look into
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-325
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-325
Summary: JCASessionFactoryImpl incompatible with WebLogic (8.1)
Type: Bug
Status: Assigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.0.1
Assignee: Daniel Bradby
Reporter: Ethan Wolf
Created: Thu, 11 Sep 2003 4:39 PM
Updated: Tue, 23 Sep 2003 6:33 PM
Environment: Windows 2000, WebLogic 8.1 (Windows version)
Description:
JCASessionImplFactory.openSession() performs a cast of the Session returned from the application server's connection manager. The cast is to the implementation class (JCASessionImpl), not the interface (Session).
However, WebLogic's connection manager returns a proxy, resulting in a class cast exception.
The problem seems to be avoidable by casting to Session instead of the implementation class.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 21:01:01
|
The following comment has been added to this issue:
Author: Jason Carreira
Created: Tue, 23 Sep 2003 4:00 PM
Body:
I've been working with John Watkinson to add a CacheConfigurationManager to manage system default configuration parameters so that the CacheProvider doesn't need to do the property file loading, and so that you can use the same configuration defaults for both Hibernate caches and caches created outside of Hibernate.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-47
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-47
Summary: Clustered Read/Write Caching
Type: Patch
Status: Assigned
Priority: Critical
Project: Hibernate2
Fix Fors:
2.1
Assignee: Gavin King
Reporter: Max Rydahl Andersen
Created: Sat, 3 May 2003 10:30 AM
Updated: Wed, 17 Sep 2003 9:52 AM
Description:
Clustered Read/Write Caching
This patch adds the ability to do read-write caching in
a clustered environment. This is accomplished by way of
the SwarmCache caching engine. It in turn uses
Javagroups to implement efficient, multicast-based
cache communication. You can read a detailed
description of SwarmCache at http://swarmcache.sf.net.
Included in the patch is a readme that explains how it
works and how to apply it.
John Watkinson
http://sourceforge.net/tracker/index.php?func=detail&aid=722039&group_id=40712&atid=428710
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 20:09:55
|
The following issue has been updated:
Updater: Matt Hall (mailto:ma...@us...)
Date: Tue, 23 Sep 2003 3:09 PM
Changes:
Attachment changed to docpatch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-359&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-359
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-359
Summary: Ordered list example for the reference docs
Type: Improvement
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Assignee:
Reporter: Matt Hall
Created: Tue, 23 Sep 2003 3:08 PM
Updated: Tue, 23 Sep 2003 3:09 PM
Environment: All
Description:
I wrote an example for ordered lists with the index column managed by hibernate. I had some problems figuring out the details and had to ask for help on the forum, hopefully this example in the collections mapping section of the docs will alleviate some confusion.
The patch file is against the XML source file for the collections mapping chapter.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 20:09:55
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-359 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-359 Summary: Ordered list example for the reference docs Type: Improvement Status: Unassigned Priority: Trivial Project: Hibernate2 Assignee: Reporter: Matt Hall Created: Tue, 23 Sep 2003 3:08 PM Updated: Tue, 23 Sep 2003 3:08 PM Environment: All Description: I wrote an example for ordered lists with the index column managed by hibernate. I had some problems figuring out the details and had to ask for help on the forum, hopefully this example in the collections mapping section of the docs will alleviate some confusion. The patch file is against the XML source file for the collections mapping chapter. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-23 17:29:56
|
Message:
The following issue has been re-assigned.
Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
Assigner: Gavin King (mailto:ga...@in...)
Date: Tue, 23 Sep 2003 12:29 PM
Comment:
handball
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-357
Summary: Field name generator in hbm2java, and a tool to load obects from a request based on those constants.
Type: New Feature
Status: Assigned
Priority: Minor
Project: Hibernate2
Components:
toolset
Assignee: Max Rydahl Andersen
Reporter: Matt Hall
Created: Tue, 23 Sep 2003 10:38 AM
Updated: Tue, 23 Sep 2003 12:29 PM
Environment: All
Description:
This patch includes a small patch to generate String constants that represent the fields in a generated class file. If we then use these field constants in our JSPs, when we get a request back in a servlet it's really easy to load data into large objects automatically.
So, the patch is to BasicRenderer.java to add generation of these constants, and the new class is HttpFormUtil.java and can be used to load any object automatically from a request.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 16:28:55
|
The following issue has been updated:
Updater: Matt Hall (mailto:ma...@us...)
Date: Tue, 23 Sep 2003 11:27 AM
Changes:
Attachment changed to patch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-358&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-358
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-358
Summary: --text option added to SchemaUpdate
Type: Improvement
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Components:
toolset
Assignee:
Reporter: Matt Hall
Created: Tue, 23 Sep 2003 11:26 AM
Updated: Tue, 23 Sep 2003 11:27 AM
Environment: All
Description:
Works the same as the SchemaExport --text option, allows you to see what updates would be necessary to a database but then have the option of executing what you want manually.
Updates to SchemaUpdate.java and it's corresponding SchemaUpdateTask.java, backwards compatibility with existing and scripts and so on should be fine.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 16:26:55
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-358 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-358 Summary: --text option added to SchemaUpdate Type: Improvement Status: Unassigned Priority: Trivial Project: Hibernate2 Components: toolset Assignee: Reporter: Matt Hall Created: Tue, 23 Sep 2003 11:26 AM Updated: Tue, 23 Sep 2003 11:26 AM Environment: All Description: Works the same as the SchemaExport --text option, allows you to see what updates would be necessary to a database but then have the option of executing what you want manually. Updates to SchemaUpdate.java and it's corresponding SchemaUpdateTask.java, backwards compatibility with existing and scripts and so on should be fine. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-23 15:40:55
|
The following issue has been updated:
Updater: Matt Hall (mailto:ma...@us...)
Date: Tue, 23 Sep 2003 10:39 AM
Comment:
Patch to BasicRenderer.java
Changes:
Attachment changed to patch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-357
Summary: Field name generator in hbm2java, and a tool to load obects from a request based on those constants.
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
toolset
Assignee:
Reporter: Matt Hall
Created: Tue, 23 Sep 2003 10:38 AM
Updated: Tue, 23 Sep 2003 10:39 AM
Environment: All
Description:
This patch includes a small patch to generate String constants that represent the fields in a generated class file. If we then use these field constants in our JSPs, when we get a request back in a servlet it's really easy to load data into large objects automatically.
So, the patch is to BasicRenderer.java to add generation of these constants, and the new class is HttpFormUtil.java and can be used to load any object automatically from a request.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 15:40:55
|
The following issue has been updated:
Updater: Matt Hall (mailto:ma...@us...)
Date: Tue, 23 Sep 2003 10:39 AM
Comment:
Utility to load objects via reflection using new field constants.
Changes:
Attachment changed to HttpFormUtil.java
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-357
Summary: Field name generator in hbm2java, and a tool to load obects from a request based on those constants.
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
toolset
Assignee:
Reporter: Matt Hall
Created: Tue, 23 Sep 2003 10:38 AM
Updated: Tue, 23 Sep 2003 10:39 AM
Environment: All
Description:
This patch includes a small patch to generate String constants that represent the fields in a generated class file. If we then use these field constants in our JSPs, when we get a request back in a servlet it's really easy to load data into large objects automatically.
So, the patch is to BasicRenderer.java to add generation of these constants, and the new class is HttpFormUtil.java and can be used to load any object automatically from a request.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 15:38:54
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-357 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-357 Summary: Field name generator in hbm2java, and a tool to load obects from a request based on those constants. Type: New Feature Status: Unassigned Priority: Minor Project: Hibernate2 Components: toolset Assignee: Reporter: Matt Hall Created: Tue, 23 Sep 2003 10:38 AM Updated: Tue, 23 Sep 2003 10:38 AM Environment: All Description: This patch includes a small patch to generate String constants that represent the fields in a generated class file. If we then use these field constants in our JSPs, when we get a request back in a servlet it's really easy to load data into large objects automatically. So, the patch is to BasicRenderer.java to add generation of these constants, and the new class is HttpFormUtil.java and can be used to load any object automatically from a request. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-23 14:46:55
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Tue, 23 Sep 2003 9:46 AM
Please read the Hibernate documentation.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-350
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-350
Summary: Mysql dialect produced sql subquery.
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Krzysztof Dabrowski
Created: Sun, 21 Sep 2003 9:43 AM
Updated: Tue, 23 Sep 2003 9:46 AM
Environment: Resin 2.1.10, Mysql 4.0.15 InnoDb
Description:
I've created the following hql query:
"from itm in class pl.elysium.boxlife.hibernate.Item where size(itm.ItemFolders)=0"
Ant this query produced the following SQL:
"select itm.itm_id as x0_0_ from item itm where ((select count(*) from item_itemfolder_binding itemfold0_ where itm.itm_id=itemfold0_.itm_id)=0 )"
As you probably now, MySQL does not have subselects so it producted the following error:
"ERROR 1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'select count(*) from item_itemfolder_binding itemfold0_ where i"
Shouldn't it rather use other methods to perform the size() in case of Mysql dialect?
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 14:44:55
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Tue, 23 Sep 2003 9:44 AM
As I told you in the mailing list, you are just plain WRONG. It does not take 1 second to dirty check 600 objects. This is an absurd number; I can dirty check 10 000 objects in that time, and I have the tests to prove it.
Please take some time to learn how to do proper performance profiling in a hotspot JVM.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-355
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-355
Summary: only save the explicitly mentioned object during flush
Type: New Feature
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: jason zhang
Created: Tue, 23 Sep 2003 4:31 AM
Updated: Tue, 23 Sep 2003 9:44 AM
Description:
When the session is commit, hibernate does a dirty check on every object in the session cache. Although it is claimed that the dirty check is effecient, it costs more than 1 second somtime to dirty check 600 objects in session in my system. I tried various of performance tuning, but no luck.
I'd rather to see the dirty check behavior can be turned on or off through a configuration parameter or session attribute. For example, if I set the hibernate.dirtyCheck=false in hibernate.cfg.xml, the hibernate would not check the objects in session cache, but only perform persistence for the objects which user metioned explicitly through session.save(), session.update(), session.saveOrUpdate() and session.delete(), and the objects that are cascaded from these objects.
If given appropriate instruction/direction, I would like to implement this feature.
jason
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 14:41:55
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Tue, 23 Sep 2003 9:41 AM
AbstractEntityPersister is an abstract class!
This is due to a bug in your JDK. Try recompiling Hibernate against your JDK.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-354
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-354
Summary: java.lang.AbstractMethodError Exception during startup using Hibernate 2.1b3
Type: Bug
Status: Closed
Priority: Major
Resolution: DUPLICATE
Project: Hibernate2
Versions:
2.1 beta 3
Assignee:
Reporter: Rich Lahnum
Created: Mon, 22 Sep 2003 1:43 PM
Updated: Tue, 23 Sep 2003 9:41 AM
Environment: WebSphere 5 under Win2k
Description:
It appears that AbstractEntityPersister does not implement Loadable.getTableName(). If I insert a dummy implementation the app will start.
[9/22/03 13:27:02:585 CDT] 5e254dcc WebGroup E SRVE0020E: [Servlet Error]-[action]: Failed to load servlet: java.lang.AbstractMethodError: net/sf/hibernate/persister/AbstractEntityPersister.getTableName
at net.sf.hibernate.loader.OuterJoinLoader.walkAssociationTree(OuterJoinLoader.java:447)
at net.sf.hibernate.loader.OuterJoinLoader.walkAssociationTree(OuterJoinLoader.java:183)
at net.sf.hibernate.loader.OuterJoinLoader.walkClassTree(OuterJoinLoader.java:214)
at net.sf.hibernate.loader.OuterJoinLoader.walkTree(OuterJoinLoader.java:86)
at net.sf.hibernate.loader.OneToManyLoader.<init>(OneToManyLoader.java:54)
at net.sf.hibernate.loader.OneToManyLoader.<init>(OneToManyLoader.java:39)
at net.sf.hibernate.collection.CollectionPersister.createCollectionInitializer(CollectionPersister.java:324)
at net.sf.hibernate.collection.CollectionPersister.<init>(CollectionPersister.java:297)
at net.sf.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:138)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:660)
at us.il.state.idpa.oigcase.controller.OIGPlugin.init(OIGPlugin.java:128)
at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:1158)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:473)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doInit(StrictServletInstance.java:82)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._init(StrictLifecycleServlet.java:147)
at com.ibm.ws.webcontainer.servlet.PreInitializedServletState.init(StrictLifecycleServlet.java:270)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.init(StrictLifecycleServlet.java:113)
at com.ibm.ws.webcontainer.servlet.ServletInstance.init(ServletInstance.java:189)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.addServlet(WebAppServletManager.java:903)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadServlet(WebAppServletManager.java:266)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadAutoLoadServlets(WebAppServletManager.java:583)
at com.ibm.ws.webcontainer.webapp.WebApp.loadServletManager(WebApp.java:1252)
at com.ibm.ws.webcontainer.webapp.WebApp.init(WebApp.java:274)
at com.ibm.ws.webcontainer.srt.WebGroup.loadWebApp(WebGroup.java:345)
at com.ibm.ws.webcontainer.srt.WebGroup.init(WebGroup.java:208)
at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:968)
at com.ibm.ws.runtime.component.WebContainerImpl.install(WebContainerImpl.java:133)
at com.ibm.ws.runtime.component.WebContainerImpl.start(WebContainerImpl.java:360)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:397)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:751)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:347)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:539)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:250)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:228)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:524)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:415)
at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:117)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:524)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:415)
at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:182)
at com.ibm.ws.runtime.WsServer.start(WsServer.java:131)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:228)
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
at com.ibm.etools.websphere.tools.runner.api.ServerRunnerV5$1.run(ServerRunnerV5.java:97)
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 14:38:54
|
Message:
The following issue has been re-assigned.
Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
Assigner: Gavin King (mailto:ga...@in...)
Date: Tue, 23 Sep 2003 9:38 AM
Comment:
Max, the problem is in AbstractQueryImpl. Would you please take a look?
TIA.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-353
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-353
Summary: query.setProperty( Object ) assumes HQL
Type: Bug
Status: Assigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee: Max Rydahl Andersen
Reporter: Christopher D Riccio
Created: Mon, 22 Sep 2003 12:58 PM
Updated: Tue, 23 Sep 2003 9:38 AM
Environment: DB2 Database
Description:
Here's what I have.
QUERY
select {d.*}
from department {d}
where {d}.deptno = :deptno
passing in an object (Department) which has a
private String deptno;
on it.
Getting the following Exception:
net.sf.hibernate.QueryException: in expected: {d} [select {d.*}
from department {d}
where {d}.deptno = :deptno]
{d} is defined in my query object.
When I do
Query.setString( "deptno", department.getDeptno() );
The query executes correctly.
After looking deeper into this.
Seems as if it is handling the Native sql call as HQL.
The query dies after parsing "department."
it's expecting a class path, ( saw indexOf( '.' ) so I assume that is what was going on). Then it sets expectingIn to true. The next thing it sees is {d} and it chokes on it.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-23 14:33:56
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-356 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-356 Summary: SchemaExport and hsqldb drop table statements Type: Improvement Status: Unassigned Priority: Trivial Project: Hibernate2 Components: toolset Versions: 2.0.3 Assignee: Reporter: Aapo Laakkonen Created: Tue, 23 Sep 2003 9:33 AM Updated: Tue, 23 Sep 2003 9:33 AM Description: For convenience it would be great if SchemaExport generates "IF EXISTS" statements after each DROP TABLE statement when HSQLDialect is in use. For example instead of this: drop table usr; generate code like this: drop table usr if exists; Also do we need to drop constraints separately? --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
93 messages has been excluded from this view by a project administrator.
