springframework-developer — Spring Framework developers list

[Springframework-developer] Threadsafe HibernateTemplate vs. non-threadsafe JdbcTemplate

[Colin S. <col...@ex...>]

I've seen somebody get burned by the fact that HibernateTemplate is 
threadsafe, while JdbcTemplate is not. We probably need to document this 
difference a bit better, and the probable usage scenario that results 
(i.e. it's generally ok to produce one singleton HibernateTemplate in 
your context and use it everywhere, whereas you probably want to create 
jdbcTemplates on demand; not even setting it non-singleton in the 
context is enough, since if it is fed as a dependency to another object 
which is singleton, and that object is assumed to be thread safe, there 
will be problems).

Will add some stuff to the javadocs tonight...

[Springframework-developer] Confucius

[Dmitriy K. <dko...@ru...>]

Have you seen this: http://www.theserverside.com/news/thread.jsp?thread_id=23779 ?

Re: [Springframework-developer] Ready for 1.0 RC1

[Colin S. <col...@ex...>]

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
>>>>

RE: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

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

Re: [Springframework-developer] Ready for 1.0 RC1

[Colin S. <col...@ex...>]

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
>>>

RE: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

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

RE: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

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

Re: [Springframework-developer] Ready for 1.0 RC1

[Colin S. <col...@ex...>]

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
>>
>
>

RE: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

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

Re: [Springframework-developer] Bean order in applicationContext.xml changed? How to force order.

[Colin S. <col...@ex...>]

Hi Jon,

You can also use the 'depends-on' attribute on each bean, to 'manually' 
force dependencies, in addition to the dependencies expressed by 
bean-refs as properties.

Regards,
Colin

Jon Mountjoy wrote:

>Hi,
>
>I used to use M2, now M4.
>
>I suspect that something has changed between the two versions, with
>respect to the order in which beans that are declared in
>applicationContext.xml, are instantiated.  Unfortunately I can't
>immediately check this as rolling back my changes are going to take a
>few hours.  Can anybody confirm that this has taken place?  Previously,
>I believe the syntactic order played a role (subject to dependency
>resolution).
>
>I have a nasty situation in which as my controllers are loaded, they
>register security  information about themselves with a class.  A
>"master" controller that needs to be loaded last, uses this registered
>information in its configuration.  In M2 I placed this class last in
>the dispatcher-servlet.xml, and it got instantiated last.  
>
>Is there anyway that I can specify this dependency, or change some
>Spring component to honour syntactic order as much as possible?
>
>Thanks
>Jon
>
>  
>

RE: [Springframework-developer] Bean order in applicationContext.xml changed? How to force order.

[<jue...@we...>]

Jon,

You should never rely on bean ordering in a context definition file. =
Bean definitions are internally stored in a HashMap; the original order =
will *not* be preserved. Bean factory internals have been significantly =
reworked in the last couple of months, so there might indeed be a change =
in the actual loading order.

Note that Spring will automatically initialize dependent beans first. So =
if you express dependencies via <ref> tags, the referenced beans will =
get initialized first (recursively). If you have non-obvious =
dependencies without direct references, you can declare "depends-on" =
attributes at the <bean> level: The beans whose names are specified =
there will get initialized before the respective bean then.

In your case, you could declare =
depends-on=3D"myController1,myController2,..." on the <bean> definition =
of your master controller. The actual definition order of your =
controllers in the XML file doesn't matter, so you're free to place this =
master controller definition anywhere.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Jon Mountjoy
Sent: Monday, February 09, 2004 4:51 PM
To: spr...@li...
Subject: [Springframework-developer] Bean order in
applicationContext.xml changed? How to force order.


Hi,

I used to use M2, now M4.

I suspect that something has changed between the two versions, with
respect to the order in which beans that are declared in
applicationContext.xml, are instantiated.  Unfortunately I can't
immediately check this as rolling back my changes are going to take a
few hours.  Can anybody confirm that this has taken place?  Previously,
I believe the syntactic order played a role (subject to dependency
resolution).

I have a nasty situation in which as my controllers are loaded, they
register security  information about themselves with a class.  A
"master" controller that needs to be loaded last, uses this registered
information in its configuration.  In M2 I placed this class last in
the dispatcher-servlet.xml, and it got instantiated last. =20

Is there anyway that I can specify this dependency, or change some
Spring component to honour syntactic order as much as possible?

Thanks
Jon


=09
=09
	=09
___________________________________________________________
BT Yahoo! Broadband - Free modem offer, sign up online today and save =
=A380 http://btyahoo.yahoo.co.uk


-------------------------------------------------------
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

Re: [Springframework-developer] Ready for 1.0 RC1

[Colin S. <col...@ex...>]

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
>>

[Springframework-developer] Bean order in applicationContext.xml changed? How to force order.

[<jon...@ya...>]

Hi,

I used to use M2, now M4.

I suspect that something has changed between the two versions, with
respect to the order in which beans that are declared in
applicationContext.xml, are instantiated.  Unfortunately I can't
immediately check this as rolling back my changes are going to take a
few hours.  Can anybody confirm that this has taken place?  Previously,
I believe the syntactic order played a role (subject to dependency
resolution).

I have a nasty situation in which as my controllers are loaded, they
register security  information about themselves with a class.  A
"master" controller that needs to be loaded last, uses this registered
information in its configuration.  In M2 I placed this class last in
the dispatcher-servlet.xml, and it got instantiated last.  

Is there anyway that I can specify this dependency, or change some
Spring component to honour syntactic order as much as possible?

Thanks
Jon


	
	
		
___________________________________________________________
BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk

RE: [Springframework-developer] Ready for 1.0 RC1

[Alef A. <al...@jt...>]

> 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.

RE: [Springframework-developer] Ready for 1.0 RC1

[Alef A. <al...@jt...>]

> 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.

Re: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

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

Re: [Springframework-developer] Ready for 1.0 RC1

[Colin S. <col...@ex...>]

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)
>  
>

Re: [Springframework-developer] Ready for 1.0 RC1

[Darren D. <da...@da...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 04 February 2004 19:11, j=FCrgen h=F6ller [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 -=20
they're lightweight web apps, one with JDBC access to MySQL and one with=20
hibernate.  Both seem fine through normal usage.

Using the autobuilds' modified jpetstore app, I tested on resin2, resin3,=20
tomcat4, tomcat5, jboss3/tomcat (all using hsqldb) with no problems.  Jetty=
=20
4.2.17 standalone failed as usual due to not reading the tld's in the jar=20
files.

Just for the hell of it, I ran all of the above tests on Sun JDK 1.4.1,=20
Blackdown JDK 1.3.1 and Blackdown JDK 1.4.1.

=46airly meaningless, but interesting nonetheless, the average time taken b=
y=20
each app server for the 'testPurchase' test case over 5 runs each on my=20
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=20
order, logging in incorrectly, logging in correctly, changing user=20
registration details, completing the purchase and checking the database=20
tables for sane numbers)

=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAJs1jKLMLAN01aw0RAsrWAJ9Rtoy137xVpciLKJf8hjsfQWNiHQCgkwCB
1QSKmgwQaE0Bo7FnMUSqIQc=3D
=3DVdQg
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] Retrieving the current transaction

[Colin S. <col...@ex...>]

jürgen höller [werk3AT] wrote:

>I've added the following static utility method "setCurrentTransactionRollbackOnly" (not committed yet), rolling back any kind of current transaction. PROPAGATION_MANDATORY will cause an exception to be thrown if there is no existing transaction. Note that the "rollback" call will just mark the surrounding transaction rollback-only here.
> 
>public abstract class PlatformTransactionManagerUtils {
> 
> public static void setCurrentTransactionRollbackOnly(PlatformTransactionManager ptm) throws TransactionException {
>  TransactionDefinition definition = new DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_MANDATORY);
>  TransactionStatus status = ptm.getTransaction(definition);
>  ptm.rollback(status);
> }
> 
>}
>
>This isn't really something that TransactionTemplate should care about: It's a general option for any kind of transaction demarcation.
> 
>An alternative would be to have a CurrentTransactionStatus ThreadLocal somewhere that AbstractPlatformTransactionManager would have to expose a returned TransactionStatus instance to (for any kind of transaction demarcation). Any opinions on the above PlatformTransactionManagerUtils vs such a CurrentTransactionStatus?
> 
>Juergen
>  
>
I presume you put this method in a separate class, instead of being part 
of the PlatformTransactionManager interface, so it would work with any 
PlatformTransactionManager implementation?

The advantage of the threadlocal vs. this implementation is that 
obviously with this impl., a user like a service or mapper object will 
now have to have an instance of the PlatformTransactionManager to feed 
to the method, whereas with the threadlocal it's accessible from 
anywhere. Same argument applies w/regards to doing it directly off 
PlatformTransactionManager, or off TransactionTemplate.

The advantage of doing it via a method on TransactionTemplate, or even 
PlatformTransactionManager, is that somebody unit testing the service 
object or mapper code using this functionality can properly feed in a 
mock implementation. As such, even if it ultimately goes to a static 
method like this, or ends up using quasi-static data like the 
ThreadLocal, I think it's worth it to have some interface that the 
actual user calls the method on, instead of a directly using a static 
method...

Regards.
Colin

Re: [Springframework-developer] Retrieving the current transaction

[<jue...@we...>]

I've added the following static utility method =
"setCurrentTransactionRollbackOnly" (not committed yet), rolling back =
any kind of current transaction. PROPAGATION_MANDATORY will cause an =
exception to be thrown if there is no existing transaction. Note that =
the "rollback" call will just mark the surrounding transaction =
rollback-only here.
=20
public abstract class PlatformTransactionManagerUtils {
=20
 public static void =
setCurrentTransactionRollbackOnly(PlatformTransactionManager ptm) throws =
TransactionException {
  TransactionDefinition definition =3D new =
DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_MANDATORY)=
;
  TransactionStatus status =3D ptm.getTransaction(definition);
  ptm.rollback(status);
 }
=20
}

This isn't really something that TransactionTemplate should care about: =
It's a general option for any kind of transaction demarcation.
=20
An alternative would be to have a CurrentTransactionStatus ThreadLocal =
somewhere that AbstractPlatformTransactionManager would have to expose a =
returned TransactionStatus instance to (for any kind of transaction =
demarcation). Any opinions on the above PlatformTransactionManagerUtils =
vs such a CurrentTransactionStatus?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 06.02.2004 22:55
An: spr...@li...
Betreff: [Springframework-developer] Re: [Springframework-user] =
Retrieving the current transaction



Guys, is it worth adding a convenience method for setRollbackOnly, to
TransactionTemplate, something like this? It's a lot more intuitive than
the anonymous class method below.

public void setRollbackOnly() throws TransactionException {

    TransactionStatus status =3D =
this.transactionManager.getTransaction(this);
    if (status.isNew)
      throw new TransactionUsageException("unable to join existing
transaction. Possible incorrect TransactionTemplate configuration");
    status.setRollbackOnly();
    this.transactionManager.commit(status);
}

Regards,
Colin

Colin Sampaleanu wrote:

> This is obviously only going to work if a TransactionInterceptor is
> involved. Alternately, if you want to do this in something like a
> mapper/DAO, and make it work whether or not a TransactionInterceptor
> is involved, you can use TransactionTemplate (in a somewhat convoluted
> fashion). So get a TransactionTemplate in a normal fashion, and then
> do something like this:
>
>    TransactionTemplate transactionTemplate;
>    ...
>
>    // now set RollbackOnly via TransactionTemplate; we should join the
> current transaction, and set rollback on that
>    transactionTemplate..execute(new TransactionCallback() {
>      public Object doInTransaction(TransactionStatus status) {
>        status.setRollbackOnly();
>        return null;
>      }
>    });
>
> Regards,
> Colin
>
>
> Rod Johnson wrote:
>
>> 1. you don't need to use an unchecked exception, you can set a
>> declarative
>> rollback rule for the relevant checked exception
>>
>> 2. If you do want programmatic rollback you do it like this
>>
>> TransactionInterceptor.currentTransactionStatus().setRollbackOnly().
>>
>> As in .NET it's static--no need to pass around something like an
>> EJBContext.
>> currentTransactionStatus() will throw NoTransactionException if you
>> don't
>> have a tx context. Put the static call in a protected method or =
strategy
>> class so you can override it at test time.
>>
>> ----- Original Message -----
>> From: "Sean Radford" <sra...@bl...>
>> To: <spr...@li...>
>> Sent: Friday, February 06, 2004 8:04 PM
>> Subject: [Springframework-user] Retrieving the current transaction
>>
>>
>> Hi all,
>>
>>
>> If one is 'in' a Business Object or DAO class (as defined below), how
>> does one get the current Transaction in order to set it to rollback? =
(I
>> don't want to (can't) throw a RuntimeException to get it to happen =
that
>> way).
>>
>>
>> <bean id=3D"fooDAO" class=3D"my.FooDAOImpl">
>>  <property name=3D"sessionFactory">
>>    <ref bean=3D"hibernateSessionFactory"/>
>>  </property>
>> </bean>
>>
>> <bean id=3D"fooBoTarget" class=3Dmy.FooBO" singleton=3D"true">
>>  <property name=3D"fooDAO">
>>    <ref bean=3D"fooDAO"/>
>>  </property>
>> </bean>
>>
>> <bean id=3D"eventManager"
>> =
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
oryBe
>>
>> an">
>>  <property name=3D"transactionManager">
>>    <ref bean=3D"tm"/>
>>  </property>
>>  <property name=3D"target">
>>    <ref bean=3D"fooBoTarget"/>
>>  </property>
>>  <property name=3D"transactionAttributes">
>>  <props>
>>    <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>>  </props>
>>  </property>
>> </bean>
>>
>>
>> Regards,
>>
>> Sean
>>
>> On Fri, 2004-02-06 at 17:21, j=FCrgen h=F6ller [werk3AT] wrote:
>>=20
>>
>>> I'm pleased to announce that Spring 1.0 RC1 will ship with pre-built
>>> JOTM
>>> =20
>>
>> integration in the form of
>> org.springframework.transaction.jta.JotmFactoryBean :-)
>>=20
>>
>>> I've just been reworking the new JTA support for the upcoming =
release,
>>> =20
>>
>> turning JtaDialect into FactoryBeans that expose
>> javax.transaction.TransactionManager. JotmFactoryBean does exactly
>> that too
>> now; the exposed object implements both UserTransaction and
>> TransactionManager. In case of an existing JOTM instance, the
>> existing one
>> will be returned; else, a new local JOTM instance will be created.
>>=20
>>
>>> This can be combined with either JOnAS JNDI DataSources or locally
>>> defined
>>> =20
>>
>> XAPool DataSources, for example in the local case:
>>=20
>>
>>>  <bean id=3D"jotm"
>>> =20
>>
>> class=3D"org.springframework.transaction.jta.JotmFactoryBean"/>
>>=20
>>
>>>  <bean id=3D"transactionManager"
>>> =20
>>
>> class=3D"org.springframework.transaction.jta.JtaTransactionManager">
>>=20
>>
>>>    <property name=3D"userTransaction"><ref =
local=3D"jotm"/></property>
>>>    <property name=3D"transactionManager"><ref =
local=3D"jotm"/></property>
>>>  </bean>
>>>
>>>  <bean id=3D"innerDataSource"
>>> =20
>>
>> class=3D"org.enhydra.jdbc.standard.StandardXADataSource">
>>=20
>>
>>>    <property name=3D"driverName">...</property>
>>>    <property name=3D"url">...</property>
>>>  </bean>
>>>
>>>  <bean id=3D"dataSource"
>>> =20
>>
>> class=3D"org.enhydra.jdbc.pool.StandardXAPoolDataSource">
>>=20
>>
>>>    <property name=3D"dataSource"><ref
>>> local=3D"innerDataSource"/></property>
>>>  </bean>
>>>
>>> Thus, your code can work with "transactionManager" and "dataSource" =
as
>>> =20
>>
>> usual, just like in the JtaTransactionManager-on-J2EE case - but in a
>> standalone environment, doing XA transactions via JOTM!
>>=20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On Behalf =
Of
>>> j=FCrgen h=F6ller [werk3AT]
>>> Sent: Friday, February 06, 2004 2:27 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi Nick,
>>>
>>> ObjectWeb's XAPool comes with pre-built DataSource wrappers that are
>>> =20
>>
>> XA-capable via JOTM. Have a look at the example at
>> http://xapool.experlog.com/examples.html#xapooldatasource.
>>=20
>>
>>> You shouldn't need to do any enlisting/delisting yourself with
>>> XAPool: You
>>> =20
>>
>> just need to set up a local JOTM instance and a local XAPool
>> XADataSource,
>> configured for JOTM.
>>=20
>>
>>> For integration into Spring, a configurer for JOTM could initialize =
the
>>> =20
>>
>> transaction manager on context startup, binding the UserTransaction =
and
>> TransactionManager instances to JNDI. Of course, you need a JNDI
>> environment; maybe Spring's SimpleNamingContextBuilder is an option.
>>=20
>>
>>> Furthermore, you need a factory for javax.sql.DataSource instances: =
You
>>> =20
>>
>> might need to implement a custom factory here, setting up an XAPool
>> XADataSource, connecting it to the JNDI-bound TransactionManager, and
>> wrapping it in a plain DataSource (to be passed to JDBC access code
>> etc).
>>=20
>>
>>> Spring's JtaTransactionManager should work nicely with such a JOTM
>>> setup,
>>> =20
>>
>> simply accessing the UserTransaction under the given JNDI name. Note
>> that as
>> of 1.0 RC1, we even support transaction suspension now, and thus all
>> six EJB
>> CMT propagation codes (including REQUIRES_NEW etc). You just need to
>> set up
>> a Spring JtaDialect for this.
>>=20
>>
>>> To avoid the need for a JNDI environment (you just need it for the =
JTA
>>> =20
>>
>> UserTransaction and TransactionManager), you could also implement
>> FactoryBeans that expose the UserTransaction respectively the
>> TransactionManager from the JOTM configuration, to be passed as bean
>> references to JtaTransactionManager and XADataSource FactoryBeans.
>>=20
>>
>>> Of course, I'd be happy to accept code donations to Spring regarding
>>> JOTM
>>> =20
>>
>> integration :-) Feel free to ask for help if you encounter any =
issues.
>>=20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> =20
>>
>> [mailto:spr...@li...]On Behalf Of
>> Nick
>> Minutello
>>=20
>>
>>> Sent: Friday, February 06, 2004 11:39 AM
>>> To: spr...@li...
>>> Subject: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi,
>>> I have to do some out-of-appserver XA transaction management.
>>> (planning on
>>> =20
>>
>> using JOTM)
>>=20
>>
>>> I was thinking of using an interceptor around the
>>> XAConnectionFactory and
>>> =20
>>
>> the XADataSource getConnection/close methods to do the enlist/delist
>> actions.
>>=20
>>
>>> I guess the question is: Is there a better way to do it with
>>> Spring's tx
>>> =20
>>
>> support?
>>=20
>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> -------------------------------------------------------
>>> 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-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>>
>>>
>>> -------------------------------------------------------
>>> 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-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>> =20
>>
>> --
>> Dr. Sean Radford, MBBS, MSc
>> sra...@bl...
>> http://bladesys.demon.co.uk/
>



-------------------------------------------------------
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

[Springframework-developer] Re: [Springframework-user] Retrieving the current transaction

[Colin S. <col...@ex...>]

Guys, is it worth adding a convenience method for setRollbackOnly, to=20
TransactionTemplate, something like this? It's a lot more intuitive than=20
the anonymous class method below.

public void setRollbackOnly() throws TransactionException {

    TransactionStatus status =3D this.transactionManager.getTransaction(t=
his);
    if (status.isNew)
      throw new TransactionUsageException("unable to join existing=20
transaction. Possible incorrect TransactionTemplate configuration");
    status.setRollbackOnly();
    this.transactionManager.commit(status);
}

Regards,
Colin

Colin Sampaleanu wrote:

> This is obviously only going to work if a TransactionInterceptor is=20
> involved. Alternately, if you want to do this in something like a=20
> mapper/DAO, and make it work whether or not a TransactionInterceptor=20
> is involved, you can use TransactionTemplate (in a somewhat convoluted=20
> fashion). So get a TransactionTemplate in a normal fashion, and then=20
> do something like this:
>
>    TransactionTemplate transactionTemplate;
>    ...
>
>    // now set RollbackOnly via TransactionTemplate; we should join the=20
> current transaction, and set rollback on that
>    transactionTemplate..execute(new TransactionCallback() {
>      public Object doInTransaction(TransactionStatus status) {
>        status.setRollbackOnly();
>        return null;
>      }
>    });
>
> Regards,
> Colin
>
>
> Rod Johnson wrote:
>
>> 1. you don't need to use an unchecked exception, you can set a=20
>> declarative
>> rollback rule for the relevant checked exception
>>
>> 2. If you do want programmatic rollback you do it like this
>>
>> TransactionInterceptor.currentTransactionStatus().setRollbackOnly().
>>
>> As in .NET it's static--no need to pass around something like an=20
>> EJBContext.
>> currentTransactionStatus() will throw NoTransactionException if you=20
>> don't
>> have a tx context. Put the static call in a protected method or strate=
gy
>> class so you can override it at test time.
>>
>> ----- Original Message -----
>> From: "Sean Radford" <sra...@bl...>
>> To: <spr...@li...>
>> Sent: Friday, February 06, 2004 8:04 PM
>> Subject: [Springframework-user] Retrieving the current transaction
>>
>>
>> Hi all,
>>
>>
>> If one is 'in' a Business Object or DAO class (as defined below), how
>> does one get the current Transaction in order to set it to rollback? (=
I
>> don't want to (can't) throw a RuntimeException to get it to happen tha=
t
>> way).
>>
>>
>> <bean id=3D"fooDAO" class=3D"my.FooDAOImpl">
>>  <property name=3D"sessionFactory">
>>    <ref bean=3D"hibernateSessionFactory"/>
>>  </property>
>> </bean>
>>
>> <bean id=3D"fooBoTarget" class=3Dmy.FooBO" singleton=3D"true">
>>  <property name=3D"fooDAO">
>>    <ref bean=3D"fooDAO"/>
>>  </property>
>> </bean>
>>
>> <bean id=3D"eventManager"
>> class=3D"org.springframework.transaction.interceptor.TransactionProxyF=
actoryBe=20
>>
>> an">
>>  <property name=3D"transactionManager">
>>    <ref bean=3D"tm"/>
>>  </property>
>>  <property name=3D"target">
>>    <ref bean=3D"fooBoTarget"/>
>>  </property>
>>  <property name=3D"transactionAttributes">
>>  <props>
>>    <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>>  </props>
>>  </property>
>> </bean>
>>
>>
>> Regards,
>>
>> Sean
>>
>> On Fri, 2004-02-06 at 17:21, j=FCrgen h=F6ller [werk3AT] wrote:
>> =20
>>
>>> I'm pleased to announce that Spring 1.0 RC1 will ship with pre-built=20
>>> JOTM
>>>  =20
>>
>> integration in the form of
>> org.springframework.transaction.jta.JotmFactoryBean :-)
>> =20
>>
>>> I've just been reworking the new JTA support for the upcoming release=
,
>>>  =20
>>
>> turning JtaDialect into FactoryBeans that expose
>> javax.transaction.TransactionManager. JotmFactoryBean does exactly=20
>> that too
>> now; the exposed object implements both UserTransaction and
>> TransactionManager. In case of an existing JOTM instance, the=20
>> existing one
>> will be returned; else, a new local JOTM instance will be created.
>> =20
>>
>>> This can be combined with either JOnAS JNDI DataSources or locally=20
>>> defined
>>>  =20
>>
>> XAPool DataSources, for example in the local case:
>> =20
>>
>>>  <bean id=3D"jotm"
>>>  =20
>>
>> class=3D"org.springframework.transaction.jta.JotmFactoryBean"/>
>> =20
>>
>>>  <bean id=3D"transactionManager"
>>>  =20
>>
>> class=3D"org.springframework.transaction.jta.JtaTransactionManager">
>> =20
>>
>>>    <property name=3D"userTransaction"><ref local=3D"jotm"/></property=
>
>>>    <property name=3D"transactionManager"><ref local=3D"jotm"/></prope=
rty>
>>>  </bean>
>>>
>>>  <bean id=3D"innerDataSource"
>>>  =20
>>
>> class=3D"org.enhydra.jdbc.standard.StandardXADataSource">
>> =20
>>
>>>    <property name=3D"driverName">...</property>
>>>    <property name=3D"url">...</property>
>>>  </bean>
>>>
>>>  <bean id=3D"dataSource"
>>>  =20
>>
>> class=3D"org.enhydra.jdbc.pool.StandardXAPoolDataSource">
>> =20
>>
>>>    <property name=3D"dataSource"><ref=20
>>> local=3D"innerDataSource"/></property>
>>>  </bean>
>>>
>>> Thus, your code can work with "transactionManager" and "dataSource" a=
s
>>>  =20
>>
>> usual, just like in the JtaTransactionManager-on-J2EE case - but in a
>> standalone environment, doing XA transactions via JOTM!
>> =20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On Behalf Of
>>> j=FCrgen h=F6ller [werk3AT]
>>> Sent: Friday, February 06, 2004 2:27 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi Nick,
>>>
>>> ObjectWeb's XAPool comes with pre-built DataSource wrappers that are
>>>  =20
>>
>> XA-capable via JOTM. Have a look at the example at
>> http://xapool.experlog.com/examples.html#xapooldatasource.
>> =20
>>
>>> You shouldn't need to do any enlisting/delisting yourself with=20
>>> XAPool: You
>>>  =20
>>
>> just need to set up a local JOTM instance and a local XAPool=20
>> XADataSource,
>> configured for JOTM.
>> =20
>>
>>> For integration into Spring, a configurer for JOTM could initialize t=
he
>>>  =20
>>
>> transaction manager on context startup, binding the UserTransaction an=
d
>> TransactionManager instances to JNDI. Of course, you need a JNDI
>> environment; maybe Spring's SimpleNamingContextBuilder is an option.
>> =20
>>
>>> Furthermore, you need a factory for javax.sql.DataSource instances: Y=
ou
>>>  =20
>>
>> might need to implement a custom factory here, setting up an XAPool
>> XADataSource, connecting it to the JNDI-bound TransactionManager, and
>> wrapping it in a plain DataSource (to be passed to JDBC access code=20
>> etc).
>> =20
>>
>>> Spring's JtaTransactionManager should work nicely with such a JOTM=20
>>> setup,
>>>  =20
>>
>> simply accessing the UserTransaction under the given JNDI name. Note=20
>> that as
>> of 1.0 RC1, we even support transaction suspension now, and thus all=20
>> six EJB
>> CMT propagation codes (including REQUIRES_NEW etc). You just need to=20
>> set up
>> a Spring JtaDialect for this.
>> =20
>>
>>> To avoid the need for a JNDI environment (you just need it for the JT=
A
>>>  =20
>>
>> UserTransaction and TransactionManager), you could also implement
>> FactoryBeans that expose the UserTransaction respectively the
>> TransactionManager from the JOTM configuration, to be passed as bean
>> references to JtaTransactionManager and XADataSource FactoryBeans.
>> =20
>>
>>> Of course, I'd be happy to accept code donations to Spring regarding=20
>>> JOTM
>>>  =20
>>
>> integration :-) Feel free to ask for help if you encounter any issues.
>> =20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>>  =20
>>
>> [mailto:spr...@li...]On Behalf Of=20
>> Nick
>> Minutello
>> =20
>>
>>> Sent: Friday, February 06, 2004 11:39 AM
>>> To: spr...@li...
>>> Subject: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi,
>>> I have to do some out-of-appserver XA transaction management.=20
>>> (planning on
>>>  =20
>>
>> using JOTM)
>> =20
>>
>>> I was thinking of using an interceptor around the=20
>>> XAConnectionFactory and
>>>  =20
>>
>> the XADataSource getConnection/close methods to do the enlist/delist
>> actions.
>> =20
>>
>>> I guess the question is: Is there a better way to do it with=20
>>> Spring's tx
>>>  =20
>>
>> support?
>> =20
>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> -------------------------------------------------------
>>> 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-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>>
>>>
>>> -------------------------------------------------------
>>> 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-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>>  =20
>>
>> --=20
>> Dr. Sean Radford, MBBS, MSc
>> sra...@bl...
>> http://bladesys.demon.co.uk/
>

[Springframework-developer] Re: [Springframework-user] Retrieving the current transaction

[Colin S. <col...@ex...>]

In fact, unless I am confused, the use of
   TransactionInterceptor.currentTransactionStatus().setRollbackOnly()
is problematic. It can not handle the mixed use of a=20
TransactionInterceptor and a contained TransactionTemplate which=20
initiates its own (nested) transaction (due to REQUIRES_NEW being set on=20
its propogation setting).

The user calling
   TransactionInterceptor.currentTransactionStatus().setRollbackOnly()
would be setting rollbackonly on the outer transaction status, which was=20
created by the TransactionInterceptor, while in fact he wants to be=20
calling it on the status of the inner transaction he is in...



Colin Sampaleanu wrote:

> Guys, is it worth adding a convenience method for setRollbackOnly, to=20
> TransactionTemplate, something like this? It's a lot more intuitive=20
> than the anonymous class method below.
>
> public void setRollbackOnly() throws TransactionException {
>
>    TransactionStatus status =3D=20
> this.transactionManager.getTransaction(this);
>    if (status.isNew)
>      throw new TransactionUsageException("unable to join existing=20
> transaction. Possible incorrect TransactionTemplate configuration");
>    status.setRollbackOnly();
>    this.transactionManager.commit(status);
> }
>
> Regards,
> Colin
>
> Colin Sampaleanu wrote:
>
>> This is obviously only going to work if a TransactionInterceptor is=20
>> involved. Alternately, if you want to do this in something like a=20
>> mapper/DAO, and make it work whether or not a TransactionInterceptor=20
>> is involved, you can use TransactionTemplate (in a somewhat=20
>> convoluted fashion). So get a TransactionTemplate in a normal=20
>> fashion, and then do something like this:
>>
>>    TransactionTemplate transactionTemplate;
>>    ...
>>
>>    // now set RollbackOnly via TransactionTemplate; we should join=20
>> the current transaction, and set rollback on that
>>    transactionTemplate..execute(new TransactionCallback() {
>>      public Object doInTransaction(TransactionStatus status) {
>>        status.setRollbackOnly();
>>        return null;
>>      }
>>    });
>>
>> Regards,
>> Colin
>>
>>
>> Rod Johnson wrote:
>>
>>> 1. you don't need to use an unchecked exception, you can set a=20
>>> declarative
>>> rollback rule for the relevant checked exception
>>>
>>> 2. If you do want programmatic rollback you do it like this
>>>
>>> TransactionInterceptor.currentTransactionStatus().setRollbackOnly().
>>>
>>> As in .NET it's static--no need to pass around something like an=20
>>> EJBContext.
>>> currentTransactionStatus() will throw NoTransactionException if you=20
>>> don't
>>> have a tx context. Put the static call in a protected method or=20
>>> strategy
>>> class so you can override it at test time.
>>>
>>> ----- Original Message -----
>>> From: "Sean Radford" <sra...@bl...>
>>> To: <spr...@li...>
>>> Sent: Friday, February 06, 2004 8:04 PM
>>> Subject: [Springframework-user] Retrieving the current transaction
>>>
>>>
>>> Hi all,
>>>
>>>
>>> If one is 'in' a Business Object or DAO class (as defined below), how
>>> does one get the current Transaction in order to set it to rollback? =
(I
>>> don't want to (can't) throw a RuntimeException to get it to happen th=
at
>>> way).
>>>
>>>
>>> <bean id=3D"fooDAO" class=3D"my.FooDAOImpl">
>>>  <property name=3D"sessionFactory">
>>>    <ref bean=3D"hibernateSessionFactory"/>
>>>  </property>
>>> </bean>
>>>
>>> <bean id=3D"fooBoTarget" class=3Dmy.FooBO" singleton=3D"true">
>>>  <property name=3D"fooDAO">
>>>    <ref bean=3D"fooDAO"/>
>>>  </property>
>>> </bean>
>>>
>>> <bean id=3D"eventManager"
>>> class=3D"org.springframework.transaction.interceptor.TransactionProxy=
FactoryBe=20
>>>
>>> an">
>>>  <property name=3D"transactionManager">
>>>    <ref bean=3D"tm"/>
>>>  </property>
>>>  <property name=3D"target">
>>>    <ref bean=3D"fooBoTarget"/>
>>>  </property>
>>>  <property name=3D"transactionAttributes">
>>>  <props>
>>>    <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>>>  </props>
>>>  </property>
>>> </bean>
>>>
>>>
>>> Regards,
>>>
>>> Sean
>>>
>>> On Fri, 2004-02-06 at 17:21, j=FCrgen h=F6ller [werk3AT] wrote:
>>> =20
>>>
>>>> I'm pleased to announce that Spring 1.0 RC1 will ship with=20
>>>> pre-built JOTM
>>>>  =20
>>>
>>>
>>> integration in the form of
>>> org.springframework.transaction.jta.JotmFactoryBean :-)
>>> =20
>>>
>>>> I've just been reworking the new JTA support for the upcoming releas=
e,
>>>>  =20
>>>
>>>
>>> turning JtaDialect into FactoryBeans that expose
>>> javax.transaction.TransactionManager. JotmFactoryBean does exactly=20
>>> that too
>>> now; the exposed object implements both UserTransaction and
>>> TransactionManager. In case of an existing JOTM instance, the=20
>>> existing one
>>> will be returned; else, a new local JOTM instance will be created.
>>> =20
>>>
>>>> This can be combined with either JOnAS JNDI DataSources or locally=20
>>>> defined
>>>>  =20
>>>
>>>
>>> XAPool DataSources, for example in the local case:
>>> =20
>>>
>>>>  <bean id=3D"jotm"
>>>>  =20
>>>
>>>
>>> class=3D"org.springframework.transaction.jta.JotmFactoryBean"/>
>>> =20
>>>
>>>>  <bean id=3D"transactionManager"
>>>>  =20
>>>
>>>
>>> class=3D"org.springframework.transaction.jta.JtaTransactionManager">
>>> =20
>>>
>>>>    <property name=3D"userTransaction"><ref local=3D"jotm"/></propert=
y>
>>>>    <property name=3D"transactionManager"><ref local=3D"jotm"/></prop=
erty>
>>>>  </bean>
>>>>
>>>>  <bean id=3D"innerDataSource"
>>>>  =20
>>>
>>>
>>> class=3D"org.enhydra.jdbc.standard.StandardXADataSource">
>>> =20
>>>
>>>>    <property name=3D"driverName">...</property>
>>>>    <property name=3D"url">...</property>
>>>>  </bean>
>>>>
>>>>  <bean id=3D"dataSource"
>>>>  =20
>>>
>>>
>>> class=3D"org.enhydra.jdbc.pool.StandardXAPoolDataSource">
>>> =20
>>>
>>>>    <property name=3D"dataSource"><ref=20
>>>> local=3D"innerDataSource"/></property>
>>>>  </bean>
>>>>
>>>> Thus, your code can work with "transactionManager" and "dataSource" =
as
>>>>  =20
>>>
>>>
>>> usual, just like in the JtaTransactionManager-on-J2EE case - but in a
>>> standalone environment, doing XA transactions via JOTM!
>>> =20
>>>
>>>> Juergen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> [mailto:spr...@li...]On Behalf O=
f
>>>> j=FCrgen h=F6ller [werk3AT]
>>>> Sent: Friday, February 06, 2004 2:27 PM
>>>> To: spr...@li...
>>>> Subject: RE: [Springframework-user] XA Transaction Support
>>>>
>>>>
>>>> Hi Nick,
>>>>
>>>> ObjectWeb's XAPool comes with pre-built DataSource wrappers that are
>>>>  =20
>>>
>>>
>>> XA-capable via JOTM. Have a look at the example at
>>> http://xapool.experlog.com/examples.html#xapooldatasource.
>>> =20
>>>
>>>> You shouldn't need to do any enlisting/delisting yourself with=20
>>>> XAPool: You
>>>>  =20
>>>
>>>
>>> just need to set up a local JOTM instance and a local XAPool=20
>>> XADataSource,
>>> configured for JOTM.
>>> =20
>>>
>>>> For integration into Spring, a configurer for JOTM could initialize=20
>>>> the
>>>>  =20
>>>
>>>
>>> transaction manager on context startup, binding the UserTransaction a=
nd
>>> TransactionManager instances to JNDI. Of course, you need a JNDI
>>> environment; maybe Spring's SimpleNamingContextBuilder is an option.
>>> =20
>>>
>>>> Furthermore, you need a factory for javax.sql.DataSource instances:=20
>>>> You
>>>>  =20
>>>
>>>
>>> might need to implement a custom factory here, setting up an XAPool
>>> XADataSource, connecting it to the JNDI-bound TransactionManager, and
>>> wrapping it in a plain DataSource (to be passed to JDBC access code=20
>>> etc).
>>> =20
>>>
>>>> Spring's JtaTransactionManager should work nicely with such a JOTM=20
>>>> setup,
>>>>  =20
>>>
>>>
>>> simply accessing the UserTransaction under the given JNDI name. Note=20
>>> that as
>>> of 1.0 RC1, we even support transaction suspension now, and thus all=20
>>> six EJB
>>> CMT propagation codes (including REQUIRES_NEW etc). You just need to=20
>>> set up
>>> a Spring JtaDialect for this.
>>> =20
>>>
>>>> To avoid the need for a JNDI environment (you just need it for the J=
TA
>>>>  =20
>>>
>>>
>>> UserTransaction and TransactionManager), you could also implement
>>> FactoryBeans that expose the UserTransaction respectively the
>>> TransactionManager from the JOTM configuration, to be passed as bean
>>> references to JtaTransactionManager and XADataSource FactoryBeans.
>>> =20
>>>
>>>> Of course, I'd be happy to accept code donations to Spring=20
>>>> regarding JOTM
>>>>  =20
>>>
>>>
>>> integration :-) Feel free to ask for help if you encounter any issues=
.
>>> =20
>>>
>>>> Juergen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>>  =20
>>>
>>>
>>> [mailto:spr...@li...]On Behalf=20
>>> Of Nick
>>> Minutello
>>> =20
>>>
>>>> Sent: Friday, February 06, 2004 11:39 AM
>>>> To: spr...@li...
>>>> Subject: [Springframework-user] XA Transaction Support
>>>>
>>>>
>>>> Hi,
>>>> I have to do some out-of-appserver XA transaction management.=20
>>>> (planning on
>>>>  =20
>>>
>>>
>>> using JOTM)
>>> =20
>>>
>>>> I was thinking of using an interceptor around the=20
>>>> XAConnectionFactory and
>>>>  =20
>>>
>>>
>>> the XADataSource getConnection/close methods to do the enlist/delist
>>> actions.
>>> =20
>>>
>>>> I guess the question is: Is there a better way to do it with=20
>>>> Spring's tx
>>>>  =20
>>>
>>>
>>> support?
>>> =20
>>>
>>>> Cheers,
>>>> Nick
>>>

RE: [Springframework-developer] Container Bean threshold?

[<jue...@we...>]

Ross,

Any news on this front? I can't find anything that could cause such =
behavior. A stacktrace would be helpful, I guess :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ross Mason
Sent: Wednesday, February 04, 2004 3:44 AM
To: spr...@li...
Subject: [Springframework-developer] Container Bean threshold?


Hi guys,

I've just found some interesting behaviour in the spring container.  If=20
we have 96 beans in the container everything works fine, but if we add=20
one more bean, say bean97, the container complains that there may be a=20
circular reference even though I'm sure there isn't. But if we remove a=20
different (and totally unrelated) bean and add our bean97 bean it works=20
fine.  It seems the container has a bean threshold of 96?!

Basically, we cannot add any than 96 beans to the container.

Have you seen this behaviour before?

--
Cheers,

Ross
http://blog.rossmason.com






-------------------------------------------------------
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

RE: [Springframework-developer] Ready for 1.0 RC1

[Alef A. <al...@jt...>]

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

Re: [Springframework-developer] IJdbcTemplate / IHibernateTemplat e / ISqlMapTemplate

[Rod J. <rod...@in...>]

Come to think of it this is a good argument as well. I don't like
XXXXInterface: to me that seems more inelegant than IXXXX.

At the end of the day, I don't really care too much.

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Thursday, February 05, 2004 5:37 PM
Subject: Re: [Springframework-developer] IJdbcTemplate / IHibernateTempla=
t e
/ ISqlMapTemplate


I used to start my interface names with I, but a year or two ago stopped
when I realized that in fact I was almost always working against the
interfaces anyways, so it was silly to always have the prefix there (now
I generally add 'Impl' to the end of the implementation object, if there
is only one variant).

The I prefix is not going to be pretty here where most of our other
interfaces don't have it, but on the other hand, I don't like interface
names which seem to have no relation to the impl. objects either... I
would probably leave them as Ixxxx and add a note to the javadoc that it
is that way for historical reasons, as opposed to having a totally
different interface and impl name...


Kopylenko, Dmitry wrote:

>I'm not a big fan of Ixxx naming pattern for interfaces. +1 for renaming
>them to something else.
>
>Dmitriy.
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
>Sent: Thursday, February 05, 2004 11:45 AM
>To: spr...@li...
>Subject: [Springframework-developer] IJdbcTemplate / IHibernateTemplate =
/
>ISqlMapTemplate
>
>
>Everybody,
>
>Due to a recent request, I've just extracted IHibernateTemplate and
>ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod introduc=
ed
a
>while ago. They are intended to ease mocking for unit-testing DAOs, for
>those who want to mock at this level. For typical DAO implementations, t=
he
>standard template classes are good enough, allowing for mocks of the
>underlying persistence tool and live tests against a database.
>
>However, I wonder about the naming. We don't have the I* pattern anywher=
e
>else in the framework; on the other hand, we need to keep the old templa=
te
>names for compatibility (and some templates don't lend themselves for su=
ch
>an interface, like JdoTemplate). IHibernateTemplate etc doesn't worry me=
,
>but maybe a different name like HibernateOperations would be better?
>Essentially, those interfaces specify a set of data access operations fo=
r a
>particular persistence tool.
>
>The naming isn't too important, though, as it will not be the main API t=
hat
>people will work with; the template classes will be. We'll just let the
>templates implement those operation interfaces to allow for mocking them=
 if
>desired. BTW, iBATIS SQL Maps is all based on concrete classes rather th=
an
>interfaces, not allowing to mock the persistence tool itself.
>
>Juergen
>
>



-------------------------------------------------------
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