springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Preparing for 1.1.5

[Rob H. <ro...@ca...>]

Not sure whether I'll finish it time. Plus something just landed on my 
desk :(.

I'll put it in for 1.2. That'll give some more time to work on it.

Rob

Juergen Hoeller wrote:

>Hmmm, if it's not too invasive and you manage to get it in by tomorrow
>morning, then go for it - let's include it in 1.1.5.
>
>I'll leave for Ulm tomorrow afternoon, for a 3-day workshop; I'd like to go
>through the 1.1.5 codebase in the evenings there.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Monday, February 21, 2005 12:43 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Preparing for 1.1.5
>
>
>I guess I should leave the MIME type support out for this release then?
>
>Rob
>
>Juergen Hoeller wrote:
>
>  
>
>>Spring developers, everybody,
>>
>>I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to go
>>for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
>>support, so we shouldn't lose any time. So please, test the current CVS
>>contents (or a current nightly snapshot) thoroughly, and refrain from
>>non-trivial code changes!
>>
>>One area worth re-testing, for example, is JDBC/Hibernate resource
>>management: There have been some recent changes, in particular affecting a
>>combination of  DataSourceTransactionManager/HibernateTransactionManager
>>    
>>
>and
>  
>
>>TransactionAwareDataSourceProxy. Of course, it's also important to check
>>that typical DataSourceTransactionManager/HibernateTransactionManager usage
>>still works properly, not causing resource leaks in any scenario.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Juergen Hoeller
>>Sent: Wednesday, February 16, 2005 8:20 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] Preparing for 1.1.5
>>
>>
>>Everybody,
>>
>>I've committed lots of minor fixes and enhancements that I've implemented
>>    
>>
>in
>  
>
>>the past two weeks (most of them driven by JIRA issues). See the changelog
>>for details. The most important changes are:
>>
>>* I've added a "getBeanNamesForType" method to the ListableBeanFactory
>>interface, also checking FactoryBeans and manual singletons (in contrast to
>>"getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
>>avoids creating prototype instances (assuming that all that is needed are
>>the names).
>>
>>* TransactionSynchronization objects can influence their execution order
>>through implementing the Ordered interface. This is used to always perform
>>JDBC Connection cleanup last, for example after Hibernate Session cleanup
>>(if any), and to always perform LobCreator cleanup first (while the JDBC
>>Connection is still active).
>>
>>* I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
>>for Image Database, to show an alternative to Commons DBCP. I've also added
>>a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
>>versions, SimpleNativeJdbcExtractor is sufficient.
>>
>>* I've upgraded MockHttpServletRequest to Servlet API 2.4 and
>>MockPageContext to JSP API 2.0. An enhancement enabled by compiling against
>>JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed with
>>the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL
>>    
>>
>for
>  
>
>>earlier JSP versions.
>>
>>* I've reworked JasperReportsMultiFormatView, in particular the
>>initialization code. I've also renamed its "discriminatorKey" property to
>>"formatKey", as a more expressive name and following the
>>AbstractJasperReportsView naming conventions ("reportDataKey" etc).
>>
>>Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar
>>    
>>
>has
>  
>
>>been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
>>to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's ejb.jar
>>with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
>>(build.xml etc).
>>
>>Juergen
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] Preparing for 1.1.5

[Juergen H. <ju...@in...>]

Hmmm, if it's not too invasive and you manage to get it in by tomorrow
morning, then go for it - let's include it in 1.1.5.

I'll leave for Ulm tomorrow afternoon, for a 3-day workshop; I'd like to go
through the 1.1.5 codebase in the evenings there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Monday, February 21, 2005 12:43 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.1.5


I guess I should leave the MIME type support out for this release then?

Rob

Juergen Hoeller wrote:

>Spring developers, everybody,
>
>I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to go
>for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
>support, so we shouldn't lose any time. So please, test the current CVS
>contents (or a current nightly snapshot) thoroughly, and refrain from
>non-trivial code changes!
>
>One area worth re-testing, for example, is JDBC/Hibernate resource
>management: There have been some recent changes, in particular affecting a
>combination of  DataSourceTransactionManager/HibernateTransactionManager
and
>TransactionAwareDataSourceProxy. Of course, it's also important to check
>that typical DataSourceTransactionManager/HibernateTransactionManager usage
>still works properly, not causing resource leaks in any scenario.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Juergen Hoeller
>Sent: Wednesday, February 16, 2005 8:20 PM
>To: spr...@li...
>Subject: [Springframework-developer] Preparing for 1.1.5
>
>
>Everybody,
>
>I've committed lots of minor fixes and enhancements that I've implemented
in
>the past two weeks (most of them driven by JIRA issues). See the changelog
>for details. The most important changes are:
>
>* I've added a "getBeanNamesForType" method to the ListableBeanFactory
>interface, also checking FactoryBeans and manual singletons (in contrast to
>"getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
>avoids creating prototype instances (assuming that all that is needed are
>the names).
>
>* TransactionSynchronization objects can influence their execution order
>through implementing the Ordered interface. This is used to always perform
>JDBC Connection cleanup last, for example after Hibernate Session cleanup
>(if any), and to always perform LobCreator cleanup first (while the JDBC
>Connection is still active).
>
>* I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
>for Image Database, to show an alternative to Commons DBCP. I've also added
>a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
>versions, SimpleNativeJdbcExtractor is sufficient.
>
>* I've upgraded MockHttpServletRequest to Servlet API 2.4 and
>MockPageContext to JSP API 2.0. An enhancement enabled by compiling against
>JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed with
>the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL
for
>earlier JSP versions.
>
>* I've reworked JasperReportsMultiFormatView, in particular the
>initialization code. I've also renamed its "discriminatorKey" property to
>"formatKey", as a more expressive name and following the
>AbstractJasperReportsView naming conventions ("reportDataKey" etc).
>
>Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar
has
>been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
>to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's ejb.jar
>with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
>(build.xml etc).
>
>Juergen
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.1.5

[Rob H. <ro...@ca...>]

I guess I should leave the MIME type support out for this release then?

Rob

Juergen Hoeller wrote:

>Spring developers, everybody,
>
>I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to go
>for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
>support, so we shouldn't lose any time. So please, test the current CVS
>contents (or a current nightly snapshot) thoroughly, and refrain from
>non-trivial code changes!
>
>One area worth re-testing, for example, is JDBC/Hibernate resource
>management: There have been some recent changes, in particular affecting a
>combination of  DataSourceTransactionManager/HibernateTransactionManager and
>TransactionAwareDataSourceProxy. Of course, it's also important to check
>that typical DataSourceTransactionManager/HibernateTransactionManager usage
>still works properly, not causing resource leaks in any scenario.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Juergen Hoeller
>Sent: Wednesday, February 16, 2005 8:20 PM
>To: spr...@li...
>Subject: [Springframework-developer] Preparing for 1.1.5
>
>
>Everybody,
>
>I've committed lots of minor fixes and enhancements that I've implemented in
>the past two weeks (most of them driven by JIRA issues). See the changelog
>for details. The most important changes are:
>
>* I've added a "getBeanNamesForType" method to the ListableBeanFactory
>interface, also checking FactoryBeans and manual singletons (in contrast to
>"getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
>avoids creating prototype instances (assuming that all that is needed are
>the names).
>
>* TransactionSynchronization objects can influence their execution order
>through implementing the Ordered interface. This is used to always perform
>JDBC Connection cleanup last, for example after Hibernate Session cleanup
>(if any), and to always perform LobCreator cleanup first (while the JDBC
>Connection is still active).
>
>* I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
>for Image Database, to show an alternative to Commons DBCP. I've also added
>a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
>versions, SimpleNativeJdbcExtractor is sufficient.
>
>* I've upgraded MockHttpServletRequest to Servlet API 2.4 and
>MockPageContext to JSP API 2.0. An enhancement enabled by compiling against
>JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed with
>the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL for
>earlier JSP versions.
>
>* I've reworked JasperReportsMultiFormatView, in particular the
>initialization code. I've also renamed its "discriminatorKey" property to
>"formatKey", as a more expressive name and following the
>AbstractJasperReportsView naming conventions ("reportDataKey" etc).
>
>Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar has
>been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
>to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's ejb.jar
>with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
>(build.xml etc).
>
>Juergen
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] Preparing for 1.1.5

[Erwin V. <erw...@er...>]

Any chance of fixing issue SPR-677 
(http://opensource.atlassian.com/projects/spring/browse/SPR-677) for 1.1.5?

Erwin Vervaet
----- Original Message ----- 
From: "Juergen Hoeller" <ju...@in...>
To: <spr...@li...>
Sent: Monday, February 21, 2005 12:10 PM
Subject: Re: [Springframework-developer] Preparing for 1.1.5


> Spring developers, everybody,
>
> I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to 
> go
> for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
> support, so we shouldn't lose any time. So please, test the current CVS
> contents (or a current nightly snapshot) thoroughly, and refrain from
> non-trivial code changes!
>
> One area worth re-testing, for example, is JDBC/Hibernate resource
> management: There have been some recent changes, in particular affecting a
> combination of  DataSourceTransactionManager/HibernateTransactionManager 
> and
> TransactionAwareDataSourceProxy. Of course, it's also important to check
> that typical DataSourceTransactionManager/HibernateTransactionManager 
> usage
> still works properly, not causing resource leaks in any scenario.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Juergen Hoeller
> Sent: Wednesday, February 16, 2005 8:20 PM
> To: spr...@li...
> Subject: [Springframework-developer] Preparing for 1.1.5
>
>
> Everybody,
>
> I've committed lots of minor fixes and enhancements that I've implemented 
> in
> the past two weeks (most of them driven by JIRA issues). See the changelog
> for details. The most important changes are:
>
> * I've added a "getBeanNamesForType" method to the ListableBeanFactory
> interface, also checking FactoryBeans and manual singletons (in contrast 
> to
> "getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
> avoids creating prototype instances (assuming that all that is needed are
> the names).
>
> * TransactionSynchronization objects can influence their execution order
> through implementing the Ordered interface. This is used to always perform
> JDBC Connection cleanup last, for example after Hibernate Session cleanup
> (if any), and to always perform LobCreator cleanup first (while the JDBC
> Connection is still active).
>
> * I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
> for Image Database, to show an alternative to Commons DBCP. I've also 
> added
> a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
> versions, SimpleNativeJdbcExtractor is sufficient.
>
> * I've upgraded MockHttpServletRequest to Servlet API 2.4 and
> MockPageContext to JSP API 2.0. An enhancement enabled by compiling 
> against
> JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed 
> with
> the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL 
> for
> earlier JSP versions.
>
> * I've reworked JasperReportsMultiFormatView, in particular the
> initialization code. I've also renamed its "discriminatorKey" property to
> "formatKey", as a more expressive name and following the
> AbstractJasperReportsView naming conventions ("reportDataKey" etc).
>
> Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar 
> has
> been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
> to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's 
> ejb.jar
> with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
> (build.xml etc).
>
> Juergen
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> 

Re: [Springframework-developer] Preparing for 1.1.5

[Juergen H. <ju...@in...>]

Spring developers, everybody,

I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to go
for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
support, so we shouldn't lose any time. So please, test the current CVS
contents (or a current nightly snapshot) thoroughly, and refrain from
non-trivial code changes!

One area worth re-testing, for example, is JDBC/Hibernate resource
management: There have been some recent changes, in particular affecting a
combination of  DataSourceTransactionManager/HibernateTransactionManager and
TransactionAwareDataSourceProxy. Of course, it's also important to check
that typical DataSourceTransactionManager/HibernateTransactionManager usage
still works properly, not causing resource leaks in any scenario.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Wednesday, February 16, 2005 8:20 PM
To: spr...@li...
Subject: [Springframework-developer] Preparing for 1.1.5


Everybody,

I've committed lots of minor fixes and enhancements that I've implemented in
the past two weeks (most of them driven by JIRA issues). See the changelog
for details. The most important changes are:

* I've added a "getBeanNamesForType" method to the ListableBeanFactory
interface, also checking FactoryBeans and manual singletons (in contrast to
"getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
avoids creating prototype instances (assuming that all that is needed are
the names).

* TransactionSynchronization objects can influence their execution order
through implementing the Ordered interface. This is used to always perform
JDBC Connection cleanup last, for example after Hibernate Session cleanup
(if any), and to always perform LobCreator cleanup first (while the JDBC
Connection is still active).

* I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
for Image Database, to show an alternative to Commons DBCP. I've also added
a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
versions, SimpleNativeJdbcExtractor is sufficient.

* I've upgraded MockHttpServletRequest to Servlet API 2.4 and
MockPageContext to JSP API 2.0. An enhancement enabled by compiling against
JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed with
the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL for
earlier JSP versions.

* I've reworked JasperReportsMultiFormatView, in particular the
initialization code. I've also renamed its "discriminatorKey" property to
"formatKey", as a more expressive name and following the
AbstractJasperReportsView naming conventions ("reportDataKey" etc).

Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar has
been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's ejb.jar
with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
(build.xml etc).

Juergen



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: Hibernate3 in sandbox

[Juergen H. <ju...@in...>]

As I said before, I intend to create a fresh port of the current Hibernate
2.1 support, adapting Hibernate API calls where necessary. There've been
many refinements in the details in the Spring 1.1.x branch, and I wouldn't
want to lose any of those in the Hibernate support.

Ideally, we should release 1.1.5 ASAP: I'd like to stick with this Sunday,
as a hard deadline. I would then immediately go for adding the Hibernate3
support to the main sources, with a first snapshot probably available by
Monday evening.

Unfortunately, I'm quite constrained in my time this week, so I'll hardly
find time to put Hibernate3 support into the sandbox earlier than that. I'll
rather use my time to address any remaining issues for Spring 1.1.5.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Artur Karazniewicz
Sent: Friday, February 18, 2005 7:27 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Hibernate3 in sandbox


Colin Sampaleanu wrote:

> +1.
>
> My only concern with using the patch in JIRA vs. making a new tree of
> code based on existing one is if the patch has really been kept up to
> date properly. There have been a pretty large number of Hibernate code
> changes/fixes since then. It seems a shame to throw away that work, but
> on the other hand it might be safer to start from scratch...

I did the first patch and know that there were a lot of changes in classic
hibernate support in spring since then (both in implementation and test
suite). It would be much better to make fresh copy of hibernate into
sandbox tree and refactor it. It took me two evnings using Elipse to
prepare patch included in SPR-300 JIRA, to be honest most of time I spent
learning MockObjects :)).

Artur

--
,,Wine, jako emulator Windows...'' -- WO, pcoa
,,As Wine's name says: "Wine Is Not an Emulator"'' -- WineHQ, FAQ



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Potentialt dangerous hibernate Session reuse

[Steven D. <ste...@gm...>]

A possible solution could be to define in the transaction demarcation
setup if sessions need to kept open until the end of the request.


On Mon, 21 Feb 2005 09:28:41 +0100, Per Olesen <po...@no...> wrote:
> 
> >
> > Yes, that's exactly how it would work, if you did indeed call down into
> > the tx wrapped service layer multiple times. Of course, it's usually not
> > appropriate to combine data from multiple transactions anyway, but one
> > common case of this is where you call down to get the form backing
> > object contents, and then later call down again with the modified
> > object. The deferred close strategy blows up in this scenario. One
> > workaround which Spring MVC makes pretty easy is to keep your form
> > backing object in the session session, from the previous get. Then you
> > end up only doing one call down into tx layer to apply changes.   But
> > this _is_ a limitation, of course.
> >
> 
> Hmm yeah, we did think about that too. Actually, we thought about it before
> deciding to use OpenSessionInView pattern, as using this pattern is exactly
> about accepting multiple calls into the tx layer to get more easy view
> development.
> 
> This is also why I cannot see how the deferred close option will be an option
> for anyone to solve this problem, cause all using OpenSessionInView will have
> multiple calls from their view to back forms. This is one of the central
> ideas of using OpenSessionInView.
> 
> Regards, Per
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>

Re: [Springframework-developer] Potentialt dangerous hibernate Session reuse

[Per O. <po...@no...>]

>
> Yes, that's exactly how it would work, if you did indeed call down into
> the tx wrapped service layer multiple times. Of course, it's usually not
> appropriate to combine data from multiple transactions anyway, but one
> common case of this is where you call down to get the form backing
> object contents, and then later call down again with the modified
> object. The deferred close strategy blows up in this scenario. One
> workaround which Spring MVC makes pretty easy is to keep your form
> backing object in the session session, from the previous get. Then you
> end up only doing one call down into tx layer to apply changes.   But
> this _is_ a limitation, of course.
>

Hmm yeah, we did think about that too. Actually, we thought about it before 
deciding to use OpenSessionInView pattern, as using this pattern is exactly 
about accepting multiple calls into the tx layer to get more easy view 
development.

This is also why I cannot see how the deferred close option will be an option 
for anyone to solve this problem, cause all using OpenSessionInView will have 
multiple calls from their view to back forms. This is one of the central 
ideas of using OpenSessionInView.

Regards, Per

RE: [Springframework-developer] Custom bean instantiation language?

[Cameron B. <ca...@br...>]

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Jean-Philippe Gariepy
> Sent: Monday, 21 February 2005 12:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Custom bean instantiation
> language?
> 
> (This is an opportunity for me to share my thoughts about the bean
> factory.)

--SNIP--

> I've added other lightweight syntaxes for lists and maps.
> 

Can you please share them too. I like the look of this :)


Thanks,

Cameron

Re: [Springframework-developer] Custom bean instantiation language?

[Jean-Philippe G. <ga...@ya...>]

(This is an opportunity for me to share my thoughts about the bean factory.)

I think the current XML syntax for the BeanFactory is very verbose.  Two years
ago, I developed my own BeanFactory based on Rod Johnson's initial
XmlBeanFactory (before Spring was born).  I'm still using this customized
BeanFactory today.  First thing I did was to remove extra XML elements that
were always implied by the context (like '<bean>' and '<property>').

So instead of...
<bean name="myBean" class="myclass">
  <property name="myProperty>value</property>
</bean>

...I only need...
<myBean class="myclass">
  <myProperty>value</myProperty>
</myBean>

This is more readable and much more terse.  The price to pay for that: I cannot
have XML grammar validation (such as DTD or Schema) but I see little value in
that (at least, for my own needs).  My XML editor can still find errors if my
document is not well-formed.

The second step I took was to add a special syntax for bean references (using
the @ symbol:

So...
<bean name="beanA" class="ClassA"/>

<bean name="beanB" class="ClassB">
 <property name="otherBean" beanRef="true">beanA</property>
</bean>

...can be expressed simply as...

<beanA class="ClassA"/>

<beanB class="ClassB">
  <otherBean>@beanA</otherBean>
</beanB>

I've added other lightweight syntaxes for lists and maps.

The third major change I did was to allow bean definitions to be overridden by
values specified in other files.  In Spring, you would use the
PropertyResourceConfigurer instead to resolve similar (but not all) problems.  

For instance, I have the following 3 files:

========base-config.xml (base configuration for the prod):
<beans>
  <logger class="com.xyz.Logger">
    <file>/var/log/app/log.txt</file>
    <level>ERROR</level>
  </logger>

  <messageMailer class="com.xyz.Mailer">
    <smtpHostname>mail.xyz.com</smtpHostName>
    <address>ab...@xy...</address>
  </messageMailer>
</beans>

========development-environment.xml (overidding for all the developers):
<beans>
  <logger>
    <level>INFO</level>
  </logger>
</beans>

========user.xml (developer specific overriding file):
<beans>
  <mailer>
    <address>us...@xy...</address>
  </mailer>
</beans>

I create the BeanFactory using the 3 files:

//not very accurate but you can get the idea...
BeanDefinitionContainer container = new BeanDefinitionContainer();
container.add(new XmlBeanDefinitionSource("base-config.xml"));
container.add(new XmlBeanDefinitionSource("development-environment.xml"));
container.add(new XmlBeanDefinitionSource("user.xml"));
BeanFactory factory = new BeanFactory(container);

The bean factory (the definition container, in fact) will read the 3 files and
merge property definitions specified in each files.  This is very handy when
you need to have multiple levels of configuration.  This lets you assemble
configurations in a very flexible manner.  I think this is interesting because
an "override file" shares the same syntax (and power) as a regular bean
definition file.

The key to a "custom bean instantiation language" is to keep bean definitions
separated from the BeanFactory.  Currently, in Spring,
DefaultListableBeanFactory plays both roles (it's a BeanFactory and a
BeanDefinitionRegistry).  Although both interfaces exists in the framework,
they are not used separately.

Having a definition container (or registry) allows the modification of the bean
definitions before they are used by the bean factory.  For example, I have a
CommandLineBeanDefinitionOverride class that modifies bean definition based on
command-line arguments.  

public class MyMain
{
  public static void main(String[] args)
  {
    BeanDefinitionContainer container = new BeanDefinitionContainer();
    container.add(new XmlBeanDefinitionSource("base-config.xml"));
    container.add(new XmlBeanDefinitionSource("development-environment.xml"));
    container.add(new XmlBeanDefinitionSource("user.xml"));

    args = CommandLineBeanDefinitionOverride.processArguments(args, container);
    BeanFactory factory = new BeanFactory(container); 
    ...
  }
}

I can invoke my java app and change bean values:

$java MyTest --logger +level=DEBUG

I use "--" to specify bean name and "+" to specify property name.  This opens
up bean definitions customization beyond XML configuration file.


I'm not totally familiar with the Spring framework and maybe it's already
possible to do everything I've explained above.  I just wanted to talk about my
experience about the subject.

Jean-Philippe

--- Paul Galbraith <pa...@pa...> wrote:
> Paul Galbraith wrote:
> 
> > jbetancourt wrote:
> >
> >> There is support for scripting.  I think it is part of the sandbox.  
> >> Thus,
> >> you can use Beanshell, Groovy, etc.
> >>
> >> But, not sure if this is meant as a 'custom language' for bean
> >> instantiation.
> >>
> >>  
> >>
> > That might do the trick...can I use a groovy script to wire up my bean 
> > factories?
> >
> After thinking about this, I doubt scripting is what I'm interested 
> in...I imagine that any creation of a BeanFactory through a scripting 
> engine is still ultimately using the documented core Spring API?
> 
> I'm more interested in something declarative, such as the XML 
> declarations that are documented in the online reference...my motivation 
> for raising the idea is simply that XML isn't a great language to use 
> for interfacing with people.  I was thinking of something more 
> java-like, such as a bean definition like:
> 
> singleton my.package.MyClass my.beannamespace.myBean 
> (my.beannamespace.myBean2) {
>         property String stringProperty "string-property";
>         property my.pacakge.myClass3 my.beannamespace.myBean3;
> }
> 
> Obviously I haven't put a whole lot of thought into it...just wondering 
> if the same thing's already been discussed or considered?
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

=====
---------------------------------------
Jean-Philippe Gariépy (ga...@ya...)

"Quand l'appétit va, tout va." 
                       -Obélix


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

[Springframework-developer] DelegatingActionProxy & setServlet()

[John G. <ig...@do...>]

Hi,

Actions wrapped by DelegatingActionProxy never have their setServlet()
method called. Does the following patch make sense?

	John

--- src/org/springframework/web/struts/DelegatingActionProxy.java.orig  2004-12-11 15:47:46.000000000 +0200
+++ src/org/springframework/web/struts/DelegatingActionProxy.java       2005-02-20 21:18:37.647013908 +0200
@@ -117,8 +117,10 @@
         */
        protected Action getDelegateAction(ActionMapping mapping) throws BeansException {
                WebApplicationContext wac = getWebApplicationContext(getServlet(), mapping.getModuleConfig());
-               String beanName = determineActionBeanName(mapping);
-               return (Action) wac.getBean(beanName, Action.class);
+               String beanName = determineActionBeanName(mapping);
+               Action action = (Action) wac.getBean(beanName, Action.class);
+               action.setServlet(getServlet());
+               return action;
        }

        /**

Re: [Springframework-developer] Custom bean instantiation language?

[Paul G. <pa...@pa...>]

Paul Galbraith wrote:

> jbetancourt wrote:
>
>> There is support for scripting.  I think it is part of the sandbox.  
>> Thus,
>> you can use Beanshell, Groovy, etc.
>>
>> But, not sure if this is meant as a 'custom language' for bean
>> instantiation.
>>
>>  
>>
> That might do the trick...can I use a groovy script to wire up my bean 
> factories?
>
After thinking about this, I doubt scripting is what I'm interested 
in...I imagine that any creation of a BeanFactory through a scripting 
engine is still ultimately using the documented core Spring API?

I'm more interested in something declarative, such as the XML 
declarations that are documented in the online reference...my motivation 
for raising the idea is simply that XML isn't a great language to use 
for interfacing with people.  I was thinking of something more 
java-like, such as a bean definition like:

singleton my.package.MyClass my.beannamespace.myBean 
(my.beannamespace.myBean2) {
        property String stringProperty "string-property";
        property my.pacakge.myClass3 my.beannamespace.myBean3;
}

Obviously I haven't put a whole lot of thought into it...just wondering 
if the same thing's already been discussed or considered?

Re: [Springframework-developer] Custom bean instantiation language?

[Paul G. <pa...@pa...>]

jbetancourt wrote:

>There is support for scripting.  I think it is part of the sandbox.  Thus,
>you can use Beanshell, Groovy, etc.
>
>But, not sure if this is meant as a 'custom language' for bean
>instantiation.
>
>  
>
That might do the trick...can I use a groovy script to wire up my bean 
factories?

>----- Original Message ----- 
>From: "Paul Galbraith" <pa...@pa...>
>To: <spr...@li...>
>Sent: Saturday, February 19, 2005 2:23 PM
>Subject: [Springframework-developer] Custom bean instantiation language?
>
>
>  
>
>>A quick search didn't turn up anything in the archive...has anyone given
>>serious thought to a custom language to replace the XML bean
>>instantiation definitions that seem to be the current standard?
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Potentialt dangerous hibernate Session reuse

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

Per Olesen wrote:

> Nick Minutello wrote:
>
>>>> Hence, one web request will quickly
>>>> use many connections, at the same time.
>>>
>>
>>
>> How so? Why should there be more than one session for a given request?
>>
>
> If the web-layer of the application calls multiple methods into the 
> services layer where each method performs hibernate work, a new 
> session will be opened for each hibernate call. That is of course, if 
> "defferred close" is set on the filter.
>
> Isn't that how it works? At least, that was what we experienced when 
> we tried it.

Yes, that's exactly how it would work, if you did indeed call down into 
the tx wrapped service layer multiple times. Of course, it's usually not 
appropriate to combine data from multiple transactions anyway, but one 
common case of this is where you call down to get the form backing 
object contents, and then later call down again with the modified 
object. The deferred close strategy blows up in this scenario. One 
workaround which Spring MVC makes pretty easy is to keep your form 
backing object in the session session, from the previous get. Then you 
end up only doing one call down into tx layer to apply changes.   But 
this _is_ a limitation, of course.

Colin

Re: [Springframework-developer] Potentialt dangerous hibernate Session reuse

[Per O. <po...@no...>]

Nick Minutello wrote:
>>>Hence, one web request will quickly
>>>use many connections, at the same time.
> 
> 
> How so? Why should there be more than one session for a given request?
> 

If the web-layer of the application calls multiple methods into the 
services layer where each method performs hibernate work, a new session 
will be opened for each hibernate call. That is of course, if "defferred 
close" is set on the filter.

Isn't that how it works? At least, that was what we experienced when we 
tried it.

/Per

Re: [Springframework-developer] Custom bean instantiation language?

[jbetancourt <jbe...@co...>]

There is support for scripting.  I think it is part of the sandbox.  Thus,
you can use Beanshell, Groovy, etc.

But, not sure if this is meant as a 'custom language' for bean
instantiation.


----- Original Message ----- 
From: "Paul Galbraith" <pa...@pa...>
To: <spr...@li...>
Sent: Saturday, February 19, 2005 2:23 PM
Subject: [Springframework-developer] Custom bean instantiation language?


> A quick search didn't turn up anything in the archive...has anyone given
> serious thought to a custom language to replace the XML bean
> instantiation definitions that seem to be the current standard?
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Custom bean instantiation language?

[Paul G. <pa...@pa...>]

A quick search didn't turn up anything in the archive...has anyone given 
serious thought to a custom language to replace the XML bean 
instantiation definitions that seem to be the current standard?

Re: [Springframework-developer] Version Numbers for JAR Files

[Nick M. <nic...@gm...>]

The first thing I do after downloading spring is rename the jars to
embed the version...

so its +1 here... :-)

-Nick


On Fri, 18 Feb 2005 22:08:27 +0000, Rob Harrop <ro...@ca...> wrote:
> I'd like to propose that we add version numbers to all JAR files going
> forward from 1.1.5. This would really help when managing many apps on
> different versions of Spring and, I think, it wouldn't take too much
> time during the release.
> 
> Rob
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Potentialt dangerous hibernate Session reuse

[Nick M. <nic...@gm...>]

>> Hence, one web request will quickly
>> use many connections, at the same time.

How so? Why should there be more than one session for a given request?

-Nick

On Mon, 14 Feb 2005 16:36:19 +0100, Per Olesen <po...@no...> wrote:
> Hi Juergen,
> 
> Thank you for your comments.
> 
> On Monday 14 February 2005 16:13, Juergen Hoeller wrote:
> >
> > I am aware of the Hibernate docs that the Session needs to be discarded
> > when an exception was thrown. However, I find that an overly strict
> > statement (just like "there is no such thing as a non-transactional
> > Session", their famous statement from their forums mid last year).
> 
> Okay, i tend to agree about it being an overly strict statement, also because
> I've looked into SessionImpl.clear() and it does what we want :-) ... but:
> When they've explicitly stated that a Session should not be reused in case of
> exception, upcoming implementations of Session might break spring then. Can
> it not?
> 
> > Session.clear should be good enough for resetting an OSIV Session after a
> > rollback. It's probably advisable to not use OSIV in single session mode at
> > all if you want to avoid side effects completely. (Closing the Session and
> > opening a new one during OSIV doesn't really add value here.)
> 
> It will add the value that:
>  1) the failing session is thrown away
>  2) new calls into spring-managed beans will operate fine on the new session
> 
> I know, that lazy-loading of objects from dead session will fail.
> 
> > Have you considered using OpenSessionInViewFilter in "deferred close mode",
> > that is, with the "singleSession" flag turned off? In that case, each
> > transaction will use its own Hibernate Session, but all of those Sessions
> > will be kept open until view rendering has completed.
> 
> Yes, actually I have tried it out. But this solution does not scale very well.
> A JDBC connection is assigned to each hibernate Session, so using deferred
> close uses a connection for each session. Hence, one web request will quickly
> use many connections, at the same time.
> 
> Per
> 
> --
> Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
> email: po...@no... - cell#: +45 23 38 95 81
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Version Numbers for JAR Files

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

I think we need to discuss this in detail first. However, I think if we were to switch, 1.2 RC1 would be the best time 
to do it. People will expect that 1.1.5 will be a drop-in replacement, rather than changing their build process.

R

Rob Harrop wrote:
> I'd like to propose that we add version numbers to all JAR files going 
> forward from 1.1.5. This would really help when managing many apps on 
> different versions of Spring and, I think, it wouldn't take too much 
> time during the release.
> 
> Rob
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 

____________________________________________________
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

Re: [Springframework-developer] Version Numbers for JAR Files

[Eugene K. <eu...@pl...>]

Matt,

   Wouldn't you copy different jars under different app/WEB-INF/lib 
dirs? Because if not, then you will have to resolve jar versions anyways 
(well, sooner or later) and with versions in jar names it is much easier.

   regards,
   Eugene

> The main problem with this is one of deployment.  You might end up with 
> classpath issues because developers will just copy JARs (i.e. in a 
> webapp) to their server.  With the current way, new version overwrites 
> old.  New way = 2 spring JARs.  If you have good production deployment 
> procedures, it's probably not an issue, but it might lead to more 
> questions on the forums. My $0.02.
> 
> Matt
> 
> 
> On Feb 18, 2005, at 3:08 PM, Rob Harrop wrote:
> 
>> I'd like to propose that we add version numbers to all JAR files going 
>> forward from 1.1.5. This would really help when managing many apps on 
>> different versions of Spring and, I think, it wouldn't take too much 
>> time during the release.
>>
>> Rob
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Version Numbers for JAR Files

[Matt R. <li...@ra...>]

The main problem with this is one of deployment.  You might end up with 
classpath issues because developers will just copy JARs (i.e. in a 
webapp) to their server.  With the current way, new version overwrites 
old.  New way = 2 spring JARs.  If you have good production deployment 
procedures, it's probably not an issue, but it might lead to more 
questions on the forums. My $0.02.

Matt


On Feb 18, 2005, at 3:08 PM, Rob Harrop wrote:

> I'd like to propose that we add version numbers to all JAR files going 
> forward from 1.1.5. This would really help when managing many apps on 
> different versions of Spring and, I think, it wouldn't take too much 
> time during the release.
>
> Rob
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Version Numbers for JAR Files

[Rob H. <ro...@ca...>]

I'd like to propose that we add version numbers to all JAR files going 
forward from 1.1.5. This would really help when managing many apps on 
different versions of Spring and, I think, it wouldn't take too much 
time during the release.

Rob

Re: [Springframework-developer] xsl transforms

[David B. <viv...@gm...>]

I do like that idea, but let me mention a few downsides.

One place where it might not be as flexible is in specifying where the
resource is.  For example, you couldn't do:
<?xml-stylesheet href="classpath:/transform.xsl" type="text/xml"?>

If we plugged in a new javax.xml.transform.URIResolver, we might be
able to still resolve paths using  Spring specific URI prefixes.

Along these same lines, it seems like it would be more desirable to
specify an xsl transform outside the XML file.  If I'm using the same
xml context file for both production and for a unit test, I can easily
specify the same file using different paths.  For example, in a
running web app, the path would be /WEB-INF/appContext.xml, but if I'm
running a UnitTest using FileSystemXMLApplicationContext, I might want
to specify an absolute path to create my context.  By this same token,
it would be nice to be able to specify the location of the XSL
transform from outside the spring context file itself.

So my preference would be a syntax like this:
transform:/(customContext.xml, customTransform.xsl). 

We could recurse through the "parameters" to the URI-type
specification, so if someone .really wanted to hang themselves, they
could put a file through multiple transforms, using sources from the
classpath or normal URL.

Maybe support of inline xsl should be supported in addition.

/David Bowers


On Fri, 18 Feb 2005 18:48:46 +0200, Juha Komulainen
<juh...@gm...> wrote:
> Actually the XML-file itself can specify the used XSL-stylesheet by
> having a processing instruction like:
> 
>   <?xml-stylesheet href="transform.xsl" type="text/xml"?>
> 
> (See http://www.w3.org/TR/xml-stylesheet/ for details.)
> 
> Unfortunately, by default XML-parsers (or at least Xerces) won't try
> to apply the specified XSLT-stylesheets when parsing. Still, it's easy
> enough by loading the document with a transformer:
> 
>     Source source = new StreamSource(file);
>     TransformerFactory tf = TransformerFactory.newInstance();
> 
>     // Extract the stylesheet from document, if there is one
>     Source stylesheet = tf.getAssociatedStylesheet(source, null, null, null);
> 
>     // If document had stylesheet, use it. Otherwise use identity transform.
>     Transformer transformer = stylesheet != null
>                             ? tf.newTransformer(stylesheet)
>                             : tf.newTransformer();
> 
>     DOMResult result = new DOMResult();
>     transformer.transform(source, result);
>     Document document = (Document) result.getNode();
> 
> So if Spring would load the context-files using this strategy it would
> be possible to get XSL-transforms for free.
> 
> Are there any problems with this solution?

[Springframework-developer] Re: Hibernate3 in sandbox

[Artur K. <kar...@as...>]

Colin Sampaleanu wrote:

> +1.
> 
> My only concern with using the patch in JIRA vs. making a new tree of
> code based on existing one is if the patch has really been kept up to
> date properly. There have been a pretty large number of Hibernate code
> changes/fixes since then. It seems a shame to throw away that work, but
> on the other hand it might be safer to start from scratch...

I did the first patch and know that there were a lot of changes in classic
hibernate support in spring since then (both in implementation and test
suite). It would be much better to make fresh copy of hibernate into
sandbox tree and refactor it. It took me two evnings using Elipse to
prepare patch included in SPR-300 JIRA, to be honest most of time I spent
learning MockObjects :)).

Artur

-- 
,,Wine, jako emulator Windows...'' -- WO, pcoa
,,As Wine's name says: "Wine Is Not an Emulator"'' -- WineHQ, FAQ