|
From: <jue...@we...> - 2004-02-04 19:22:22
|
Forgot to say, thanks to Thomas Achleitner for providing the initial =
version of ReloadableResourceBundleMessageSource!
(BTW, Thomas: Resource locations can now resolve system properties like =
${user.home} out of the box - no need for custom =
PropertyPlaceholderConfigurer subclasses anymore).
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, February 04, 2004 8:11 PM
To: spr...@li...
Subject: [Springframework-developer] Ready for 1.0 RC1
Everybody,
I've committed my final reworkings for 1.0 RC1 one. Quite a few internal =
classes have moved between packages; there shouldn't be any major =
incompatilities. I've also incorporated most recent bug reports in the =
affected areas.
A new feature is ReloadableResourceBundleMessageSource: An alternative =
implementation of MessageSource that follows basic ResourceBundle =
conventions but is able to reload message definitions and to load the =
properties files from any resource location. This removes a major =
nuisance of java.util.ResourceBundle in a server environment: =
Effectively, message definitions can now be changed on-the-fly like JSPs =
or templates can, without losing a significant amount efficiency.
The "cacheSeconds" interval specifies the refresh interval: If the =
last-modified timestamp of the files hasn't changed, no reloading will =
occur. So "cacheSeconds" can be set to 1 without worrying about =
performance. My own rudimentary performance tests indicate that =
ReloadableResourceBundleMessageSource is twice as fast as the standard =
ResourceBundleMessageSource when caching forever, and still 40% faster =
with "cacheSeconds" =3D 1.
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.
Juergen
P.S.:
Haven't had the time to look at the 96-beans issue; will do so tomorrow.
DI J=FCrgen H=F6ller
Senior System Architect
______________________________________
werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme
europaplatz 4
A - 4020 linz
t. +43 (0) 732 71 65 29 502
f. +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG
-------------------------------------------------------
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: <jue...@we...> - 2004-02-05 07:54:52
|
Alef,
=20
What you're doing here is getting a *new* TransactionStatus for a new =
sub-transaction back: A sub-transaction needs to be committed or =
rollbacked (via mgr.commit/rollback) to be effective.
=20
What you intend is to mark the *current* TransactionStatus =
rollback-only: with TransactionTemplate, you can use the passed-in =
TransactionStatus; with AOP, =
TransactionInterceptor.currentTransactionStatus().
=20
In general, I see hardly any use cases for rolling back without throwing =
an exception anyway. If you want to roll back on checked exception, =
simply specify those in the transaction attributes, e.g. =
"-MyCheckedException".
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Do 05.02.2004 00:27
An: spr...@li...
Betreff: RE: [Springframework-developer] Ready for 1.0 RC1
There's an issue that just came up with the TransactionManager. I
haven't spend enough time on it to fully figure it out, but before I dig
into it further, maybe you guys can give an opinion:
When using a DataSourceTransactionManager, in a bean I'm asking the
applicationcontext for the transactionmanager. After calling
setRollbackOnly() is doesn't rollback. I've reproduced this using
petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic
and in one of the store*** methods calling:
PlatformTransactionManager mgr =3D
(PlatformTransactionManager)appCtx.getBean(
"transactionManager");
// does this give me the current transaction???
mgr.getTransaction(null).setRollbackOnly();
AFAIK this should result in a rollback, shouldn't it...
Thanx,
Alef
P.s. we're doing this because of some legacy code that needs to rollback
as well. We can't reimplement it right now...
-------------------------------------------------------
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-05 12:38:48
|
There _is_ actually a pretty big use case for this, supporting existing code which wants to use this type of mechanism. For example, we currently use OSWorkflow with the EJB implementation. We want to move to the Hibernate workflow store, but would have to create our own Spring-based transactional workflow to wrap around that. This needs to support a setRollbackOnly mechanism, same as the existing impl. (based on ejb), and the caller doesn't expect an exception at that point, so it's not like the impl. could just throw an exception. Anyways, we can just use the status off the template, so that's fine, but other people might do the same thing as Alef (try to work off the transactionmanager). I got confused myself; when I was looking at the impl. last night I saw for a few of the propogation cases (not supported, and new) that it created a new status and suspended the existing trans., but I figured for the null case with the default definition object being created, and joining in the existing transaction, with no new synchronization, that he was ok. Of course that doesn't make any sense, there is a whole new status object being created... We should probably change the javadocs for PlatformTransactionManager to clarify that getTransaction is not for this use case... jürgen höller [werk3AT] wrote: >Alef, > >What you're doing here is getting a *new* TransactionStatus for a new sub-transaction back: A sub-transaction needs to be committed or rollbacked (via mgr.commit/rollback) to be effective. > >What you intend is to mark the *current* TransactionStatus rollback-only: with TransactionTemplate, you can use the passed-in TransactionStatus; with AOP, TransactionInterceptor.currentTransactionStatus(). > >In general, I see hardly any use cases for rolling back without throwing an exception anyway. If you want to roll back on checked exception, simply specify those in the transaction attributes, e.g. "-MyCheckedException". > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Alef Arendsen >Gesendet: Do 05.02.2004 00:27 >An: spr...@li... >Betreff: RE: [Springframework-developer] Ready for 1.0 RC1 > > > >There's an issue that just came up with the TransactionManager. I >haven't spend enough time on it to fully figure it out, but before I dig >into it further, maybe you guys can give an opinion: > >When using a DataSourceTransactionManager, in a bean I'm asking the >applicationcontext for the transactionmanager. After calling >setRollbackOnly() is doesn't rollback. I've reproduced this using >petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic >and in one of the store*** methods calling: > >PlatformTransactionManager mgr = > (PlatformTransactionManager)appCtx.getBean( > "transactionManager"); >// does this give me the current transaction??? >mgr.getTransaction(null).setRollbackOnly(); > >AFAIK this should result in a rollback, shouldn't it... > >Thanx, > >Alef > >P.s. we're doing this because of some legacy code that needs to rollback >as well. We can't reimplement it right now... > > |
|
From: Alef A. <al...@jt...> - 2004-02-06 12:25:07
|
TransactionInterceptor.currentTransactionStatus() seems to work with the petclinic example. However, it does not work here, but that=92s our = problem... Thanx, Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, February 05, 2004 8:54 AM > To: spr...@li... > Subject: Re: [Springframework-developer] Ready for 1.0 RC1 >=20 > Alef, >=20 > What you're doing here is getting a *new* TransactionStatus for a new = sub- > transaction back: A sub-transaction needs to be committed or = rollbacked > (via mgr.commit/rollback) to be effective. >=20 > What you intend is to mark the *current* TransactionStatus = rollback-only: > with TransactionTemplate, you can use the passed-in TransactionStatus; > with AOP, TransactionInterceptor.currentTransactionStatus(). >=20 > In general, I see hardly any use cases for rolling back without = throwing > an exception anyway. If you want to roll back on checked exception, = simply > specify those in the transaction attributes, e.g. = "-MyCheckedException". >=20 > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag = von > Alef Arendsen > Gesendet: Do 05.02.2004 00:27 > An: spr...@li... > Betreff: RE: [Springframework-developer] Ready for 1.0 RC1 >=20 >=20 >=20 > There's an issue that just came up with the TransactionManager. I > haven't spend enough time on it to fully figure it out, but before I = dig > into it further, maybe you guys can give an opinion: >=20 > When using a DataSourceTransactionManager, in a bean I'm asking the > applicationcontext for the transactionmanager. After calling > setRollbackOnly() is doesn't rollback. I've reproduced this using > petclinic, by implementing ApplicationContextAware in = AbstractJdbcClinic > and in one of the store*** methods calling: >=20 > PlatformTransactionManager mgr =3D > (PlatformTransactionManager)appCtx.getBean( > "transactionManager"); > // does this give me the current transaction??? > mgr.getTransaction(null).setRollbackOnly(); >=20 > AFAIK this should result in a rollback, shouldn't it... >=20 > Thanx, >=20 > Alef >=20 > P.s. we're doing this because of some legacy code that needs to = rollback > as well. We can't reimplement it right now... >=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 >=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 |
|
From: <rod...@in...> - 2004-02-05 09:10:57
|
>In general, I see hardly any use cases for rolling back without throwing an exception anyway. If you want to roll back on checked exception, simply specify those in the transaction attributes, e.g. "-MyCheckedException". +1. This is important for non-invasiveness. You want to try avoid depending on Spring tx api if you can. With Spring rollback rules you can avoid such dependence; with EJB CMT you can't. |
|
From: <jue...@we...> - 2004-02-09 09:06:47
|
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=FCrgen h=F6ller [werk3AT] wrote: > >=20 > >>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. >> =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, = 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) >=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: Alef A. <al...@jt...> - 2004-02-09 10:50:25
|
> 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"). Unfortunately I can't test proprietary apps currently, got a couple of days off and am not in the office... I'll try to test imagedb and some of the other samples. > 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. Yeah that works, agree not including it for now... > 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... Yup, no problem... Strange that thing is still in there... It's on the website as well. Maybe later on we should remove it from the CVS... I'll update the version on the website as well. Btw hope to find some time to do more on it this week. |
|
From: Alef A. <al...@jt...> - 2004-02-09 10:55:04
|
> 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... It's there. |
|
From: Colin S. <col...@ex...> - 2004-02-09 16:06:59
|
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 get=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
org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHan=
dler.java:101)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Meth=
od)
at=20
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAc=
cessorImpl.java:39)
at=20
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConst=
ructorAccessorImpl.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=20
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31)
at=20
org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:150=
)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:570)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:184)
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:
>I'm gonna commit some minor code polishing within the next couple of hou=
rs; 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 (unfortun=
ately, 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 (particular=
ly 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 whe=
n 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 vo=
n 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:
>
> =20
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>> =20
>>
>>>I'd like to encourage everybody to test the current CVS head thoroughl=
y.
>>>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.
>>> =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 wit=
h
>>hibernate. Both seem fine through normal usage.
>>
>>Using the autobuilds' modified jpetstore app, I tested on resin2, resin=
3,
>>tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no problems. J=
etty
>>4.2.17 standalone failed as usual due to not reading the tld's in the j=
ar
>>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)
>> =20
>>
|
|
From: Colin S. <col...@ex...> - 2004-02-09 16:36:31
|
Juergen, I have done some decompiling of the 3 Oracle JDBC driver versions. Looks=20 like classes12 (9i) and ojdbc14 (9i) have these fields, but classes12=20 (8i) does not. That version does not even have an open() method. I do have working code for handling blobs with the classes12 (8i)=20 driver, so can probably produce a variant of the lobhandler targetted=20 towards that. Unfortunately I am _really_ busy for the next month, so=20 may or may not be able to do it during that time. Colin Colin Sampaleanu wrote: > 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=20 > get 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 > org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobH= andler.java:101)=20 > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native=20 > Method) > at=20 > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor= AccessorImpl.java:39)=20 > > at=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:1= 50)=20 > > at=20 > org.springframework.beans.factory.support.AbstractBeanFactory.createBea= n(AbstractBeanFactory.java:570)=20 > > at=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: > >> I'm gonna commit some minor code polishing within the next couple of=20 >> hours; I'm gonna re-test everything I have this afternoon. I'll also=20 >> update our CVS libs to Hibernate 2.1.2 and iBATIS Database Layer=20 >> 1.3.1 (unfortunately, CGLIB 2.0 is still at RC2). >> >> Colin, Darren, It would be great if you could give the most current=20 >> CVS head another go then. I'm gonna do the release tomorrow morning=20 >> (my time, that is in less than 24 hours). Please report any urgent=20 >> issues promptly. I'd also be happy if you give some of the sample=20 >> apps a try (particularly the new "imagedb"). >> >> I'm inclined to include neither a PlatformTransactionManagerUtils nor=20 >> a CurrentTransactionStatus class in this release, if we haven't=20 >> settled on how we want to proceed there. For the time being, the=20 >> 4-line code snippet I posted for a setCurrentTransactionRollbackOnly=20 >> method works nicely when coded by hand. >> >> BTW, could someone please generate a current reference doc PDF into=20 >> the docs directory in CVS? The current version there is from=20 >> November, and I still haven't set up the required libraries on my=20 >> machine here... >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag=20 >> 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 mai= n >> 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 >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] wrot= e: >>> >>> >>> >>> =20 >>> >>>> I'd like to encourage everybody to test the current CVS head=20 >>>> thoroughly. >>>> I will test our sample apps myself too, against HSQLDB and MySQL,=20 >>>> but I'm >>>> primarily talking of custom applications here. Please report any >>>> remaining issues promptly; I intend to release RC1 this weekend. >>>> =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=20 >>> with >>> hibernate. Both seem fine through normal usage. >>> >>> Using the autobuilds' modified jpetstore app, I tested on resin2,=20 >>> resin3, >>> tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no=20 >>> problems. Jetty >>> 4.2.17 standalone failed as usual due to not reading the tld's in=20 >>> 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=20 >>> 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 t= he >>> order, logging in incorrectly, logging in correctly, changing user >>> registration details, completing the purchase and checking the databa= se >>> tables for sane numbers) >>> =20 >> > > |
|
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: <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: <jue...@we...> - 2004-02-09 16:21:55
|
Colin,
The answer is in OracleLobHandler's javadoc, end of first paragraph: =
"Developed and tested on Oracle 9i." ;-)=20
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'=20
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] -----=20
Root Cause -----
java.lang.NoSuchFieldException: DURATION_SESSION
at java.lang.Class.getField(Class.java:911)
at=20
org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHan=
dler.java:101)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native =
Method)
at=20
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAc=
cessorImpl.java:39)
at=20
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConst=
ructorAccessorImpl.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=20
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31)
at=20
org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:150=
)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:570)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:184)
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:
>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:
>
> =20
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] =
wrote:
>>
>>
>>
>> =20
>>
>>>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.
>>> =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, =
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)
>> =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-09 16:53:19
|
No, I have personal experience that using the 9i classes12 against an 8i=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 lobhandler=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: >Colin, > >The answer is in OracleLobHandler's javadoc, end of first paragraph: "De= veloped and tested on Oracle 9i." ;-)=20 > >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 ag= ainst 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 th= e 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'=20 >zip/jar from Oracle, which works with Oracle 8. With that version, I get= =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 >org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHa= ndler.java:101) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Met= hod) > at=20 >sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA= ccessorImpl.java:39) > at=20 >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons= tructorAccessorImpl.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=20 >org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31) > at=20 >org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:15= 0) > at=20 >org.springframework.beans.factory.support.AbstractBeanFactory.createBean= (AbstractBeanFactory.java:570) > at=20 >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab= stractBeanFactory.java:184) > >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 > >>I'm gonna commit some minor code polishing within the next couple of ho= urs; 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 (unfortu= nately, 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 promptl= y. I'd also be happy if you give some of the sample apps a try (particula= rly 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 snippe= t I posted for a setCurrentTransactionRollbackOnly method works nicely wh= en 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 v= on 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: >> >>=20 >> >> =20 >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] wrote= : >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>I'd like to encourage everybody to test the current CVS head thorough= ly. >>>>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. >>>>=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 wi= th >>>hibernate. Both seem fine through normal usage. >>> >>>Using the autobuilds' modified jpetstore app, I tested on resin2, resi= n3, >>>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 take= n by >>>each app server for the 'testPurchase' test case over 5 runs each on m= y >>>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 th= e >>>order, logging in incorrectly, logging in correctly, changing user >>>registration details, completing the purchase and checking the databas= e >>>tables for sane numbers) >>> =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: 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: <jue...@we...> - 2004-02-09 16:36:44
|
Actually, that "someone" is a Werk3 colleague sitting right opposite of =
me at the moment - that noticed the mail below and had to smile because =
of my wording :-)
I haven't seen that work myself, though: We've developed the product on =
9i, it's just been deployed on 8i for a specific customer. We'd have to =
double-check the actual driver version and database version used.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, February 09, 2004 5:22 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Ready for 1.0 RC1
Colin,
The answer is in OracleLobHandler's javadoc, end of first paragraph: =
"Developed and tested on Oracle 9i." ;-)=20
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'=20
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] -----=20
Root Cause -----
java.lang.NoSuchFieldException: DURATION_SESSION
at java.lang.Class.getField(Class.java:911)
at=20
org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHan=
dler.java:101)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native =
Method)
at=20
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAc=
cessorImpl.java:39)
at=20
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConst=
ructorAccessorImpl.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=20
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31)
at=20
org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:150=
)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:570)
at=20
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:184)
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:
>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:
>
> =20
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] =
wrote:
>>
>>
>>
>> =20
>>
>>>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.
>>> =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, =
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)
>> =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
-------------------------------------------------------
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: <jue...@we...> - 2004-02-09 16:51:15
|
For Spring 1.0, supporting Oracle 9i here is definitely good enough. Of = course, adding Oracle 8i support - if possible - would be a nice bonus! = After all, many companies are still stuck with 8i and won't upgrade in = the near future. However, I won't be able to work on this myself, as I'm = no Oracle expert by any means. (I'm glad that I found my way through the = 9i API!) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, February 09, 2004 5:36 PM To: spr...@li... Subject: Re: [Springframework-developer] Ready for 1.0 RC1 Juergen, I have done some decompiling of the 3 Oracle JDBC driver versions. Looks = like classes12 (9i) and ojdbc14 (9i) have these fields, but classes12=20 (8i) does not. That version does not even have an open() method. I do have working code for handling blobs with the classes12 (8i)=20 driver, so can probably produce a variant of the lobhandler targetted=20 towards that. Unfortunately I am _really_ busy for the next month, so=20 may or may not be able to do it during that time. Colin Colin Sampaleanu wrote: > 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=20 > get 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 > = org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHan= dler.java:101)=20 > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native=20 > Method) > at=20 > = sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAc= cessorImpl.java:39)=20 > > at=20 > = sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConst= ructorAccessorImpl.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= )=20 > > at=20 > = org.springframework.beans.factory.support.AbstractBeanFactory.createBean(= AbstractBeanFactory.java:570)=20 > > at=20 > = org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs= tractBeanFactory.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: > >> I'm gonna commit some minor code polishing within the next couple of=20 >> hours; I'm gonna re-test everything I have this afternoon. I'll also=20 >> update our CVS libs to Hibernate 2.1.2 and iBATIS Database Layer=20 >> 1.3.1 (unfortunately, CGLIB 2.0 is still at RC2). >> >> Colin, Darren, It would be great if you could give the most current=20 >> CVS head another go then. I'm gonna do the release tomorrow morning=20 >> (my time, that is in less than 24 hours). Please report any urgent=20 >> issues promptly. I'd also be happy if you give some of the sample=20 >> 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=20 >> settled on how we want to proceed there. For the time being, the=20 >> 4-line code snippet I posted for a setCurrentTransactionRollbackOnly=20 >> method works nicely when coded by hand. >> >> BTW, could someone please generate a current reference doc PDF into=20 >> the docs directory in CVS? The current version there is from=20 >> November, and I still haven't set up the required libraries on my=20 >> 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: >> >> =20 >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] = wrote: >>> >>> >>> >>> =20 >>> >>>> I'd like to encourage everybody to test the current CVS head=20 >>>> thoroughly. >>>> I will test our sample apps myself too, against HSQLDB and MySQL,=20 >>>> but I'm >>>> primarily talking of custom applications here. Please report any >>>> remaining issues promptly; I intend to release RC1 this weekend. >>>> =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=20 >>> with >>> hibernate. Both seem fine through normal usage. >>> >>> Using the autobuilds' modified jpetstore app, I tested on resin2,=20 >>> resin3, >>> tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no=20 >>> problems. Jetty >>> 4.2.17 standalone failed as usual due to not reading the tld's in=20 >>> 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=20 >>> 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) >>> =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: <jue...@we...> - 2004-02-09 17:09:51
|
I take your word for it - as I said in another mail, I haven't seen the = 9i driver work on an 8i database myself, and frankly, I have no trust in = the general viability of such a combo. So it'd be great if you can come = up with an 8i-capable OracleLobHandler! (possibly in the Spring 1.1 = timeframe) Maybe we can simply auto-detect the Oracle driver version through = introspection in a single unified OracleLobHandler implementation. = AFAIK, the difference is that the 8i driver didn't have the notion of = temporary LOBs; the Oracle BLOB and CLOB implementation classes = themselves should be compatible. So there's a chance for some code = reuse. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, February 09, 2004 5:53 PM To: spr...@li... Subject: Re: [Springframework-developer] Ready for 1.0 RC1 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=20 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=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: >Colin, > >The answer is in OracleLobHandler's javadoc, end of first paragraph: = "Developed and tested on Oracle 9i." ;-)=20 > >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'=20 >zip/jar from Oracle, which works with Oracle 8. With that version, I = get=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 >org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobHa= ndler.java:101) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native = Method) > at=20 >sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA= ccessorImpl.java:39) > at=20 >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons= tructorAccessorImpl.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=20 >org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31) > at=20 >org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:15= 0) > at=20 >org.springframework.beans.factory.support.AbstractBeanFactory.createBean= (AbstractBeanFactory.java:570) > at=20 >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab= stractBeanFactory.java:184) > >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 > >>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: >> >>=20 >> >> =20 >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [werk3AT] = wrote: >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>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. >>>>=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, = 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) >>> =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 |
|
From: Colin S. <col...@ex...> - 2004-02-09 17:48:34
|
No, there's no temporary LOBs, you essentially create it empty, then get=20
it back for update, and write to it. For example, here's some code for=20
writing LOBs (mixes in the selection code too, have to think how this=20
would translate to Spring's LobHandler):
/**
*
* Writes a lob object into the database
*
* @param tableName - the name of the table
* @param lobColumn - the name of the lob column
* @param idColumns - String array of reference column names
* @param ids - String array of reference column values
* @param in - InputStream which holds the data
* @param lobType - the type of the lob data: BLOB|CLOB
* @throws DataAccessException if there is a database or IO exception
*/
public void writeLob(String tableName, final String lobColumn,=20
String[] idColumns,
String[] ids, final InputStream in, String lobType) throws=20
DataAccessException {
Statement stmt =3D null;
ResultSet rset =3D null;
final boolean blob =3D checkLobType(lobType);
StringBuffer upd =3D new StringBuffer("update " + tableName + " set "=
=20
+ lobColumn
+ " =3D empty_" + lobType + "() where ");
StringBuffer cmds =3D new StringBuffer("select * from " + tableName +=
=20
" where ");
for (int i =3D 0; i < idColumns.length; i++) {
cmds.append(idColumns[i] + " =3D '" + ids[i] + "'");
upd.append(idColumns[i] + " =3D '" + ids[i] + "'");
if (i !=3D idColumns.length - 1) {
cmds.append(" and ");
upd.append(" and ");
}
}
cmds.append(" for update");
//logger.debug(cmds.toString());
//logger.debug(upd.toString());
_jdbcTemplate.update(upd.toString());
final boolean[] processedRow =3D {false};
_jdbcTemplate.query(cmds.toString(), new RowCallbackHandler() {
/* (non-Javadoc)
* @see=20
org.springframework.jdbc.core.RowCallbackHandler#processRow(java.sql.Resu=
ltSet)
*/
public void processRow(ResultSet rs) throws SQLException {
=20
processedRow[0] =3D true;
_log.debug("Inserting " + lobColumn);
BLOB blob_loc =3D null;
CLOB clob_loc =3D null;
if (blob)
blob_loc =3D ((OracleResultSet) rs).getBLOB(lobColumn);
else
clob_loc =3D ((OracleResultSet) rs).getCLOB(lobColumn);
if ((blob && blob_loc !=3D null) || (!blob && clob_loc !=3D null)=
) {
//logger.debug("Lob not null");
int size =3D 0;
OutputStream os =3D null;
if (blob) {
os =3D blob_loc.getBinaryOutputStream();
size =3D blob_loc.getBufferSize();
}
else {
os =3D clob_loc.getAsciiOutputStream();
size =3D clob_loc.getBufferSize();
}
byte[] buffer =3D new byte[size];
int length =3D -1;
try {
while ((length =3D in.read(buffer)) !=3D -1) {
os.write(buffer, 0, length);
//logger.debug("Writing " + length);
}
os.close();
}
catch (IOException e) {
throw new DataAccessResourceFailureException(
"Stream IO Error during LOB access", e);
}
}
else {
_log.debug("Lob is null");
}
}
});
if (!processedRow[0])
_log.warn("select returns no records");
try {
in.close();
}
catch (IOException e) {
// I think if everything worked this far, we don't care about a=20
failure to close the stream
}
}
j=FCrgen h=F6ller [werk3AT] wrote:
>I take your word for it - as I said in another mail, I haven't seen the =
9i driver work on an 8i database myself, and frankly, I have no trust in =
the general viability of such a combo. So it'd be great if you can come u=
p with an 8i-capable OracleLobHandler! (possibly in the Spring 1.1 timefr=
ame)
>
>Maybe we can simply auto-detect the Oracle driver version through intros=
pection in a single unified OracleLobHandler implementation. AFAIK, the d=
ifference is that the 8i driver didn't have the notion of temporary LOBs;=
the Oracle BLOB and CLOB implementation classes themselves should be com=
patible. So there's a chance for some code reuse.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Monday, February 09, 2004 5:53 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Ready for 1.0 RC1
>
>
>No, I have personal experience that using the 9i classes12 against an 8i=
=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 lobhandler=
=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: "D=
eveloped and tested on Oracle 9i." ;-)=20
>>
>>The Oracle 8i drivers did not have the current proprietary BLOB/CLOB AP=
I. Nevertheless, I've heard that someone has used the Oracle 9i drivers a=
gainst 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 t=
he 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'=20
>>zip/jar from Oracle, which works with Oracle 8. With that version, I ge=
t=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
>>org.springframework.jdbc.support.lob.OracleLobHandler.<init>(OracleLobH=
andler.java:101)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Met=
hod)
>> at=20
>>sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor=
AccessorImpl.java:39)
>> at=20
>>sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCon=
structorAccessorImpl.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=20
>>org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:31)
>> at=20
>>org.springframework.beans.BeanWrapperImpl.<init>(BeanWrapperImpl.java:1=
50)
>> at=20
>>org.springframework.beans.factory.support.AbstractBeanFactory.createBea=
n(AbstractBeanFactory.java:570)
>> at=20
>>org.springframework.beans.factory.support.AbstractBeanFactory.getBean(A=
bstractBeanFactory.java:184)
>>
>>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 h=
ours; I'm gonna re-test everything I have this afternoon. I'll also updat=
e our CVS libs to Hibernate 2.1.2 and iBATIS Database Layer 1.3.1 (unfort=
unately, CGLIB 2.0 is still at RC2).
>>>
>>>Colin, Darren, It would be great if you could give the most current CV=
S 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 prompt=
ly. I'd also be happy if you give some of the sample apps a try (particul=
arly the new "imagedb").
>>>
>>>I'm inclined to include neither a PlatformTransactionManagerUtils nor =
a 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 snipp=
et I posted for a setCurrentTransactionRollbackOnly method works nicely w=
hen coded by hand.
>>>
>>>BTW, could someone please generate a current reference doc PDF into th=
e 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 mai=
n
>>>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] wrot=
e:
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>> =20
>>>>
>>>> =20
>>>>
>>>>>I'd like to encourage everybody to test the current CVS head thoroug=
hly.
>>>>>I will test our sample apps myself too, against HSQLDB and MySQL, bu=
t I'm
>>>>>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 w=
ith
>>>>hibernate. Both seem fine through normal usage.
>>>>
>>>>Using the autobuilds' modified jpetstore app, I tested on resin2, res=
in3,
>>>>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 tak=
en 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 t=
he
>>>>order, logging in incorrectly, logging in correctly, changing user
>>>>registration details, completing the purchase and checking the databa=
se
>>>>tables for sane numbers)
>>>> =20
>>>> =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: 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: <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 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 > |