springframework-developer — Spring Framework developers list

Re: [Springframework-developer] re: OracleLobCreator

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

Note that read access with OracleLobHandler does not need an unwrapped =
Connection; just write access via OracleLobCreator does.
=20
I've just decided to remove SimpleNativeJdbcExtractor as the =
OracleLobHandler default again, as it might be unwanted behavior if the =
pool offers handles that mirror the native Connections. There's a clear =
recommendation in the javadocs, though, particularly with respect to =
SimpleNativeJdbcExtractor's new strategy which should work with almost =
any connection pool.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tho...@tr...
Gesendet: Mo 31.05.2004 21:35
An: spr...@li...
Betreff: Re: [Springframework-developer] re: OracleLobCreator




It looks to me that the WebLogic connection wrapper works fine.  No need =
to
extract the native Oracle driver.

My connection is
"weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_OracleConnection=
"

I remember hearing some Bea guys mentioning that they added LOB =
functionality to
their wrapper.

I'm using WLS 8.1 SP2 that comes with the Oracle ojdbc14.jar (<Driver =
Version is
9.2.0.3.0>).

This code ran just fine using Spring 1.0.1 jar:

        conn =3D ds.getConnection();
        lh =3D new OracleLobHandler();
        ps =3D conn.prepareStatement("select text from docs where doc_id =
=3D 1");
        rs =3D ps.executeQuery();
        if (rs.next()) {
                clobText =3D lh.getClobAsString(rs, 1);
        }
        System.out.println("***> READ TEXT <*** length is " +
                clobText.length());


There must me something else going on.  I would make sure to check that =
the
ojdbc14.jar that comes with WLS81 SP2 is the one that is on the =
classpath for
the server.  Could it be something in the transaction management that
interferes?

Thomas



Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> OracleLobHandler needs to work on a native OracleConnection as it =
comes =3D
> from the driver. The usual problem in that respect is not the driver =
but =3D
> the connection pool: Every connection pool needs to wrap native =3D
> connections with pooled connections that at least have different =
closing =3D
> behavior.
> =3D20
> To address this, OracleLobHandler has the "nativeJdbcExtractor" =3D
> property, taking an implementation of Spring's NativeJdbcExtractor =3D
> interface. Spring includes out-of-the-box implementations for Commons =
=3D
> DBCP, XAPool, and JBoss. I guess what you need to do is write such an =
=3D
> extractor for Weblogic.
> =3D20
> What's odd about your exception is that OracleLobCreator does not =3D
> complain that it doesn't receive an OracleConnection (there's an =3D
> explicit check in there). It seems to get a wrapped connection that is =
=3D
> still assignable to OracleConnection, although it's not the native =3D
> OracleConnection from the driver...
> =3D20
> Maybe Weblogic uses some special way of pooling connections for the =
=3D
> Oracle driver, using poolable OracleConnections? The =3D
> getPhysicalConnection method will probably be in the OracleConnection =
=3D
> class, not in the CLOB class. Try writing a NativeJdbcExtractor that =
=3D
> unwraps an OracleConnection with that method.=3D20
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von Bronwen Cassidy
> Gesendet: Mo 31.05.2004 04:27
> An: spr...@li...
> Betreff: RE: [Springframework-developer] re: OracleLobCreator
>
>
>
> Hi I have:
>
> Weblogic 8 service pack 2
> ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
> Oracle9i
> I have set up the connection pool using the jdbc:oracle:thin (oracle =
=3D
> thin
> drivers (not weblogic ones)=3D20
>
> Actually I managed to find some information (very little) one from a
> hibernate mail, suggested using the getPhysicalConnection() instead of
> createTemporary, but this method does not seem to available on the =
CLOB
> class??
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf =3D
> Of
> Thomas Risberg
> Sent: 31 May 2004 02:09
> To: spr...@li...
> Subject: Re: [Springframework-developer] re: OracleLobCreator
>
> Bronwen,
>
> In order to pinpoint the problem quicker - what version of WebLogic,
> Oracle and JDBC drivers are you using?
>
> Thomas
>
> Bronwen Cassidy wrote:
>
> > Hi I have a CLOB column in oracle and in the test there are no
> > problems, unfortunately deploying to weblogic I get the exception
> > below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, =
I
> > firstly replaced weblogics jars and classpath settings to use the
> > classes12.jar, but got the same error, so I pulled weblogic oracle =
jar
> > into my test classpath to test if the problem was with the jars but
> > the test worked fine ?? I am really stuck as to whom this should go =
to
> > weblogic, oracle, or . I am hoping there is an expert there who can
> > shed some light. Google did not have a single match for variations =
of
> > the first 2 lines!!
> >
> > java.lang.ClassCastException
> >
> > at
> >
> =
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.jav=
=3D
> a:5
> 090)
> >
> > at
> >
> =
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnec=
=3D
> tio
> n.java:5141)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:956)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> >
> =
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
=3D
> :39
> )
> >
> > at
> >
> =
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
=3D
> mpl
> .java:25)
> >
> > at java.lang.reflect.Method.invoke(Method.java:324)
> >
> > at
> >
> =
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.pr=
=3D
> epa
> reLob(OracleLobHandler.java:375)
> >
> > at
> >
> =
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.cr=
=3D
> eat
> eLob(OracleLobHandler.java:327)
> >
> > at
> >
> =
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.se=
=3D
> tCl
> obAsString(OracleLobHandler.java:255)
> >
> > thank-you for any help
> >
> > Bronwen
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3D3149&alloc_id=3D3D8166&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3D3149&alloc_id=3D3D8166&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] re: OracleLobCreator

[<bro...@ya...>]

Hi
I have no concern as to the pool i use, i am actually
completely ignorant and have been blindly feeling my
way using the spring test cases, samples, docs and
some googling, until 4 months ago i had never used
oracle and until a week ago i did not need to do more
than work out db agnostic sql queries :-)

so please i am more than happy to use weblogic pool,
which i am using when the app is deployed, hence the
test time passes and deploy time failures most
likely!! I am guessing the changes are needed in the
nativeJdbcExtractor class in the spring.xml needs to
point to a weblogic equivalent??

 --- Thomas Risberg <tho...@tr...> wrote:
> Since you are using the Commons DBCP rather than a
> WebLogic pool the 
> issue is slightly different. We have to figure out
> why the connection 
> returned from the DBCP pool is not unwrapped
> properly.
> 
> Thomas
> 
> 
> Bronwen Cassidy wrote:
> 
> >Thank-you Jurgen
> >This was the approach i had come to conclude as the
> >only difference between passing test case and
> failing
> >deployed app is the connection pool handled by
> >weblogic , ahh well another trip into the unknown,
> the
> >best part of being a developer ;-) 
> >
> >regards
> >Bronwen
> >
> >--- jürgen_höller_[werk3AT]
> ><jue...@we...> wrote: >
> >OracleLobHandler needs to work on a native
> >  
> >
> >>OracleConnection as it comes from the driver. The
> >>usual problem in that respect is not the driver
> but
> >>the connection pool: Every connection pool needs
> to
> >>wrap native connections with pooled connections
> that
> >>at least have different closing behavior.
> >> 
> >>To address this, OracleLobHandler has the
> >>"nativeJdbcExtractor" property, taking an
> >>implementation of Spring's NativeJdbcExtractor
> >>interface. Spring includes out-of-the-box
> >>implementations for Commons DBCP, XAPool, and
> JBoss.
> >>I guess what you need to do is write such an
> >>extractor for Weblogic.
> >> 
> >>What's odd about your exception is that
> >>OracleLobCreator does not complain that it doesn't
> >>receive an OracleConnection (there's an explicit
> >>check in there). It seems to get a wrapped
> >>connection that is still assignable to
> >>OracleConnection, although it's not the native
> >>OracleConnection from the driver...
> >> 
> >>Maybe Weblogic uses some special way of pooling
> >>connections for the Oracle driver, using poolable
> >>OracleConnections? The getPhysicalConnection
> method
> >>will probably be in the OracleConnection class,
> not
> >>in the CLOB class. Try writing a
> NativeJdbcExtractor
> >>that unwraps an OracleConnection with that method.
> 
> >> 
> >>Juergen
> >> 
> >>
> >>________________________________
> >>
> >>Von:
> >>
> >>    
> >>
>
>spr...@li...
> >  
> >
> >>im Auftrag von Bronwen Cassidy
> >>Gesendet: Mo 31.05.2004 04:27
> >>An:
> spr...@li...
> >>Betreff: RE: [Springframework-developer] re:
> >>OracleLobCreator
> >>
> >>
> >>
> >>Hi I have:
> >>
> >>Weblogic 8 service pack 2
> >>ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
> >>Oracle9i
> >>I have set up the connection pool using the
> >>jdbc:oracle:thin (oracle thin
> >>drivers (not weblogic ones) 
> >>
> >>Actually I managed to find some information (very
> >>little) one from a
> >>hibernate mail, suggested using the
> >>getPhysicalConnection() instead of
> >>createTemporary, but this method does not seem to
> >>available on the CLOB
> >>class??
> >>
> >>-----Original Message-----
> >>From:
> >>
> >>    
> >>
>
>spr...@li...
> >  
> >
>
>[mailto:spr...@li...]
> >  
> >
> >>On Behalf Of
> >>Thomas Risberg
> >>Sent: 31 May 2004 02:09
> >>To:
> spr...@li...
> >>Subject: Re: [Springframework-developer] re:
> >>OracleLobCreator
> >>
> >>Bronwen,
> >>
> >>In order to pinpoint the problem quicker - what
> >>version of WebLogic,
> >>Oracle and JDBC drivers are you using?
> >>
> >>Thomas
> >>
> >>Bronwen Cassidy wrote:
> >>
> >>    
> >>
> >>>Hi I have a CLOB column in oracle and in the test
> >>>      
> >>>
> >>there are no
> >>    
> >>
> >>>problems, unfortunately deploying to weblogic I
> >>>      
> >>>
> >>get the exception
> >>    
> >>
> >>>below. We are using classes12.jar whereas
> weblogic
> >>>      
> >>>
> >>uses ojdbc14.jar, I
> >>    
> >>
> >>>firstly replaced weblogics jars and classpath
> >>>      
> >>>
> >>settings to use the
> >>    
> >>
> >>>classes12.jar, but got the same error, so I
> pulled
> >>>      
> >>>
> >>weblogic oracle jar
> >>    
> >>
> >>>into my test classpath to test if the problem was
> >>>      
> >>>
> >>with the jars but
> >>    
> >>
> >>>the test worked fine ?? I am really stuck as to
> >>>      
> >>>
> >>whom this should go to
> >>    
> >>
> >>>weblogic, oracle, or . I am hoping there is an
> >>>      
> >>>
> >>expert there who can
> >>    
> >>
> >>>shed some light. Google did not have a single
> >>>      
> >>>
> >>match for variations of
> >>    
> >>
> >>>the first 2 lines!!
> >>>
> >>>java.lang.ClassCastException
> >>>
> >>>at
> >>>
> >>>      
> >>>
>
>oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
> >  
> 
=== message truncated === 


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Re: [Springframework-developer] re: OracleLobCreator

[<bro...@ya...>]

Thanx guys,

I have searched the entire weblogic directories and
the only "oracle" jar is the ojdbc14.jar, we were
using classes12.jar in the app, but i undeployed the
app, deleted all of our uploaded, generated files
replaced classes12.jar with ojdbc14.jar and redeployed
with the same failure of null ClassCastException.... 

I will try firstly using the
SimpleNativeJdbcExtractor, then play around with
changing pool connection drivers to see if i get that
going.

Will report back results

Thank-you all again for your help, i have at least now
a plan of action 

Regards
Bronwen



--- tho...@tr... wrote: > 
> It looks to me that the WebLogic connection wrapper
> works fine.  No need to
> extract the native Oracle driver.
> 
> My connection is
>
"weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_OracleConnection"
> 
> I remember hearing some Bea guys mentioning that
> they added LOB functionality to
> their wrapper.
> 
> I'm using WLS 8.1 SP2 that comes with the Oracle
> ojdbc14.jar (<Driver Version is
> 9.2.0.3.0>).
> 
> This code ran just fine using Spring 1.0.1 jar:
> 
> 	conn = ds.getConnection();
> 	lh = new OracleLobHandler();
> 	ps = conn.prepareStatement("select text from docs
> where doc_id = 1");
> 	rs = ps.executeQuery();
> 	if (rs.next()) {
> 		clobText = lh.getClobAsString(rs, 1);
> 	}
> 	System.out.println("***> READ TEXT <*** length is "
> +
> 		clobText.length());
> 
> 
> There must me something else going on.  I would make
> sure to check that the
> ojdbc14.jar that comes with WLS81 SP2 is the one
> that is on the classpath for
> the server.  Could it be something in the
> transaction management that
> interferes?
> 
> Thomas
> 
> 
> 
> Quoting "jürgen höller [werk3AT]"
> <jue...@we...>:
> 
> > OracleLobHandler needs to work on a native
> OracleConnection as it comes =
> > from the driver. The usual problem in that respect
> is not the driver but =
> > the connection pool: Every connection pool needs
> to wrap native =
> > connections with pooled connections that at least
> have different closing =
> > behavior.
> > =20
> > To address this, OracleLobHandler has the
> "nativeJdbcExtractor" =
> > property, taking an implementation of Spring's
> NativeJdbcExtractor =
> > interface. Spring includes out-of-the-box
> implementations for Commons =
> > DBCP, XAPool, and JBoss. I guess what you need to
> do is write such an =
> > extractor for Weblogic.
> > =20
> > What's odd about your exception is that
> OracleLobCreator does not =
> > complain that it doesn't receive an
> OracleConnection (there's an =
> > explicit check in there). It seems to get a
> wrapped connection that is =
> > still assignable to OracleConnection, although
> it's not the native =
> > OracleConnection from the driver...
> > =20
> > Maybe Weblogic uses some special way of pooling
> connections for the =
> > Oracle driver, using poolable OracleConnections?
> The =
> > getPhysicalConnection method will probably be in
> the OracleConnection =
> > class, not in the CLOB class. Try writing a
> NativeJdbcExtractor that =
> > unwraps an OracleConnection with that method.=20
> > =20
> > Juergen
> > =20
> >
> > ________________________________
> >
> > Von:
>
spr...@li...
> im Auftrag =
> > von Bronwen Cassidy
> > Gesendet: Mo 31.05.2004 04:27
> > An:
> spr...@li...
> > Betreff: RE: [Springframework-developer] re:
> OracleLobCreator
> >
> >
> >
> > Hi I have:
> >
> > Weblogic 8 service pack 2
> > ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
> > Oracle9i
> > I have set up the connection pool using the
> jdbc:oracle:thin (oracle =
> > thin
> > drivers (not weblogic ones)=20
> >
> > Actually I managed to find some information (very
> little) one from a
> > hibernate mail, suggested using the
> getPhysicalConnection() instead of
> > createTemporary, but this method does not seem to
> available on the CLOB
> > class??
> >
> > -----Original Message-----
> > From:
>
spr...@li...
> >
>
[mailto:spr...@li...]
> On Behalf =
> > Of
> > Thomas Risberg
> > Sent: 31 May 2004 02:09
> > To:
> spr...@li...
> > Subject: Re: [Springframework-developer] re:
> OracleLobCreator
> >
> > Bronwen,
> >
> > In order to pinpoint the problem quicker - what
> version of WebLogic,
> > Oracle and JDBC drivers are you using?
> >
> > Thomas
> >
> > Bronwen Cassidy wrote:
> >
> > > Hi I have a CLOB column in oracle and in the
> test there are no
> > > problems, unfortunately deploying to weblogic I
> get the exception
> > > below. We are using classes12.jar whereas
> weblogic uses ojdbc14.jar, I
> > > firstly replaced weblogics jars and classpath
> settings to use the
> > > classes12.jar, but got the same error, so I
> pulled weblogic oracle jar
> > > into my test classpath to test if the problem
> was with the jars but
> > > the test worked fine ?? I am really stuck as to
> whom this should go to
> > > weblogic, oracle, or . I am hoping there is an
> expert there who can
> > > shed some light. Google did not have a single
> match for variations of
> > > the first 2 lines!!
> > >
> > > java.lang.ClassCastException
> > >
> > > at
> > >
> >
>
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.jav=
> > a:5
> > 090)
> > >
> > > at
> > >
> >
>
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnec=
> > tio
> > n.java:5141)
> > >
> > > at
> oracle.sql.CLOB.createTemporary(CLOB.java:1009)
> > >
> > > at
> oracle.sql.CLOB.createTemporary(CLOB.java:956)
> > >
> > > at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > >
> > > at
> > >
> >
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
> > :39
> > )
> > >
> > > at
> > >
> >
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
> 
=== message truncated === 


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Re: [Springframework-developer] re: OracleLobCreator

[Thomas R. <tho...@tr...>]

Since you are using the Commons DBCP rather than a WebLogic pool the 
issue is slightly different. We have to figure out why the connection 
returned from the DBCP pool is not unwrapped properly.

Thomas


Bronwen Cassidy wrote:

>Thank-you Jurgen
>This was the approach i had come to conclude as the
>only difference between passing test case and failing
>deployed app is the connection pool handled by
>weblogic , ahh well another trip into the unknown, the
>best part of being a developer ;-) 
>
>regards
>Bronwen
>
>--- jürgen_höller_[werk3AT]
><jue...@we...> wrote: >
>OracleLobHandler needs to work on a native
>  
>
>>OracleConnection as it comes from the driver. The
>>usual problem in that respect is not the driver but
>>the connection pool: Every connection pool needs to
>>wrap native connections with pooled connections that
>>at least have different closing behavior.
>> 
>>To address this, OracleLobHandler has the
>>"nativeJdbcExtractor" property, taking an
>>implementation of Spring's NativeJdbcExtractor
>>interface. Spring includes out-of-the-box
>>implementations for Commons DBCP, XAPool, and JBoss.
>>I guess what you need to do is write such an
>>extractor for Weblogic.
>> 
>>What's odd about your exception is that
>>OracleLobCreator does not complain that it doesn't
>>receive an OracleConnection (there's an explicit
>>check in there). It seems to get a wrapped
>>connection that is still assignable to
>>OracleConnection, although it's not the native
>>OracleConnection from the driver...
>> 
>>Maybe Weblogic uses some special way of pooling
>>connections for the Oracle driver, using poolable
>>OracleConnections? The getPhysicalConnection method
>>will probably be in the OracleConnection class, not
>>in the CLOB class. Try writing a NativeJdbcExtractor
>>that unwraps an OracleConnection with that method. 
>> 
>>Juergen
>> 
>>
>>________________________________
>>
>>Von:
>>
>>    
>>
>spr...@li...
>  
>
>>im Auftrag von Bronwen Cassidy
>>Gesendet: Mo 31.05.2004 04:27
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] re:
>>OracleLobCreator
>>
>>
>>
>>Hi I have:
>>
>>Weblogic 8 service pack 2
>>ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
>>Oracle9i
>>I have set up the connection pool using the
>>jdbc:oracle:thin (oracle thin
>>drivers (not weblogic ones) 
>>
>>Actually I managed to find some information (very
>>little) one from a
>>hibernate mail, suggested using the
>>getPhysicalConnection() instead of
>>createTemporary, but this method does not seem to
>>available on the CLOB
>>class??
>>
>>-----Original Message-----
>>From:
>>
>>    
>>
>spr...@li...
>  
>
>[mailto:spr...@li...]
>  
>
>>On Behalf Of
>>Thomas Risberg
>>Sent: 31 May 2004 02:09
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] re:
>>OracleLobCreator
>>
>>Bronwen,
>>
>>In order to pinpoint the problem quicker - what
>>version of WebLogic,
>>Oracle and JDBC drivers are you using?
>>
>>Thomas
>>
>>Bronwen Cassidy wrote:
>>
>>    
>>
>>>Hi I have a CLOB column in oracle and in the test
>>>      
>>>
>>there are no
>>    
>>
>>>problems, unfortunately deploying to weblogic I
>>>      
>>>
>>get the exception
>>    
>>
>>>below. We are using classes12.jar whereas weblogic
>>>      
>>>
>>uses ojdbc14.jar, I
>>    
>>
>>>firstly replaced weblogics jars and classpath
>>>      
>>>
>>settings to use the
>>    
>>
>>>classes12.jar, but got the same error, so I pulled
>>>      
>>>
>>weblogic oracle jar
>>    
>>
>>>into my test classpath to test if the problem was
>>>      
>>>
>>with the jars but
>>    
>>
>>>the test worked fine ?? I am really stuck as to
>>>      
>>>
>>whom this should go to
>>    
>>
>>>weblogic, oracle, or . I am hoping there is an
>>>      
>>>
>>expert there who can
>>    
>>
>>>shed some light. Google did not have a single
>>>      
>>>
>>match for variations of
>>    
>>
>>>the first 2 lines!!
>>>
>>>java.lang.ClassCastException
>>>
>>>at
>>>
>>>      
>>>
>oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
>  
>
>>090)
>>    
>>
>>>at
>>>
>>>      
>>>
>oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnectio
>  
>
>>n.java:5141)
>>    
>>
>>>at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>>>
>>>at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>>>
>>>at
>>>      
>>>
>>sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>Method)
>>    
>>
>>>at
>>>
>>>      
>>>
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
>  
>
>>)
>>    
>>
>>>at
>>>
>>>      
>>>
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
>  
>
>>.java:25)
>>    
>>
>>>at
>>>      
>>>
>>java.lang.reflect.Method.invoke(Method.java:324)
>>    
>>
>>>at
>>>
>>>      
>>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepa
>  
>
>>reLob(OracleLobHandler.java:375)
>>    
>>
>>>at
>>>
>>>      
>>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.creat
>  
>
>>eLob(OracleLobHandler.java:327)
>>    
>>
>>>at
>>>
>>>      
>>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setCl
>  
>
>>obAsString(OracleLobHandler.java:255)
>>    
>>
>>>thank-you for any help
>>>
>>>Bronwen
>>>
>>>      
>>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the
>>market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the
>>exam FREE.
>>
>>    
>>
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>  
>
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>
>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the
>>market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the
>>exam FREE.
>>
>>    
>>
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>  
>
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>
>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the
>>market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the
>>exam FREE.
>>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>
>
>	
>	
>		
>____________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] re: OracleLobCreator

[<bro...@ya...>]

Thank-you Jurgen
This was the approach i had come to conclude as the
only difference between passing test case and failing
deployed app is the connection pool handled by
weblogic , ahh well another trip into the unknown, the
best part of being a developer ;-) 

regards
Bronwen

--- jürgen_höller_[werk3AT]
<jue...@we...> wrote: >
OracleLobHandler needs to work on a native
> OracleConnection as it comes from the driver. The
> usual problem in that respect is not the driver but
> the connection pool: Every connection pool needs to
> wrap native connections with pooled connections that
> at least have different closing behavior.
>  
> To address this, OracleLobHandler has the
> "nativeJdbcExtractor" property, taking an
> implementation of Spring's NativeJdbcExtractor
> interface. Spring includes out-of-the-box
> implementations for Commons DBCP, XAPool, and JBoss.
> I guess what you need to do is write such an
> extractor for Weblogic.
>  
> What's odd about your exception is that
> OracleLobCreator does not complain that it doesn't
> receive an OracleConnection (there's an explicit
> check in there). It seems to get a wrapped
> connection that is still assignable to
> OracleConnection, although it's not the native
> OracleConnection from the driver...
>  
> Maybe Weblogic uses some special way of pooling
> connections for the Oracle driver, using poolable
> OracleConnections? The getPhysicalConnection method
> will probably be in the OracleConnection class, not
> in the CLOB class. Try writing a NativeJdbcExtractor
> that unwraps an OracleConnection with that method. 
>  
> Juergen
>  
> 
> ________________________________
> 
> Von:
>
spr...@li...
> im Auftrag von Bronwen Cassidy
> Gesendet: Mo 31.05.2004 04:27
> An: spr...@li...
> Betreff: RE: [Springframework-developer] re:
> OracleLobCreator
> 
> 
> 
> Hi I have:
> 
> Weblogic 8 service pack 2
> ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
> Oracle9i
> I have set up the connection pool using the
> jdbc:oracle:thin (oracle thin
> drivers (not weblogic ones) 
> 
> Actually I managed to find some information (very
> little) one from a
> hibernate mail, suggested using the
> getPhysicalConnection() instead of
> createTemporary, but this method does not seem to
> available on the CLOB
> class??
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]
> On Behalf Of
> Thomas Risberg
> Sent: 31 May 2004 02:09
> To: spr...@li...
> Subject: Re: [Springframework-developer] re:
> OracleLobCreator
> 
> Bronwen,
> 
> In order to pinpoint the problem quicker - what
> version of WebLogic,
> Oracle and JDBC drivers are you using?
> 
> Thomas
> 
> Bronwen Cassidy wrote:
> 
> > Hi I have a CLOB column in oracle and in the test
> there are no
> > problems, unfortunately deploying to weblogic I
> get the exception
> > below. We are using classes12.jar whereas weblogic
> uses ojdbc14.jar, I
> > firstly replaced weblogics jars and classpath
> settings to use the
> > classes12.jar, but got the same error, so I pulled
> weblogic oracle jar
> > into my test classpath to test if the problem was
> with the jars but
> > the test worked fine ?? I am really stuck as to
> whom this should go to
> > weblogic, oracle, or . I am hoping there is an
> expert there who can
> > shed some light. Google did not have a single
> match for variations of
> > the first 2 lines!!
> >
> > java.lang.ClassCastException
> >
> > at
> >
>
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
> 090)
> >
> > at
> >
>
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnectio
> n.java:5141)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:956)
> >
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> >
> > at
> >
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
> >
> > at
> >
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
> >
> > at
> java.lang.reflect.Method.invoke(Method.java:324)
> >
> > at
> >
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepa
> reLob(OracleLobHandler.java:375)
> >
> > at
> >
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.creat
> eLob(OracleLobHandler.java:327)
> >
> > at
> >
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setCl
> obAsString(OracleLobHandler.java:255)
> >
> > thank-you for any help
> >
> > Bronwen
> >
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the
> market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the
> exam FREE.
>
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the
> market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the
> exam FREE.
>
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the
> market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the
> exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer 


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

[Springframework-developer] petclinic rich client sample application

[Keith D. <kd...@cs...>]

Our in-development, swing-based rich client framework (spring-rcp) now has
its first sample app!

 

The application is a Pet Clinic; in fact, it works with the original Pet
Clinic-Web's domain layer directly.   Right now it is just a start and very
basic, but it does illustrate the foundation APIs in play, as well as the
configuration metadata needed to layout the GUI.  I will continue to enhance
the sample to more accurately mirror the PetClinic-Web use cases,
particularly to illustrate new rich-client concepts, advantages, and
features as they are introduced. 

 

Specifically, here is a feature highlights breakdown:

 

-          An application splash screen, configurable in a Spring
application context.



-          Centralized action definitions, as well as action contribution
policies to menus and toolbars are configurable in a Spring application
context.  Locale-specific properties, such as labels, mnemonics,
accelerators, and icons are pulled from Spring message / image sources.  The
visual representation of an action is clearly separated from the functional
command object; support for dynamic, context-sensitive commands is provided.

 

-          Page and view definition is configurable via a Spring application
context.  The framework handles loading application views and laying them
out on the application page, registering local action handlers with global
actions when a particular view is activated.

 

-          A wizard framework that makes it easy to build step-by-step input
forms supporting a use case.  The use of the template method pattern
captures wizard workflow in super-classes, similar to Spring's Web-MVC
framework, substantially reducing the amount of code you have to write.

 

-          A rich as-you-type validation framework built on the
in-development declarative validation API (which is based on interfaces.)
Validation rules can be declared external to the code and associated with
bean properties.  Bean binders handle binding text field input to the
backing domain objects automatically, testing defined validation rules on
user input.  Sophisticated validation reporters are capable of reporting on
rule violations with zero coding required - just define the rules and the
message resources used for display.

 

-          Integration with jgoodies-forms for creating and laying out
professional looking forms quickly.  We provide an enhanced component
factory API as well as a simplified, interface-based abstraction around
JGoodies form builders.

 

-          Leverage of Spring's core infrastructure where it makes sense.
For example, the framework makes heavy use of the beans infrastructure as
well as the bean factory hooks.  For example, the "application object
configurer" bean post processor substantially reduces the amount of
configuration information you need to specify to configure labeled objects
consistently in the GUI (treating configuration as a separate concern.)  In
general, we want to find creative new ways to leverage the core.

 

To launch the application, you'll need to do the following:

 

1.	If you're using Eclipse and have already checked out spring and
spring-rcp as projects, just run the "PetClinic.java" class in
org.springframework.rcp.samples.PetClinic as a Java Application.

 

Or, from ant:

 

You'll need both spring and spring-rcp checked out from CVS at the same
directory level.

 

1.	Build spring.jar - "build alljars" from spring's root module
directory.
2.	Build spring-sandbox.jar - "build sandboxjar" from spring's root
module directory.
3.	Build spring's Pet Clinic Web - "build build" from spring's
petclinic sample root directory (spring/samples/petclinic)
4.	Build spring-rcp.jar - "build alljars" from spring-rcp's root module
directory.
5.	Launch PetClinic Rich Client - "build run" from the pet clinic rich
client sample root directory (spring-rcp/samples/petclinic)

 

You'll know when things are working when you see the splash screen appear,
followed by the main application window.

 

I certainly want to make the app web-startable ASAP.  If anyone would like
to help with this, let me know!



Some stats:

 

-          So far the simple sample app is about 400 lines of UI and
Controller code total; pretty good I think given swing apps have a bad
reputation for generating tons of code.  And much of that code is simple,
concise stuff (each file on average has about 100 lines); like setter
definitions for configuration, or hook-methods that do one thing.  Although,
I'm sure we can still do better. I'm always looking for ways to reduce LoC.

 

As always, we very much value and encourage your feedback!  The framework
still has some way to go for release candidate form, but this is a definite
milestone for us!  I appreciate the patience of those who've been waiting
for a sample!

 

Sincere regards,

Keith

Re: [Springframework-developer] re: OracleLobCreator

[<tho...@tr...>]

It looks to me that the WebLogic connection wrapper works fine.  No need to
extract the native Oracle driver.

My connection is
"weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_OracleConnection"

I remember hearing some Bea guys mentioning that they added LOB functionality to
their wrapper.

I'm using WLS 8.1 SP2 that comes with the Oracle ojdbc14.jar (<Driver Version is
9.2.0.3.0>).

This code ran just fine using Spring 1.0.1 jar:

	conn = ds.getConnection();
	lh = new OracleLobHandler();
	ps = conn.prepareStatement("select text from docs where doc_id = 1");
	rs = ps.executeQuery();
	if (rs.next()) {
		clobText = lh.getClobAsString(rs, 1);
	}
	System.out.println("***> READ TEXT <*** length is " +
		clobText.length());


There must me something else going on.  I would make sure to check that the
ojdbc14.jar that comes with WLS81 SP2 is the one that is on the classpath for
the server.  Could it be something in the transaction management that
interferes?

Thomas



Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> OracleLobHandler needs to work on a native OracleConnection as it comes =
> from the driver. The usual problem in that respect is not the driver but =
> the connection pool: Every connection pool needs to wrap native =
> connections with pooled connections that at least have different closing =
> behavior.
> =20
> To address this, OracleLobHandler has the "nativeJdbcExtractor" =
> property, taking an implementation of Spring's NativeJdbcExtractor =
> interface. Spring includes out-of-the-box implementations for Commons =
> DBCP, XAPool, and JBoss. I guess what you need to do is write such an =
> extractor for Weblogic.
> =20
> What's odd about your exception is that OracleLobCreator does not =
> complain that it doesn't receive an OracleConnection (there's an =
> explicit check in there). It seems to get a wrapped connection that is =
> still assignable to OracleConnection, although it's not the native =
> OracleConnection from the driver...
> =20
> Maybe Weblogic uses some special way of pooling connections for the =
> Oracle driver, using poolable OracleConnections? The =
> getPhysicalConnection method will probably be in the OracleConnection =
> class, not in the CLOB class. Try writing a NativeJdbcExtractor that =
> unwraps an OracleConnection with that method.=20
> =20
> Juergen
> =20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
> von Bronwen Cassidy
> Gesendet: Mo 31.05.2004 04:27
> An: spr...@li...
> Betreff: RE: [Springframework-developer] re: OracleLobCreator
>
>
>
> Hi I have:
>
> Weblogic 8 service pack 2
> ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
> Oracle9i
> I have set up the connection pool using the jdbc:oracle:thin (oracle =
> thin
> drivers (not weblogic ones)=20
>
> Actually I managed to find some information (very little) one from a
> hibernate mail, suggested using the getPhysicalConnection() instead of
> createTemporary, but this method does not seem to available on the CLOB
> class??
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
> Of
> Thomas Risberg
> Sent: 31 May 2004 02:09
> To: spr...@li...
> Subject: Re: [Springframework-developer] re: OracleLobCreator
>
> Bronwen,
>
> In order to pinpoint the problem quicker - what version of WebLogic,
> Oracle and JDBC drivers are you using?
>
> Thomas
>
> Bronwen Cassidy wrote:
>
> > Hi I have a CLOB column in oracle and in the test there are no
> > problems, unfortunately deploying to weblogic I get the exception
> > below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I
> > firstly replaced weblogics jars and classpath settings to use the
> > classes12.jar, but got the same error, so I pulled weblogic oracle jar
> > into my test classpath to test if the problem was with the jars but
> > the test worked fine ?? I am really stuck as to whom this should go to
> > weblogic, oracle, or . I am hoping there is an expert there who can
> > shed some light. Google did not have a single match for variations of
> > the first 2 lines!!
> >
> > java.lang.ClassCastException
> >
> > at
> >
> oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.jav=
> a:5
> 090)
> >
> > at
> >
> oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnec=
> tio
> n.java:5141)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
> >
> > at oracle.sql.CLOB.createTemporary(CLOB.java:956)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
> :39
> )
> >
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
> mpl
> .java:25)
> >
> > at java.lang.reflect.Method.invoke(Method.java:324)
> >
> > at
> >
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.pr=
> epa
> reLob(OracleLobHandler.java:375)
> >
> > at
> >
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.cr=
> eat
> eLob(OracleLobHandler.java:327)
> >
> > at
> >
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.se=
> tCl
> obAsString(OracleLobHandler.java:255)
> >
> > thank-you for any help
> >
> > Bronwen
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] re: OracleLobCreator

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

I've done some quick googling, and found those related forum entries:
=20
http://forum.java.sun.com/thread.jsp?thread=3D342767&forum=3D48&message=3D=
2018577 =
<http://forum.java.sun.com/thread.jsp?thread=3D342767&forum=3D48&message=3D=
2018577>=20
http://coding.derkeiler.com/Archive/Java/comp.lang.java.databases/2003-10=
/0156.html =
<http://coding.derkeiler.com/Archive/Java/comp.lang.java.databases/2003-1=
0/0156.html>=20
http://www-106.ibm.com/developerworks/forums/dw_forum.jsp?forum=3D244&sta=
rt=3D210&thRange=3D15&cat=3D10 =
<http://www-106.ibm.com/developerworks/forums/dw_forum.jsp?forum=3D244&st=
art=3D210&thRange=3D15&cat=3D10>=20
http://www.hibernate.org/56.html <http://www.hibernate.org/56.html>=20

So indeed Weblogic, WebSphere and OC4J seem to return special Connection =
handles for Oracle - that are assignable to OracleConnection. =
Nevertheless, we need to unwrap those for OracleLobHandler.

You could configure your OracleLobHandler with Spring's =
SimpleNativeJdbcExtractor: The latter uses a simple strategy of =
retrieving the underlying Connection that should work with many pools =
(namely, creating an empty java.sql.Statement and invoking getConnection =
on it).

For Spring 1.0.2, I've just changed SimpleNativeJdbcExtractor's strategy =
(on the occasion of a comment in the Hibernate forum above): It attempts =
to retrieve the underlying Connection via =
conHandle.getMetaData().getConnection() now, which should work with even =
more pools.

I've also changed OracleLobHandler to use a SimpleNativeJdbcExtractor by =
default, as the latter's new strategy should effectively work with =
almost any connection pool (and a plain JDBC driver too).

Note that OracleLobHandler just requires Connection unwrapping; For more =
advanced usage of a NativeJdbcExtractor (for example with JdbcTemplate), =
you still need specific NativeJdbcExtractor implementations for specific =
connection pools.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 31.05.2004 12:54
An: spr...@li...
Betreff: Re: [Springframework-developer] re: OracleLobCreator



OracleLobHandler needs to work on a native OracleConnection as it comes =
from the driver. The usual problem in that respect is not the driver but =
the connection pool: Every connection pool needs to wrap native =
connections with pooled connections that at least have different closing =
behavior.

To address this, OracleLobHandler has the "nativeJdbcExtractor" =
property, taking an implementation of Spring's NativeJdbcExtractor =
interface. Spring includes out-of-the-box implementations for Commons =
DBCP, XAPool, and JBoss. I guess what you need to do is write such an =
extractor for Weblogic.

What's odd about your exception is that OracleLobCreator does not =
complain that it doesn't receive an OracleConnection (there's an =
explicit check in there). It seems to get a wrapped connection that is =
still assignable to OracleConnection, although it's not the native =
OracleConnection from the driver...

Maybe Weblogic uses some special way of pooling connections for the =
Oracle driver, using poolable OracleConnections? The =
getPhysicalConnection method will probably be in the OracleConnection =
class, not in the CLOB class. Try writing a NativeJdbcExtractor that =
unwraps an OracleConnection with that method.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Bronwen Cassidy
Gesendet: Mo 31.05.2004 04:27
An: spr...@li...
Betreff: RE: [Springframework-developer] re: OracleLobCreator



Hi I have:

Weblogic 8 service pack 2
ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
Oracle9i
I have set up the connection pool using the jdbc:oracle:thin (oracle =
thin
drivers (not weblogic ones)

Actually I managed to find some information (very little) one from a
hibernate mail, suggested using the getPhysicalConnection() instead of
createTemporary, but this method does not seem to available on the CLOB
class??

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Thomas Risberg
Sent: 31 May 2004 02:09
To: spr...@li...
Subject: Re: [Springframework-developer] re: OracleLobCreator

Bronwen,

In order to pinpoint the problem quicker - what version of WebLogic,
Oracle and JDBC drivers are you using?

Thomas

Bronwen Cassidy wrote:

> Hi I have a CLOB column in oracle and in the test there are no
> problems, unfortunately deploying to weblogic I get the exception
> below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I
> firstly replaced weblogics jars and classpath settings to use the
> classes12.jar, but got the same error, so I pulled weblogic oracle jar
> into my test classpath to test if the problem was with the jars but
> the test worked fine ?? I am really stuck as to whom this should go to
> weblogic, oracle, or . I am hoping there is an expert there who can
> shed some light. Google did not have a single match for variations of
> the first 2 lines!!
>
> java.lang.ClassCastException
>
> at
>
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.jav=
a:5
090)
>
> at
>
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnec=
tio
n.java:5141)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39
)
>
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl
.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:324)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.pr=
epa
reLob(OracleLobHandler.java:375)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.cr=
eat
eLob(OracleLobHandler.java:327)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.se=
tCl
obAsString(OracleLobHandler.java:255)
>
> thank-you for any help
>
> Bronwen
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

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

The IntrospectorCleanupListener and IntrospectorCleanupServlet sound=20
reasonable. At the end of the day, as has been discussed, this is=20
probably going to be of most use to people in development; I'm not sure=20
how many people trust hot-deploy in production. Certainly I would never=20
do it with something like JBoss. The only option I am pretty strongly=20
opposed to is to have the default behaviour to be to call flushCaches on=20
shutdown, since it can affect so many other apps in the container; I=20
realize you don't think this is a good default either .

I should mention Juergen that your changes appear to have had an=20
interesting effect on hot-redeploy of my main app in JBoss. As of about=20
maybe 1.5 months ago, hot redeploy in JBoss stopped working for me, with=20
JBoss complaining on reload about ClassCastExceptions on a number of=20
classes. As of about a week ago, it's working again. I never really had=20
time to track down why the hot-redeploy stopped working (the JBoss=20
unified classloader is a fairly random, unpredictable beast, especially=20
with EJBs involved), but the timing with it working again now makes me=20
think that the recent changes are responsible for it working again...

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>I've just found out that our JPetStore's remaining resource leak is not =
caused by iBATIS or JDOM but by Struts: Struts uses Commons BeanUtils whi=
ch in turn uses the JavaBeans Introspector without flushing... So on web =
app shutdown, the Introspector cache holds references to Struts Actions f=
rom the web app classloder. This prevents garbage collection of JDOM's si=
ngletons because the web app classloader (which holds its loaded classes =
and thus their static references) is still around. So it's not JDOM's fau=
lt; it's rather like with Spring's SQLErrorCodesFactory and co.
>=20
>Which gives 2 candidates that would benefit from a general Introspector.=
flushCaches call on shutdown so far: Struts and Quartz. As per my mail fr=
om yesterday, Spring does not need that anymore as it flushes the JavaBea=
ns Introspector for each class that it caches introspection results for i=
tself. If you still see Spring classes hanging around after web app shutd=
own, that's caused by leaks of *other* tools that prevent the class loade=
r (which is referencing Spring classes) from being disposed.
>=20
>So the remaining question is: Should we provide a way to call Introspect=
or.flushCaches on web app shutdown? Doing this in ContextLoaderListener w=
ill just affect apps that actually use ContextLoaderListener: What about =
DispatcherServlet-only apps? What about Struts apps that load a Spring co=
ntext via a plugin? What about Servlet 2.2 apps that can't register liste=
ners? I guess it would be better to provide separate IntrospectorCleanupL=
istener and IntrospectorCleanupServlet classes (analogous to Log4jConfigL=
istener and Log4jConfigServlet), just doing a Introspector.flushCaches ca=
ll on shutdown.
>=20
>Of course, it would be ideal if the JavaBeans Introspector used a WeakHa=
shMap with WeakReference values - none of this would be necessary then. A=
fter all, it's a pretty obvious bug in the current JDK: What's the point =
in using a WeakHashMap with values that reference the key but are not hel=
d in WeakReferences? If they wouldn't care about garbage collection in th=
e first place, they could use a plain HashMap... Currently, they seem to =
go just half the way.
>=20
>With the current JDK implementation, it would also be nice if the servle=
t container did an Introspector.flushCaches call on web app shutdown, or =
preferably a flushFromCaches call for each class loader by the correspond=
ing class loader. However, it's unrealistic that all containers will do t=
his any time soon - and this wouldn't be necessary either if that d*** Ja=
vaBeans Introspector implementation properly used WeakReferences.
>=20
>So I guess I'll add IntrospectorCleanupListener and IntrospectorCleanupS=
ervlet classes... thoughts?
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n j=FCrgen h=F6ller [werk3AT]
>Gesendet: Mo 31.05.2004 13:08
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on=
 webapp reload
>
>
>
>Guillaume,
>
>As far as I see, the only benefit that we would gain with such a classlo=
ader check is that we avoid recaching introspection results during applic=
ation runtime, for the case where the garbage collector has eagerly remov=
ed them. However, the latter can only happen when there are no other refe=
rences to the given Class: This won't be the case with typical Spring usa=
ge, as both bean factories and web command controllers (i.e. the main usa=
ges of BeanWrapper) hold a reference to the bean class respectively comma=
nd class.
>
>And if there are no other references to a specific Class, I suppose the =
garbage collector is free to remove the cached introspection results for =
it; this can be considered a desirable thing. So I guess it's better to l=
eave CachedIntrospectionResults as it is, as there's no noteworthy differ=
ence in all other respects. Do you see any negative impact on performance=
, given the scenario from above? Your earlier point comes to my mind here=
: It's also about a simple implementation that doesn't obscure the purpos=
e of the code.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n Guillaume Poirier
>Gesendet: Mo 31.05.2004 00:26
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on=
 webapp reload
>
>
>
>Juergen,
>
>I think that Introspector.flushCaches() on a ServletContextListener it s=
till
>the lesser of evils for that memory leak, the effect on other webapps wo=
uld
>not be that bad anyway, just slow a little bit the next few calls to
>Introspector.getBeanInfo().  However, I agree with you that this should
>probably be dealt with by the application rather than Spring.  But may b=
e it
>could be an option with Spring's ContextLoaderListener (probably off by
>default)?
>
>Concerning your solution with CachedIntrospectionResults, I would have a
>sugestion for performance.  For the majority of the use cases,
>CachedIntrospectionResults would be in the same ClassLoader as the targe=
t
>class.  So I would suggest to first check the ClassLoader to know if it'=
s
>safe to cache the class without WeakReference.  I've attached a patch to=
 the
>E-Mail if you would like to include my suggestion.
>
>Thanks,
>Guillaume
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Sunday, May 30, 2004 11:09 AM
>Subject: Re: [Springframework-developer] Cleanup of context resources on
>webapp reload
>
>
>Guillaume,
>
>I'm using a profiler, explicitly running garbage collection after
>application shutdown and then seeing what remains on the heap. It's actu=
ally
>my first really instance profiler work for about two years; haven't had =
any
>need for it in the meantime.
>
>Anyway, I did some further tests today, changing SQLErrorCodesFactory an=
d
>GlobalAdvisorAdapterRegistry to classic singletons again, with an
>Introspector.flushCaches call on shutdown. While this didn't have any ef=
fect
>with Petclinic, it did result in proper cleanup with Image Database.
>
>So the Introspector.flushCaches call *does* have some effect, contrary t=
o my
>assumption from yesterday, but not in all scenarios. After some further
>tests, I found out that Hibernate (-> Petclinic) has its own leaks, thus
>keeps the web app class loader around, thus no cleanup of Spring's
>singletons in that class loader. If Hibernate isn't used, everything get=
s
>cleaned up properly.
>
>This means that you're perfectly right: Coding singletons with
>WeakReferences only cleans up that particular singleton object but of co=
urse
>doesn't do anything about the class loader itself with its remaining lea=
ks.
>As the code *is* uglier with WeakReferences, I've permanently changed
>SQLErrorCodesFactory and GlobalAdvisorAdapterRegistry back to classic
>singletons (like they were until a week ago).
>
>I'd like to leave CachedIntrospectionResults as-is with a WeakHashMap an=
d
>WeakReferences, as this holds references to classes and might reside in =
a
>parent classloader of the referenced classes. That's how the JDK's
>Introspector class should be coded too...
>
>The remaining issue is: Where to invoke Introspector.flushCaches? Every
>ApplicationContext shutdown? How to avoid cleaning all BeanInfos *of the
>entire VM*, when all we want to do is clean up all BeanInfos of the curr=
ent
>app?
>Sure, a general flushCaches call cleans up all BeanInfo leaks of the app
>too, be it from Spring or Quartz or whatever, but all we want to provide
>out-of-the-box is proper cleanup of Spring itself.
>
>So my solution for Spring is simple: CachedIntrospectionResults flushes =
the
>Introspector cache for the given class (and its superclasses) right afte=
r it
>fetched the BeanInfo for it (i.e. right after it's been cached). As we c=
ache
>the introspection results ourselves anyway, we wouldn't benefit from the
>Introspector cache in the first place. That shouldn't have any negative
>impact on performance.
>
>I did quite a lot of tests with this new strategy, and everything gets
>cleaned up nicely within Spring. Just if you add Hibernate or Quartz to =
the
>mix, you'll get leaks from them that prevent the class loader from getti=
ng
>garbage collected. With Quartz, a general flushCaches call helps; with
>Hibernate, even that doesn't.
>
>So in certain scenarios, it might help to add a custom
>ServletContextListener that does an Introspector.flushCaches call on
>shutdown - but for Spring itself, this isn't necessary, as the beans
>infrastructure does not cause any leaks anymore. I'm happy with the curr=
ent
>solution: classic singletons as before, just a flushFromCaches call for =
each
>introspected class right when building the CachedIntrospectionResults
>object.
>
>We should probably tell the Quartz guys to apply specific flushFromCache=
s
>calls after their Introspector usage. I've also noticed that JDOM, as us=
ed
>within iBATIS SQL Maps 1.3, has a resource leak too. I haven't researche=
d
>where the Hibernate leaks come from in detail, but the root of the probl=
em
>seems to be CGLIB there.
>
>Many thanks for pointing this out! :-)
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
>Guillaume Poirier
>Gesendet: So 30.05.2004 07:01
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on
>webapp reload
>
>
>
>Juergen, I'm curious about how exactly you assert what is leaking, what =
is
>not, and exactly what is it better with WeakReference?  Are you using a
>profiler that tells you the non-garbage collected objects in the JVM or =
do
>you use other means?
>
>Concerning SQLErrorCodesFactory, while the class' constructor does cause=
 a
>leak (indirectly by the use of XmlBeanFactory), it is not itself the lea=
k,
>it's the class instance of SQLErrorCodes that prevent the ClassLoader's
>collection.  I did a test calling
>SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
>ClassLoader, and it caused a leak when the ClassLoader is thrown away.  =
Then
>I tried to create my own SQLErrorCodesFactory implementation, and it kep=
t
>leaking until I stopped using the XmlBeanFactory to create the instances=
 of
>SQLErrorCodes.  Then I tried to just use an Introspector directly to set=
 the
>properties on the SQLErrorCodes instances by reflection, and it leaked j=
ust
>as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
>Introspector has an hard reference on SQLErrorCodes.class, then none of =
the
>class loaded by its ClassLoader can be collected.  So it would be the ca=
use
>of SQLErrorCodesFactory singleton to be kept alive, not because
>SQLFactoryErrorCodes has an hard reference on it, but because the
>ClassLoader does, and SQLErrorCodes.class has an hard reference on the
>ClassLoader, and the Introspector has an hard reference on
>SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is real=
ly
>kept alive because Introspector has an hard reference on the class insta=
nce
>of SQLErrorCodes.
>
>I might misunderstand the situation, but as I see it, you're working on =
the
>symptom rather than the cause.  If you allow the singleton to be garbage
>collected when the class itself is retained, then you might save some
>memory, but it's just like adding memory to the JVM to solve a leak, it =
will
>only delay the OutOfMemoryError, it won't prevent it.  However, if you a=
llow
>the ClassLoader to be collected by removing any hard reference to its
>classes, that would prevent the leak to even take place at all.
>
>That's why I'm curious as to why you say it's better with WeakReference =
on
>singleton and Introspector.flushCaches() does nothing, how do you make t=
hat
>assertion?  I realize that if there's something else than Introspector t=
hat
>has an hard reference on a class of the ClassLoader being thown away,
>flushing the Introspector's cache will have no effect on the leak, it wo=
uld
>still leak as fast.  But while the WeakReference on the singleton will d=
elay
>the OutOfMemoryError, does it really help that much, since anyway all th=
e
>Class definitions and static members cannot be collected?  You have to
>consider that coding defensively on this might reduce performance becaus=
e of
>more object creation and use of synchronization, while also complicating=
 the
>code.  Is it really worth it, did your tests really showed a significant
>effect on a typical application?
>
>Guillaume
>
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Saturday, May 29, 2004 2:28 PM
>Subject: Re: [Springframework-developer] Cleanup of context resources on
>webapp reload
>
>
>Guillaume,
>
>I've prototypically added an Introspector.flushCaches call to context
>shutdown: I don't see any difference in the profiler. That's not too
>surprising, as the originally leaking classes are not managed by beans
>facilities in the first place: for example, SQLErrorCodesFactory, which =
is
>just used internally by SQLErrorCodeSQLExceptionTranslator.
>
>Of course, since my changes from a week ago, those classes don't leak
>anymore, as they hold their singleton instance in a WeakReference now...=
 I
>still don't understand why this is necessary, but I'm 100% sure that it =
does
>make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also tri=
ed
>various GC configuration options - always the same effect.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n
>Guillaume Poirier
>Gesendet: Sa 29.05.2004 06:12
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on
>webapp reload
>
>
>
>I experimented some more about this cleanup issue, and I was able to nar=
row
>down the problem to the caching done by the java.beans.Introspector.  It
>stores the BeanInfo instances in a WeakHashMap, but in that Map
>implementation, only the keys uses WeakReference, the values are stored =
with
>hard references since BeanInfo has an hard reference on the class it giv=
es
>info about (indirectly through BeanDescriptor and others), any time
>Introspector.getBeanInfo(Class) is used, that class and it's static memb=
ers
>will not ever be able to be garbage collected.  I kind of remember someo=
ne
>mentioning something related to this in the mailling list, but I cannot =
find
>the mail.  I wonder if there's other case where the java[x] classes migh=
t
>have an hard reference on a class or its instances.  A fix for this
>particular problem is to have a ServletContextListener call
>Introspector.flushCaches() when the context is destroyed.
>
>It seems like a known issue at Sun :
>
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008
>
>So, unless I'm missing something here, that means fixes like using
>synchronization and WeakReference on singleton probably won't help much =
if
>at all.  The only way that I can see for a class not to be gargage colle=
cted
>when no more active thread use it, is if another ClassLoader has an hard
>reference to the class instance, or an instance of that class.  Having t=
he
>class itself have an hard reference on a its own singleton has no effect=
,
>it's a circular reference that will not prevent the class or the instanc=
e to
>be gargabe collected when neither is being refered to by something else.
>
>Guillaume
> =20
>

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[William G. T. Jr. <wg...@ru...>]

Maxim,

If looks like you are trying an old version...directions for the latest 
version are here:

http://list.unm.edu/cgi-bin/wa?A2=ind0405&L=jasig-dev&P=R2654

After running,
   ant deployPortletApp -DportletApp=spring-example-portlet.war

you should have a servlet context,
  ../webapps/spring-example-portlet

and the portlet Id is,
   spring-example-portlet.spring-example-portlet

later.
Bill

Maxim Petrashev wrote:
> Hello,William 
> 
> I did deploy on uPortal server as you say but receive the following exception:
> org.jasig.portal.PortalException: Unable to find portlet definition for 
> ID 'springportlet.ExampleSpringPortlet'
> 	at org.jasig.portal.channels.portlet.CPortletAdapter.initPortletWindow
> (CPortletAdapter.java:194)
> 	at org.jasig.portal.channels.portlet.CPortletAdapter.renderCharacters
> (CPortletAdapter.java:429)
> 	at 
> org.jasig.portal.MultithreadedCharacterChannelAdapter.renderCharacters
> (MultithreadedCharacterChannelAdapter.java:71)
> 	at org.jasig.portal.ChannelRenderer$Worker.run(ChannelRenderer.java:481)
> 	at org.jasig.portal.utils.threading.Worker.run(Worker.java:88)
> 
> I don't see any portlet definitions in webapps/uPortal dir...
> 
> What I did wrong?
> 
> Thank you,
> Maxim

Re: [Springframework-developer] Cleanup of context resources on webapp reload

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

I've just found out that our JPetStore's remaining resource leak is not =
caused by iBATIS or JDOM but by Struts: Struts uses Commons BeanUtils =
which in turn uses the JavaBeans Introspector without flushing... So on =
web app shutdown, the Introspector cache holds references to Struts =
Actions from the web app classloder. This prevents garbage collection of =
JDOM's singletons because the web app classloader (which holds its =
loaded classes and thus their static references) is still around. So =
it's not JDOM's fault; it's rather like with Spring's =
SQLErrorCodesFactory and co.
=20
Which gives 2 candidates that would benefit from a general =
Introspector.flushCaches call on shutdown so far: Struts and Quartz. As =
per my mail from yesterday, Spring does not need that anymore as it =
flushes the JavaBeans Introspector for each class that it caches =
introspection results for itself. If you still see Spring classes =
hanging around after web app shutdown, that's caused by leaks of *other* =
tools that prevent the class loader (which is referencing Spring =
classes) from being disposed.
=20
So the remaining question is: Should we provide a way to call =
Introspector.flushCaches on web app shutdown? Doing this in =
ContextLoaderListener will just affect apps that actually use =
ContextLoaderListener: What about DispatcherServlet-only apps? What =
about Struts apps that load a Spring context via a plugin? What about =
Servlet 2.2 apps that can't register listeners? I guess it would be =
better to provide separate IntrospectorCleanupListener and =
IntrospectorCleanupServlet classes (analogous to Log4jConfigListener and =
Log4jConfigServlet), just doing a Introspector.flushCaches call on =
shutdown.
=20
Of course, it would be ideal if the JavaBeans Introspector used a =
WeakHashMap with WeakReference values - none of this would be necessary =
then. After all, it's a pretty obvious bug in the current JDK: What's =
the point in using a WeakHashMap with values that reference the key but =
are not held in WeakReferences? If they wouldn't care about garbage =
collection in the first place, they could use a plain HashMap... =
Currently, they seem to go just half the way.
=20
With the current JDK implementation, it would also be nice if the =
servlet container did an Introspector.flushCaches call on web app =
shutdown, or preferably a flushFromCaches call for each class loader by =
the corresponding class loader. However, it's unrealistic that all =
containers will do this any time soon - and this wouldn't be necessary =
either if that d*** JavaBeans Introspector implementation properly used =
WeakReferences.
=20
So I guess I'll add IntrospectorCleanupListener and =
IntrospectorCleanupServlet classes... thoughts?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 31.05.2004 13:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Guillaume,

As far as I see, the only benefit that we would gain with such a =
classloader check is that we avoid recaching introspection results =
during application runtime, for the case where the garbage collector has =
eagerly removed them. However, the latter can only happen when there are =
no other references to the given Class: This won't be the case with =
typical Spring usage, as both bean factories and web command controllers =
(i.e. the main usages of BeanWrapper) hold a reference to the bean class =
respectively command class.

And if there are no other references to a specific Class, I suppose the =
garbage collector is free to remove the cached introspection results for =
it; this can be considered a desirable thing. So I guess it's better to =
leave CachedIntrospectionResults as it is, as there's no noteworthy =
difference in all other respects. Do you see any negative impact on =
performance, given the scenario from above? Your earlier point comes to =
my mind here: It's also about a simple implementation that doesn't =
obscure the purpose of the code.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Guillaume Poirier
Gesendet: Mo 31.05.2004 00:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Juergen,

I think that Introspector.flushCaches() on a ServletContextListener it =
still
the lesser of evils for that memory leak, the effect on other webapps =
would
not be that bad anyway, just slow a little bit the next few calls to
Introspector.getBeanInfo().  However, I agree with you that this should
probably be dealt with by the application rather than Spring.  But may =
be it
could be an option with Spring's ContextLoaderListener (probably off by
default)?

Concerning your solution with CachedIntrospectionResults, I would have a
sugestion for performance.  For the majority of the use cases,
CachedIntrospectionResults would be in the same ClassLoader as the =
target
class.  So I would suggest to first check the ClassLoader to know if =
it's
safe to cache the class without WeakReference.  I've attached a patch to =
the
E-Mail if you would like to include my suggestion.

Thanks,
Guillaume

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, May 30, 2004 11:09 AM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I'm using a profiler, explicitly running garbage collection after
application shutdown and then seeing what remains on the heap. It's =
actually
my first really instance profiler work for about two years; haven't had =
any
need for it in the meantime.

Anyway, I did some further tests today, changing SQLErrorCodesFactory =
and
GlobalAdvisorAdapterRegistry to classic singletons again, with an
Introspector.flushCaches call on shutdown. While this didn't have any =
effect
with Petclinic, it did result in proper cleanup with Image Database.

So the Introspector.flushCaches call *does* have some effect, contrary =
to my
assumption from yesterday, but not in all scenarios. After some further
tests, I found out that Hibernate (-> Petclinic) has its own leaks, thus
keeps the web app class loader around, thus no cleanup of Spring's
singletons in that class loader. If Hibernate isn't used, everything =
gets
cleaned up properly.

This means that you're perfectly right: Coding singletons with
WeakReferences only cleans up that particular singleton object but of =
course
doesn't do anything about the class loader itself with its remaining =
leaks.
As the code *is* uglier with WeakReferences, I've permanently changed
SQLErrorCodesFactory and GlobalAdvisorAdapterRegistry back to classic
singletons (like they were until a week ago).

I'd like to leave CachedIntrospectionResults as-is with a WeakHashMap =
and
WeakReferences, as this holds references to classes and might reside in =
a
parent classloader of the referenced classes. That's how the JDK's
Introspector class should be coded too...

The remaining issue is: Where to invoke Introspector.flushCaches? Every
ApplicationContext shutdown? How to avoid cleaning all BeanInfos *of the
entire VM*, when all we want to do is clean up all BeanInfos of the =
current
app?
Sure, a general flushCaches call cleans up all BeanInfo leaks of the app
too, be it from Spring or Quartz or whatever, but all we want to provide
out-of-the-box is proper cleanup of Spring itself.

So my solution for Spring is simple: CachedIntrospectionResults flushes =
the
Introspector cache for the given class (and its superclasses) right =
after it
fetched the BeanInfo for it (i.e. right after it's been cached). As we =
cache
the introspection results ourselves anyway, we wouldn't benefit from the
Introspector cache in the first place. That shouldn't have any negative
impact on performance.

I did quite a lot of tests with this new strategy, and everything gets
cleaned up nicely within Spring. Just if you add Hibernate or Quartz to =
the
mix, you'll get leaks from them that prevent the class loader from =
getting
garbage collected. With Quartz, a general flushCaches call helps; with
Hibernate, even that doesn't.

So in certain scenarios, it might help to add a custom
ServletContextListener that does an Introspector.flushCaches call on
shutdown - but for Spring itself, this isn't necessary, as the beans
infrastructure does not cause any leaks anymore. I'm happy with the =
current
solution: classic singletons as before, just a flushFromCaches call for =
each
introspected class right when building the CachedIntrospectionResults
object.

We should probably tell the Quartz guys to apply specific =
flushFromCaches
calls after their Introspector usage. I've also noticed that JDOM, as =
used
within iBATIS SQL Maps 1.3, has a resource leak too. I haven't =
researched
where the Hibernate leaks come from in detail, but the root of the =
problem
seems to be CGLIB there.

Many thanks for pointing this out! :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Guillaume Poirier
Gesendet: So 30.05.2004 07:01
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Juergen, I'm curious about how exactly you assert what is leaking, what =
is
not, and exactly what is it better with WeakReference?  Are you using a
profiler that tells you the non-garbage collected objects in the JVM or =
do
you use other means?

Concerning SQLErrorCodesFactory, while the class' constructor does cause =
a
leak (indirectly by the use of XmlBeanFactory), it is not itself the =
leak,
it's the class instance of SQLErrorCodes that prevent the ClassLoader's
collection.  I did a test calling
SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
ClassLoader, and it caused a leak when the ClassLoader is thrown away.  =
Then
I tried to create my own SQLErrorCodesFactory implementation, and it =
kept
leaking until I stopped using the XmlBeanFactory to create the instances =
of
SQLErrorCodes.  Then I tried to just use an Introspector directly to set =
the
properties on the SQLErrorCodes instances by reflection, and it leaked =
just
as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
Introspector has an hard reference on SQLErrorCodes.class, then none of =
the
class loaded by its ClassLoader can be collected.  So it would be the =
cause
of SQLErrorCodesFactory singleton to be kept alive, not because
SQLFactoryErrorCodes has an hard reference on it, but because the
ClassLoader does, and SQLErrorCodes.class has an hard reference on the
ClassLoader, and the Introspector has an hard reference on
SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is =
really
kept alive because Introspector has an hard reference on the class =
instance
of SQLErrorCodes.

I might misunderstand the situation, but as I see it, you're working on =
the
symptom rather than the cause.  If you allow the singleton to be garbage
collected when the class itself is retained, then you might save some
memory, but it's just like adding memory to the JVM to solve a leak, it =
will
only delay the OutOfMemoryError, it won't prevent it.  However, if you =
allow
the ClassLoader to be collected by removing any hard reference to its
classes, that would prevent the leak to even take place at all.

That's why I'm curious as to why you say it's better with WeakReference =
on
singleton and Introspector.flushCaches() does nothing, how do you make =
that
assertion?  I realize that if there's something else than Introspector =
that
has an hard reference on a class of the ClassLoader being thown away,
flushing the Introspector's cache will have no effect on the leak, it =
would
still leak as fast.  But while the WeakReference on the singleton will =
delay
the OutOfMemoryError, does it really help that much, since anyway all =
the
Class definitions and static members cannot be collected?  You have to
consider that coding defensively on this might reduce performance =
because of
more object creation and use of synchronization, while also complicating =
the
code.  Is it really worth it, did your tests really showed a significant
effect on a typical application?

Guillaume


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, May 29, 2004 2:28 PM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I've prototypically added an Introspector.flushCaches call to context
shutdown: I don't see any difference in the profiler. That's not too
surprising, as the originally leaking classes are not managed by beans
facilities in the first place: for example, SQLErrorCodesFactory, which =
is
just used internally by SQLErrorCodeSQLExceptionTranslator.

Of course, since my changes from a week ago, those classes don't leak
anymore, as they hold their singleton instance in a WeakReference now... =
I
still don't understand why this is necessary, but I'm 100% sure that it =
does
make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also =
tried
various GC configuration options - always the same effect.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I experimented some more about this cleanup issue, and I was able to =
narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored =
with
hard references since BeanInfo has an hard reference on the class it =
gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static =
members
will not ever be able to be garbage collected.  I kind of remember =
someone
mentioning something related to this in the mailling list, but I cannot =
find
the mail.  I wonder if there's other case where the java[x] classes =
might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much =
if
at all.  The only way that I can see for a class not to be gargage =
collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having =
the
class itself have an hard reference on a its own singleton has no =
effect,
it's a circular reference that will not prevent the class or the =
instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

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

Guillaume,
=20
As far as I see, the only benefit that we would gain with such a =
classloader check is that we avoid recaching introspection results =
during application runtime, for the case where the garbage collector has =
eagerly removed them. However, the latter can only happen when there are =
no other references to the given Class: This won't be the case with =
typical Spring usage, as both bean factories and web command controllers =
(i.e. the main usages of BeanWrapper) hold a reference to the bean class =
respectively command class.
=20
And if there are no other references to a specific Class, I suppose the =
garbage collector is free to remove the cached introspection results for =
it; this can be considered a desirable thing. So I guess it's better to =
leave CachedIntrospectionResults as it is, as there's no noteworthy =
difference in all other respects. Do you see any negative impact on =
performance, given the scenario from above? Your earlier point comes to =
my mind here: It's also about a simple implementation that doesn't =
obscure the purpose of the code.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Guillaume Poirier
Gesendet: Mo 31.05.2004 00:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Juergen,

I think that Introspector.flushCaches() on a ServletContextListener it =
still
the lesser of evils for that memory leak, the effect on other webapps =
would
not be that bad anyway, just slow a little bit the next few calls to
Introspector.getBeanInfo().  However, I agree with you that this should
probably be dealt with by the application rather than Spring.  But may =
be it
could be an option with Spring's ContextLoaderListener (probably off by
default)?

Concerning your solution with CachedIntrospectionResults, I would have a
sugestion for performance.  For the majority of the use cases,
CachedIntrospectionResults would be in the same ClassLoader as the =
target
class.  So I would suggest to first check the ClassLoader to know if =
it's
safe to cache the class without WeakReference.  I've attached a patch to =
the
E-Mail if you would like to include my suggestion.

Thanks,
Guillaume

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, May 30, 2004 11:09 AM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I'm using a profiler, explicitly running garbage collection after
application shutdown and then seeing what remains on the heap. It's =
actually
my first really instance profiler work for about two years; haven't had =
any
need for it in the meantime.

Anyway, I did some further tests today, changing SQLErrorCodesFactory =
and
GlobalAdvisorAdapterRegistry to classic singletons again, with an
Introspector.flushCaches call on shutdown. While this didn't have any =
effect
with Petclinic, it did result in proper cleanup with Image Database.

So the Introspector.flushCaches call *does* have some effect, contrary =
to my
assumption from yesterday, but not in all scenarios. After some further
tests, I found out that Hibernate (-> Petclinic) has its own leaks, thus
keeps the web app class loader around, thus no cleanup of Spring's
singletons in that class loader. If Hibernate isn't used, everything =
gets
cleaned up properly.

This means that you're perfectly right: Coding singletons with
WeakReferences only cleans up that particular singleton object but of =
course
doesn't do anything about the class loader itself with its remaining =
leaks.
As the code *is* uglier with WeakReferences, I've permanently changed
SQLErrorCodesFactory and GlobalAdvisorAdapterRegistry back to classic
singletons (like they were until a week ago).

I'd like to leave CachedIntrospectionResults as-is with a WeakHashMap =
and
WeakReferences, as this holds references to classes and might reside in =
a
parent classloader of the referenced classes. That's how the JDK's
Introspector class should be coded too...

The remaining issue is: Where to invoke Introspector.flushCaches? Every
ApplicationContext shutdown? How to avoid cleaning all BeanInfos *of the
entire VM*, when all we want to do is clean up all BeanInfos of the =
current
app?
Sure, a general flushCaches call cleans up all BeanInfo leaks of the app
too, be it from Spring or Quartz or whatever, but all we want to provide
out-of-the-box is proper cleanup of Spring itself.

So my solution for Spring is simple: CachedIntrospectionResults flushes =
the
Introspector cache for the given class (and its superclasses) right =
after it
fetched the BeanInfo for it (i.e. right after it's been cached). As we =
cache
the introspection results ourselves anyway, we wouldn't benefit from the
Introspector cache in the first place. That shouldn't have any negative
impact on performance.

I did quite a lot of tests with this new strategy, and everything gets
cleaned up nicely within Spring. Just if you add Hibernate or Quartz to =
the
mix, you'll get leaks from them that prevent the class loader from =
getting
garbage collected. With Quartz, a general flushCaches call helps; with
Hibernate, even that doesn't.

So in certain scenarios, it might help to add a custom
ServletContextListener that does an Introspector.flushCaches call on
shutdown - but for Spring itself, this isn't necessary, as the beans
infrastructure does not cause any leaks anymore. I'm happy with the =
current
solution: classic singletons as before, just a flushFromCaches call for =
each
introspected class right when building the CachedIntrospectionResults
object.

We should probably tell the Quartz guys to apply specific =
flushFromCaches
calls after their Introspector usage. I've also noticed that JDOM, as =
used
within iBATIS SQL Maps 1.3, has a resource leak too. I haven't =
researched
where the Hibernate leaks come from in detail, but the root of the =
problem
seems to be CGLIB there.

Many thanks for pointing this out! :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Guillaume Poirier
Gesendet: So 30.05.2004 07:01
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Juergen, I'm curious about how exactly you assert what is leaking, what =
is
not, and exactly what is it better with WeakReference?  Are you using a
profiler that tells you the non-garbage collected objects in the JVM or =
do
you use other means?

Concerning SQLErrorCodesFactory, while the class' constructor does cause =
a
leak (indirectly by the use of XmlBeanFactory), it is not itself the =
leak,
it's the class instance of SQLErrorCodes that prevent the ClassLoader's
collection.  I did a test calling
SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
ClassLoader, and it caused a leak when the ClassLoader is thrown away.  =
Then
I tried to create my own SQLErrorCodesFactory implementation, and it =
kept
leaking until I stopped using the XmlBeanFactory to create the instances =
of
SQLErrorCodes.  Then I tried to just use an Introspector directly to set =
the
properties on the SQLErrorCodes instances by reflection, and it leaked =
just
as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
Introspector has an hard reference on SQLErrorCodes.class, then none of =
the
class loaded by its ClassLoader can be collected.  So it would be the =
cause
of SQLErrorCodesFactory singleton to be kept alive, not because
SQLFactoryErrorCodes has an hard reference on it, but because the
ClassLoader does, and SQLErrorCodes.class has an hard reference on the
ClassLoader, and the Introspector has an hard reference on
SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is =
really
kept alive because Introspector has an hard reference on the class =
instance
of SQLErrorCodes.

I might misunderstand the situation, but as I see it, you're working on =
the
symptom rather than the cause.  If you allow the singleton to be garbage
collected when the class itself is retained, then you might save some
memory, but it's just like adding memory to the JVM to solve a leak, it =
will
only delay the OutOfMemoryError, it won't prevent it.  However, if you =
allow
the ClassLoader to be collected by removing any hard reference to its
classes, that would prevent the leak to even take place at all.

That's why I'm curious as to why you say it's better with WeakReference =
on
singleton and Introspector.flushCaches() does nothing, how do you make =
that
assertion?  I realize that if there's something else than Introspector =
that
has an hard reference on a class of the ClassLoader being thown away,
flushing the Introspector's cache will have no effect on the leak, it =
would
still leak as fast.  But while the WeakReference on the singleton will =
delay
the OutOfMemoryError, does it really help that much, since anyway all =
the
Class definitions and static members cannot be collected?  You have to
consider that coding defensively on this might reduce performance =
because of
more object creation and use of synchronization, while also complicating =
the
code.  Is it really worth it, did your tests really showed a significant
effect on a typical application?

Guillaume


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, May 29, 2004 2:28 PM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I've prototypically added an Introspector.flushCaches call to context
shutdown: I don't see any difference in the profiler. That's not too
surprising, as the originally leaking classes are not managed by beans
facilities in the first place: for example, SQLErrorCodesFactory, which =
is
just used internally by SQLErrorCodeSQLExceptionTranslator.

Of course, since my changes from a week ago, those classes don't leak
anymore, as they hold their singleton instance in a WeakReference now... =
I
still don't understand why this is necessary, but I'm 100% sure that it =
does
make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also =
tried
various GC configuration options - always the same effect.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I experimented some more about this cleanup issue, and I was able to =
narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored =
with
hard references since BeanInfo has an hard reference on the class it =
gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static =
members
will not ever be able to be garbage collected.  I kind of remember =
someone
mentioning something related to this in the mailling list, but I cannot =
find
the mail.  I wonder if there's other case where the java[x] classes =
might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much =
if
at all.  The only way that I can see for a class not to be gargage =
collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having =
the
class itself have an hard reference on a its own singleton has no =
effect,
it's a circular reference that will not prevent the class or the =
instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] re: OracleLobCreator

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

OracleLobHandler needs to work on a native OracleConnection as it comes =
from the driver. The usual problem in that respect is not the driver but =
the connection pool: Every connection pool needs to wrap native =
connections with pooled connections that at least have different closing =
behavior.
=20
To address this, OracleLobHandler has the "nativeJdbcExtractor" =
property, taking an implementation of Spring's NativeJdbcExtractor =
interface. Spring includes out-of-the-box implementations for Commons =
DBCP, XAPool, and JBoss. I guess what you need to do is write such an =
extractor for Weblogic.
=20
What's odd about your exception is that OracleLobCreator does not =
complain that it doesn't receive an OracleConnection (there's an =
explicit check in there). It seems to get a wrapped connection that is =
still assignable to OracleConnection, although it's not the native =
OracleConnection from the driver...
=20
Maybe Weblogic uses some special way of pooling connections for the =
Oracle driver, using poolable OracleConnections? The =
getPhysicalConnection method will probably be in the OracleConnection =
class, not in the CLOB class. Try writing a NativeJdbcExtractor that =
unwraps an OracleConnection with that method.=20
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Bronwen Cassidy
Gesendet: Mo 31.05.2004 04:27
An: spr...@li...
Betreff: RE: [Springframework-developer] re: OracleLobCreator



Hi I have:

Weblogic 8 service pack 2
ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers)
Oracle9i
I have set up the connection pool using the jdbc:oracle:thin (oracle =
thin
drivers (not weblogic ones)=20

Actually I managed to find some information (very little) one from a
hibernate mail, suggested using the getPhysicalConnection() instead of
createTemporary, but this method does not seem to available on the CLOB
class??

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Thomas Risberg
Sent: 31 May 2004 02:09
To: spr...@li...
Subject: Re: [Springframework-developer] re: OracleLobCreator

Bronwen,

In order to pinpoint the problem quicker - what version of WebLogic,
Oracle and JDBC drivers are you using?

Thomas

Bronwen Cassidy wrote:

> Hi I have a CLOB column in oracle and in the test there are no
> problems, unfortunately deploying to weblogic I get the exception
> below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I
> firstly replaced weblogics jars and classpath settings to use the
> classes12.jar, but got the same error, so I pulled weblogic oracle jar
> into my test classpath to test if the problem was with the jars but
> the test worked fine ?? I am really stuck as to whom this should go to
> weblogic, oracle, or . I am hoping there is an expert there who can
> shed some light. Google did not have a single match for variations of
> the first 2 lines!!
>
> java.lang.ClassCastException
>
> at
>
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.jav=
a:5
090)
>
> at
>
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnec=
tio
n.java:5141)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39
)
>
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl
.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:324)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.pr=
epa
reLob(OracleLobHandler.java:375)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.cr=
eat
eLob(OracleLobHandler.java:327)
>
> at
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.se=
tCl
obAsString(OracleLobHandler.java:255)
>
> thank-you for any help
>
> Bronwen
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Spring Portlet MVC layer is rendering JSTL Views!!!

[Maxim P. <MPe...@in...>]

Hello,William 

I did deploy on uPortal server as you say but receive the following exception:
org.jasig.portal.PortalException: Unable to find portlet definition for 
ID 'springportlet.ExampleSpringPortlet'
	at org.jasig.portal.channels.portlet.CPortletAdapter.initPortletWindow
(CPortletAdapter.java:194)
	at org.jasig.portal.channels.portlet.CPortletAdapter.renderCharacters
(CPortletAdapter.java:429)
	at 
org.jasig.portal.MultithreadedCharacterChannelAdapter.renderCharacters
(MultithreadedCharacterChannelAdapter.java:71)
	at org.jasig.portal.ChannelRenderer$Worker.run(ChannelRenderer.java:481)
	at org.jasig.portal.utils.threading.Worker.run(Worker.java:88)

I don't see any portlet definitions in webapps/uPortal dir...

What I did wrong?

Thank you,
Maxim

[Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Maxim P. <MPe...@in...>]

Hello,William 

I did deploy on uPortal server as you say but receive the following exception:
org.jasig.portal.PortalException: Unable to find portlet definition for 
ID 'springportlet.ExampleSpringPortlet'
	at org.jasig.portal.channels.portlet.CPortletAdapter.initPortletWindow
(CPortletAdapter.java:194)
	at org.jasig.portal.channels.portlet.CPortletAdapter.renderCharacters
(CPortletAdapter.java:429)
	at 
org.jasig.portal.MultithreadedCharacterChannelAdapter.renderCharacters
(MultithreadedCharacterChannelAdapter.java:71)
	at org.jasig.portal.ChannelRenderer$Worker.run(ChannelRenderer.java:481)
	at org.jasig.portal.utils.threading.Worker.run(Worker.java:88)

I don't see any portlet definitions in webapps/uPortal dir...

What I did wrong?

Thank you,
Maxim

Re: [Springframework-developer] re: OracleLobCreator

[Thomas R. <tho...@tr...>]

That's close to what I have available here.  I'm using the 9.2.0.3 
ojdbc14.jar driver though.  You might want to try downloading the latest 
driver from Oracle's OTN site and see if that makes any difference.  If 
that does not help, could you email me a small testcase that I could try 
here.  My email is "trisberg [at] tridb.com"

Thomas


Bronwen Cassidy wrote:

>Hi I have:
>
>Weblogic 8 service pack 2 
>ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers) 
>Oracle9i 
>I have set up the connection pool using the jdbc:oracle:thin (oracle thin
>drivers (not weblogic ones)  
>
>Actually I managed to find some information (very little) one from a
>hibernate mail, suggested using the getPhysicalConnection() instead of
>createTemporary, but this method does not seem to available on the CLOB
>class?? 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Thomas Risberg
>Sent: 31 May 2004 02:09
>To: spr...@li...
>Subject: Re: [Springframework-developer] re: OracleLobCreator
>
>Bronwen,
>
>In order to pinpoint the problem quicker - what version of WebLogic, 
>Oracle and JDBC drivers are you using?
>
>Thomas
>
>Bronwen Cassidy wrote:
>
>  
>
>>Hi I have a CLOB column in oracle and in the test there are no 
>>problems, unfortunately deploying to weblogic I get the exception 
>>below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I 
>>firstly replaced weblogics jars and classpath settings to use the 
>>classes12.jar, but got the same error, so I pulled weblogic oracle jar 
>>into my test classpath to test if the problem was with the jars but 
>>the test worked fine ?? I am really stuck as to whom this should go to 
>>weblogic, oracle, or . I am hoping there is an expert there who can 
>>shed some light. Google did not have a single match for variations of 
>>the first 2 lines!!
>>
>>java.lang.ClassCastException
>>
>>at 
>>
>>    
>>
>oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
>090)
>  
>
>>at 
>>
>>    
>>
>oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnectio
>n.java:5141)
>  
>
>>at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>>
>>at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>>
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>>at 
>>
>>    
>>
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
>)
>  
>
>>at 
>>
>>    
>>
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
>.java:25)
>  
>
>>at java.lang.reflect.Method.invoke(Method.java:324)
>>
>>at 
>>
>>    
>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepa
>reLob(OracleLobHandler.java:375)
>  
>
>>at 
>>
>>    
>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.creat
>eLob(OracleLobHandler.java:327)
>  
>
>>at 
>>
>>    
>>
>org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setCl
>obAsString(OracleLobHandler.java:255)
>  
>
>>thank-you for any help
>>
>>Bronwen
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

RE: [Springframework-developer] re: OracleLobCreator

[Bronwen C. <bro...@ya...>]

Hi I have:

Weblogic 8 service pack 2 
ojdbc.jar (Oracle9i 9.2.0.1 JDBC Drivers) 
Oracle9i 
I have set up the connection pool using the jdbc:oracle:thin (oracle thin
drivers (not weblogic ones)  

Actually I managed to find some information (very little) one from a
hibernate mail, suggested using the getPhysicalConnection() instead of
createTemporary, but this method does not seem to available on the CLOB
class?? 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: 31 May 2004 02:09
To: spr...@li...
Subject: Re: [Springframework-developer] re: OracleLobCreator

Bronwen,

In order to pinpoint the problem quicker - what version of WebLogic, 
Oracle and JDBC drivers are you using?

Thomas

Bronwen Cassidy wrote:

> Hi I have a CLOB column in oracle and in the test there are no 
> problems, unfortunately deploying to weblogic I get the exception 
> below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I 
> firstly replaced weblogics jars and classpath settings to use the 
> classes12.jar, but got the same error, so I pulled weblogic oracle jar 
> into my test classpath to test if the problem was with the jars but 
> the test worked fine ?? I am really stuck as to whom this should go to 
> weblogic, oracle, or . I am hoping there is an expert there who can 
> shed some light. Google did not have a single match for variations of 
> the first 2 lines!!
>
> java.lang.ClassCastException
>
> at 
>
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
090)
>
> at 
>
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnectio
n.java:5141)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at 
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
>
> at 
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:324)
>
> at 
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepa
reLob(OracleLobHandler.java:375)
>
> at 
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.creat
eLob(OracleLobHandler.java:327)
>
> at 
>
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setCl
obAsString(OracleLobHandler.java:255)
>
> thank-you for any help
>
> Bronwen
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] re: OracleLobCreator

[Thomas R. <tho...@tr...>]

Bronwen,

In order to pinpoint the problem quicker - what version of WebLogic, 
Oracle and JDBC drivers are you using?

Thomas

Bronwen Cassidy wrote:

> Hi I have a CLOB column in oracle and in the test there are no 
> problems, unfortunately deploying to weblogic I get the exception 
> below. We are using classes12.jar whereas weblogic uses ojdbc14.jar, I 
> firstly replaced weblogics jars and classpath settings to use the 
> classes12.jar, but got the same error, so I pulled weblogic oracle jar 
> into my test classpath to test if the problem was with the jars but 
> the test worked fine ?? I am really stuck as to whom this should go to 
> weblogic, oracle, or … I am hoping there is an expert there who can 
> shed some light. Google did not have a single match for variations of 
> the first 2 lines!!
>
> java.lang.ClassCastException
>
> at 
> oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5090)
>
> at 
> oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnection.java:5141)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:1009)
>
> at oracle.sql.CLOB.createTemporary(CLOB.java:956)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:324)
>
> at 
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepareLob(OracleLobHandler.java:375)
>
> at 
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.createLob(OracleLobHandler.java:327)
>
> at 
> org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setClobAsString(OracleLobHandler.java:255)
>
> thank-you for any help
>
> Bronwen
>

[Springframework-developer] re: OracleLobCreator

[Bronwen C. <bro...@ya...>]

Hi I have a CLOB column in oracle and in the test there are no problems,
unfortunately deploying to weblogic I get the exception below. We are using
classes12.jar whereas weblogic uses ojdbc14.jar, I firstly replaced
weblogics jars and classpath settings to use the classes12.jar, but got the
same error, so I pulled weblogic oracle jar into my test classpath to test
if the problem was with the jars but the test worked fine ?? I am really
stuck as to whom this should go to weblogic, oracle, or . I am hoping there
is an expert there who can shed some light. Google did not have a single
match for variations of the first 2 lines!!

 

java.lang.ClassCastException

        at
oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5
090)

        at
oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnectio
n.java:5141)

        at oracle.sql.CLOB.createTemporary(CLOB.java:1009)

        at oracle.sql.CLOB.createTemporary(CLOB.java:956)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

        at java.lang.reflect.Method.invoke(Method.java:324)

        at
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.prepa
reLob(OracleLobHandler.java:375)

        at
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.creat
eLob(OracleLobHandler.java:327)

        at
org.springframework.jdbc.support.lob.OracleLobHandler$OracleLobCreator.setCl
obAsString(OracleLobHandler.java:255)

 

thank-you for any help

 

Bronwen

Re: [Springframework-developer] Cleanup of context resources on webapp reload

[Guillaume P. <gpo...@gl...>]

Juergen,

I think that Introspector.flushCaches() on a ServletContextListener it still
the lesser of evils for that memory leak, the effect on other webapps would
not be that bad anyway, just slow a little bit the next few calls to
Introspector.getBeanInfo().  However, I agree with you that this should
probably be dealt with by the application rather than Spring.  But may be it
could be an option with Spring's ContextLoaderListener (probably off by
default)?

Concerning your solution with CachedIntrospectionResults, I would have a
sugestion for performance.  For the majority of the use cases,
CachedIntrospectionResults would be in the same ClassLoader as the target
class.  So I would suggest to first check the ClassLoader to know if it's
safe to cache the class without WeakReference.  I've attached a patch to the
E-Mail if you would like to include my suggestion.

Thanks,
Guillaume

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, May 30, 2004 11:09 AM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I'm using a profiler, explicitly running garbage collection after
application shutdown and then seeing what remains on the heap. It's actually
my first really instance profiler work for about two years; haven't had any
need for it in the meantime.

Anyway, I did some further tests today, changing SQLErrorCodesFactory and
GlobalAdvisorAdapterRegistry to classic singletons again, with an
Introspector.flushCaches call on shutdown. While this didn't have any effect
with Petclinic, it did result in proper cleanup with Image Database.

So the Introspector.flushCaches call *does* have some effect, contrary to my
assumption from yesterday, but not in all scenarios. After some further
tests, I found out that Hibernate (-> Petclinic) has its own leaks, thus
keeps the web app class loader around, thus no cleanup of Spring's
singletons in that class loader. If Hibernate isn't used, everything gets
cleaned up properly.

This means that you're perfectly right: Coding singletons with
WeakReferences only cleans up that particular singleton object but of course
doesn't do anything about the class loader itself with its remaining leaks.
As the code *is* uglier with WeakReferences, I've permanently changed
SQLErrorCodesFactory and GlobalAdvisorAdapterRegistry back to classic
singletons (like they were until a week ago).

I'd like to leave CachedIntrospectionResults as-is with a WeakHashMap and
WeakReferences, as this holds references to classes and might reside in a
parent classloader of the referenced classes. That's how the JDK's
Introspector class should be coded too...

The remaining issue is: Where to invoke Introspector.flushCaches? Every
ApplicationContext shutdown? How to avoid cleaning all BeanInfos *of the
entire VM*, when all we want to do is clean up all BeanInfos of the current
app?
Sure, a general flushCaches call cleans up all BeanInfo leaks of the app
too, be it from Spring or Quartz or whatever, but all we want to provide
out-of-the-box is proper cleanup of Spring itself.

So my solution for Spring is simple: CachedIntrospectionResults flushes the
Introspector cache for the given class (and its superclasses) right after it
fetched the BeanInfo for it (i.e. right after it's been cached). As we cache
the introspection results ourselves anyway, we wouldn't benefit from the
Introspector cache in the first place. That shouldn't have any negative
impact on performance.

I did quite a lot of tests with this new strategy, and everything gets
cleaned up nicely within Spring. Just if you add Hibernate or Quartz to the
mix, you'll get leaks from them that prevent the class loader from getting
garbage collected. With Quartz, a general flushCaches call helps; with
Hibernate, even that doesn't.

So in certain scenarios, it might help to add a custom
ServletContextListener that does an Introspector.flushCaches call on
shutdown - but for Spring itself, this isn't necessary, as the beans
infrastructure does not cause any leaks anymore. I'm happy with the current
solution: classic singletons as before, just a flushFromCaches call for each
introspected class right when building the CachedIntrospectionResults
object.

We should probably tell the Quartz guys to apply specific flushFromCaches
calls after their Introspector usage. I've also noticed that JDOM, as used
within iBATIS SQL Maps 1.3, has a resource leak too. I haven't researched
where the Hibernate leaks come from in detail, but the root of the problem
seems to be CGLIB there.

Many thanks for pointing this out! :-)

Juergen


________________________________

Von: spr...@li... im Auftrag von
Guillaume Poirier
Gesendet: So 30.05.2004 07:01
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Juergen, I'm curious about how exactly you assert what is leaking, what is
not, and exactly what is it better with WeakReference?  Are you using a
profiler that tells you the non-garbage collected objects in the JVM or do
you use other means?

Concerning SQLErrorCodesFactory, while the class' constructor does cause a
leak (indirectly by the use of XmlBeanFactory), it is not itself the leak,
it's the class instance of SQLErrorCodes that prevent the ClassLoader's
collection.  I did a test calling
SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
ClassLoader, and it caused a leak when the ClassLoader is thrown away.  Then
I tried to create my own SQLErrorCodesFactory implementation, and it kept
leaking until I stopped using the XmlBeanFactory to create the instances of
SQLErrorCodes.  Then I tried to just use an Introspector directly to set the
properties on the SQLErrorCodes instances by reflection, and it leaked just
as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
Introspector has an hard reference on SQLErrorCodes.class, then none of the
class loaded by its ClassLoader can be collected.  So it would be the cause
of SQLErrorCodesFactory singleton to be kept alive, not because
SQLFactoryErrorCodes has an hard reference on it, but because the
ClassLoader does, and SQLErrorCodes.class has an hard reference on the
ClassLoader, and the Introspector has an hard reference on
SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is really
kept alive because Introspector has an hard reference on the class instance
of SQLErrorCodes.

I might misunderstand the situation, but as I see it, you're working on the
symptom rather than the cause.  If you allow the singleton to be garbage
collected when the class itself is retained, then you might save some
memory, but it's just like adding memory to the JVM to solve a leak, it will
only delay the OutOfMemoryError, it won't prevent it.  However, if you allow
the ClassLoader to be collected by removing any hard reference to its
classes, that would prevent the leak to even take place at all.

That's why I'm curious as to why you say it's better with WeakReference on
singleton and Introspector.flushCaches() does nothing, how do you make that
assertion?  I realize that if there's something else than Introspector that
has an hard reference on a class of the ClassLoader being thown away,
flushing the Introspector's cache will have no effect on the leak, it would
still leak as fast.  But while the WeakReference on the singleton will delay
the OutOfMemoryError, does it really help that much, since anyway all the
Class definitions and static members cannot be collected?  You have to
consider that coding defensively on this might reduce performance because of
more object creation and use of synchronization, while also complicating the
code.  Is it really worth it, did your tests really showed a significant
effect on a typical application?

Guillaume


----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, May 29, 2004 2:28 PM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I've prototypically added an Introspector.flushCaches call to context
shutdown: I don't see any difference in the profiler. That's not too
surprising, as the originally leaking classes are not managed by beans
facilities in the first place: for example, SQLErrorCodesFactory, which is
just used internally by SQLErrorCodeSQLExceptionTranslator.

Of course, since my changes from a week ago, those classes don't leak
anymore, as they hold their singleton instance in a WeakReference now... I
still don't understand why this is necessary, but I'm 100% sure that it does
make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also tried
various GC configuration options - always the same effect.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I experimented some more about this cleanup issue, and I was able to narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored with
hard references since BeanInfo has an hard reference on the class it gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static members
will not ever be able to be garbage collected.  I kind of remember someone
mentioning something related to this in the mailling list, but I cannot find
the mail.  I wonder if there's other case where the java[x] classes might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much if
at all.  The only way that I can see for a class not to be gargage collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having the
class itself have an hard reference on a its own singleton has no effect,
it's a circular reference that will not prevent the class or the instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.2

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

OK, the very last time: Triggered by Guillaume's findings, there is a =
simpler solution for the garbage collection problem now, which is =
actually much closer to the original code, as the only change compared =
to the 1.0.1 codebase is in the CachedIntrospectionResults class. Less =
to worry about in terms of stability than with last week's solution...
=20
As I'm about to leave for a concert in a couple of minutes, the actual =
release will happen tomorrow. At least, it's still gonna be May, isn't =
it ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 30.05.2004 01:07
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



Done - everything's in CVS now from my point of view. Of course, tons of =
minor polishing, as usual ;-)

So, last chance to review anything. Thomas, I hope the stored procedure =
refactorings from a couple of days ago are fine as-is.

I'll take the release snapshot tomorrow early afternoon, doing my usual =
sample app tests then before uploading to SourceForge.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 28.05.2004 13:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



I plan to release 1.0.2 tomorrow morning - finally...

BTW, I'm committing a couple of minor refinements during the course of =
today. Among them is that BeanWrapperImpl registers default editors for =
Boolean and Number objects now, using Integer.valueOf/toString etc.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Fr 28.05.2004 12:47
An: spr...@li...
Betreff: RE: [Springframework-developer] Preparing for 1.0.2



Juergen, if you still need to release 1.0.2, the doco for the scheduler =
can still make it. I've inserted an issue in jira, but set the fix =
version to 1.0.3, if the doco makes it, I'll switch it to 1.0.2

Alef



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, May 27, 2004 7:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.2

Looking at it the other way round: Why not use the DataSource itself as =
key? That's what we're doing to manage transactional resources too.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of tho...@tr...
Sent: Thursday, May 27, 2004 5:38 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.2



I remember we considered it extremely unlikely that two datasources for
different database products would have the same hash value - also, the =
worst
case scenario would be a poor translation of an error.  It would not =
cause an
error.

If you feel using the actual datasource as the key is safer, then I'm OK =
with
that too.

Thomas


Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've also reworked SQLErrorCodesFactory to use the DataSource itself =
as =3D
> key of the dataSourceProductName HashMap, instead of the previous =3D
> Integer built from DataSource.hashCode. With the new SQLErrorCodes =3D
> themselves being held in a WeakReference, this shouldn't cause garbage =
=3D
> collection issues.
>
> Actually, the previous strategy wasn't entirely safe: If two different =
=3D
> DataSources had the same hashCode, they would have overwritten each =
=3D
> other in the Map, as the corresponding Integer keys would have been =
=3D
> equal. With the DataSources themselves as keys, same hashCodes would =
=3D
> just result in less efficient hash lookup but correct storage of both =
=3D
> DataSources.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of j=3DFCrgen h=3DF6ller [werk3AT]
> Sent: Thursday, May 27, 2004 11:08 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Preparing for 1.0.2
>
>
> Further minor refinements that I committed yesterday:
> =3D20
> - added IncorrectResultSizeDataAccessException to dao package
> - added DataAccessUtils class to dao.support package, providing =3D
> "uniqueResult" and "requiredUniqueResult" methods
> - refactored SqlQuery.findObject to delegate to =3D
> DataAccessUtils.uniqueResult
> =3D20
> DataAccessUtils.uniqueResult should be useful for any DAO that =
receives =3D
> a List and expects a unique result object in it, for example with =3D
> Hibernate finders, i.e. Session.find respectively =3D
> HibernateTemplate.find. The uniqueResult method throws =3D
> IncorrectResultSizeDataAccessException if the result is not actually =
=3D
> unique; that's why it is in the dao.support package.
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von j=3DFCrgen h=3DF6ller [werk3AT]
> Gesendet: Do 27.05.2004 10:33
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> Oh well, time schedules and my perfectionism...
>
> I've done some further polishing, committed yesterday morning =3D
> respectively today:
>
> - I've factored out RowMapperResultReader from SqlParameter, to make =
=3D
> RowMapper usable for plain JDBC queries too
> - JdbcTemplate.call respectively StoredProcedure supports =3D
> ResultSetExtractor as output parameter too
> - I've slightly refactored JdbcTemplate.call's implementation to allow =
=3D
> for a higher level of code reuse
>
> - AbstractAutowireCapableBeanFactory catches Throwable on bean =
creation, =3D
> rethrowing it as meaningful BeanCreationException
> - DefaultListableBeanFactory.preInstantiateSingletons cleans up =
already =3D
> created singletons if it fails
> - XmlViewResolver and ResourceBundleViewResolver clean up their view =
=3D
> bean factories on context shutdown
>
> Thomas, it would be great if you had a chance to review the JDBC =3D
> changes, and maybe run a couple of integration tests with stored =3D
> procedures - to make sure that I haven't broken anything, even if the =
=3D
> test suite passes.
>
> As there haven't been any reports on problems with the garbage =3D
> collection changes, I plan to go ahead and finalize 1.0.2 for =
tomorrow.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von j=3DFCrgen h=3DF6ller [werk3AT]
> Gesendet: Mi 26.05.2004 07:38
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> There hasn't been any change in AbstractXsltView since 1.0 final, so I =
=3D
> guess this is usual behavior...
>
> BTW, current planned release date: tonight! I know, I know - this time =
=3D
> for real, provided that there's no showstopper :-)
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von Darren Davison
> Gesendet: Mi 26.05.2004 01:40
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 26 May 2004 00:27, Darren Davison wrote:
>
> > AbstractXsltView (line 143) shown below is throwing a
> > TransformerConfigurationException.  The stylesheet is correctly =
loaded
> > and appears valid whether loaded from a servlet context resource or =
a
> > classpath resource (the 2 I tried).
>
> hmm..
>
> it seems that removing any <xsl:output> tags in the stylesheets =3D
> themselves
> makes the problem disappear.  That strikes me as a bit odd though: has
> something changed recently in XSL world?  I can't find any info on =3D
> this..
>
> Cheers,
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAs9l7KLMLAN01aw0RAgFCAJ97NbqA547fyx6rCQLiSXkCUFWreQCghOiD
> Tle6ycCFcmn5hNf2ZLZznX0=3D3D
> =3D3D4YWT
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g. =3D
>
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

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

Guillaume,
=20
I'm using a profiler, explicitly running garbage collection after =
application shutdown and then seeing what remains on the heap. It's =
actually my first really instance profiler work for about two years; =
haven't had any need for it in the meantime.
=20
Anyway, I did some further tests today, changing SQLErrorCodesFactory =
and GlobalAdvisorAdapterRegistry to classic singletons again, with an =
Introspector.flushCaches call on shutdown. While this didn't have any =
effect with Petclinic, it did result in proper cleanup with Image =
Database.
=20
So the Introspector.flushCaches call *does* have some effect, contrary =
to my assumption from yesterday, but not in all scenarios. After some =
further tests, I found out that Hibernate (-> Petclinic) has its own =
leaks, thus keeps the web app class loader around, thus no cleanup of =
Spring's singletons in that class loader. If Hibernate isn't used, =
everything gets cleaned up properly.
=20
This means that you're perfectly right: Coding singletons with =
WeakReferences only cleans up that particular singleton object but of =
course doesn't do anything about the class loader itself with its =
remaining leaks. As the code *is* uglier with WeakReferences, I've =
permanently changed SQLErrorCodesFactory and =
GlobalAdvisorAdapterRegistry back to classic singletons (like they were =
until a week ago).
=20
I'd like to leave CachedIntrospectionResults as-is with a WeakHashMap =
and WeakReferences, as this holds references to classes and might reside =
in a parent classloader of the referenced classes. That's how the JDK's =
Introspector class should be coded too...
=20
The remaining issue is: Where to invoke Introspector.flushCaches? Every =
ApplicationContext shutdown? How to avoid cleaning all BeanInfos *of the =
entire VM*, when all we want to do is clean up all BeanInfos of the =
current app?=20
Sure, a general flushCaches call cleans up all BeanInfo leaks of the app =
too, be it from Spring or Quartz or whatever, but all we want to provide =
out-of-the-box is proper cleanup of Spring itself.
=20
So my solution for Spring is simple: CachedIntrospectionResults flushes =
the Introspector cache for the given class (and its superclasses) right =
after it fetched the BeanInfo for it (i.e. right after it's been =
cached). As we cache the introspection results ourselves anyway, we =
wouldn't benefit from the Introspector cache in the first place. That =
shouldn't have any negative impact on performance.
=20
I did quite a lot of tests with this new strategy, and everything gets =
cleaned up nicely within Spring. Just if you add Hibernate or Quartz to =
the mix, you'll get leaks from them that prevent the class loader from =
getting garbage collected. With Quartz, a general flushCaches call =
helps; with Hibernate, even that doesn't.
=20
So in certain scenarios, it might help to add a custom =
ServletContextListener that does an Introspector.flushCaches call on =
shutdown - but for Spring itself, this isn't necessary, as the beans =
infrastructure does not cause any leaks anymore. I'm happy with the =
current solution: classic singletons as before, just a flushFromCaches =
call for each introspected class right when building the =
CachedIntrospectionResults object.
=20
We should probably tell the Quartz guys to apply specific =
flushFromCaches calls after their Introspector usage. I've also noticed =
that JDOM, as used within iBATIS SQL Maps 1.3, has a resource leak too. =
I haven't researched where the Hibernate leaks come from in detail, but =
the root of the problem seems to be CGLIB there.
=20
Many thanks for pointing this out! :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Guillaume Poirier
Gesendet: So 30.05.2004 07:01
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Juergen, I'm curious about how exactly you assert what is leaking, what =
is
not, and exactly what is it better with WeakReference?  Are you using a
profiler that tells you the non-garbage collected objects in the JVM or =
do
you use other means?

Concerning SQLErrorCodesFactory, while the class' constructor does cause =
a
leak (indirectly by the use of XmlBeanFactory), it is not itself the =
leak,
it's the class instance of SQLErrorCodes that prevent the ClassLoader's
collection.  I did a test calling
SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
ClassLoader, and it caused a leak when the ClassLoader is thrown away.  =
Then
I tried to create my own SQLErrorCodesFactory implementation, and it =
kept
leaking until I stopped using the XmlBeanFactory to create the instances =
of
SQLErrorCodes.  Then I tried to just use an Introspector directly to set =
the
properties on the SQLErrorCodes instances by reflection, and it leaked =
just
as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
Introspector has an hard reference on SQLErrorCodes.class, then none of =
the
class loaded by its ClassLoader can be collected.  So it would be the =
cause
of SQLErrorCodesFactory singleton to be kept alive, not because
SQLFactoryErrorCodes has an hard reference on it, but because the
ClassLoader does, and SQLErrorCodes.class has an hard reference on the
ClassLoader, and the Introspector has an hard reference on
SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is =
really
kept alive because Introspector has an hard reference on the class =
instance
of SQLErrorCodes.

I might misunderstand the situation, but as I see it, you're working on =
the
symptom rather than the cause.  If you allow the singleton to be garbage
collected when the class itself is retained, then you might save some
memory, but it's just like adding memory to the JVM to solve a leak, it =
will
only delay the OutOfMemoryError, it won't prevent it.  However, if you =
allow
the ClassLoader to be collected by removing any hard reference to its
classes, that would prevent the leak to even take place at all.

That's why I'm curious as to why you say it's better with WeakReference =
on
singleton and Introspector.flushCaches() does nothing, how do you make =
that
assertion?  I realize that if there's something else than Introspector =
that
has an hard reference on a class of the ClassLoader being thown away,
flushing the Introspector's cache will have no effect on the leak, it =
would
still leak as fast.  But while the WeakReference on the singleton will =
delay
the OutOfMemoryError, does it really help that much, since anyway all =
the
Class definitions and static members cannot be collected?  You have to
consider that coding defensively on this might reduce performance =
because of
more object creation and use of synchronization, while also complicating =
the
code.  Is it really worth it, did your tests really showed a significant
effect on a typical application?

Guillaume


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, May 29, 2004 2:28 PM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I've prototypically added an Introspector.flushCaches call to context
shutdown: I don't see any difference in the profiler. That's not too
surprising, as the originally leaking classes are not managed by beans
facilities in the first place: for example, SQLErrorCodesFactory, which =
is
just used internally by SQLErrorCodeSQLExceptionTranslator.

Of course, since my changes from a week ago, those classes don't leak
anymore, as they hold their singleton instance in a WeakReference now... =
I
still don't understand why this is necessary, but I'm 100% sure that it =
does
make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also =
tried
various GC configuration options - always the same effect.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I experimented some more about this cleanup issue, and I was able to =
narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored =
with
hard references since BeanInfo has an hard reference on the class it =
gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static =
members
will not ever be able to be garbage collected.  I kind of remember =
someone
mentioning something related to this in the mailling list, but I cannot =
find
the mail.  I wonder if there's other case where the java[x] classes =
might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much =
if
at all.  The only way that I can see for a class not to be gargage =
collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having =
the
class itself have an hard reference on a its own singleton has no =
effect,
it's a circular reference that will not prevent the class or the =
instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

[Guillaume P. <gpo...@gl...>]

Juergen, I'm curious about how exactly you assert what is leaking, what is
not, and exactly what is it better with WeakReference?  Are you using a
profiler that tells you the non-garbage collected objects in the JVM or do
you use other means?

Concerning SQLErrorCodesFactory, while the class' constructor does cause a
leak (indirectly by the use of XmlBeanFactory), it is not itself the leak,
it's the class instance of SQLErrorCodes that prevent the ClassLoader's
collection.  I did a test calling
SQLErrorCodesFactory.getInstance().getErrorCodes("DB2") in a child
ClassLoader, and it caused a leak when the ClassLoader is thrown away.  Then
I tried to create my own SQLErrorCodesFactory implementation, and it kept
leaking until I stopped using the XmlBeanFactory to create the instances of
SQLErrorCodes.  Then I tried to just use an Introspector directly to set the
properties on the SQLErrorCodes instances by reflection, and it leaked just
as the SQLErrorCodesFactory. You have to keep in mind that if e.g.
Introspector has an hard reference on SQLErrorCodes.class, then none of the
class loaded by its ClassLoader can be collected.  So it would be the cause
of SQLErrorCodesFactory singleton to be kept alive, not because
SQLFactoryErrorCodes has an hard reference on it, but because the
ClassLoader does, and SQLErrorCodes.class has an hard reference on the
ClassLoader, and the Introspector has an hard reference on
SQLErrorCodes.class.  So the singleton of SQLFactoryCodesFactory is really
kept alive because Introspector has an hard reference on the class instance
of SQLErrorCodes.

I might misunderstand the situation, but as I see it, you're working on the
symptom rather than the cause.  If you allow the singleton to be garbage
collected when the class itself is retained, then you might save some
memory, but it's just like adding memory to the JVM to solve a leak, it will
only delay the OutOfMemoryError, it won't prevent it.  However, if you allow
the ClassLoader to be collected by removing any hard reference to its
classes, that would prevent the leak to even take place at all.

That's why I'm curious as to why you say it's better with WeakReference on
singleton and Introspector.flushCaches() does nothing, how do you make that
assertion?  I realize that if there's something else than Introspector that
has an hard reference on a class of the ClassLoader being thown away,
flushing the Introspector's cache will have no effect on the leak, it would
still leak as fast.  But while the WeakReference on the singleton will delay
the OutOfMemoryError, does it really help that much, since anyway all the
Class definitions and static members cannot be collected?  You have to
consider that coding defensively on this might reduce performance because of
more object creation and use of synchronization, while also complicating the
code.  Is it really worth it, did your tests really showed a significant
effect on a typical application?

Guillaume


----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, May 29, 2004 2:28 PM
Subject: Re: [Springframework-developer] Cleanup of context resources on
webapp reload


Guillaume,

I've prototypically added an Introspector.flushCaches call to context
shutdown: I don't see any difference in the profiler. That's not too
surprising, as the originally leaking classes are not managed by beans
facilities in the first place: for example, SQLErrorCodesFactory, which is
just used internally by SQLErrorCodeSQLExceptionTranslator.

Of course, since my changes from a week ago, those classes don't leak
anymore, as they hold their singleton instance in a WeakReference now... I
still don't understand why this is necessary, but I'm 100% sure that it does
make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've also tried
various GC configuration options - always the same effect.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I experimented some more about this cleanup issue, and I was able to narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored with
hard references since BeanInfo has an hard reference on the class it gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static members
will not ever be able to be garbage collected.  I kind of remember someone
mentioning something related to this in the mailling list, but I cannot find
the mail.  I wonder if there's other case where the java[x] classes might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much if
at all.  The only way that I can see for a class not to be gargage collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having the
class itself have an hard reference on a its own singleton has no effect,
it's a circular reference that will not prevent the class or the instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Spring / Mule integration - step 1

[Ben A. <ben...@ac...>]

Hi Keith

> If you would, let me know when you begin your journey 
> developing a Swing GUI built on top of Spring.  As the 
> developer for Spring's in-development rich client support 
> (which is built directly on Swing), I'd love to be able to 
> combine what we've done so far and our future plans with your 
> expertise and the ideas you have in mind.

I just joined the mailing list. I'm presenting checking out the project from
CVS and look forward to participating.

Best regards
Ben

Re: [Springframework-developer] Preparing for 1.0.2

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

Done - everything's in CVS now from my point of view. Of course, tons of =
minor polishing, as usual ;-)
=20
So, last chance to review anything. Thomas, I hope the stored procedure =
refactorings from a couple of days ago are fine as-is.
=20
I'll take the release snapshot tomorrow early afternoon, doing my usual =
sample app tests then before uploading to SourceForge.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 28.05.2004 13:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



I plan to release 1.0.2 tomorrow morning - finally...

BTW, I'm committing a couple of minor refinements during the course of =
today. Among them is that BeanWrapperImpl registers default editors for =
Boolean and Number objects now, using Integer.valueOf/toString etc.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Fr 28.05.2004 12:47
An: spr...@li...
Betreff: RE: [Springframework-developer] Preparing for 1.0.2



Juergen, if you still need to release 1.0.2, the doco for the scheduler =
can still make it. I've inserted an issue in jira, but set the fix =
version to 1.0.3, if the doco makes it, I'll switch it to 1.0.2

Alef



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, May 27, 2004 7:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.2

Looking at it the other way round: Why not use the DataSource itself as =
key? That's what we're doing to manage transactional resources too.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of tho...@tr...
Sent: Thursday, May 27, 2004 5:38 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.2



I remember we considered it extremely unlikely that two datasources for
different database products would have the same hash value - also, the =
worst
case scenario would be a poor translation of an error.  It would not =
cause an
error.

If you feel using the actual datasource as the key is safer, then I'm OK =
with
that too.

Thomas


Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've also reworked SQLErrorCodesFactory to use the DataSource itself =
as =3D
> key of the dataSourceProductName HashMap, instead of the previous =3D
> Integer built from DataSource.hashCode. With the new SQLErrorCodes =3D
> themselves being held in a WeakReference, this shouldn't cause garbage =
=3D
> collection issues.
>
> Actually, the previous strategy wasn't entirely safe: If two different =
=3D
> DataSources had the same hashCode, they would have overwritten each =
=3D
> other in the Map, as the corresponding Integer keys would have been =
=3D
> equal. With the DataSources themselves as keys, same hashCodes would =
=3D
> just result in less efficient hash lookup but correct storage of both =
=3D
> DataSources.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of j=3DFCrgen h=3DF6ller [werk3AT]
> Sent: Thursday, May 27, 2004 11:08 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Preparing for 1.0.2
>
>
> Further minor refinements that I committed yesterday:
> =3D20
> - added IncorrectResultSizeDataAccessException to dao package
> - added DataAccessUtils class to dao.support package, providing =3D
> "uniqueResult" and "requiredUniqueResult" methods
> - refactored SqlQuery.findObject to delegate to =3D
> DataAccessUtils.uniqueResult
> =3D20
> DataAccessUtils.uniqueResult should be useful for any DAO that =
receives =3D
> a List and expects a unique result object in it, for example with =3D
> Hibernate finders, i.e. Session.find respectively =3D
> HibernateTemplate.find. The uniqueResult method throws =3D
> IncorrectResultSizeDataAccessException if the result is not actually =
=3D
> unique; that's why it is in the dao.support package.
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von j=3DFCrgen h=3DF6ller [werk3AT]
> Gesendet: Do 27.05.2004 10:33
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> Oh well, time schedules and my perfectionism...
>
> I've done some further polishing, committed yesterday morning =3D
> respectively today:
>
> - I've factored out RowMapperResultReader from SqlParameter, to make =
=3D
> RowMapper usable for plain JDBC queries too
> - JdbcTemplate.call respectively StoredProcedure supports =3D
> ResultSetExtractor as output parameter too
> - I've slightly refactored JdbcTemplate.call's implementation to allow =
=3D
> for a higher level of code reuse
>
> - AbstractAutowireCapableBeanFactory catches Throwable on bean =
creation, =3D
> rethrowing it as meaningful BeanCreationException
> - DefaultListableBeanFactory.preInstantiateSingletons cleans up =
already =3D
> created singletons if it fails
> - XmlViewResolver and ResourceBundleViewResolver clean up their view =
=3D
> bean factories on context shutdown
>
> Thomas, it would be great if you had a chance to review the JDBC =3D
> changes, and maybe run a couple of integration tests with stored =3D
> procedures - to make sure that I haven't broken anything, even if the =
=3D
> test suite passes.
>
> As there haven't been any reports on problems with the garbage =3D
> collection changes, I plan to go ahead and finalize 1.0.2 for =
tomorrow.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von j=3DFCrgen h=3DF6ller [werk3AT]
> Gesendet: Mi 26.05.2004 07:38
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> There hasn't been any change in AbstractXsltView since 1.0 final, so I =
=3D
> guess this is usual behavior...
>
> BTW, current planned release date: tonight! I know, I know - this time =
=3D
> for real, provided that there's no showstopper :-)
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von Darren Davison
> Gesendet: Mi 26.05.2004 01:40
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 26 May 2004 00:27, Darren Davison wrote:
>
> > AbstractXsltView (line 143) shown below is throwing a
> > TransformerConfigurationException.  The stylesheet is correctly =
loaded
> > and appears valid whether loaded from a servlet context resource or =
a
> > classpath resource (the 2 I tried).
>
> hmm..
>
> it seems that removing any <xsl:output> tags in the stylesheets =3D
> themselves
> makes the problem disappear.  That strikes me as a bit odd though: has
> something changed recently in XSL world?  I can't find any info on =3D
> this..
>
> Cheers,
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAs9l7KLMLAN01aw0RAgFCAJ97NbqA547fyx6rCQLiSXkCUFWreQCghOiD
> Tle6ycCFcmn5hNf2ZLZznX0=3D3D
> =3D3D4YWT
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g. =3D
>
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=3D8166&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer