You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jue...@we...> - 2004-02-11 22:34:08
|
(Currently uploading 1.0 RC1 to SourceForge...)
=20
As this represents a minor enhancement, let's simply implement it for =
1.0 RC2. That release will mainly be about completed docs, but noone =
will mind some refinements in code, I assume :-)
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Mi 11.02.2004 18:25
An: spr...@li...
Cc: spr...@li...
Betreff: [Springframework-developer] Re: [Springframework-user] Mapping =
Exceptions with sql-error-codes.xm l
This has come up a couple of times, but we have never really committed =
to adding
additional exception categories.
We are currently supporting translation to:
DataIntegrityViolationException
BadSqlGrammarException
=20
=20
Suggested categories to add (from my recollection):
DataRetrievalFailureException
OptimisticLockingFailureException
DataAccessResourceFailureException
Do we want to add some additional categories to the
SQLErrorCodeSQLExceptionTranslator?=20
If we do, we could keep it backwards compatible by making these =
additional
categories optional based on entries in sql-error-codes.xml.
If we decide to add this, when would be a good time considering RC1 =
being
released any minute?
Thomas
Quoting Meier Martin <mar...@el...>:
> Hi,
>=20
> I tried to map a stale connection error code to a
> DataAccessResourceFailureException, but this did not work:
>=20
> <bean id=3D"Oracle" =
class=3D"org.springframework.jdbc.support.SQLErrorCodes">
> <property
> =
name=3D"badSqlGrammarCodes"><value>900,903,904,917,936,942,17006</value><=
/prop
> erty>
> <property
> =
name=3D"dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></pro=
perty
> >
> <property
> =
name=3D"dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></pro=
perty
> >
> <property
> =
name=3D"dataAccessResourceFailureCodes"><value>17002</value></property>
> </bean>
>=20
> As I saw in the class SQLErrorCodes only the methods
> setBadSqlGrammerCodes(...) and setDataIntegrityViolationCodes(...) are
> supported. How is it possible to map an error code to a
> dataAccessResourceFailureException with the sql-error-codes.xml?
>=20
> Cheers
> -Martin
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <tri...@tr...> - 2004-02-11 17:25:55
|
This has come up a couple of times, but we have never really committed to adding additional exception categories. We are currently supporting translation to: DataIntegrityViolationException BadSqlGrammarException Suggested categories to add (from my recollection): DataRetrievalFailureException OptimisticLockingFailureException DataAccessResourceFailureException Do we want to add some additional categories to the SQLErrorCodeSQLExceptionTranslator? If we do, we could keep it backwards compatible by making these additional categories optional based on entries in sql-error-codes.xml. If we decide to add this, when would be a good time considering RC1 being released any minute? Thomas Quoting Meier Martin <mar...@el...>: > Hi, > > I tried to map a stale connection error code to a > DataAccessResourceFailureException, but this did not work: > > <bean id="Oracle" class="org.springframework.jdbc.support.SQLErrorCodes"> > <property > name="badSqlGrammarCodes"><value>900,903,904,917,936,942,17006</value></prop > erty> > <property > name="dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></property > > > <property > name="dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></property > > > <property > name="dataAccessResourceFailureCodes"><value>17002</value></property> > </bean> > > As I saw in the class SQLErrorCodes only the methods > setBadSqlGrammerCodes(...) and setDataIntegrityViolationCodes(...) are > supported. How is it possible to map an error code to a > dataAccessResourceFailureException with the sql-error-codes.xml? > > Cheers > -Martin > |
|
From: Ivan R. <iv...@we...> - 2004-02-11 17:22:53
|
jürgen höller [werk3AT] wrote: > This is a known M4 bug that has been fixed for a while. RC1 > (to be released in a couple of hours) includes this fix. Thanks for the fast reply. FYI I did look in the CVS first but the code there throws an exception too. Either something else was the problem or the CVS is stale (again). Anyway, thanks. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Chris W. <cwi...@op...> - 2004-02-11 17:21:24
|
j=FCrgen h=F6ller [werk3AT] wrote: > That package *is* in jboss-common-jdbc-wrapper.jar, and > building works fine for me. Maybe that jar doesn't get picked > up properly? Weird -- I must have copied the wrong jar to the lib/ directory a=20 while ago or something. (Or it was my evil alter ego...) Blasting=20 the lib/ directory and doing a cvs update fixed the trick. Sorry=20 for the trouble, and thanks. Chris --=20 Chris Winters (cwi...@op...) Senior Software Architect |
|
From: Ivan R. <iv...@we...> - 2004-02-11 17:19:23
|
Ivan Ristic wrote: > It > doesn't happen when I remove the application and install it > again. Actually it does happen with app remove/install too. The only action I can take is shutdown the Tomcat completely and start it again. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: <jue...@we...> - 2004-02-11 17:11:23
|
That package *is* in jboss-common-jdbc-wrapper.jar, and building works = fine for me. Maybe that jar doesn't get picked up properly? BTW, SourceForge isn't in read-only mode anymore, so I'll release RC1 in = a couple of hours. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Chris Winters Sent: Wednesday, February 11, 2004 5:50 PM To: Spring-Dev Subject: [Springframework-developer] problems building from CVS Since SF is giving Juergen problems I figured I'd refresh my CVS=20 directory and build from scratch. Except that I get a bunch of=20 errors (building with both Ant and Maven) from=20 'o.s.jdbc.support.nativejdbc.JBossNativeJdbcExtractor' not=20 finding 'org.jboss.resource.adapter.jdbc.*'. This package seems like it should be in the=20 lib/jboss/jboss-common-jdbc-wrapper.jar, but it's not. Anywhere=20 else to turn? Thanks! Chris --=20 Chris Winters (cwi...@op...) Senior Software Architect ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-02-11 17:08:42
|
This is a known M4 bug that has been fixed for a while. RC1 (to be = released in a couple of hours) includes this fix. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Ivan Ristic Sent: Wednesday, February 11, 2004 5:55 PM To: spr...@li... Subject: [Springframework-developer] Possible bug/problem with webAppRootKey Yesterday I upgraded an application from Spring 1.0m2 to 1.0m4. Since then, I can't reload my application (using Tomcat 4.1.29). The error I am getting is: "java.lang.IllegalStateException: WARNING: Web app root system property already set: dsf.root =3D /opt/tomcat/webapps/dsf/ - Choose unique webAppRootKey values in your web.xml files!" This does not happen the first time the Tomcat is started. It doesn't happen when I remove the application and install it again. It seems that Tomcat is caching the value from before but the class WebUtils insists it must not be present before it sets it (1.0m2 did not have this requirement). Is there anything I am not aware of, or should I add report this as a bug? --=20 ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ivan R. <iv...@we...> - 2004-02-11 17:00:42
|
Yesterday I upgraded an application from Spring 1.0m2 to 1.0m4. Since then, I can't reload my application (using Tomcat 4.1.29). The error I am getting is: "java.lang.IllegalStateException: WARNING: Web app root system property already set: dsf.root = /opt/tomcat/webapps/dsf/ - Choose unique webAppRootKey values in your web.xml files!" This does not happen the first time the Tomcat is started. It doesn't happen when I remove the application and install it again. It seems that Tomcat is caching the value from before but the class WebUtils insists it must not be present before it sets it (1.0m2 did not have this requirement). Is there anything I am not aware of, or should I add report this as a bug? -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Chris W. <cwi...@op...> - 2004-02-11 16:55:28
|
Since SF is giving Juergen problems I figured I'd refresh my CVS directory and build from scratch. Except that I get a bunch of errors (building with both Ant and Maven) from 'o.s.jdbc.support.nativejdbc.JBossNativeJdbcExtractor' not finding 'org.jboss.resource.adapter.jdbc.*'. This package seems like it should be in the lib/jboss/jboss-common-jdbc-wrapper.jar, but it's not. Anywhere else to turn? Thanks! Chris -- Chris Winters (cwi...@op...) Senior Software Architect |
|
From: <jue...@we...> - 2004-02-11 12:45:32
|
Damn, 1.0 RC1 is prepared and ready for upload... but SourceForge is =
currently in "read-only" mode :-(
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Tuesday, February 10, 2004 8:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ready for 1.0 RC1
Just did a quick test of dropping in ojdbc14.jar into JBoss, where my=20
app is working ok with the 8i classes12.jar, and JBoss CMP is not happy=20
all of a sudden:
2004-02-10 13:53:28,595 DEBUG=20
[com.opensymphony.workflow.loader.XMLWorkflowFactory] getWorkflow build=20
descriptor=3Dcom.opensymphony.workflow.loader.WorkflowDescriptor@1626c6d
2004-02-10 13:53:28,611 ERROR [org.jboss.ejb.plugins.LogInterceptor]=20
TransactionRolledbackLocalException in method: public abstract=20
java.lang.Long=20
com.opensymphony.workflow.spi.ejb.CurrentStepLocal.getId(), causedBy:
java.lang.ArrayIndexOutOfBoundsException: -90
at oracle.sql.LnxLibThin.lnxnuc(LnxLibThin.java:5744)
at oracle.sql.NUMBER.toInt(NUMBER.java:412)
at=20
oracle.jdbc.dbaccess.DBConversion.NumberBytesToInt(DBConversion.java:2884=
)
at=20
oracle.jdbc.driver.OracleStatement.getIntValue(OracleStatement.java:4489)=
at=20
oracle.jdbc.driver.OracleResultSetImpl.getInt(OracleResultSetImpl.java:53=
6)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$24.readResult(JDBCUtil.java:876)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$AbstractPrimitiveReader.get(JDBCU=
til.java:803)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgu=
mentResults(JDBCAbstractCMPFieldBridge.java:424)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInst=
anceResults(JDBCAbstractCMPFieldBridge.java:373)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:188)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:72)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:612)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:594)
at=20
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceMana=
ger.java:381)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEnti=
ty(CachedConnectionInterceptor.java:352)
at=20
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynch=
ronizationInterceptor.java:239)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:185)
at=20
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentrance=
Interceptor.java:114)
at=20
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInte=
rceptor.java:163)
at=20
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.=
java:89)
at=20
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInte=
rceptor.java:54)
at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:297)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
at=20
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at org.jboss.ejb.Container.invoke(Container.java:700)
at=20
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFa=
ctory.java:375)
at =
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy126.getId(Unknown Source)
This is OsWorkflow EJB based code. All my Spring/Hibernate code is still =
happy though.
So who knows who's at fault here? :-) All I know is I'm staying with=20
the 8i classes12 until we either move to Oracle 9i, or have no more=20
JBoss EJB dependencies....
tri...@tr... wrote:
>I did some more digging and I can get JDK 1.3 and a recent =
classes12.jar to work
>with 8i. Have not tried 9i today, but it should work too.
>
>The reason I said it did not work was that I tested the JDK 1.4 and 1.3 =
with
>different versions of WebLogic. I used WebLogic 6.1 for JDK 1.3 and =
even when I
>added the most recent oracle driver it blew up on
>"oracle.sql.BLOB.getField(DURATION_SESSION)". I started digging some =
more and
>it turns out that the weblogic.jar for 6.1 contains an outdated version =
of the
>oracle.sql.BLOB and oracle.sql.CLOB classes. By putting the latest
>classes12.jar first on the classpath everything works fine.
>
>If I have some time later, I will try 9i as well.
>
>Thomas
>
>
>Quoting Colin Sampaleanu <col...@ex...>:
>
> =20
>
>>I think Thomas is saying that classes12 didn't work with JDK 1.3 with=20
>>8i. It probably works with 9i... Thomas, please correct me if I am =
wrong.
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>> =20
>>
>>>Thanks for testing, Thomas. It's a pity that this approach just works =
for
>>> =20
>>>
>>JDK 1.4; however, JDKs are easier to upgrade than databases. I've =
never tried
>>it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did work =
(after
>>I've changed our code to read the Oracle constants via reflection; the
>>constant values differ between classes12 and ojdbc14!). I'm not sure =
why JDK
>>1.3 causes a problem here.
>> =20
>>
>>>I'm finally gonna release RC1 tonight, so there's still a couple of =
hours to
>>> =20
>>>
>>go if you find any issues :-)
>> =20
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag =
von
>>> =20
>>>
>>tri...@tr...
>> =20
>>
>>>Gesendet: Di 10.02.2004 17:40
>>>An: spr...@li...
>>> =20
>>>
>
> =20
>
>>>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1
>>>
>>>
>>>
>>>I tried the imagedb sample application for Oracle. It works using =
JDK 1.4
>>> =20
>>>
>>and
>> =20
>>
>>>the odbcj14.jar jdbc driver for an 8i database. It does not work at =
all
>>> =20
>>>
>>using
>> =20
>>
>>>JDK 1.3 and classes12.zip/jar. This means that we are limited to =
JDK 1.4
>>> =20
>>>
>>for
>> =20
>>
>>>this type functionality with Oracle for now.
>>>
>>>Just to clarify the Oracle drivers - there are no particular 8i or 9i =
jdbc
>>>drivers. They are just labeled based on which database version they =
are
>>>distributed with. They should be backwards compatible, and if they =
are not
>>> =20
>>>
>>it
>> =20
>>
>>>is a bug. (There is even a patch for the driver that came with 8i to =
fix a
>>>problem connecting to a 9i database.) The only driver availale for =
JDK 1.4
>>> =20
>>>
>>is
>> =20
>>
>>>the ojdbc14.jar that comes with 9i. Haven't checked out the 10g =
drivers
>>> =20
>>>
>>yet.
>> =20
>>
>>>I ran into a small problem with the html generated by the =
application. The
>>>browser did not pick up the end of the <textarea> for the =
description. I
>>> =20
>>>
>>added
>> =20
>>
>>>a separate closing tag and comitted it to cvs.
>>>
>>>Thomas
>>>=20
>>>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-02-10 19:30:28
|
Just did a quick test of dropping in ojdbc14.jar into JBoss, where my=20
app is working ok with the 8i classes12.jar, and JBoss CMP is not happy=20
all of a sudden:
2004-02-10 13:53:28,595 DEBUG=20
[com.opensymphony.workflow.loader.XMLWorkflowFactory] getWorkflow build=20
descriptor=3Dcom.opensymphony.workflow.loader.WorkflowDescriptor@1626c6d
2004-02-10 13:53:28,611 ERROR [org.jboss.ejb.plugins.LogInterceptor]=20
TransactionRolledbackLocalException in method: public abstract=20
java.lang.Long=20
com.opensymphony.workflow.spi.ejb.CurrentStepLocal.getId(), causedBy:
java.lang.ArrayIndexOutOfBoundsException: -90
at oracle.sql.LnxLibThin.lnxnuc(LnxLibThin.java:5744)
at oracle.sql.NUMBER.toInt(NUMBER.java:412)
at=20
oracle.jdbc.dbaccess.DBConversion.NumberBytesToInt(DBConversion.java:2884=
)
at=20
oracle.jdbc.driver.OracleStatement.getIntValue(OracleStatement.java:4489)
at=20
oracle.jdbc.driver.OracleResultSetImpl.getInt(OracleResultSetImpl.java:53=
6)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$24.readResult(JDBCUtil.java:876)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$AbstractPrimitiveReader.get(JDBCU=
til.java:803)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgu=
mentResults(JDBCAbstractCMPFieldBridge.java:424)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInst=
anceResults(JDBCAbstractCMPFieldBridge.java:373)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:188)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:72)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:612)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:594)
at=20
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceMana=
ger.java:381)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEnti=
ty(CachedConnectionInterceptor.java:352)
at=20
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynch=
ronizationInterceptor.java:239)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:185)
at=20
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentrance=
Interceptor.java:114)
at=20
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInte=
rceptor.java:163)
at=20
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.=
java:89)
at=20
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInte=
rceptor.java:54)
at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:297)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
at=20
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at org.jboss.ejb.Container.invoke(Container.java:700)
at=20
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFa=
ctory.java:375)
at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38=
)
at $Proxy126.getId(Unknown Source)
This is OsWorkflow EJB based code. All my Spring/Hibernate code is still=20
happy though.
So who knows who's at fault here? :-) All I know is I'm staying with=20
the 8i classes12 until we either move to Oracle 9i, or have no more=20
JBoss EJB dependencies....
tri...@tr... wrote:
>I did some more digging and I can get JDK 1.3 and a recent classes12.jar=
to work
>with 8i. Have not tried 9i today, but it should work too.
>
>The reason I said it did not work was that I tested the JDK 1.4 and 1.3 =
with
>different versions of WebLogic. I used WebLogic 6.1 for JDK 1.3 and eve=
n when I
>added the most recent oracle driver it blew up on
>"oracle.sql.BLOB.getField(DURATION_SESSION)". I started digging some mo=
re and
>it turns out that the weblogic.jar for 6.1 contains an outdated version =
of the
>oracle.sql.BLOB and oracle.sql.CLOB classes. By putting the latest
>classes12.jar first on the classpath everything works fine.
>
>If I have some time later, I will try 9i as well.
>
>Thomas
>
>
>Quoting Colin Sampaleanu <col...@ex...>:
>
> =20
>
>>I think Thomas is saying that classes12 didn't work with JDK 1.3 with=20
>>8i. It probably works with 9i... Thomas, please correct me if I am wron=
g.
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>> =20
>>
>>>Thanks for testing, Thomas. It's a pity that this approach just works =
for
>>> =20
>>>
>>JDK 1.4; however, JDKs are easier to upgrade than databases. I've never=
tried
>>it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did work =
(after
>>I've changed our code to read the Oracle constants via reflection; the
>>constant values differ between classes12 and ojdbc14!). I'm not sure wh=
y JDK
>>1.3 causes a problem here.
>> =20
>>
>>>I'm finally gonna release RC1 tonight, so there's still a couple of ho=
urs to
>>> =20
>>>
>>go if you find any issues :-)
>> =20
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag =
von
>>> =20
>>>
>>tri...@tr...
>> =20
>>
>>>Gesendet: Di 10.02.2004 17:40
>>>An: spr...@li...
>>> =20
>>>
>
> =20
>
>>>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1
>>>
>>>
>>>
>>>I tried the imagedb sample application for Oracle. It works using JDK=
1.4
>>> =20
>>>
>>and
>> =20
>>
>>>the odbcj14.jar jdbc driver for an 8i database. It does not work at a=
ll
>>> =20
>>>
>>using
>> =20
>>
>>>JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK=
1.4
>>> =20
>>>
>>for
>> =20
>>
>>>this type functionality with Oracle for now.
>>>
>>>Just to clarify the Oracle drivers - there are no particular 8i or 9i =
jdbc
>>>drivers. They are just labeled based on which database version they a=
re
>>>distributed with. They should be backwards compatible, and if they ar=
e not
>>> =20
>>>
>>it
>> =20
>>
>>>is a bug. (There is even a patch for the driver that came with 8i to =
fix a
>>>problem connecting to a 9i database.) The only driver availale for JD=
K 1.4
>>> =20
>>>
>>is
>> =20
>>
>>>the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drive=
rs
>>> =20
>>>
>>yet.
>> =20
>>
>>>I ran into a small problem with the html generated by the application.=
The
>>>browser did not pick up the end of the <textarea> for the description.=
I
>>> =20
>>>
>>added
>> =20
>>
>>>a separate closing tag and comitted it to cvs.
>>>
>>>Thomas
>>>=20
>>>
|
|
From: <tri...@tr...> - 2004-02-10 18:39:10
|
9i works too. JDK 1.3.1, recent classes12.jar connecting to Oracle 9i runs fine for the imagedb application. Thomas Quoting Colin Sampaleanu <col...@ex...>: > I think Thomas is saying that classes12 didn't work with JDK 1.3 with > 8i. It probably works with 9i... Thomas, please correct me if I am wrong. > > > jürgen höller [werk3AT] wrote: > > >Thanks for testing, Thomas. It's a pity that this approach just works for > JDK 1.4; however, JDKs are easier to upgrade than databases. I've never tried > it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did work (after > I've changed our code to read the Oracle constants via reflection; the > constant values differ between classes12 and ojdbc14!). I'm not sure why JDK > 1.3 causes a problem here. > > > >I'm finally gonna release RC1 tonight, so there's still a couple of hours to > go if you find any issues :-) > > > >Juergen > > > > > >________________________________ > > > >Von: spr...@li... im Auftrag von > tri...@tr... > >Gesendet: Di 10.02.2004 17:40 > >An: spr...@li... > >Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 > > > > > > > >I tried the imagedb sample application for Oracle. It works using JDK 1.4 > and > >the odbcj14.jar jdbc driver for an 8i database. It does not work at all > using > >JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1.4 > for > >this type functionality with Oracle for now. > > > >Just to clarify the Oracle drivers - there are no particular 8i or 9i jdbc > >drivers. They are just labeled based on which database version they are > >distributed with. They should be backwards compatible, and if they are not > it > >is a bug. (There is even a patch for the driver that came with 8i to fix a > >problem connecting to a 9i database.) The only driver availale for JDK 1.4 > is > >the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers > yet. > > > >I ran into a small problem with the html generated by the application. The > >browser did not pick up the end of the <textarea> for the description. I > added > >a separate closing tag and comitted it to cvs. > > > >Thomas > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <tri...@tr...> - 2004-02-10 18:24:50
|
I did some more digging and I can get JDK 1.3 and a recent classes12.jar to work with 8i. Have not tried 9i today, but it should work too. The reason I said it did not work was that I tested the JDK 1.4 and 1.3 with different versions of WebLogic. I used WebLogic 6.1 for JDK 1.3 and even when I added the most recent oracle driver it blew up on "oracle.sql.BLOB.getField(DURATION_SESSION)". I started digging some more and it turns out that the weblogic.jar for 6.1 contains an outdated version of the oracle.sql.BLOB and oracle.sql.CLOB classes. By putting the latest classes12.jar first on the classpath everything works fine. If I have some time later, I will try 9i as well. Thomas Quoting Colin Sampaleanu <col...@ex...>: > I think Thomas is saying that classes12 didn't work with JDK 1.3 with > 8i. It probably works with 9i... Thomas, please correct me if I am wrong. > > > jürgen höller [werk3AT] wrote: > > >Thanks for testing, Thomas. It's a pity that this approach just works for > JDK 1.4; however, JDKs are easier to upgrade than databases. I've never tried > it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did work (after > I've changed our code to read the Oracle constants via reflection; the > constant values differ between classes12 and ojdbc14!). I'm not sure why JDK > 1.3 causes a problem here. > > > >I'm finally gonna release RC1 tonight, so there's still a couple of hours to > go if you find any issues :-) > > > >Juergen > > > > > >________________________________ > > > >Von: spr...@li... im Auftrag von > tri...@tr... > >Gesendet: Di 10.02.2004 17:40 > >An: spr...@li... > >Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 > > > > > > > >I tried the imagedb sample application for Oracle. It works using JDK 1.4 > and > >the odbcj14.jar jdbc driver for an 8i database. It does not work at all > using > >JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1.4 > for > >this type functionality with Oracle for now. > > > >Just to clarify the Oracle drivers - there are no particular 8i or 9i jdbc > >drivers. They are just labeled based on which database version they are > >distributed with. They should be backwards compatible, and if they are not > it > >is a bug. (There is even a patch for the driver that came with 8i to fix a > >problem connecting to a 9i database.) The only driver availale for JDK 1.4 > is > >the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers > yet. > > > >I ran into a small problem with the html generated by the application. The > >browser did not pick up the end of the <textarea> for the description. I > added > >a separate closing tag and comitted it to cvs. > > > >Thomas > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-02-10 17:37:06
|
I am still debugging a $%$^%$% issue where Spring tries to close a=20
connection and JBoss says it is unknown.
2004-02-10 12:30:44,900 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
executing flush
2004-02-10 12:30:44,900 DEBUG [net.sf.hibernate.impl.SessionImpl] post fl=
ush
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.jta.JtaTransactionManager] Triggering=20
beforeCompletion synchronization
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Removed value [org.springframework.orm.hibernate.SessionHolder@df42ce]=20
for key [net.sf.hibernate.impl.SessionFactoryImpl@1da6868] from thread=20
[TP-Processor2]
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Removed value=20
[org.springframework.jdbc.datasource.ConnectionHolder@52a665] for key=20
[org.jboss.resource.adapter.jdbc.WrapperDataSource@c39410] from thread=20
[TP-Processor2]
2004-02-10 12:30:44,900 INFO =20
[org.jboss.resource.connectionmanager.TxConnectionManager] throwable=20
from unregister connection
java.lang.IllegalStateException: Trying to return an unknown=20
connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@1e94776
at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterCo=
nnection(CachedConnectionManager.java:330)
at=20
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEven=
tListener.connectionClosed(TxConnectionManager.java:539)
at=20
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(=
BaseWrapperManagedConnection.java:296)
at=20
org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection=
.java:117)
at=20
org.springframework.jdbc.datasource.DataSourceUtils.closeConnectionIfNece=
ssary(DataSourceUtils.java:162)
at=20
org.springframework.jdbc.datasource.DataSourceUtils$ConnectionSynchroniza=
tion.beforeCompletion(DataSourceUtils.java:237)
at=20
org.springframework.transaction.support.AbstractPlatformTransactionManage=
r.triggerBeforeCompletion(AbstractPlatformTransactionManager.java:417)
at=20
org.springframework.transaction.support.AbstractPlatformTransactionManage=
r.commit(AbstractPlatformTransactionManager.java:298)
at=20
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:174)
at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
at=20
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
at $Proxy142.createBuild(Unknown Source)
at=20
com.whatever.coreserv.services.controller.application.ApplicationControll=
erBean.createBuild(ApplicationControllerBean.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at=20
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(State=
lessSessionContainer.java:683)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:185)
at=20
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
at=20
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:700)
at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at=20
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:54=
6)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:1=
01)
at=20
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
at=20
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
at=20
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
at=20
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
at $Proxy127.createBuild(Unknown Source)
....
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.transaction.jta.JtaTransactionManager] Triggering=20
afterCompletion synchronization
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
transaction completion
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.orm.hibernate.SessionFactoryUtils] Closing=20
Hibernate session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
closing session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
disconnecting session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
transaction completion
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Clearing transaction synchronization
My feeling is that this is a JBoss bug of some sort though. It was worse=20
in 3.2.2RC3, happeing in a number of places. When I moved to 3.2.3, it=20
only happened in one spot, among a bunch of code that is essentially=20
similar. My feeling is that it's some sort of race condition in the=20
JBoss transaction code. Certainly, if I look at the wrapped connection=20
and the actual connection, right before we call close() on it, it says=20
it is not closed. Then the close() call causes the error to show up in=20
the log...
Weird stuff...
j=FCrgen h=F6ller [werk3AT] wrote:
>Thanks for testing, Thomas. It's a pity that this approach just works fo=
r JDK 1.4; however, JDKs are easier to upgrade than databases. I've never=
tried it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did =
work (after I've changed our code to read the Oracle constants via reflec=
tion; the constant values differ between classes12 and ojdbc14!). I'm not=
sure why JDK 1.3 causes a problem here.
>=20
>I'm finally gonna release RC1 tonight, so there's still a couple of hour=
s to go if you find any issues :-)
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n tri...@tr...
>Gesendet: Di 10.02.2004 17:40
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1
>
>
>
>I tried the imagedb sample application for Oracle. It works using JDK 1=
.4 and
>the odbcj14.jar jdbc driver for an 8i database. It does not work at all=
using
>JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1=
.4 for
>this type functionality with Oracle for now.
>
>Just to clarify the Oracle drivers - there are no particular 8i or 9i jd=
bc
>drivers. They are just labeled based on which database version they are
>distributed with. They should be backwards compatible, and if they are =
not it
>is a bug. (There is even a patch for the driver that came with 8i to fi=
x a
>problem connecting to a 9i database.) The only driver availale for JDK =
1.4 is
>the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers=
yet.
>
>I ran into a small problem with the html generated by the application. =
The
>browser did not pick up the end of the <textarea> for the description. =
I added
>a separate closing tag and comitted it to cvs.
>
>Thomas
> =20
>
|
|
From: Colin S. <col...@ex...> - 2004-02-10 17:24:40
|
I think Thomas is saying that classes12 didn't work with JDK 1.3 with=20 8i. It probably works with 9i... Thomas, please correct me if I am wrong. j=FCrgen h=F6ller [werk3AT] wrote: >Thanks for testing, Thomas. It's a pity that this approach just works fo= r JDK 1.4; however, JDKs are easier to upgrade than databases. I've never= tried it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did = work (after I've changed our code to read the Oracle constants via reflec= tion; the constant values differ between classes12 and ojdbc14!). I'm not= sure why JDK 1.3 causes a problem here. >=20 >I'm finally gonna release RC1 tonight, so there's still a couple of hour= s to go if you find any issues :-) >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag vo= n tri...@tr... >Gesendet: Di 10.02.2004 17:40 >An: spr...@li... >Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 > > > >I tried the imagedb sample application for Oracle. It works using JDK 1= .4 and >the odbcj14.jar jdbc driver for an 8i database. It does not work at all= using >JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1= .4 for >this type functionality with Oracle for now. > >Just to clarify the Oracle drivers - there are no particular 8i or 9i jd= bc >drivers. They are just labeled based on which database version they are >distributed with. They should be backwards compatible, and if they are = not it >is a bug. (There is even a patch for the driver that came with 8i to fi= x a >problem connecting to a 9i database.) The only driver availale for JDK = 1.4 is >the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers= yet. > >I ran into a small problem with the html generated by the application. = The >browser did not pick up the end of the <textarea> for the description. = I added >a separate closing tag and comitted it to cvs. > >Thomas > =20 > |
|
From: <jue...@we...> - 2004-02-10 17:03:21
|
Thanks for testing, Thomas. It's a pity that this approach just works = for JDK 1.4; however, JDKs are easier to upgrade than databases. I've = never tried it on JDK 1.3, but I did try classes12 with JDK 1.4, and = that did work (after I've changed our code to read the Oracle constants = via reflection; the constant values differ between classes12 and = ojdbc14!). I'm not sure why JDK 1.3 causes a problem here. =20 I'm finally gonna release RC1 tonight, so there's still a couple of = hours to go if you find any issues :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von tri...@tr... Gesendet: Di 10.02.2004 17:40 An: spr...@li... Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 I tried the imagedb sample application for Oracle. It works using JDK = 1.4 and the odbcj14.jar jdbc driver for an 8i database. It does not work at all = using JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK = 1.4 for this type functionality with Oracle for now. Just to clarify the Oracle drivers - there are no particular 8i or 9i = jdbc drivers. They are just labeled based on which database version they are distributed with. They should be backwards compatible, and if they are = not it is a bug. (There is even a patch for the driver that came with 8i to = fix a problem connecting to a 9i database.) The only driver availale for JDK = 1.4 is the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers = yet. I ran into a small problem with the html generated by the application. = The browser did not pick up the end of the <textarea> for the description. = I added a separate closing tag and comitted it to cvs. Thomas ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tri...@tr...> - 2004-02-10 16:40:28
|
I tried the imagedb sample application for Oracle. It works using JDK 1.4 and the odbcj14.jar jdbc driver for an 8i database. It does not work at all using JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1.4 for this type functionality with Oracle for now. Just to clarify the Oracle drivers - there are no particular 8i or 9i jdbc drivers. They are just labeled based on which database version they are distributed with. They should be backwards compatible, and if they are not it is a bug. (There is even a patch for the driver that came with 8i to fix a problem connecting to a 9i database.) The only driver availale for JDK 1.4 is the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers yet. I ran into a small problem with the html generated by the application. The browser did not pick up the end of the <textarea> for the description. I added a separate closing tag and comitted it to cvs. Thomas |
|
From: Colin S. <col...@ex...> - 2004-02-10 15:22:33
|
Here's another article on IOC on java.net: http://today.java.net/pub/a/today/2004/02/10/ioc.html It's somewhat of a variation on Fowler's article from a few weeks back. I do not agree with his statement at the end that if you don't need all of Spring's supporting (ORM, Transactions, etc.) features Pico may be a better choice due to its smaller footprint, since of course you can also use Spring with just the BeanFactory or just the ApplicationContext support... Regards, Colin |
|
From: Darren D. <da...@da...> - 2004-02-10 10:26:26
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 February 2004 09:06, j=FCrgen h=F6ller [werk3AT] wrote: > Colin, Darren, It would be great if you could give the most current CVS > head another go then. I ran all the same tests as before based on a CVS update taken at around=20 2200 GMT last night. Everything continued to pass. Regards, =2D --=20 Darren Davison Public Key: http://www.davison.uk.net/key.jsp =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKLHDKLMLAN01aw0RAv8LAKCax7GMGoXhyeROW/wUbks19sQrNwCgiGMq KyVRlyiFP+EEffFsvtV+9+M=3D =3DhebX =2D----END PGP SIGNATURE----- |
|
From: Rod J. <rod...@in...> - 2004-02-09 22:02:32
|
I normally make DAOs threadsafe: seldom find reason to do otherwise. So yes, they should be singletons. TransactionInterceptor/TransactionManager etc normally should be singletons, as with the advised POJOs. Advisors and pointcuts in general can be shared, or per-proxy instance. So if you use a singleton tx interceptor (as you should) that will be shared for all AOP proxies. If you have a stateful advice such as a mixin, that would be unique to each proxy instance created using it. ----- Original Message ----- From: "Rob Rudin" <rob...@ur...> To: "Colin Sampaleanu" <spr...@li...> Sent: Monday, February 09, 2004 8:24 PM Subject: Re: [Springframework-developer] Threadsafe HibernateTemplate vs. non-threadsafe JdbcTemplate > Regarding HibernateTemplate being threadsafe - this means that > HibernateDaoSupport is threadsafe, which means that all > subclasses of it (provided they themselves are threadsafe) can > be marked as singleton's in the config file, right? > > Also, we just added an instance of TransactionInterceptor and > BeanNameAutoProxyCreator, along with an instance of > TransactionManager, so that we could define transaction rqmts > for each business object. I assume that these can be singleton's > as well, and the thread-safe business objects (manager-style) > which the interceptor is applied to can thus be singleton's > too? > > Rob > > > > > > ---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) > wrote: > > > I've seen somebody get burned by the fact that > HibernateTemplate is > > threadsafe, while JdbcTemplate is not. We probably need to > document this > > difference a bit better, and the probable usage scenario that > results > > (i.e. it's generally ok to produce one singleton > HibernateTemplate in > > your context and use it everywhere, whereas you probably want > to create > > jdbcTemplates on demand; not even setting it non-singleton in > the > > context is enough, since if it is fed as a dependency to > another object > > which is singleton, and that object is assumed to be thread > safe, there > > will be problems). > > > > Will add some stuff to the javadocs tonight... > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, > CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-02-09 21:06:44
|
First of all, my statement about JdbcTemplate being non-threadsafe seems to be BS. I always thought it was threadsafe, but then somebody here got hit with an error from JBoss that a connection was already closed. I looked at the source, but not well enough, and assumed it was not threadsafe. Aside from the parameters which are set once at creation, there is actually nothing in there which needs to be touched once it is created, and the DataSource and connection obtained from it is attached to the current thread and transaction, so there is no problem with coming in to the same jdbctemplate instance from another thread. Now there _does_ appear to be a problem in JBoss with managing connections in a mixed Spring/EJB environment. I am still trying to track this down. It seems to be worse in 3.2.2RC3 than 3.2.3, which leads me to believe it's a JBoss bug. As for HibernateTemplate being threadsafe; yes, it's threadsafe, and so is HibernateDaoSupport and any subclasses, unless of course you add something which is not threadsafe. Same goes for HibernateInterceptor, and the TransactionInterceptors. We run everything as singletons... Regards, Colin Rob Rudin wrote: >Regarding HibernateTemplate being threadsafe - this means that >HibernateDaoSupport is threadsafe, which means that all >subclasses of it (provided they themselves are threadsafe) can >be marked as singleton's in the config file, right? > >Also, we just added an instance of TransactionInterceptor and >BeanNameAutoProxyCreator, along with an instance of >TransactionManager, so that we could define transaction rqmts >for each business object. I assume that these can be singleton's >as well, and the thread-safe business objects (manager-style) >which the interceptor is applied to can thus be singleton's >too? > >Rob > > > > > >---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) >wrote: > > > >>I've seen somebody get burned by the fact that >> >> >HibernateTemplate is > > >>threadsafe, while JdbcTemplate is not. We probably need to >> >> >document this > > >>difference a bit better, and the probable usage scenario that >> >> >results > > >>(i.e. it's generally ok to produce one singleton >> >> >HibernateTemplate in > > >>your context and use it everywhere, whereas you probably want >> >> >to create > > >>jdbcTemplates on demand; not even setting it non-singleton in >> >> >the > > >>context is enough, since if it is fed as a dependency to >> >> >another object > > >>which is singleton, and that object is assumed to be thread >> >> >safe, there > > >>will be problems). >> >>Will add some stuff to the javadocs tonight... >> >> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by EclipseCon 2004 >>Premiere Conference on Open Tools Development and Integration >>See the breadth of Eclipse activity. February 3-5 in Anaheim, >> >> >CA. > > >>http://www.eclipsecon.org/osdn >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >> >> >> >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >> >> |
|
From: Colin S. <col...@ex...> - 2004-02-09 20:43:13
|
I tried ojdbc14.jar around August, and this was the version which had=20 files inside it dated 2002-6-11 for the most part, with some dated=20 2003-2-19(. It mostly worked, but broke some part of our app;=20 unfortunately I don't remember exactly what the problem was. However, if=20 I remember, ojdbc14 is even listed on the Oracle site as being only for=20 9i+... I've only tried imagedb with the 8i classes12 driver, which broke in the=20 fashion described in this thread. It may even work with 8i with the=20 ojdbc14 driver, but unfortuantely that doesn't mean other apps will=20 necessarilly work ok. I must say, for a bilion dollar company, Oracle has totally f*cked up=20 the implementation, bundling, and documentation of their JDBC drivers.=20 Quite inexcusable... tri...@tr... wrote: >Have you tried using ojdbc14.jar - I don't recall having any problems ac= cessing >an 8i database with the latest version. I'm not at work today, but I co= uld try >it tomorrow on both 8i and 9i with various jdbc drivers. Are you runnin= g the >imagedb sample app? > >Thomas > > >Quoting Colin Sampaleanu <col...@ex...>: > > =20 > >>No, I have personal experience that using the 9i classes12 against an 8= i=20 >>database has weird (bad) results. >> >>As I mentioned in a subsequent message, I do have working code for the=20 >>8i driver (figured out at great pain :-) ), and can produce a lobhandle= r=20 >>for that. Given the fact that database migration is such a pain, a lot=20 >>of people are still using 8i, so it's probably worth it for me to do it= . >> >>Colin >> >> >>j=FCrgen h=F6ller [werk3AT] wrote: >> >> =20 >> >>>Colin, >>> >>>The answer is in OracleLobHandler's javadoc, end of first paragraph: >>> =20 >>> >>"Developed and tested on Oracle 9i." ;-)=20 >> =20 >> >>>The Oracle 8i drivers did not have the current proprietary BLOB/CLOB A= PI. >>> =20 >>> >>Nevertheless, I've heard that someone has used the Oracle 9i drivers ag= ainst >>an 8i database with OracleLobHandler, and it did work. In any case, I d= on't >>see a chance to explicitly support Oracle 8i here, as we need the LOB A= PI. >> =20 >> >>>Juergen >>> >>> >>>-----Original Message----- >>>From: spr...@li... >>>[mailto:spr...@li...]On Behal= f >>>Of Colin Sampaleanu >>>Sent: Monday, February 09, 2004 5:07 PM >>>To: spr...@li... >>>Subject: Re: [Springframework-developer] Ready for 1.0 RC1 >>> >>> >>>Juergen, >>> >>>What Oracle JDBC driver version did you develop Oracle LobHandler with= ? >>> >>>I am using it with the last version of the JDK 1.2/1.3 'classes12'=20 >>>zip/jar from Oracle, which works with Oracle 8. With that version, I g= et=20 >>>the following exception: >>> >>>2004-02-09 10:56:09,655 ERROR [org.jboss.web.localhost.Engine] -----=20 >>>Root Cause ----- >>>java.lang.NoSuchFieldException: DURATION_SESSION >>> at java.lang.Class.getField(Class.java:911) >>> at=20 >>> =20 >>> >>org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobH= andler.java:101) >> =20 >> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> =20 >>> >>Method) >> =20 >> >>> at=20 >>> =20 >>> >>sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor= AccessorImpl.java:39) >> =20 >> >>> at=20 >>> =20 >>> >>sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCon= structorAccessorImpl.java:27) >> =20 >> >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:274) >>> at java.lang.Class.newInstance0(Class.java:308) >>> at java.lang.Class.newInstance(Class.java:261) >>> at=20 >>>org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31= ) >>> at=20 >>>org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:= 150) >>> at=20 >>> =20 >>> >>org.springframework.beans.factory.support.AbstractBeanFactory.createBea= n(AbstractBeanFactory.java:570) >> =20 >> >>> at=20 >>> =20 >>> >>org.springframework.beans.factory.support.AbstractBeanFactory.getBean(A= bstractBeanFactory.java:184) >> =20 >> >>>Note that there is a later 'classes12' zip/jar targetted at Oracle 9,=20 >>>which will not work with Oracle 8. >>> >>>There is also a JDK 1.4 'ojdbc14.jar' which is good with Oracle 9 only= . >>> >>>Regards, >>>Colin >>> >>> >>> >>>j=FCrgen h=F6ller [werk3AT] wrote: >>> >>>=20 >>> >>> =20 >>> >>>>I'm gonna commit some minor code polishing within the next couple of = hours; >>>> =20 >>>> >>I'm gonna re-test everything I have this afternoon. I'll also update ou= r CVS >>libs to Hibernate 2.1.2 and iBATIS Database Layer 1.3.1 (unfortunately,= CGLIB >>2.0 is still at RC2). >> =20 >> >>>>Colin, Darren, It would be great if you could give the most current C= VS >>>> =20 >>>> >>head another go then. I'm gonna do the release tomorrow morning (my tim= e, >>that is in less than 24 hours). Please report any urgent issues promptl= y. I'd >>also be happy if you give some of the sample apps a try (particularly t= he new >>"imagedb"). >> =20 >> >>>>I'm inclined to include neither a PlatformTransactionManagerUtils nor= a >>>> =20 >>>> >>CurrentTransactionStatus class in this release, if we haven't settled o= n how >>we want to proceed there. For the time being, the 4-line code snippet I >>posted for a setCurrentTransactionRollbackOnly method works nicely when= coded >>by hand. >> =20 >> >>>>BTW, could someone please generate a current reference doc PDF into t= he >>>> =20 >>>> >>docs directory in CVS? The current version there is from November, and = I >>still haven't set up the required libraries on my machine here... >> =20 >> >>>>Juergen >>>> >>>> >>>>________________________________ >>>> >>>>Von: spr...@li... im Auftrag= von >>>> =20 >>>> >>Colin Sampaleanu >> =20 >> >>>>Gesendet: Mo 09.02.2004 01:15 >>>>An: spr...@li... >>>>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 >>>> >>>> >>>> >>>>I've been in a big crunch mode here, including working most of the >>>>weekend, so have not tested Spring functionality not related to my ma= in >>>>app. However, for my main app, the new code from Wed/Thurs has been >>>>running with no problems (this includes multi-context use, AOP for >>>>transaction and Hibernate session wrapping, Hibernate OR support code= , >>>>and small amounts of JDBC code, against Oracle). >>>> >>>>Some time later tonight I'll pull down any changes, and give that ago= , >>>>also adding in the new Hibernate 2.12... >>>> >>>> >>>>Darren Davison wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>-----BEGIN PGP SIGNED MESSAGE----- >>>>>Hash: SHA1 >>>>> >>>>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] wro= te: >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>>>I'd like to encourage everybody to test the current CVS head thorou= ghly. >>>>>>I will test our sample apps myself too, against HSQLDB and MySQL, b= ut >>>>>> =20 >>>>>> >>I'm >> =20 >> >>>>>>primarily talking of custom applications here. Please report any >>>>>>remaining issues promptly; I intend to release RC1 this weekend. >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>>>>I've run a couple of apps this weekend without any issues on tomcat5= - >>>>>they're lightweight web apps, one with JDBC access to MySQL and one = with >>>>>hibernate. Both seem fine through normal usage. >>>>> >>>>>Using the autobuilds' modified jpetstore app, I tested on resin2, re= sin3, >>>>>tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no problems.= =20 >>>>> =20 >>>>> >>Jetty >> =20 >> >>>>>4.2.17 standalone failed as usual due to not reading the tld's in th= e jar >>>>>files. >>>>> >>>>>Just for the hell of it, I ran all of the above tests on Sun JDK 1.4= .1, >>>>>Blackdown JDK 1.3.1 and Blackdown JDK 1.4.1. >>>>> >>>>>Fairly meaningless, but interesting nonetheless, the average time ta= ken >>>>> =20 >>>>> >>by >> =20 >> >>>>>each app server for the 'testPurchase' test case over 5 runs each on= my >>>>>machine (with the Sun JDK) is below. >>>>> >>>>>resin2: 10s >>>>>resin3: 30s >>>>>tomcat4: 25s >>>>>tomcat5: 12s >>>>>jboss3/tomcat: 36s (gotta love those JBoss guys) >>>>> >>>>>(testPurchase involves browsing the items, adding to cart, changing = the >>>>>order, logging in incorrectly, logging in correctly, changing user >>>>>registration details, completing the purchase and checking the datab= ase >>>>>tables for sane numbers) >>>>> =20 >>>>> =20 >>>>> >>>>> =20 >>>>> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by EclipseCon 2004 >>Premiere Conference on Open Tools Development and Integration >>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>http://www.eclipsecon.org/osdn >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> =20 >> > > > > =20 > |
|
From: <tri...@tr...> - 2004-02-09 20:32:25
|
Have you tried using ojdbc14.jar - I don't recall having any problems accessing an 8i database with the latest version. I'm not at work today, but I could try it tomorrow on both 8i and 9i with various jdbc drivers. Are you running the imagedb sample app? Thomas Quoting Colin Sampaleanu <col...@ex...>: > No, I have personal experience that using the 9i classes12 against an 8i > database has weird (bad) results. > > As I mentioned in a subsequent message, I do have working code for the > 8i driver (figured out at great pain :-) ), and can produce a lobhandler > for that. Given the fact that database migration is such a pain, a lot > of people are still using 8i, so it's probably worth it for me to do it. > > Colin > > > jürgen höller [werk3AT] wrote: > > >Colin, > > > >The answer is in OracleLobHandler's javadoc, end of first paragraph: > "Developed and tested on Oracle 9i." ;-) > > > >The Oracle 8i drivers did not have the current proprietary BLOB/CLOB API. > Nevertheless, I've heard that someone has used the Oracle 9i drivers against > an 8i database with OracleLobHandler, and it did work. In any case, I don't > see a chance to explicitly support Oracle 8i here, as we need the LOB API. > > > >Juergen > > > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...]On Behalf > >Of Colin Sampaleanu > >Sent: Monday, February 09, 2004 5:07 PM > >To: spr...@li... > >Subject: Re: [Springframework-developer] Ready for 1.0 RC1 > > > > > >Juergen, > > > >What Oracle JDBC driver version did you develop Oracle LobHandler with? > > > >I am using it with the last version of the JDK 1.2/1.3 'classes12' > >zip/jar from Oracle, which works with Oracle 8. With that version, I get > >the following exception: > > > >2004-02-09 10:56:09,655 ERROR [org.jboss.web.localhost.Engine] ----- > >Root Cause ----- > >java.lang.NoSuchFieldException: DURATION_SESSION > > at java.lang.Class.getField(Class.java:911) > > at > >org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHandler.java:101) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > >sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > at > >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > > at java.lang.Class.newInstance0(Class.java:308) > > at java.lang.Class.newInstance(Class.java:261) > > at > >org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31) > > at > >org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:150) > > at > >org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:570) > > at > >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:184) > > > >Note that there is a later 'classes12' zip/jar targetted at Oracle 9, > >which will not work with Oracle 8. > > > >There is also a JDK 1.4 'ojdbc14.jar' which is good with Oracle 9 only. > > > >Regards, > >Colin > > > > > > > >jürgen höller [werk3AT] wrote: > > > > > > > >>I'm gonna commit some minor code polishing within the next couple of hours; > I'm gonna re-test everything I have this afternoon. I'll also update our CVS > libs to Hibernate 2.1.2 and iBATIS Database Layer 1.3.1 (unfortunately, CGLIB > 2.0 is still at RC2). > >> > >>Colin, Darren, It would be great if you could give the most current CVS > head another go then. I'm gonna do the release tomorrow morning (my time, > that is in less than 24 hours). Please report any urgent issues promptly. I'd > also be happy if you give some of the sample apps a try (particularly the new > "imagedb"). > >> > >>I'm inclined to include neither a PlatformTransactionManagerUtils nor a > CurrentTransactionStatus class in this release, if we haven't settled on how > we want to proceed there. For the time being, the 4-line code snippet I > posted for a setCurrentTransactionRollbackOnly method works nicely when coded > by hand. > >> > >>BTW, could someone please generate a current reference doc PDF into the > docs directory in CVS? The current version there is from November, and I > still haven't set up the required libraries on my machine here... > >> > >>Juergen > >> > >> > >>________________________________ > >> > >>Von: spr...@li... im Auftrag von > Colin Sampaleanu > >>Gesendet: Mo 09.02.2004 01:15 > >>An: spr...@li... > >>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1 > >> > >> > >> > >>I've been in a big crunch mode here, including working most of the > >>weekend, so have not tested Spring functionality not related to my main > >>app. However, for my main app, the new code from Wed/Thurs has been > >>running with no problems (this includes multi-context use, AOP for > >>transaction and Hibernate session wrapping, Hibernate OR support code, > >>and small amounts of JDBC code, against Oracle). > >> > >>Some time later tonight I'll pull down any changes, and give that ago, > >>also adding in the new Hibernate 2.12... > >> > >> > >>Darren Davison wrote: > >> > >> > >> > >> > >> > >>>-----BEGIN PGP SIGNED MESSAGE----- > >>>Hash: SHA1 > >>> > >>>On Wednesday 04 February 2004 19:11, jürgen höller [werk3AT] wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>I'd like to encourage everybody to test the current CVS head thoroughly. > >>>>I will test our sample apps myself too, against HSQLDB and MySQL, but > I'm > >>>>primarily talking of custom applications here. Please report any > >>>>remaining issues promptly; I intend to release RC1 this weekend. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I've run a couple of apps this weekend without any issues on tomcat5 - > >>>they're lightweight web apps, one with JDBC access to MySQL and one with > >>>hibernate. Both seem fine through normal usage. > >>> > >>>Using the autobuilds' modified jpetstore app, I tested on resin2, resin3, > >>>tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no problems. > Jetty > >>>4.2.17 standalone failed as usual due to not reading the tld's in the jar > >>>files. > >>> > >>>Just for the hell of it, I ran all of the above tests on Sun JDK 1.4.1, > >>>Blackdown JDK 1.3.1 and Blackdown JDK 1.4.1. > >>> > >>>Fairly meaningless, but interesting nonetheless, the average time taken > by > >>>each app server for the 'testPurchase' test case over 5 runs each on my > >>>machine (with the Sun JDK) is below. > >>> > >>>resin2: 10s > >>>resin3: 30s > >>>tomcat4: 25s > >>>tomcat5: 12s > >>>jboss3/tomcat: 36s (gotta love those JBoss guys) > >>> > >>>(testPurchase involves browsing the items, adding to cart, changing the > >>>order, logging in incorrectly, logging in correctly, changing user > >>>registration details, completing the purchase and checking the database > >>>tables for sane numbers) > >>> > >>> > >>> > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Rob R. <rob...@ur...> - 2004-02-09 20:24:52
|
Regarding HibernateTemplate being threadsafe - this means that HibernateDaoSupport is threadsafe, which means that all subclasses of it (provided they themselves are threadsafe) can be marked as singleton's in the config file, right? Also, we just added an instance of TransactionInterceptor and BeanNameAutoProxyCreator, along with an instance of TransactionManager, so that we could define transaction rqmts for each business object. I assume that these can be singleton's as well, and the thread-safe business objects (manager-style) which the interceptor is applied to can thus be singleton's too? Rob ---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) wrote: > I've seen somebody get burned by the fact that HibernateTemplate is > threadsafe, while JdbcTemplate is not. We probably need to document this > difference a bit better, and the probable usage scenario that results > (i.e. it's generally ok to produce one singleton HibernateTemplate in > your context and use it everywhere, whereas you probably want to create > jdbcTemplates on demand; not even setting it non-singleton in the > context is enough, since if it is fed as a dependency to another object > which is singleton, and that object is assumed to be thread safe, there > will be problems). > > Will add some stuff to the javadocs tonight... > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Colin S. <col...@ex...> - 2004-02-09 19:47:58
|
This reminds me of something else in JdbcTemplate that I've been meaning
to bring up for a while. Why does the JdbcTemplate(DataSource)
constructor eagerly instantiate the SQL exception translator? I seem to
remember it was not always so.
As per the email below, anywhere you don't know for sure you are
threadsafe, it's convenient to use JdbcTemplate in a form like
new JdbcTemplate(datasource).xxxxx(...);
but this results in an annoying lookup of the metadata to build the
exception translator.
Now obviously you could instead just use a static factory method which
creates an instance for you like this:
public static JDBCTemplate createJdbcTemplate(Datasource ds) {
JdbcTemplate jt = new JdbcTemplate();
jt.setDataSource(ds);
return jt;
}
but I'm not sure why the eager loading should be the default. And even
the above static method is 'technically' wrong, since it shold by
contract be calling afterPropertiesSet(), which would force the eager
init of the exception translator.
Aside from making it non-eager, the other option is for the exception
translator to actually cache lookups towards the same datasource...
Regards,
Colin
Colin Sampaleanu wrote:
> I've seen somebody get burned by the fact that HibernateTemplate is
> threadsafe, while JdbcTemplate is not. We probably need to document
> this difference a bit better, and the probable usage scenario that
> results (i.e. it's generally ok to produce one singleton
> HibernateTemplate in your context and use it everywhere, whereas you
> probably want to create jdbcTemplates on demand; not even setting it
> non-singleton in the context is enough, since if it is fed as a
> dependency to another object which is singleton, and that object is
> assumed to be thread safe, there will be problems).
>
> Will add some stuff to the javadocs tonight...
|