springframework-developer — Spring Framework developers list

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

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

Here is a good read about Reference API: http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-java101.html

Dmitriy.

jürgen höller [werk3AT] wrote:

> Just finished tests on Resin 2.1.11 - exactly same behavior as with Tomcat. This *is* a general class loader respectively garbage collection issue, rather than a server-specific leak.
>  
> Consequently, with the changes I've committed yesterday, there is the same significant benefit as with Tomcat. The only remaining issue are the "full object" constants like ClassFilter.TRUE.
>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
> Gesendet: Mo 24.05.2004 09:20
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with both.
> 
> BTW, a couple of related posts from the Resin mailing list:
> 
> http://www.caucho.com/support/resin-interest/0404/0117.html
> http://www.caucho.com/support/resin-interest/0111/0164.html <http://www.caucho.com/support/resin-interest/0111/0164.html>
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
> Gesendet: Mo 24.05.2004 08:42
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> I've told JProfiler to explicitly run garbage collection - a number of times, actually - before I've had a look at the heap. So I'm sure that those remaining objects were not garbage-collected, and probably would have stayed around in the VM forever...
> 
> I'm aware that it seems odd, but this issue just seems to affect specific static fields: BeanWrapperImpl's defaultEditors did not cause a leak, but CachedIntrospectionResults' classCache did. Normal constants or static logger fields didn't, but "full object" constants like ClassFilters.TRUE did.
> 
> CachedIntrospectionResults' classCache uses the Class as key; the value, a CachedIntrospectionResult object, also refers to the key Class. Consequently, I had to use a WeakHashMap *with WeakReferences as values* to see proper garbage collection. Note that this static cache contains instances of its containing class as values.
> 
> I've run all my tests x times to make sure that I could trust my eyes. I've even undone the WeakReference changes again, and voila, there were the leaks again. I'd be happy to learn more about how the garbage collector works here... All I can state at this point of time is that the changes did cause an obvious difference in terms of resource leaks.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Guillaume Poirier
> Gesendet: Mo 24.05.2004 05:17
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> The "resource leak" caused by a singleton when a webapp's classloader is
> thrown away is only temorary, the unused classes and the classloader will be
> eventually garbage collected and the resources will be freed.  The only
> thing that could prevent that is if there was a something in the server's
> classloader that still had a reference on an object or a class of the child
> classloader.
> 
> Unless there's a bug in Tomcat or in the application code, I really can't
> see how the classes won't be eventually garbage collected when the JVM needs
> memory.  And anyway, if there was indeed a leak because SQLErrorCodesFactory
> is a singleton, why wouldn't there be one for each static fields such as
> constants?
> 
> Are you sure that JProfiler does not disable garbage collecting in order to
> make its profiling?  I know that in many of the JVMPI method calls are done
> with garbage collecting off.  I suspect the above to be the cause of the
> "resource leak", rather than any singleton that Spring might be using.
> 
> Guillaume
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Sunday, May 23, 2004 4:45 PM
> Subject: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> I've just spent about 10 hours profiling Spring, using the Image Database
> and Petclinic samples. (BTW, I've used an evaluation version of JProfiler
> from ej-technologies - nice product!)
> 
> Although I still don't completely understand the garbage collection
> behavior, I've figured out the following issues. Each of them simply
> prevents the respective classes from getting garbage collected on
> destruction of the class loader (e.g. on Tomcat web app shutdown).
> 
> - A classic singleton with a class variable holding the object. I've
> reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the
> respective singleton as a WeakReference.
> 
> - A static cache. I've reworked CachedIntrospectionResults to use a
> WeakHashMap with WeakReferences as values.
> 
> - A ThreadLocal with a default other than null. I've reworked
> TransactionSynchronizationManager to use null as default for the resource
> map, setting a HashMap there on demand, removing the entire HashMap when
> unbinding the last resource.
> 
> - Constants that define a full object. We have a number of those, for
> example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried
> for quite a while, but I haven't been able to figure out a way to define
> such constants such that they will be garbage collected.
> 
> The latter programming style is not uncommon, so I really don't understand
> why it causes trouble with garbage collection. Hibernate uses a similar
> style for its FlushMode, for example.
> 
> In general, other frameworks like CGLIB, Hibernate, Velocity have huge
> resource leaks on web app shutdown, while just the constants issue remains
> with Spring now. As long as those huge third-party leaks are not addressed,
> I'm not worried at all by the single remaining Spring issue.
> 
> As I initially said, we shouldn't exaggerate the problem, as it basically
> just affects hot reloading of web apps - mainly a development feature
> anyway. We need to make that clear to users too, to avoid comments a la
> "Spring is not usable for real apps because it leaks on hot redeployment".
> 
> Please, everybody, give the current CVS head a sanity check tomorrow. There
> shouldn't be any issues: the test suite passes, the sample apps run
> properly. Still, I'd feel more comfortable if we make sure that no subtle
> side effects have been introduced.
> 
> For this reason, I will delay release 1.0.2 till tomorrow night.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> jürgen höller [werk3AT]
> Gesendet: Sa 22.05.2004 15:52
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> So basically, all static caches cause resource leaks when restarting a
> Tomcat web app? I wonder why this happens... The class loader should
> completely dissolve all classes that it has loaded in its lifetime,
> including static caches. Or have I misunderstood something here? Anyone
> having in-detail experience with handling such a scenario?
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> Dmitriy Kopylenko
> Gesendet: Di 04.05.2004 18:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> Well,
> 
> for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
> caches SQLErrorCodes internally in the Map with strong references. Again, I
> don't know if trying
> to use WeakHashMap there would do the trick...
> 
> Dmitriy
> 
> Tim Kettering wrote:
> 
> 
>>I looked at it some more this morning, and basically what I did was
>>start up tomcat w/ the webapp in the profiler, then after it was done
>>starting up I used tomcat's manager to stop the context.  This should
>>destroy all resources related to the context.   Here is a list of
>>spring related stuff that still were in memory after the context was
>>closed.  Other stuff was cleaned up just fine.
>>
>>org.springframework.beans.CachedIntrospectionResults
>>org.springframework.jdbc.support.SQLCodes
>>org.springframework.core.Constants
>>org.springframework.aop.framework.AdvisedSupport$1
>>org.springframework.aop.framework.adapter.BeforeAdviceAdapter
>>org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
>>org.springframework.jdbc.support.SQLErrorCodesFactory
>>org.springframework.transaction.support.TransactionSynchronizationManage
>>r$1
>>org.springframework.transaction.interceptor.RollbackRuleAttribute
>>org.springframework.aop.framework.adapter.ThrosAdviceAdapter
>>org.springframework.aop.Pointcut$1
>>org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>>
>>On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>>
>>
>>>I'm just wondering, would the use of WeakHashMap in
>>>CachedIntrospectionResults help?
>>>
>>>Dmitriy.
>>>
>>>Tim Kettering wrote:
>>>
>>>
>>>>I posted this to the users list last week and did not receive any
>>>>reply  on it, so I'm posting it again here on the developer list, in
>>>>hopes i  could get an reply from someone here.   I'm trying to
>>>>determine if its  something I should be doing myself, or if hte
>>>>spring context should be  cleaning up those resources by itself on
>>>>the .close() call.  Further  profiling shows that there are
>>>>duplicate  instances of SQLError and  hibernate proxy classes hanging
>>>>around  afterwards too.  Other objects  do get cleaned up properly.
>>>>--------
>>>>Hi everyone,
>>>>We're (meaning me) looking into some resource leaks that are
>>>>occuring   when our webapp context gets reloaded.  I found that
>>>>context.close()   needs to be called on the destroy() method of
>>>>plugin we're using,  and  it works for a good majority of the objects
>>>>we were seeing  leaked, but  there are some objects that I'm unable
>>>>to make go away.  Object in  question is the:
>>>>org.springframework.beans.CachedIntrospectionResults
>>>>Whenever I reload the context - the profiler I'm using shows that I
>>>>have essentially a duplicate group of those objects (same instance
>>>>count) as the original, and successive reloads will continue to
>>>>duplicate this.
>>>>The profiler also shows the final reference to those objects like  this:
>>>>100% - 1008 bytes - 63 alloc.
>>>>org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>>>it >
>>>>So basically I guess what I'm asking is for ideas or suggestions on
>>>>how  I could get those to clean up.  This bean doesnt show up in the
>>>>Spring  javadocs.  And looking in CVS says its a package level bean,
>>>>not for  application use, so I'm thinking that closing the context
>>>>should (in  theory) clean this up?   Thanks in advance.
>>>>-tim
>>>>-------------------------------------------------------
>>>>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_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=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_id149&alloc_id66&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_id66&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_id149&alloc_id66&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_id149&alloc_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

Juergen,

I'm just wondering - did you try to play with different GC algorithms (through command line switches in the container's bootstrap script, I guess)while doing the 
profiling, i.e. -XX:+UseParNewGC, -XX:+UseParallelGC,  -Xincgc, -XX:+UseConMarkSweepGC ?

Dmitriy.


jürgen höller [werk3AT] wrote:
> Just finished tests on Resin 2.1.11 - exactly same behavior as with Tomcat. This *is* a general class loader respectively garbage collection issue, rather than a server-specific leak.
>  
> Consequently, with the changes I've committed yesterday, there is the same significant benefit as with Tomcat. The only remaining issue are the "full object" constants like ClassFilter.TRUE.
>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
> Gesendet: Mo 24.05.2004 09:20
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with both.
> 
> BTW, a couple of related posts from the Resin mailing list:
> 
> http://www.caucho.com/support/resin-interest/0404/0117.html
> http://www.caucho.com/support/resin-interest/0111/0164.html <http://www.caucho.com/support/resin-interest/0111/0164.html>
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
> Gesendet: Mo 24.05.2004 08:42
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> I've told JProfiler to explicitly run garbage collection - a number of times, actually - before I've had a look at the heap. So I'm sure that those remaining objects were not garbage-collected, and probably would have stayed around in the VM forever...
> 
> I'm aware that it seems odd, but this issue just seems to affect specific static fields: BeanWrapperImpl's defaultEditors did not cause a leak, but CachedIntrospectionResults' classCache did. Normal constants or static logger fields didn't, but "full object" constants like ClassFilters.TRUE did.
> 
> CachedIntrospectionResults' classCache uses the Class as key; the value, a CachedIntrospectionResult object, also refers to the key Class. Consequently, I had to use a WeakHashMap *with WeakReferences as values* to see proper garbage collection. Note that this static cache contains instances of its containing class as values.
> 
> I've run all my tests x times to make sure that I could trust my eyes. I've even undone the WeakReference changes again, and voila, there were the leaks again. I'd be happy to learn more about how the garbage collector works here... All I can state at this point of time is that the changes did cause an obvious difference in terms of resource leaks.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Guillaume Poirier
> Gesendet: Mo 24.05.2004 05:17
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> The "resource leak" caused by a singleton when a webapp's classloader is
> thrown away is only temorary, the unused classes and the classloader will be
> eventually garbage collected and the resources will be freed.  The only
> thing that could prevent that is if there was a something in the server's
> classloader that still had a reference on an object or a class of the child
> classloader.
> 
> Unless there's a bug in Tomcat or in the application code, I really can't
> see how the classes won't be eventually garbage collected when the JVM needs
> memory.  And anyway, if there was indeed a leak because SQLErrorCodesFactory
> is a singleton, why wouldn't there be one for each static fields such as
> constants?
> 
> Are you sure that JProfiler does not disable garbage collecting in order to
> make its profiling?  I know that in many of the JVMPI method calls are done
> with garbage collecting off.  I suspect the above to be the cause of the
> "resource leak", rather than any singleton that Spring might be using.
> 
> Guillaume
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Sunday, May 23, 2004 4:45 PM
> Subject: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> I've just spent about 10 hours profiling Spring, using the Image Database
> and Petclinic samples. (BTW, I've used an evaluation version of JProfiler
> from ej-technologies - nice product!)
> 
> Although I still don't completely understand the garbage collection
> behavior, I've figured out the following issues. Each of them simply
> prevents the respective classes from getting garbage collected on
> destruction of the class loader (e.g. on Tomcat web app shutdown).
> 
> - A classic singleton with a class variable holding the object. I've
> reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the
> respective singleton as a WeakReference.
> 
> - A static cache. I've reworked CachedIntrospectionResults to use a
> WeakHashMap with WeakReferences as values.
> 
> - A ThreadLocal with a default other than null. I've reworked
> TransactionSynchronizationManager to use null as default for the resource
> map, setting a HashMap there on demand, removing the entire HashMap when
> unbinding the last resource.
> 
> - Constants that define a full object. We have a number of those, for
> example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried
> for quite a while, but I haven't been able to figure out a way to define
> such constants such that they will be garbage collected.
> 
> The latter programming style is not uncommon, so I really don't understand
> why it causes trouble with garbage collection. Hibernate uses a similar
> style for its FlushMode, for example.
> 
> In general, other frameworks like CGLIB, Hibernate, Velocity have huge
> resource leaks on web app shutdown, while just the constants issue remains
> with Spring now. As long as those huge third-party leaks are not addressed,
> I'm not worried at all by the single remaining Spring issue.
> 
> As I initially said, we shouldn't exaggerate the problem, as it basically
> just affects hot reloading of web apps - mainly a development feature
> anyway. We need to make that clear to users too, to avoid comments a la
> "Spring is not usable for real apps because it leaks on hot redeployment".
> 
> Please, everybody, give the current CVS head a sanity check tomorrow. There
> shouldn't be any issues: the test suite passes, the sample apps run
> properly. Still, I'd feel more comfortable if we make sure that no subtle
> side effects have been introduced.
> 
> For this reason, I will delay release 1.0.2 till tomorrow night.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> jürgen höller [werk3AT]
> Gesendet: Sa 22.05.2004 15:52
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> So basically, all static caches cause resource leaks when restarting a
> Tomcat web app? I wonder why this happens... The class loader should
> completely dissolve all classes that it has loaded in its lifetime,
> including static caches. Or have I misunderstood something here? Anyone
> having in-detail experience with handling such a scenario?
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> Dmitriy Kopylenko
> Gesendet: Di 04.05.2004 18:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> Well,
> 
> for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
> caches SQLErrorCodes internally in the Map with strong references. Again, I
> don't know if trying
> to use WeakHashMap there would do the trick...
> 
> Dmitriy
> 
> Tim Kettering wrote:
> 
> 
>>I looked at it some more this morning, and basically what I did was
>>start up tomcat w/ the webapp in the profiler, then after it was done
>>starting up I used tomcat's manager to stop the context.  This should
>>destroy all resources related to the context.   Here is a list of
>>spring related stuff that still were in memory after the context was
>>closed.  Other stuff was cleaned up just fine.
>>
>>org.springframework.beans.CachedIntrospectionResults
>>org.springframework.jdbc.support.SQLCodes
>>org.springframework.core.Constants
>>org.springframework.aop.framework.AdvisedSupport$1
>>org.springframework.aop.framework.adapter.BeforeAdviceAdapter
>>org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
>>org.springframework.jdbc.support.SQLErrorCodesFactory
>>org.springframework.transaction.support.TransactionSynchronizationManage
>>r$1
>>org.springframework.transaction.interceptor.RollbackRuleAttribute
>>org.springframework.aop.framework.adapter.ThrosAdviceAdapter
>>org.springframework.aop.Pointcut$1
>>org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>>
>>On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>>
>>
>>>I'm just wondering, would the use of WeakHashMap in
>>>CachedIntrospectionResults help?
>>>
>>>Dmitriy.
>>>
>>>Tim Kettering wrote:
>>>
>>>
>>>>I posted this to the users list last week and did not receive any
>>>>reply  on it, so I'm posting it again here on the developer list, in
>>>>hopes i  could get an reply from someone here.   I'm trying to
>>>>determine if its  something I should be doing myself, or if hte
>>>>spring context should be  cleaning up those resources by itself on
>>>>the .close() call.  Further  profiling shows that there are
>>>>duplicate  instances of SQLError and  hibernate proxy classes hanging
>>>>around  afterwards too.  Other objects  do get cleaned up properly.
>>>>--------
>>>>Hi everyone,
>>>>We're (meaning me) looking into some resource leaks that are
>>>>occuring   when our webapp context gets reloaded.  I found that
>>>>context.close()   needs to be called on the destroy() method of
>>>>plugin we're using,  and  it works for a good majority of the objects
>>>>we were seeing  leaked, but  there are some objects that I'm unable
>>>>to make go away.  Object in  question is the:
>>>>org.springframework.beans.CachedIntrospectionResults
>>>>Whenever I reload the context - the profiler I'm using shows that I
>>>>have essentially a duplicate group of those objects (same instance
>>>>count) as the original, and successive reloads will continue to
>>>>duplicate this.
>>>>The profiler also shows the final reference to those objects like  this:
>>>>100% - 1008 bytes - 63 alloc.
>>>>org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>>>it >
>>>>So basically I guess what I'm asking is for ideas or suggestions on
>>>>how  I could get those to clean up.  This bean doesnt show up in the
>>>>Spring  javadocs.  And looking in CVS says its a package level bean,
>>>>not for  application use, so I'm thinking that closing the context
>>>>should (in  theory) clean this up?   Thanks in advance.
>>>>-tim
>>>>-------------------------------------------------------
>>>>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_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=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_id149&alloc_id66&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_id66&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_id149&alloc_id66&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_id149&alloc_id66&op=click
> _______________________________________________
> 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...>]

Well, I find it really weird, because I've tested such behavior before on
Resin 2.1.10, and while it took a while before the resources were garbage
collected, they were always eventually collected.  And if I added a
System.gc() when the ServletContext was loaded, all my singletons were being
collected right away.  During all your tests, did you notice higher memory
consumption or did you actually get a OutOfMemoryError ?  May be it's the
profiler that keeps a reference on some resource(s) for some reasons?

But if it is really a ClassLoader issue, shouldn't you be able to simulate
the situation outside a Servlet Container?  I've run the attached test, and
while I create a memory leak quickly if I keep a reference on the
ClassLoader, I am not able to produce one without holding a ref on it.

Or is my test flawed?

Guillaume

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


Just finished tests on Resin 2.1.11 - exactly same behavior as with Tomcat.
This *is* a general class loader respectively garbage collection issue,
rather than a server-specific leak.

Consequently, with the changes I've committed yesterday, there is the same
significant benefit as with Tomcat. The only remaining issue are the "full
object" constants like ClassFilter.TRUE.

Juergen


________________________________

Von: spr...@li... im Auftrag von
jürgen höller [werk3AT]
Gesendet: Mo 24.05.2004 09:20
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with both.

BTW, a couple of related posts from the Resin mailing list:

http://www.caucho.com/support/resin-interest/0404/0117.html
http://www.caucho.com/support/resin-interest/0111/0164.html
<http://www.caucho.com/support/resin-interest/0111/0164.html>

Juergen


________________________________

Von: spr...@li... im Auftrag von
jürgen höller [werk3AT]
Gesendet: Mo 24.05.2004 08:42
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



I've told JProfiler to explicitly run garbage collection - a number of
times, actually - before I've had a look at the heap. So I'm sure that those
remaining objects were not garbage-collected, and probably would have stayed
around in the VM forever...

I'm aware that it seems odd, but this issue just seems to affect specific
static fields: BeanWrapperImpl's defaultEditors did not cause a leak, but
CachedIntrospectionResults' classCache did. Normal constants or static
logger fields didn't, but "full object" constants like ClassFilters.TRUE
did.

CachedIntrospectionResults' classCache uses the Class as key; the value, a
CachedIntrospectionResult object, also refers to the key Class.
Consequently, I had to use a WeakHashMap *with WeakReferences as values* to
see proper garbage collection. Note that this static cache contains
instances of its containing class as values.

I've run all my tests x times to make sure that I could trust my eyes. I've
even undone the WeakReference changes again, and voila, there were the leaks
again. I'd be happy to learn more about how the garbage collector works
here... All I can state at this point of time is that the changes did cause
an obvious difference in terms of resource leaks.

Juergen


________________________________

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



The "resource leak" caused by a singleton when a webapp's classloader is
thrown away is only temorary, the unused classes and the classloader will be
eventually garbage collected and the resources will be freed.  The only
thing that could prevent that is if there was a something in the server's
classloader that still had a reference on an object or a class of the child
classloader.

Unless there's a bug in Tomcat or in the application code, I really can't
see how the classes won't be eventually garbage collected when the JVM needs
memory.  And anyway, if there was indeed a leak because SQLErrorCodesFactory
is a singleton, why wouldn't there be one for each static fields such as
constants?

Are you sure that JProfiler does not disable garbage collecting in order to
make its profiling?  I know that in many of the JVMPI method calls are done
with garbage collecting off.  I suspect the above to be the cause of the
"resource leak", rather than any singleton that Spring might be using.

Guillaume

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


I've just spent about 10 hours profiling Spring, using the Image Database
and Petclinic samples. (BTW, I've used an evaluation version of JProfiler
from ej-technologies - nice product!)

Although I still don't completely understand the garbage collection
behavior, I've figured out the following issues. Each of them simply
prevents the respective classes from getting garbage collected on
destruction of the class loader (e.g. on Tomcat web app shutdown).

- A classic singleton with a class variable holding the object. I've
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the
respective singleton as a WeakReference.

- A static cache. I've reworked CachedIntrospectionResults to use a
WeakHashMap with WeakReferences as values.

- A ThreadLocal with a default other than null. I've reworked
TransactionSynchronizationManager to use null as default for the resource
map, setting a HashMap there on demand, removing the entire HashMap when
unbinding the last resource.

- Constants that define a full object. We have a number of those, for
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried
for quite a while, but I haven't been able to figure out a way to define
such constants such that they will be garbage collected.

The latter programming style is not uncommon, so I really don't understand
why it causes trouble with garbage collection. Hibernate uses a similar
style for its FlushMode, for example.

In general, other frameworks like CGLIB, Hibernate, Velocity have huge
resource leaks on web app shutdown, while just the constants issue remains
with Spring now. As long as those huge third-party leaks are not addressed,
I'm not worried at all by the single remaining Spring issue.

As I initially said, we shouldn't exaggerate the problem, as it basically
just affects hot reloading of web apps - mainly a development feature
anyway. We need to make that clear to users too, to avoid comments a la
"Spring is not usable for real apps because it leaks on hot redeployment".

Please, everybody, give the current CVS head a sanity check tomorrow. There
shouldn't be any issues: the test suite passes, the sample apps run
properly. Still, I'd feel more comfortable if we make sure that no subtle
side effects have been introduced.

For this reason, I will delay release 1.0.2 till tomorrow night.

Juergen


________________________________

Von: spr...@li... im Auftrag von
jürgen höller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



So basically, all static caches cause resource leaks when restarting a
Tomcat web app? I wonder why this happens... The class loader should
completely dissolve all classes that it has loaded in its lifetime,
including static caches. Or have I misunderstood something here? Anyone
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag von
Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
caches SQLErrorCodes internally in the Map with strong references. Again, I
don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I
>>> have essentially a duplicate group of those objects (same instance
>>> count) as the original, and successive reloads will continue to
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  this:
>>> 100% - 1008 bytes - 63 alloc.
>>> org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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_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=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_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




-------------------------------------------------------
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_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Method Visibility

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

I don't mind that at all: I've just changed the visibility of all such =
resource factory accessors to public - in JdbcDaoSupport, =
HibernateDaoSupport, JdoDaoSupport, SqlMapDaoSupport, and =
SqlMapClientDaoSupport.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Mo 24.05.2004 09:16
An: spr...@li...
Betreff: Re: [Springframework-developer] Method Visibility



Ralph

This really is irrelevant for performance. The issue is: is it annoying
enough to justify changing the visibility?

Juergen, what are your thoughts? This has come up in the forums before. =
I'd
have no objection to changing it to public.

Rgds
Rod

----- Original Message -----
From: "Ralph Schaer" <ral...@ya...>
To: <spr...@li...>
Sent: Sunday, May 23, 2004 10:03 PM
Subject: [Springframework-developer] Method Visibility


> Hello
>
> I often have this sort of code in my dao's:
>
>     HibernateCallback callback =3D new HibernateCallback() {
>
>       public Object doInHibernate(Session session) throws
HibernateException {
>         Criteria criteria =3D =
getHibernateTemplate().createCriteria(session,
User.class);
>         criteria.add(Expression.eq("userName", userName));
>         if (id !=3D null) {
>           criteria.add(Expression.not(Expression.eq("id", id)));
>         }
>         return criteria.list();
>       }
>     };
>
> Now Eclipse complains with this warning message:
> Access to enclosing method getHibernateTemplate() from the type
> HibernateDaoSupport is emulated by a synthetic accessor method.
> Increasing its visibility will improve your performance
>
> That's because getHibernateTemplate() is protected.
>
> Regards
> Ralph
>
>
>
>
>
>
> -------------------------------------------------------
> 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] Method Visibility

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

Ralph

This really is irrelevant for performance. The issue is: is it annoying
enough to justify changing the visibility?

Juergen, what are your thoughts? This has come up in the forums before. I'd
have no objection to changing it to public.

Rgds
Rod

----- Original Message -----
From: "Ralph Schaer" <ral...@ya...>
To: <spr...@li...>
Sent: Sunday, May 23, 2004 10:03 PM
Subject: [Springframework-developer] Method Visibility


> Hello
>
> I often have this sort of code in my dao's:
>
>     HibernateCallback callback = new HibernateCallback() {
>
>       public Object doInHibernate(Session session) throws
HibernateException {
>         Criteria criteria = getHibernateTemplate().createCriteria(session,
User.class);
>         criteria.add(Expression.eq("userName", userName));
>         if (id != null) {
>           criteria.add(Expression.not(Expression.eq("id", id)));
>         }
>         return criteria.list();
>       }
>     };
>
> Now Eclipse complains with this warning message:
> Access to enclosing method getHibernateTemplate() from the type
> HibernateDaoSupport is emulated by a synthetic accessor method.
> Increasing its visibility will improve your performance
>
> That's because getHibernateTemplate() is protected.
>
> Regards
> Ralph
>
>
>
>
>
>
> -------------------------------------------------------
> 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] Cleanup of context resources on webapp reload

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

Just finished tests on Resin 2.1.11 - exactly same behavior as with =
Tomcat. This *is* a general class loader respectively garbage collection =
issue, rather than a server-specific leak.
=20
Consequently, with the changes I've committed yesterday, there is the =
same significant benefit as with Tomcat. The only remaining issue are =
the "full object" constants like ClassFilter.TRUE.
=20
Juergen
=20

________________________________

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



FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with =
both.

BTW, a couple of related posts from the Resin mailing list:

http://www.caucho.com/support/resin-interest/0404/0117.html
http://www.caucho.com/support/resin-interest/0111/0164.html =
<http://www.caucho.com/support/resin-interest/0111/0164.html>

Juergen


________________________________

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



I've told JProfiler to explicitly run garbage collection - a number of =
times, actually - before I've had a look at the heap. So I'm sure that =
those remaining objects were not garbage-collected, and probably would =
have stayed around in the VM forever...

I'm aware that it seems odd, but this issue just seems to affect =
specific static fields: BeanWrapperImpl's defaultEditors did not cause a =
leak, but CachedIntrospectionResults' classCache did. Normal constants =
or static logger fields didn't, but "full object" constants like =
ClassFilters.TRUE did.

CachedIntrospectionResults' classCache uses the Class as key; the value, =
a CachedIntrospectionResult object, also refers to the key Class. =
Consequently, I had to use a WeakHashMap *with WeakReferences as values* =
to see proper garbage collection. Note that this static cache contains =
instances of its containing class as values.

I've run all my tests x times to make sure that I could trust my eyes. =
I've even undone the WeakReference changes again, and voila, there were =
the leaks again. I'd be happy to learn more about how the garbage =
collector works here... All I can state at this point of time is that =
the changes did cause an obvious difference in terms of resource leaks.

Juergen


________________________________

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



The "resource leak" caused by a singleton when a webapp's classloader is
thrown away is only temorary, the unused classes and the classloader =
will be
eventually garbage collected and the resources will be freed.  The only
thing that could prevent that is if there was a something in the =
server's
classloader that still had a reference on an object or a class of the =
child
classloader.

Unless there's a bug in Tomcat or in the application code, I really =
can't
see how the classes won't be eventually garbage collected when the JVM =
needs
memory.  And anyway, if there was indeed a leak because =
SQLErrorCodesFactory
is a singleton, why wouldn't there be one for each static fields such as
constants?

Are you sure that JProfiler does not disable garbage collecting in order =
to
make its profiling?  I know that in many of the JVMPI method calls are =
done
with garbage collecting off.  I suspect the above to be the cause of the
"resource leak", rather than any singleton that Spring might be using.

Guillaume

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


I've just spent about 10 hours profiling Spring, using the Image =
Database
and Petclinic samples. (BTW, I've used an evaluation version of =
JProfiler
from ej-technologies - nice product!)

Although I still don't completely understand the garbage collection
behavior, I've figured out the following issues. Each of them simply
prevents the respective classes from getting garbage collected on
destruction of the class loader (e.g. on Tomcat web app shutdown).

- A classic singleton with a class variable holding the object. I've
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold =
the
respective singleton as a WeakReference.

- A static cache. I've reworked CachedIntrospectionResults to use a
WeakHashMap with WeakReferences as values.

- A ThreadLocal with a default other than null. I've reworked
TransactionSynchronizationManager to use null as default for the =
resource
map, setting a HashMap there on demand, removing the entire HashMap when
unbinding the last resource.

- Constants that define a full object. We have a number of those, for
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've =
tried
for quite a while, but I haven't been able to figure out a way to define
such constants such that they will be garbage collected.

The latter programming style is not uncommon, so I really don't =
understand
why it causes trouble with garbage collection. Hibernate uses a similar
style for its FlushMode, for example.

In general, other frameworks like CGLIB, Hibernate, Velocity have huge
resource leaks on web app shutdown, while just the constants issue =
remains
with Spring now. As long as those huge third-party leaks are not =
addressed,
I'm not worried at all by the single remaining Spring issue.

As I initially said, we shouldn't exaggerate the problem, as it =
basically
just affects hot reloading of web apps - mainly a development feature
anyway. We need to make that clear to users too, to avoid comments a la
"Spring is not usable for real apps because it leaks on hot =
redeployment".

Please, everybody, give the current CVS head a sanity check tomorrow. =
There
shouldn't be any issues: the test suite passes, the sample apps run
properly. Still, I'd feel more comfortable if we make sure that no =
subtle
side effects have been introduced.

For this reason, I will delay release 1.0.2 till tomorrow night.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



So basically, all static caches cause resource leaks when restarting a
Tomcat web app? I wonder why this happens... The class loader should
completely dissolve all classes that it has loaded in its lifetime,
including static caches. Or have I misunderstood something here? Anyone
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
caches SQLErrorCodes internally in the Map with strong references. =
Again, I
don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> =
org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the =
objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I
>>> have essentially a duplicate group of those objects (same instance
>>> count) as the original, and successive reloads will continue to
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  =
this:
>>> 100% - 1008 bytes - 63 alloc.
>>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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=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_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

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

There's a thread on the tapestry user list as well about this, they seem =
to
conclude that OC4J has the same issue...

http://www.caddr.com/macho/archives/tapestry-users/2004-3/4939.html

Also, there was a discussion going on at the forums, I'll update the =
people
involved there...

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Monday, May 24, 2004 9:21 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
> FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with =
both.
>=20
> BTW, a couple of related posts from the Resin mailing list:
>=20
> http://www.caucho.com/support/resin-interest/0404/0117.html
> http://www.caucho.com/support/resin-interest/0111/0164.html
> <http://www.caucho.com/support/resin-interest/0111/0164.html>
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Mo 24.05.2004 08:42
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
>=20
>=20
> I've told JProfiler to explicitly run garbage collection - a number of
> times, actually - before I've had a look at the heap. So I'm sure that
> those remaining objects were not garbage-collected, and probably would
> have stayed around in the VM forever...
>=20
> I'm aware that it seems odd, but this issue just seems to affect =
specific
> static fields: BeanWrapperImpl's defaultEditors did not cause a leak, =
but
> CachedIntrospectionResults' classCache did. Normal constants or static
> logger fields didn't, but "full object" constants like =
ClassFilters.TRUE
> did.
>=20
> CachedIntrospectionResults' classCache uses the Class as key; the =
value, a
> CachedIntrospectionResult object, also refers to the key Class.
> Consequently, I had to use a WeakHashMap *with WeakReferences as =
values*
> to see proper garbage collection. Note that this static cache contains
> instances of its containing class as values.
>=20
> I've run all my tests x times to make sure that I could trust my eyes.
> I've even undone the WeakReference changes again, and voila, there =
were
> the leaks again. I'd be happy to learn more about how the garbage
> collector works here... All I can state at this point of time is that =
the
> changes did cause an obvious difference in terms of resource leaks.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Guillaume Poirier
> Gesendet: Mo 24.05.2004 05:17
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
>=20
>=20
> The "resource leak" caused by a singleton when a webapp's classloader =
is
> thrown away is only temorary, the unused classes and the classloader =
will
> be
> eventually garbage collected and the resources will be freed.  The =
only
> thing that could prevent that is if there was a something in the =
server's
> classloader that still had a reference on an object or a class of the
> child
> classloader.
>=20
> Unless there's a bug in Tomcat or in the application code, I really =
can't
> see how the classes won't be eventually garbage collected when the JVM
> needs
> memory.  And anyway, if there was indeed a leak because
> SQLErrorCodesFactory
> is a singleton, why wouldn't there be one for each static fields such =
as
> constants?
>=20
> Are you sure that JProfiler does not disable garbage collecting in =
order
> to
> make its profiling?  I know that in many of the JVMPI method calls are
> done
> with garbage collecting off.  I suspect the above to be the cause of =
the
> "resource leak", rather than any singleton that Spring might be using.
>=20
> Guillaume
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Sunday, May 23, 2004 4:45 PM
> Subject: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
>=20
> I've just spent about 10 hours profiling Spring, using the Image =
Database
> and Petclinic samples. (BTW, I've used an evaluation version of =
JProfiler
> from ej-technologies - nice product!)
>=20
> Although I still don't completely understand the garbage collection
> behavior, I've figured out the following issues. Each of them simply
> prevents the respective classes from getting garbage collected on
> destruction of the class loader (e.g. on Tomcat web app shutdown).
>=20
> - A classic singleton with a class variable holding the object. I've
> reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold =
the
> respective singleton as a WeakReference.
>=20
> - A static cache. I've reworked CachedIntrospectionResults to use a
> WeakHashMap with WeakReferences as values.
>=20
> - A ThreadLocal with a default other than null. I've reworked
> TransactionSynchronizationManager to use null as default for the =
resource
> map, setting a HashMap there on demand, removing the entire HashMap =
when
> unbinding the last resource.
>=20
> - Constants that define a full object. We have a number of those, for
> example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've
> tried
> for quite a while, but I haven't been able to figure out a way to =
define
> such constants such that they will be garbage collected.
>=20
> The latter programming style is not uncommon, so I really don't =
understand
> why it causes trouble with garbage collection. Hibernate uses a =
similar
> style for its FlushMode, for example.
>=20
> In general, other frameworks like CGLIB, Hibernate, Velocity have huge
> resource leaks on web app shutdown, while just the constants issue =
remains
> with Spring now. As long as those huge third-party leaks are not
> addressed,
> I'm not worried at all by the single remaining Spring issue.
>=20
> As I initially said, we shouldn't exaggerate the problem, as it =
basically
> just affects hot reloading of web apps - mainly a development feature
> anyway. We need to make that clear to users too, to avoid comments a =
la
> "Spring is not usable for real apps because it leaks on hot =
redeployment".
>=20
> Please, everybody, give the current CVS head a sanity check tomorrow.
> There
> shouldn't be any issues: the test suite passes, the sample apps run
> properly. Still, I'd feel more comfortable if we make sure that no =
subtle
> side effects have been introduced.
>=20
> For this reason, I will delay release 1.0.2 till tomorrow night.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Sa 22.05.2004 15:52
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
>=20
>=20
> So basically, all static caches cause resource leaks when restarting a
> Tomcat web app? I wonder why this happens... The class loader should
> completely dissolve all classes that it has loaded in its lifetime,
> including static caches. Or have I misunderstood something here? =
Anyone
> having in-detail experience with handling such a scenario?
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Dmitriy Kopylenko
> Gesendet: Di 04.05.2004 18:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources =
on
> webapp reload
>=20
>=20
>=20
> Well,
>=20
> for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) =
which
> caches SQLErrorCodes internally in the Map with strong references. =
Again,
> I
> don't know if trying
> to use WeakHashMap there would do the trick...
>=20
> Dmitriy
>=20
> Tim Kettering wrote:
>=20
> >
> > I looked at it some more this morning, and basically what I did was
> > start up tomcat w/ the webapp in the profiler, then after it was =
done
> > starting up I used tomcat's manager to stop the context.  This =
should
> > destroy all resources related to the context.   Here is a list of
> > spring related stuff that still were in memory after the context was
> > closed.  Other stuff was cleaned up just fine.
> >
> > org.springframework.beans.CachedIntrospectionResults
> > org.springframework.jdbc.support.SQLCodes
> > org.springframework.core.Constants
> > org.springframework.aop.framework.AdvisedSupport$1
> > org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> > =
org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> > org.springframework.jdbc.support.SQLErrorCodesFactory
> > =
org.springframework.transaction.support.TransactionSynchronizationManage
> > r$1
> > org.springframework.transaction.interceptor.RollbackRuleAttribute
> > org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> > org.springframework.aop.Pointcut$1
> > =
org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
> >
> > On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
> >
> >> I'm just wondering, would the use of WeakHashMap in
> >> CachedIntrospectionResults help?
> >>
> >> Dmitriy.
> >>
> >> Tim Kettering wrote:
> >>
> >>> I posted this to the users list last week and did not receive any
> >>> reply  on it, so I'm posting it again here on the developer list, =
in
> >>> hopes i  could get an reply from someone here.   I'm trying to
> >>> determine if its  something I should be doing myself, or if hte
> >>> spring context should be  cleaning up those resources by itself on
> >>> the .close() call.  Further  profiling shows that there are
> >>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
> >>> around  afterwards too.  Other objects  do get cleaned up =
properly.
> >>> --------
> >>> Hi everyone,
> >>> We're (meaning me) looking into some resource leaks that are
> >>> occuring   when our webapp context gets reloaded.  I found that
> >>> context.close()   needs to be called on the destroy() method of
> >>> plugin we're using,  and  it works for a good majority of the =
objects
> >>> we were seeing  leaked, but  there are some objects that I'm =
unable
> >>> to make go away.  Object in  question is the:
> >>> org.springframework.beans.CachedIntrospectionResults
> >>> Whenever I reload the context - the profiler I'm using shows that =
I
> >>> have essentially a duplicate group of those objects (same instance
> >>> count) as the original, and successive reloads will continue to
> >>> duplicate this.
> >>> The profiler also shows the final reference to those objects like
> this:
> >>> 100% - 1008 bytes - 63 alloc.
> >>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
> >>> it >
> >>> So basically I guess what I'm asking is for ideas or suggestions =
on
> >>> how  I could get those to clean up.  This bean doesnt show up in =
the
> >>> Spring  javadocs.  And looking in CVS says its a package level =
bean,
> >>> not for  application use, so I'm thinking that closing the context
> >>> should (in  theory) clean this up?   Thanks in advance.
> >>> -tim
> >>> -------------------------------------------------------
> >>> 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=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=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=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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

[Arto P. <art...@of...>]

Hi!

I have developed couple web application to tomcat, and i have used those
Juergen's mentioned versions of tomcat, and i'm positive sure that there
is memory leak in tomcat, which appear when you install web application
by copying war to webapps directory.

I think that leak appears to tomcat, when it moved to use catalina
source, earlier (maby version 3.x) there wasn't that leak.

I have tested it with couple JVM version's and windows and linux
enviroments, but only with sun's virtual machine, and leak appears every
time, so i'm sure that problem is in tomcat.

I have used Hibernate&Template in every application, and Springframework
some application's and leak appears.

It's easy to notice it by looking how much JVM reserves memory, and copy
that war again and again to webapps directory.

Artsi.

On Mon, 2004-05-24 at 10:20, jürgen höller [werk3AT] wrote:
> FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with both.
>  
> BTW, a couple of related posts from the Resin mailing list:
>  
> http://www.caucho.com/support/resin-interest/0404/0117.html
> http://www.caucho.com/support/resin-interest/0111/0164.html <http://www.caucho.com/support/resin-interest/0111/0164.html> 
>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
> Gesendet: Mo 24.05.2004 08:42
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> I've told JProfiler to explicitly run garbage collection - a number of times, actually - before I've had a look at the heap. So I'm sure that those remaining objects were not garbage-collected, and probably would have stayed around in the VM forever...
> 
> I'm aware that it seems odd, but this issue just seems to affect specific static fields: BeanWrapperImpl's defaultEditors did not cause a leak, but CachedIntrospectionResults' classCache did. Normal constants or static logger fields didn't, but "full object" constants like ClassFilters.TRUE did.
> 
> CachedIntrospectionResults' classCache uses the Class as key; the value, a CachedIntrospectionResult object, also refers to the key Class. Consequently, I had to use a WeakHashMap *with WeakReferences as values* to see proper garbage collection. Note that this static cache contains instances of its containing class as values.
> 
> I've run all my tests x times to make sure that I could trust my eyes. I've even undone the WeakReference changes again, and voila, there were the leaks again. I'd be happy to learn more about how the garbage collector works here... All I can state at this point of time is that the changes did cause an obvious difference in terms of resource leaks.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Guillaume Poirier
> Gesendet: Mo 24.05.2004 05:17
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
> 
> 
> 
> The "resource leak" caused by a singleton when a webapp's classloader is
> thrown away is only temorary, the unused classes and the classloader will be
> eventually garbage collected and the resources will be freed.  The only
> thing that could prevent that is if there was a something in the server's
> classloader that still had a reference on an object or a class of the child
> classloader.
> 
> Unless there's a bug in Tomcat or in the application code, I really can't
> see how the classes won't be eventually garbage collected when the JVM needs
> memory.  And anyway, if there was indeed a leak because SQLErrorCodesFactory
> is a singleton, why wouldn't there be one for each static fields such as
> constants?
> 
> Are you sure that JProfiler does not disable garbage collecting in order to
> make its profiling?  I know that in many of the JVMPI method calls are done
> with garbage collecting off.  I suspect the above to be the cause of the
> "resource leak", rather than any singleton that Spring might be using.
> 
> Guillaume
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Sunday, May 23, 2004 4:45 PM
> Subject: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> I've just spent about 10 hours profiling Spring, using the Image Database
> and Petclinic samples. (BTW, I've used an evaluation version of JProfiler
> from ej-technologies - nice product!)
> 
> Although I still don't completely understand the garbage collection
> behavior, I've figured out the following issues. Each of them simply
> prevents the respective classes from getting garbage collected on
> destruction of the class loader (e.g. on Tomcat web app shutdown).
> 
> - A classic singleton with a class variable holding the object. I've
> reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the
> respective singleton as a WeakReference.
> 
> - A static cache. I've reworked CachedIntrospectionResults to use a
> WeakHashMap with WeakReferences as values.
> 
> - A ThreadLocal with a default other than null. I've reworked
> TransactionSynchronizationManager to use null as default for the resource
> map, setting a HashMap there on demand, removing the entire HashMap when
> unbinding the last resource.
> 
> - Constants that define a full object. We have a number of those, for
> example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried
> for quite a while, but I haven't been able to figure out a way to define
> such constants such that they will be garbage collected.
> 
> The latter programming style is not uncommon, so I really don't understand
> why it causes trouble with garbage collection. Hibernate uses a similar
> style for its FlushMode, for example.
> 
> In general, other frameworks like CGLIB, Hibernate, Velocity have huge
> resource leaks on web app shutdown, while just the constants issue remains
> with Spring now. As long as those huge third-party leaks are not addressed,
> I'm not worried at all by the single remaining Spring issue.
> 
> As I initially said, we shouldn't exaggerate the problem, as it basically
> just affects hot reloading of web apps - mainly a development feature
> anyway. We need to make that clear to users too, to avoid comments a la
> "Spring is not usable for real apps because it leaks on hot redeployment".
> 
> Please, everybody, give the current CVS head a sanity check tomorrow. There
> shouldn't be any issues: the test suite passes, the sample apps run
> properly. Still, I'd feel more comfortable if we make sure that no subtle
> side effects have been introduced.
> 
> For this reason, I will delay release 1.0.2 till tomorrow night.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> jürgen höller [werk3AT]
> Gesendet: Sa 22.05.2004 15:52
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> So basically, all static caches cause resource leaks when restarting a
> Tomcat web app? I wonder why this happens... The class loader should
> completely dissolve all classes that it has loaded in its lifetime,
> including static caches. Or have I misunderstood something here? Anyone
> having in-detail experience with handling such a scenario?
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> Dmitriy Kopylenko
> Gesendet: Di 04.05.2004 18:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Cleanup of context resources on
> webapp reload
> 
> 
> 
> Well,
> 
> for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
> caches SQLErrorCodes internally in the Map with strong references. Again, I
> don't know if trying
> to use WeakHashMap there would do the trick...
> 
> Dmitriy
> 
> Tim Kettering wrote:
> 
> >
> > I looked at it some more this morning, and basically what I did was
> > start up tomcat w/ the webapp in the profiler, then after it was done
> > starting up I used tomcat's manager to stop the context.  This should
> > destroy all resources related to the context.   Here is a list of
> > spring related stuff that still were in memory after the context was
> > closed.  Other stuff was cleaned up just fine.
> >
> > org.springframework.beans.CachedIntrospectionResults
> > org.springframework.jdbc.support.SQLCodes
> > org.springframework.core.Constants
> > org.springframework.aop.framework.AdvisedSupport$1
> > org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> > org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> > org.springframework.jdbc.support.SQLErrorCodesFactory
> > org.springframework.transaction.support.TransactionSynchronizationManage
> > r$1
> > org.springframework.transaction.interceptor.RollbackRuleAttribute
> > org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> > org.springframework.aop.Pointcut$1
> > org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
> >
> > On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
> >
> >> I'm just wondering, would the use of WeakHashMap in
> >> CachedIntrospectionResults help?
> >>
> >> Dmitriy.
> >>
> >> Tim Kettering wrote:
> >>
> >>> I posted this to the users list last week and did not receive any
> >>> reply  on it, so I'm posting it again here on the developer list, in
> >>> hopes i  could get an reply from someone here.   I'm trying to
> >>> determine if its  something I should be doing myself, or if hte
> >>> spring context should be  cleaning up those resources by itself on
> >>> the .close() call.  Further  profiling shows that there are
> >>> duplicate  instances of SQLError and  hibernate proxy classes hanging
> >>> around  afterwards too.  Other objects  do get cleaned up properly.
> >>> --------
> >>> Hi everyone,
> >>> We're (meaning me) looking into some resource leaks that are
> >>> occuring   when our webapp context gets reloaded.  I found that
> >>> context.close()   needs to be called on the destroy() method of
> >>> plugin we're using,  and  it works for a good majority of the objects
> >>> we were seeing  leaked, but  there are some objects that I'm unable
> >>> to make go away.  Object in  question is the:
> >>> org.springframework.beans.CachedIntrospectionResults
> >>> Whenever I reload the context - the profiler I'm using shows that I
> >>> have essentially a duplicate group of those objects (same instance
> >>> count) as the original, and successive reloads will continue to
> >>> duplicate this.
> >>> The profiler also shows the final reference to those objects like  this:
> >>> 100% - 1008 bytes - 63 alloc.
> >>> org.springframework.context.support.ClassPathXmlApplicationContext.<in
> >>> it >
> >>> So basically I guess what I'm asking is for ideas or suggestions on
> >>> how  I could get those to clean up.  This bean doesnt show up in the
> >>> Spring  javadocs.  And looking in CVS says its a package level bean,
> >>> not for  application use, so I'm thinking that closing the context
> >>> should (in  theory) clean this up?   Thanks in advance.
> >>> -tim
> >>> -------------------------------------------------------
> >>> 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_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=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_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
> 
> 
> 
> 
> -------------------------------------------------------
> 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

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

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

FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with =
both.
=20
BTW, a couple of related posts from the Resin mailing list:
=20
http://www.caucho.com/support/resin-interest/0404/0117.html
http://www.caucho.com/support/resin-interest/0111/0164.html =
<http://www.caucho.com/support/resin-interest/0111/0164.html>=20
=20
Juergen
=20

________________________________

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



I've told JProfiler to explicitly run garbage collection - a number of =
times, actually - before I've had a look at the heap. So I'm sure that =
those remaining objects were not garbage-collected, and probably would =
have stayed around in the VM forever...

I'm aware that it seems odd, but this issue just seems to affect =
specific static fields: BeanWrapperImpl's defaultEditors did not cause a =
leak, but CachedIntrospectionResults' classCache did. Normal constants =
or static logger fields didn't, but "full object" constants like =
ClassFilters.TRUE did.

CachedIntrospectionResults' classCache uses the Class as key; the value, =
a CachedIntrospectionResult object, also refers to the key Class. =
Consequently, I had to use a WeakHashMap *with WeakReferences as values* =
to see proper garbage collection. Note that this static cache contains =
instances of its containing class as values.

I've run all my tests x times to make sure that I could trust my eyes. =
I've even undone the WeakReference changes again, and voila, there were =
the leaks again. I'd be happy to learn more about how the garbage =
collector works here... All I can state at this point of time is that =
the changes did cause an obvious difference in terms of resource leaks.

Juergen


________________________________

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



The "resource leak" caused by a singleton when a webapp's classloader is
thrown away is only temorary, the unused classes and the classloader =
will be
eventually garbage collected and the resources will be freed.  The only
thing that could prevent that is if there was a something in the =
server's
classloader that still had a reference on an object or a class of the =
child
classloader.

Unless there's a bug in Tomcat or in the application code, I really =
can't
see how the classes won't be eventually garbage collected when the JVM =
needs
memory.  And anyway, if there was indeed a leak because =
SQLErrorCodesFactory
is a singleton, why wouldn't there be one for each static fields such as
constants?

Are you sure that JProfiler does not disable garbage collecting in order =
to
make its profiling?  I know that in many of the JVMPI method calls are =
done
with garbage collecting off.  I suspect the above to be the cause of the
"resource leak", rather than any singleton that Spring might be using.

Guillaume

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


I've just spent about 10 hours profiling Spring, using the Image =
Database
and Petclinic samples. (BTW, I've used an evaluation version of =
JProfiler
from ej-technologies - nice product!)

Although I still don't completely understand the garbage collection
behavior, I've figured out the following issues. Each of them simply
prevents the respective classes from getting garbage collected on
destruction of the class loader (e.g. on Tomcat web app shutdown).

- A classic singleton with a class variable holding the object. I've
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold =
the
respective singleton as a WeakReference.

- A static cache. I've reworked CachedIntrospectionResults to use a
WeakHashMap with WeakReferences as values.

- A ThreadLocal with a default other than null. I've reworked
TransactionSynchronizationManager to use null as default for the =
resource
map, setting a HashMap there on demand, removing the entire HashMap when
unbinding the last resource.

- Constants that define a full object. We have a number of those, for
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've =
tried
for quite a while, but I haven't been able to figure out a way to define
such constants such that they will be garbage collected.

The latter programming style is not uncommon, so I really don't =
understand
why it causes trouble with garbage collection. Hibernate uses a similar
style for its FlushMode, for example.

In general, other frameworks like CGLIB, Hibernate, Velocity have huge
resource leaks on web app shutdown, while just the constants issue =
remains
with Spring now. As long as those huge third-party leaks are not =
addressed,
I'm not worried at all by the single remaining Spring issue.

As I initially said, we shouldn't exaggerate the problem, as it =
basically
just affects hot reloading of web apps - mainly a development feature
anyway. We need to make that clear to users too, to avoid comments a la
"Spring is not usable for real apps because it leaks on hot =
redeployment".

Please, everybody, give the current CVS head a sanity check tomorrow. =
There
shouldn't be any issues: the test suite passes, the sample apps run
properly. Still, I'd feel more comfortable if we make sure that no =
subtle
side effects have been introduced.

For this reason, I will delay release 1.0.2 till tomorrow night.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



So basically, all static caches cause resource leaks when restarting a
Tomcat web app? I wonder why this happens... The class loader should
completely dissolve all classes that it has loaded in its lifetime,
including static caches. Or have I misunderstood something here? Anyone
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
caches SQLErrorCodes internally in the Map with strong references. =
Again, I
don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> =
org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the =
objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I
>>> have essentially a duplicate group of those objects (same instance
>>> count) as the original, and successive reloads will continue to
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  =
this:
>>> 100% - 1008 bytes - 63 alloc.
>>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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=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_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

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

I've told JProfiler to explicitly run garbage collection - a number of =
times, actually - before I've had a look at the heap. So I'm sure that =
those remaining objects were not garbage-collected, and probably would =
have stayed around in the VM forever...
=20
I'm aware that it seems odd, but this issue just seems to affect =
specific static fields: BeanWrapperImpl's defaultEditors did not cause a =
leak, but CachedIntrospectionResults' classCache did. Normal constants =
or static logger fields didn't, but "full object" constants like =
ClassFilters.TRUE did.
=20
CachedIntrospectionResults' classCache uses the Class as key; the value, =
a CachedIntrospectionResult object, also refers to the key Class. =
Consequently, I had to use a WeakHashMap *with WeakReferences as values* =
to see proper garbage collection. Note that this static cache contains =
instances of its containing class as values.
=20
I've run all my tests x times to make sure that I could trust my eyes. =
I've even undone the WeakReference changes again, and voila, there were =
the leaks again. I'd be happy to learn more about how the garbage =
collector works here... All I can state at this point of time is that =
the changes did cause an obvious difference in terms of resource leaks.
=20
Juergen
=20

________________________________

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



The "resource leak" caused by a singleton when a webapp's classloader is
thrown away is only temorary, the unused classes and the classloader =
will be
eventually garbage collected and the resources will be freed.  The only
thing that could prevent that is if there was a something in the =
server's
classloader that still had a reference on an object or a class of the =
child
classloader.

Unless there's a bug in Tomcat or in the application code, I really =
can't
see how the classes won't be eventually garbage collected when the JVM =
needs
memory.  And anyway, if there was indeed a leak because =
SQLErrorCodesFactory
is a singleton, why wouldn't there be one for each static fields such as
constants?

Are you sure that JProfiler does not disable garbage collecting in order =
to
make its profiling?  I know that in many of the JVMPI method calls are =
done
with garbage collecting off.  I suspect the above to be the cause of the
"resource leak", rather than any singleton that Spring might be using.

Guillaume

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


I've just spent about 10 hours profiling Spring, using the Image =
Database
and Petclinic samples. (BTW, I've used an evaluation version of =
JProfiler
from ej-technologies - nice product!)

Although I still don't completely understand the garbage collection
behavior, I've figured out the following issues. Each of them simply
prevents the respective classes from getting garbage collected on
destruction of the class loader (e.g. on Tomcat web app shutdown).

- A classic singleton with a class variable holding the object. I've
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold =
the
respective singleton as a WeakReference.

- A static cache. I've reworked CachedIntrospectionResults to use a
WeakHashMap with WeakReferences as values.

- A ThreadLocal with a default other than null. I've reworked
TransactionSynchronizationManager to use null as default for the =
resource
map, setting a HashMap there on demand, removing the entire HashMap when
unbinding the last resource.

- Constants that define a full object. We have a number of those, for
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've =
tried
for quite a while, but I haven't been able to figure out a way to define
such constants such that they will be garbage collected.

The latter programming style is not uncommon, so I really don't =
understand
why it causes trouble with garbage collection. Hibernate uses a similar
style for its FlushMode, for example.

In general, other frameworks like CGLIB, Hibernate, Velocity have huge
resource leaks on web app shutdown, while just the constants issue =
remains
with Spring now. As long as those huge third-party leaks are not =
addressed,
I'm not worried at all by the single remaining Spring issue.

As I initially said, we shouldn't exaggerate the problem, as it =
basically
just affects hot reloading of web apps - mainly a development feature
anyway. We need to make that clear to users too, to avoid comments a la
"Spring is not usable for real apps because it leaks on hot =
redeployment".

Please, everybody, give the current CVS head a sanity check tomorrow. =
There
shouldn't be any issues: the test suite passes, the sample apps run
properly. Still, I'd feel more comfortable if we make sure that no =
subtle
side effects have been introduced.

For this reason, I will delay release 1.0.2 till tomorrow night.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



So basically, all static caches cause resource leaks when restarting a
Tomcat web app? I wonder why this happens... The class loader should
completely dissolve all classes that it has loaded in its lifetime,
including static caches. Or have I misunderstood something here? Anyone
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
caches SQLErrorCodes internally in the Map with strong references. =
Again, I
don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> =
org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the =
objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I
>>> have essentially a duplicate group of those objects (same instance
>>> count) as the original, and successive reloads will continue to
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  =
this:
>>> 100% - 1008 bytes - 63 alloc.
>>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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=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_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...>]

The "resource leak" caused by a singleton when a webapp's classloader is
thrown away is only temorary, the unused classes and the classloader will be
eventually garbage collected and the resources will be freed.  The only
thing that could prevent that is if there was a something in the server's
classloader that still had a reference on an object or a class of the child
classloader.

Unless there's a bug in Tomcat or in the application code, I really can't
see how the classes won't be eventually garbage collected when the JVM needs
memory.  And anyway, if there was indeed a leak because SQLErrorCodesFactory
is a singleton, why wouldn't there be one for each static fields such as
constants?

Are you sure that JProfiler does not disable garbage collecting in order to
make its profiling?  I know that in many of the JVMPI method calls are done
with garbage collecting off.  I suspect the above to be the cause of the
"resource leak", rather than any singleton that Spring might be using.

Guillaume

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


I've just spent about 10 hours profiling Spring, using the Image Database
and Petclinic samples. (BTW, I've used an evaluation version of JProfiler
from ej-technologies - nice product!)

Although I still don't completely understand the garbage collection
behavior, I've figured out the following issues. Each of them simply
prevents the respective classes from getting garbage collected on
destruction of the class loader (e.g. on Tomcat web app shutdown).

- A classic singleton with a class variable holding the object. I've
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the
respective singleton as a WeakReference.

- A static cache. I've reworked CachedIntrospectionResults to use a
WeakHashMap with WeakReferences as values.

- A ThreadLocal with a default other than null. I've reworked
TransactionSynchronizationManager to use null as default for the resource
map, setting a HashMap there on demand, removing the entire HashMap when
unbinding the last resource.

- Constants that define a full object. We have a number of those, for
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried
for quite a while, but I haven't been able to figure out a way to define
such constants such that they will be garbage collected.

The latter programming style is not uncommon, so I really don't understand
why it causes trouble with garbage collection. Hibernate uses a similar
style for its FlushMode, for example.

In general, other frameworks like CGLIB, Hibernate, Velocity have huge
resource leaks on web app shutdown, while just the constants issue remains
with Spring now. As long as those huge third-party leaks are not addressed,
I'm not worried at all by the single remaining Spring issue.

As I initially said, we shouldn't exaggerate the problem, as it basically
just affects hot reloading of web apps - mainly a development feature
anyway. We need to make that clear to users too, to avoid comments a la
"Spring is not usable for real apps because it leaks on hot redeployment".

Please, everybody, give the current CVS head a sanity check tomorrow. There
shouldn't be any issues: the test suite passes, the sample apps run
properly. Still, I'd feel more comfortable if we make sure that no subtle
side effects have been introduced.

For this reason, I will delay release 1.0.2 till tomorrow night.

Juergen


________________________________

Von: spr...@li... im Auftrag von
jürgen höller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



So basically, all static caches cause resource leaks when restarting a
Tomcat web app? I wonder why this happens... The class loader should
completely dissolve all classes that it has loaded in its lifetime,
including static caches. Or have I misunderstood something here? Anyone
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag von
Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which
caches SQLErrorCodes internally in the Map with strong references. Again, I
don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I
>>> have essentially a duplicate group of those objects (same instance
>>> count) as the original, and successive reloads will continue to
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  this:
>>> 100% - 1008 bytes - 63 alloc.
>>> org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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_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=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_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Method Visibility

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

Ralph,

The Eclipse warning is a valid point, but the reality is that in the 
face of a call to Hibernate and probably out to the database, the extra 
overhead of the synthetic accessor method is going to be completely 
inconsequential...

Regards,
Colin

Ralph Schaer wrote:

>Hello
>
>I often have this sort of code in my dao's:
>
>    HibernateCallback callback = new HibernateCallback() {
>
>      public Object doInHibernate(Session session) throws HibernateException {
>        Criteria criteria = getHibernateTemplate().createCriteria(session, User.class);
>        criteria.add(Expression.eq("userName", userName));
>        if (id != null) {
>          criteria.add(Expression.not(Expression.eq("id", id)));
>        }
>        return criteria.list();
>      }
>    };
>
>Now Eclipse complains with this warning message:
>Access to enclosing method getHibernateTemplate() from the type
>HibernateDaoSupport is emulated by a synthetic accessor method.
>Increasing its visibility will improve your performance
>
>That's because getHibernateTemplate() is protected.
>
>Regards
>Ralph
>  
>

Test prior to 1.0.2 (was Re: [Springframework-developer] Cleanup of context resources on webapp reload)

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

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

On Sunday 23 May 2004 21:45, j=FCrgen h=F6ller [werk3AT] wrote:

> Please, everybody, give the current CVS head a sanity check tomorrow.
> There shouldn't be any issues: the test suite passes, the sample apps run
> properly. Still, I'd feel more comfortable if we make sure that no subtle
> side effects have been introduced.

XSLT views appear to be failing.  Tests fail when running the jpetstore app=
=20
in autobuilds and I also checked against a separate test project using=20
classpath and servlet context resource locations for the xsl template. =20

Beginning of stack trace:

org.springframework.context.ApplicationContextException: Can't load=20
stylesheet from resource [/WEB-INF/xsl/home.xslt] of ServletContext in XSLT=
=20
view 'xsl'; nested exception is=20
javax.xml.transform.TransformerConfigurationException:=20
javax.xml.transform.TransformerException:=20
javax.xml.transform.TransformerException: Illegal value: text/html used for=
=20
QNAME attribute: method
        org.springframework.web.servlet.view.xslt.AbstractXsltView.cacheTem=
plates(AbstractXsltView.java:147)
        org.springframework.web.servlet.view.xslt.AbstractXsltView.initAppl=
icationContext(AbstractXsltView.java:137)

I've not had time to look into it at all, and won't have during the day=20
tomorrow either. It's possible it's something local on my machine (xslt=20
engine impl. or something) but just in case it's not I posted it.  I'll=20
check further tomorrow night.

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

iD8DBQFAsSdUKLMLAN01aw0RAo17AJ9DAsQJ0mUjgrtD2cmztKhHDUDq5wCdEoyd
WWrrh1wj44cMJJYFuEhk5Bc=3D
=3DathJ
=2D----END PGP SIGNATURE-----

[Springframework-developer] Method Visibility

[Ralph S. <ral...@ya...>]

Hello

I often have this sort of code in my dao's:

    HibernateCallback callback = new HibernateCallback() {

      public Object doInHibernate(Session session) throws HibernateException {
        Criteria criteria = getHibernateTemplate().createCriteria(session, User.class);
        criteria.add(Expression.eq("userName", userName));
        if (id != null) {
          criteria.add(Expression.not(Expression.eq("id", id)));
        }
        return criteria.list();
      }
    };

Now Eclipse complains with this warning message:
Access to enclosing method getHibernateTemplate() from the type
HibernateDaoSupport is emulated by a synthetic accessor method.
Increasing its visibility will improve your performance

That's because getHibernateTemplate() is protected.

Regards
Ralph

Re: [Springframework-developer] Re: Preparing for 1.0.2

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

As I just noted in my mail regarding resource leaks when hot reloading a =
web app, I will delay release 1.0.2 till tomorrow night to allow for =
some further sanity checks in real life apps. See the other mail for =
details.
=20
Juergen
=20

________________________________

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



Tim,

Thanks for spotting this - actually, all 2004 date entries in the =
changelog said 2003 - and noone noticed up to now... :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Tim Nolan
Gesendet: So 23.05.2004 08:56
An: spr...@li...
Betreff: [Springframework-developer] Re: Preparing for 1.0.2



Just a small thing, change log date is 2003 instead of 2004. I think a
few of the date entries need fixing.


j=FCrgen h=F6ller [werk3AT] wrote:
> Hi everybody,
>
> I've just finished my final preparations for our upcoming Spring =
release 1.0.2, scheduled for Sunday night. See the changelog for =
details; most issues have been discussed on the mailing lists or in =
JIRA. All remaining issues in JIRA have been addressed but do not incur =
Spring changes; I plan to close most of them at the time of the 1.0.2 =
release, resolved as "Won't fix".
>
> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate =
2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons =
Attributes May 9th snapshot. (Will Commons Attributes ever get out of =
the Jakarta sandbox?? At least some sort of official beta release would =
be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS =
nor in the release distribution, as we don't use it anymore.
>
> I plan to create the actual release Sunday night. So for all you =
weekend workhorses out there, there's still a chance to test and review =
the current CVS head :-) Please no further enhancements, though: As the =
changelog shows, we've already gathered a lot of minor bugfixes and =
enhancements, so we should get out 1.0.2 ASAP. Further enhancements =
should go into 1.0.3, scheduled for late June.
>
> Juergen
>
>
>
> -------------------------------------------------------
> 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=3Dclick



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

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

I've just spent about 10 hours profiling Spring, using the Image =
Database and Petclinic samples. (BTW, I've used an evaluation version of =
JProfiler from ej-technologies - nice product!)
=20
Although I still don't completely understand the garbage collection =
behavior, I've figured out the following issues. Each of them simply =
prevents the respective classes from getting garbage collected on =
destruction of the class loader (e.g. on Tomcat web app shutdown).
=20
- A classic singleton with a class variable holding the object. I've =
reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold =
the respective singleton as a WeakReference.
=20
- A static cache. I've reworked CachedIntrospectionResults to use a =
WeakHashMap with WeakReferences as values.
=20
- A ThreadLocal with a default other than null. I've reworked =
TransactionSynchronizationManager to use null as default for the =
resource map, setting a HashMap there on demand, removing the entire =
HashMap when unbinding the last resource.
=20
- Constants that define a full object. We have a number of those, for =
example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've =
tried for quite a while, but I haven't been able to figure out a way to =
define such constants such that they will be garbage collected.
=20
The latter programming style is not uncommon, so I really don't =
understand why it causes trouble with garbage collection. Hibernate uses =
a similar style for its FlushMode, for example.
=20
In general, other frameworks like CGLIB, Hibernate, Velocity have huge =
resource leaks on web app shutdown, while just the constants issue =
remains with Spring now. As long as those huge third-party leaks are not =
addressed, I'm not worried at all by the single remaining Spring issue.
=20
As I initially said, we shouldn't exaggerate the problem, as it =
basically just affects hot reloading of web apps - mainly a development =
feature anyway. We need to make that clear to users too, to avoid =
comments a la "Spring is not usable for real apps because it leaks on =
hot redeployment".
=20
Please, everybody, give the current CVS head a sanity check tomorrow. =
There shouldn't be any issues: the test suite passes, the sample apps =
run properly. Still, I'd feel more comfortable if we make sure that no =
subtle side effects have been introduced.
=20
For this reason, I will delay release 1.0.2 till tomorrow night.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 15:52
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



So basically, all static caches cause resource leaks when restarting a =
Tomcat web app? I wonder why this happens... The class loader should =
completely dissolve all classes that it has loaded in its lifetime, =
including static caches. Or have I misunderstood something here? Anyone =
having in-detail experience with handling such a scenario?

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which =
caches SQLErrorCodes internally in the Map with strong references. =
Again, I don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was
> start up tomcat w/ the webapp in the profiler, then after it was done
> starting up I used tomcat's manager to stop the context.  This should
> destroy all resources related to the context.   Here is a list of
> spring related stuff that still were in memory after the context was
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> =
org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any
>>> reply  on it, so I'm posting it again here on the developer list, in
>>> hopes i  could get an reply from someone here.   I'm trying to
>>> determine if its  something I should be doing myself, or if hte
>>> spring context should be  cleaning up those resources by itself on
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the =
objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I=20
>>> have essentially a duplicate group of those objects (same instance=20
>>> count) as the original, and successive reloads will continue to=20
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  =
this:
>>> 100% - 1008 bytes - 63 alloc.=20
>>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on
>>> how  I could get those to clean up.  This bean doesnt show up in the
>>> Spring  javadocs.  And looking in CVS says its a package level bean,
>>> not for  application use, so I'm thinking that closing the context
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> 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=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] Spring IDE with eclipse M9

[Torsten J. <tju...@ya...>]

Juergen,

actually there was no version 1.0.2 publicly announced
yet ;-) Only some mails on the developer list.

The version 1.0.2 which is available on the update
site right now is an preview / interims release. It
was intended to verify if it solves Seth's problem
with GEF 3.0 (the constructor of GEF's 3.0 PrintAction
has a new signature).

No problem, I will bump the version number of the
"final version of 1.0.2" to 1.0.3. So nobody has to
uninstall the pre-1.0.2.

Keeping the version number of Spring IDE in sync with
Spring was not intended. With 1.0.1 it was only a
coincidence :-)

Torsten

--- jürgen_höller_[werk3AT]
<jue...@we...> wrote:
> Torsten,
>  
> What's the rationale for keeping the version number
> 1.0.2 for Spring IDE? Just for being in sync with
> the Spring Framework 1.0.2 release? IMO, Spring IDE
> can and should have its own release schedule, so a
> Spring IDE release 1.0.3 that ships with Spring
> Framework core 1.0.2 would be fine.
>  
> Juergen
>  
> 
> ________________________________
> 
> Von:
>
spr...@li...
> im Auftrag von Torsten Juergeleit
> Gesendet: So 23.05.2004 19:24
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Spring IDE
> with eclipse M9
> 
> 
> 
> The new version (1.0.2) of Spring IDE is nearly
> finished. I am preparing the documentation right now
> and waiting for Spring 1.0.2 to be released (today)
> to
> include an updated spring-core.jar as well.
> 
> With this new version of Spring IDE you will get the
> following changes:
> 
> * to support Eclipse 3.0 (final) Spring IDE has to
> bring it's own version of the Apache Xerces XML
> parser
> (Xerces is not shipped with the Eclipse platform
> anymore)
> 
> * to support external beans configs the beans
> configs
> are now handled by their full path instead of their
> project-relative path
> 
> * double-clicking a bean or a reference part in the
> Beans Graph now opens the corresponding beans config
> file
> 
> * config set properties page now supports external
> beans config files from referenced Spring projects
> 
> * new overlay indicator for beans in config sets
> which
> are defined in an external config file
> 
> * documention for Spring IDE is now provided as a
> new
> plugin which leverages Eclipse's help system
> 
> * both features (Spring Framework and Spring IDE)
> are
> providing now information for Eclipse's about dialog
> 
> * both features (Spring Framework and Spring IDE)
> are
> providing now a welcome page with some Quick Start
> information
> 
> Depending on Spring's release today I will upload
> the
> new version today.
> 
> Due to the unchanged feature/plugin version number
> you
> have to uninstall the old version 1.0.2 which is
> currently available on the unpdate site and
> re-install
> the new version.
> 
> Cheers,
> Torsten
> 
> --- Thomas Risberg <tho...@tr...> wrote:
> > Cameron,
> >
> > It's already available - and it works well - see
> my
> > comment on this thread
> >
> >
>
http://sourceforge.net/forum/message.php?msg_id=2581562
> >
> > Thomas
> >
> >
> >
> > Cameron Braid wrote:
> >
> > > As many of you may know, Eclipse 3.0 M9 is out,
> > and they don't supply
> > > the xerces plugin anymore.
> > >
> > > Are there plans for a new release of the Spring
> > IDE that will work
> > > with M9 ?
> > >
> > > Thanks,
> > >
> > > Cameron
> > >
> >
> >
> >
> >
>
-------------------------------------------------------
> > 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
> 
> 
> 
>        
>                
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains - Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer
> 
> 
>
-------------------------------------------------------
> 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&#65533;66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: [Springframework-developer] Spring IDE with eclipse M9

[Torsten J. <tju...@ya...>]

Juergen,

actually there was no version 1.0.2 publicly announced
yet ;-) Only some mails on the developer list.

The version 1.0.2 which is available on the update
site right now is an preview / interims release. It
was intended to verify if it solves Seth's problem
with GEF 3.0 (the constructor of GEF's 3.0 PrintAction
has a new signature).

No problem, I will bump the version number of the
"final version of 1.0.2" to 1.0.3. So nobody has to
uninstall the pre-1.0.2.

Keeping the version number of Spring IDE in sync with
Spring was not intended. With 1.0.1 it was only a
coincidence :-)

Torsten

--- jürgen_höller_[werk3AT]
<jue...@we...> wrote:
> Torsten,
>  
> What's the rationale for keeping the version number
> 1.0.2 for Spring IDE? Just for being in sync with
> the Spring Framework 1.0.2 release? IMO, Spring IDE
> can and should have its own release schedule, so a
> Spring IDE release 1.0.3 that ships with Spring
> Framework core 1.0.2 would be fine.
>  
> Juergen
>  
> 
> ________________________________
> 
> Von:
>
spr...@li...
> im Auftrag von Torsten Juergeleit
> Gesendet: So 23.05.2004 19:24
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Spring IDE
> with eclipse M9
> 
> 
> 
> The new version (1.0.2) of Spring IDE is nearly
> finished. I am preparing the documentation right now
> and waiting for Spring 1.0.2 to be released (today)
> to
> include an updated spring-core.jar as well.
> 
> With this new version of Spring IDE you will get the
> following changes:
> 
> * to support Eclipse 3.0 (final) Spring IDE has to
> bring it's own version of the Apache Xerces XML
> parser
> (Xerces is not shipped with the Eclipse platform
> anymore)
> 
> * to support external beans configs the beans
> configs
> are now handled by their full path instead of their
> project-relative path
> 
> * double-clicking a bean or a reference part in the
> Beans Graph now opens the corresponding beans config
> file
> 
> * config set properties page now supports external
> beans config files from referenced Spring projects
> 
> * new overlay indicator for beans in config sets
> which
> are defined in an external config file
> 
> * documention for Spring IDE is now provided as a
> new
> plugin which leverages Eclipse's help system
> 
> * both features (Spring Framework and Spring IDE)
> are
> providing now information for Eclipse's about dialog
> 
> * both features (Spring Framework and Spring IDE)
> are
> providing now a welcome page with some Quick Start
> information
> 
> Depending on Spring's release today I will upload
> the
> new version today.
> 
> Due to the unchanged feature/plugin version number
> you
> have to uninstall the old version 1.0.2 which is
> currently available on the unpdate site and
> re-install
> the new version.
> 
> Cheers,
> Torsten
> 
> --- Thomas Risberg <tho...@tr...> wrote:
> > Cameron,
> >
> > It's already available - and it works well - see
> my
> > comment on this thread
> >
> >
>
http://sourceforge.net/forum/message.php?msg_id=2581562
> >
> > Thomas
> >
> >
> >
> > Cameron Braid wrote:
> >
> > > As many of you may know, Eclipse 3.0 M9 is out,
> > and they don't supply
> > > the xerces plugin anymore.
> > >
> > > Are there plans for a new release of the Spring
> > IDE that will work
> > > with M9 ?
> > >
> > > Thanks,
> > >
> > > Cameron
> > >
> >
> >
> >
> >
>
-------------------------------------------------------
> > 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
> 
> 
> 
>        
>                
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains - Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer
> 
> 
>
-------------------------------------------------------
> 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&#65533;66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: [Springframework-developer] Spring IDE with eclipse M9

[Torsten J. <tju...@ya...>]

Colin,

not "absolute" but "full" path ;-)
This is the path of an Eclise resource including it's
project name. In previous versions of Spring IDE the
"project-relative" path of a Spring beans config was
used. So no hardcoded OS-specific path ;-)

But by using a config file's full path makes Spring
IDE project configurations vulnerable to renaming of
Spring projects. This is not handled in v1.0.2 - needs
to be addressed in v1.0.3!!!

Torsten


--- Colin Sampaleanu <col...@ex...> wrote:
> Torsten,
> 
> This sounds great. Can you clarify one thing? The
> external beans configs 
> sounds like what we were talking about at the TSS
> Symposium, that is 
> allowing bean config sets across projects. But are
> you saying that you 
> are actually including the hard (absolute) path to
> the files in this 
> case? If this is the case this is a bit problematic
> when these projects 
> need to be checked into CVS. Can you clarify?
> 
> Regards,
> Colin
> 
> Torsten Juergeleit wrote:
> 
> >The new version (1.0.2) of Spring IDE is nearly
> >finished. I am preparing the documentation right
> now
> >and waiting for Spring 1.0.2 to be released (today)
> to
> >include an updated spring-core.jar as well.
> >
> >With this new version of Spring IDE you will get
> the
> >following changes:
> >
> >* to support Eclipse 3.0 (final) Spring IDE has to
> >bring it's own version of the Apache Xerces XML
> parser
> >(Xerces is not shipped with the Eclipse platform
> >anymore)
> >
> >* to support external beans configs the beans
> configs
> >are now handled by their full path instead of their
> >project-relative path
> >
> >* double-clicking a bean or a reference part in the
> >Beans Graph now opens the corresponding beans
> config
> >file
> >
> >* config set properties page now supports external
> >beans config files from referenced Spring projects
> >
> >* new overlay indicator for beans in config sets
> which
> >are defined in an external config file
> >
> >* documention for Spring IDE is now provided as a
> new
> >plugin which leverages Eclipse's help system
> >
> >* both features (Spring Framework and Spring IDE)
> are
> >providing now information for Eclipse's about
> dialog
> >
> >* both features (Spring Framework and Spring IDE)
> are
> >providing now a welcome page with some Quick Start
> >information
> >
> >Depending on Spring's release today I will upload
> the
> >new version today.
> >
> >Due to the unchanged feature/plugin version number
> you
> >have to uninstall the old version 1.0.2 which is
> >currently available on the unpdate site and
> re-install
> >the new version.
> >
> >Cheers,
> >Torsten
> >
> >--- Thomas Risberg <tho...@tr...>
> wrote:
> >  
> >
> >>Cameron,
> >>
> >>It's already available - and it works well - see
> my
> >>comment on this thread
> >>
> >>
> >>    
> >>
>
>http://sourceforge.net/forum/message.php?msg_id=2581562
> >  
> >
> >>Thomas
> >>
> >>
> >>
> >>Cameron Braid wrote:
> >>
> >>    
> >>
> >>>As many of you may know, Eclipse 3.0 M9 is out,
> >>>      
> >>>
> >>and they don’t supply 
> >>    
> >>
> >>>the xerces plugin anymore.
> >>>
> >>>Are there plans for a new release of the Spring
> >>>      
> >>>
> >>IDE that will work 
> >>    
> >>
> >>>with M9 ?
> >>>
> >>>Thanks,
> >>>
> >>>Cameron
> >>>      
> >>>
> 
> 
> 
> 
>
-------------------------------------------------------
> 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



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: [Springframework-developer] Spring IDE with eclipse M9

[Torsten J. <tju...@ya...>]

No, the XML parser shipped with J2SE (Apache Crimson)
doesn't support DOM Level 3 (user data in DOM node ->
used to track line numbers of Spring bean
definitions).

I don't know any XML parser other than Xerces which
supports DOM Level 3 yet. Maybe this is the reason why
plugins like XmlBuddy ship with their own copy of
Xerces ;-)

Cheers,
Torsten

--- snpe <sn...@sn...> wrote:
> Now all plugins include own xerces (>1mb download) -
> can you use xml parser from J2SE ?
> 
> regards
> On Sunday 23 May 2004 05:24 pm, Torsten Juergeleit
> wrote:
> > The new version (1.0.2) of Spring IDE is nearly
> > finished. I am preparing the documentation right
> now
> > and waiting for Spring 1.0.2 to be released
> (today) to
> > include an updated spring-core.jar as well.
> > 
> > With this new version of Spring IDE you will get
> the
> > following changes:
> > 
> > * to support Eclipse 3.0 (final) Spring IDE has to
> > bring it's own version of the Apache Xerces XML
> parser
> > (Xerces is not shipped with the Eclipse platform
> > anymore)
> > 
> > * to support external beans configs the beans
> configs
> > are now handled by their full path instead of
> their
> > project-relative path
> > 
> > * double-clicking a bean or a reference part in
> the
> > Beans Graph now opens the corresponding beans
> config
> > file
> > 
> > * config set properties page now supports external
> > beans config files from referenced Spring projects
> > 
> > * new overlay indicator for beans in config sets
> which
> > are defined in an external config file
> > 
> > * documention for Spring IDE is now provided as a
> new
> > plugin which leverages Eclipse's help system
> > 
> > * both features (Spring Framework and Spring IDE)
> are
> > providing now information for Eclipse's about
> dialog
> > 
> > * both features (Spring Framework and Spring IDE)
> are
> > providing now a welcome page with some Quick Start
> > information
> > 
> > Depending on Spring's release today I will upload
> the
> > new version today.
> > 
> > Due to the unchanged feature/plugin version number
> you
> > have to uninstall the old version 1.0.2 which is
> > currently available on the unpdate site and
> re-install
> > the new version.
> > 
> > Cheers,
> > Torsten
> > 
> > --- Thomas Risberg <tho...@tr...>
> wrote:
> > > Cameron,
> > > 
> > > It's already available - and it works well - see
> my
> > > comment on this thread
> > > 
> > >
> >
>
http://sourceforge.net/forum/message.php?msg_id=2581562
> > > 
> > > Thomas
> > > 
> > > 
> > > 
> > > Cameron Braid wrote:
> > > 
> > > > As many of you may know, Eclipse 3.0 M9 is
> out,
> > > and they dont supply 
> > > > the xerces plugin anymore.
> > > >
> > > > Are there plans for a new release of the
> Spring
> > > IDE that will work 
> > > > with M9 ?
> > > >
> > > > Thanks,
> > > >
> > > > Cameron
> > > >
> > > 
> > > 
> > > 
> > >
> >
>
-------------------------------------------------------
> > > 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
> > 
> > 
> > 
> > 	
> > 		
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Domains  Claim yours for only $14.70/year
> > http://smallbusiness.promotions.yahoo.com/offer 
> > 
> > 
> >
>
-------------------------------------------------------
> > 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



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: [Springframework-developer] Spring IDE with eclipse M9

[snpe <sn...@sn...>]

Now all plugins include own xerces (>1mb download) - can you use xml parser from J2SE ?

regards
On Sunday 23 May 2004 05:24 pm, Torsten Juergeleit wrote:
> The new version (1.0.2) of Spring IDE is nearly
> finished. I am preparing the documentation right now
> and waiting for Spring 1.0.2 to be released (today) to
> include an updated spring-core.jar as well.
> 
> With this new version of Spring IDE you will get the
> following changes:
> 
> * to support Eclipse 3.0 (final) Spring IDE has to
> bring it's own version of the Apache Xerces XML parser
> (Xerces is not shipped with the Eclipse platform
> anymore)
> 
> * to support external beans configs the beans configs
> are now handled by their full path instead of their
> project-relative path
> 
> * double-clicking a bean or a reference part in the
> Beans Graph now opens the corresponding beans config
> file
> 
> * config set properties page now supports external
> beans config files from referenced Spring projects
> 
> * new overlay indicator for beans in config sets which
> are defined in an external config file
> 
> * documention for Spring IDE is now provided as a new
> plugin which leverages Eclipse's help system
> 
> * both features (Spring Framework and Spring IDE) are
> providing now information for Eclipse's about dialog
> 
> * both features (Spring Framework and Spring IDE) are
> providing now a welcome page with some Quick Start
> information
> 
> Depending on Spring's release today I will upload the
> new version today.
> 
> Due to the unchanged feature/plugin version number you
> have to uninstall the old version 1.0.2 which is
> currently available on the unpdate site and re-install
> the new version.
> 
> Cheers,
> Torsten
> 
> --- Thomas Risberg <tho...@tr...> wrote:
> > Cameron,
> > 
> > It's already available - and it works well - see my
> > comment on this thread
> > 
> >
> http://sourceforge.net/forum/message.php?msg_id=2581562
> > 
> > Thomas
> > 
> > 
> > 
> > Cameron Braid wrote:
> > 
> > > As many of you may know, Eclipse 3.0 M9 is out,
> > and they dont supply 
> > > the xerces plugin anymore.
> > >
> > > Are there plans for a new release of the Spring
> > IDE that will work 
> > > with M9 ?
> > >
> > > Thanks,
> > >
> > > Cameron
> > >
> > 
> > 
> > 
> >
> -------------------------------------------------------
> > 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
> 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains  Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer 
> 
> 
> -------------------------------------------------------
> 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] Spring IDE with eclipse M9

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

Torsten,
=20
What's the rationale for keeping the version number 1.0.2 for Spring =
IDE? Just for being in sync with the Spring Framework 1.0.2 release? =
IMO, Spring IDE can and should have its own release schedule, so a =
Spring IDE release 1.0.3 that ships with Spring Framework core 1.0.2 =
would be fine.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Torsten Juergeleit
Gesendet: So 23.05.2004 19:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Spring IDE with eclipse M9



The new version (1.0.2) of Spring IDE is nearly
finished. I am preparing the documentation right now
and waiting for Spring 1.0.2 to be released (today) to
include an updated spring-core.jar as well.

With this new version of Spring IDE you will get the
following changes:

* to support Eclipse 3.0 (final) Spring IDE has to
bring it's own version of the Apache Xerces XML parser
(Xerces is not shipped with the Eclipse platform
anymore)

* to support external beans configs the beans configs
are now handled by their full path instead of their
project-relative path

* double-clicking a bean or a reference part in the
Beans Graph now opens the corresponding beans config
file

* config set properties page now supports external
beans config files from referenced Spring projects

* new overlay indicator for beans in config sets which
are defined in an external config file

* documention for Spring IDE is now provided as a new
plugin which leverages Eclipse's help system

* both features (Spring Framework and Spring IDE) are
providing now information for Eclipse's about dialog

* both features (Spring Framework and Spring IDE) are
providing now a welcome page with some Quick Start
information

Depending on Spring's release today I will upload the
new version today.

Due to the unchanged feature/plugin version number you
have to uninstall the old version 1.0.2 which is
currently available on the unpdate site and re-install
the new version.

Cheers,
Torsten

--- Thomas Risberg <tho...@tr...> wrote:
> Cameron,
>
> It's already available - and it works well - see my
> comment on this thread
>
>
http://sourceforge.net/forum/message.php?msg_id=3D2581562
>
> Thomas
>
>
>
> Cameron Braid wrote:
>
> > As many of you may know, Eclipse 3.0 M9 is out,
> and they don't supply
> > the xerces plugin anymore.
> >
> > Are there plans for a new release of the Spring
> IDE that will work
> > with M9 ?
> >
> > Thanks,
> >
> > Cameron
> >
>
>
>
>
-------------------------------------------------------
> 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



      =20
              =20
__________________________________
Do you Yahoo!?
Yahoo! Domains - Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer


-------------------------------------------------------
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] Spring IDE with eclipse M9

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

Torsten,

This sounds great. Can you clarify one thing? The external beans configs 
sounds like what we were talking about at the TSS Symposium, that is 
allowing bean config sets across projects. But are you saying that you 
are actually including the hard (absolute) path to the files in this 
case? If this is the case this is a bit problematic when these projects 
need to be checked into CVS. Can you clarify?

Regards,
Colin

Torsten Juergeleit wrote:

>The new version (1.0.2) of Spring IDE is nearly
>finished. I am preparing the documentation right now
>and waiting for Spring 1.0.2 to be released (today) to
>include an updated spring-core.jar as well.
>
>With this new version of Spring IDE you will get the
>following changes:
>
>* to support Eclipse 3.0 (final) Spring IDE has to
>bring it's own version of the Apache Xerces XML parser
>(Xerces is not shipped with the Eclipse platform
>anymore)
>
>* to support external beans configs the beans configs
>are now handled by their full path instead of their
>project-relative path
>
>* double-clicking a bean or a reference part in the
>Beans Graph now opens the corresponding beans config
>file
>
>* config set properties page now supports external
>beans config files from referenced Spring projects
>
>* new overlay indicator for beans in config sets which
>are defined in an external config file
>
>* documention for Spring IDE is now provided as a new
>plugin which leverages Eclipse's help system
>
>* both features (Spring Framework and Spring IDE) are
>providing now information for Eclipse's about dialog
>
>* both features (Spring Framework and Spring IDE) are
>providing now a welcome page with some Quick Start
>information
>
>Depending on Spring's release today I will upload the
>new version today.
>
>Due to the unchanged feature/plugin version number you
>have to uninstall the old version 1.0.2 which is
>currently available on the unpdate site and re-install
>the new version.
>
>Cheers,
>Torsten
>
>--- Thomas Risberg <tho...@tr...> wrote:
>  
>
>>Cameron,
>>
>>It's already available - and it works well - see my
>>comment on this thread
>>
>>
>>    
>>
>http://sourceforge.net/forum/message.php?msg_id=2581562
>  
>
>>Thomas
>>
>>
>>
>>Cameron Braid wrote:
>>
>>    
>>
>>>As many of you may know, Eclipse 3.0 M9 is out,
>>>      
>>>
>>and they don’t supply 
>>    
>>
>>>the xerces plugin anymore.
>>>
>>>Are there plans for a new release of the Spring
>>>      
>>>
>>IDE that will work 
>>    
>>
>>>with M9 ?
>>>
>>>Thanks,
>>>
>>>Cameron
>>>      
>>>

Re: [Springframework-developer] Spring IDE with eclipse M9

[Torsten J. <tju...@ya...>]

The new version (1.0.2) of Spring IDE is nearly
finished. I am preparing the documentation right now
and waiting for Spring 1.0.2 to be released (today) to
include an updated spring-core.jar as well.

With this new version of Spring IDE you will get the
following changes:

* to support Eclipse 3.0 (final) Spring IDE has to
bring it's own version of the Apache Xerces XML parser
(Xerces is not shipped with the Eclipse platform
anymore)

* to support external beans configs the beans configs
are now handled by their full path instead of their
project-relative path

* double-clicking a bean or a reference part in the
Beans Graph now opens the corresponding beans config
file

* config set properties page now supports external
beans config files from referenced Spring projects

* new overlay indicator for beans in config sets which
are defined in an external config file

* documention for Spring IDE is now provided as a new
plugin which leverages Eclipse's help system

* both features (Spring Framework and Spring IDE) are
providing now information for Eclipse's about dialog

* both features (Spring Framework and Spring IDE) are
providing now a welcome page with some Quick Start
information

Depending on Spring's release today I will upload the
new version today.

Due to the unchanged feature/plugin version number you
have to uninstall the old version 1.0.2 which is
currently available on the unpdate site and re-install
the new version.

Cheers,
Torsten

--- Thomas Risberg <tho...@tr...> wrote:
> Cameron,
> 
> It's already available - and it works well - see my
> comment on this thread
> 
>
http://sourceforge.net/forum/message.php?msg_id=2581562
> 
> Thomas
> 
> 
> 
> Cameron Braid wrote:
> 
> > As many of you may know, Eclipse 3.0 M9 is out,
> and they don’t supply 
> > the xerces plugin anymore.
> >
> > Are there plans for a new release of the Spring
> IDE that will work 
> > with M9 ?
> >
> > Thanks,
> >
> > Cameron
> >
> 
> 
> 
>
-------------------------------------------------------
> 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



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

[Springframework-developer] Re: Build and Test Notes

[Tim N. <kat...@ho...>]

I'm getting this with the default maven target:

Attempting to download commons-attributes-api-SNAPSHOT.jar.
Attempting to download commons-attributes-compiler-SNAPSHOT.jar
Attempting to download velocity-tools-generic-1.1.jar.
WARNING: Failed to download velocity-tools-generic-1.1.jar.


Should I be putting this jar in manually?



NB - "testsummary" target is now patched

kat...@ho... wrote:

> Apologies in advance if I've broken any posting protocols - 1st time 
> poster.
> 
> 
> I'd like to run the full test suite - I'm running the "testsummary" 
> target, but it fails. See:
> http://opensource.atlassian.com/projects/spring/browse/SPR-126
> 
> Build.xml states to run "tests" target but this fails too - see DB error 
> at bottom.
> 
> Is there documentation on the build/test targets that would answer the 
> following:
> 
> Am I doing something wrong?
> 
> Is the "testsummary" target obsolete?
> 
> Is there doco. on which targets I should run, so I can be sure my build 
> passes all tests?
> 
> Are all DB tests (such as transactions) done against HSQLDB - if so do 
> the targets startup the server? If not, what is the environment I need 
> to setup before running tests? - see DB at bottom.
> 
> Cheers and long live Spring.
> 
> 
> 
> 
> 
> 
> NB - The tests continue despite this test failing.
> 
>     [junit] Running 
> org.springframework.jdbc.datasource.DataSourceTransactionManagerTests
>     [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 1.051 sec
>     [junit] Testsuite: 
> org.springframework.jdbc.datasource.DataSourceTransactionManagerTests
>     [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 1.051 sec
>     [junit] ------------- Standard Error -----------------
>     [junit] java.lang.RuntimeException: Application exception
>     [junit]     at 
> org.springframework.jdbc.datasource.DataSourceTransactionManagerTests.testTransactionRollbackOnly(DataSourceTransactionManagerTests.java:192) 
> 
>     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     [junit]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> 
>     [junit]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
> 
>     [junit]     at java.lang.reflect.Method.invoke(Method.java:324)
>     [junit]     at junit.framework.TestCase.runTest(TestCase.java:154)
>     [junit]     at junit.framework.TestCase.runBare(TestCase.java:127)
>     [junit]     at 
> junit.framework.TestResult$1.protect(TestResult.java:106)
>     [junit]     at 
> junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit]     at junit.framework.TestResult.run(TestResult.java:109)
>     [junit]     at junit.framework.TestCase.run(TestCase.java:118)
>     [junit]     at junit.framework.TestSuite.runTest(TestSuite.java:208)
>     [junit]     at junit.framework.TestSuite.run(TestSuite.java:203)
>     [junit]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:289) 
> 
>     [junit]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:523) 
> 
>     [junit] ------------- ---------------- ---------------
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click