springframework-developer — Spring Framework developers list

[Springframework-developer] Spring build.51 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring WebFlow build.27 SUCCEEDED

[<al...@in...>]

    			Snapshot has been uploaded to http://static.springframework.org/downloads/nightly/spring-webflow
    			
    			The list of modifications for this build can be found in the build log (http://static.springframework.org/spring-webflow/build/index.html).    			
			

[Springframework-developer] Spring build.50 SUCCEEDED

[<ale...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.50 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

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

You mean a setting at the application context level that determines the
lazy-init semantics? Where would you specify that? I guess in the end it
comes down to tweaking the XML bean definition files again...

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Erwin Vervaet
Sent: Monday, June 19, 2006 9:18 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Changed behavior
fordefault-lazy-init="true" in 2.0 M5

Absolutely.

Maybe we should have a setting to switch to Spring 1.x lazy-init semantics?

Erwin Vervaet
erw...@er...
----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, June 19, 2006 2:01 AM
Subject: Re: [Springframework-developer] Changed behavior for
default-lazy-init="true" in 2.0 M5


>I think this makes sense, personally, although it does mean most apps  
>marked with the default lazy init set to true will probably have to 
>have  their config tweaked. I guess we need to really emphasize this 
>change in  the change docs.
>
> Colin
>
> On 6/18/2006 7:40 PM, Juergen Hoeller wrote:
>
>>This is actually expected behavior: lazy-init has stronger effect in 
>>Spring 2.0 now, not even loading the affected bean classes until they 
>>are explicitly accessed.
>>
>>For an application context's type detection (such as 
>>BeanFactoryPostProcessor detection or ApplicationListener detection), 
>>we only check beans that allow for eager initialization now (i.e. that 
>>are not marked as lazy-init and are not FactoryBeans).
>>
>>Else we'd have to load each and every bean class just to find out 
>>those special beans, which would require all bean classes to be 
>>present and loadable - and exactly that is what we intend to avoid 
>>with the new semantics in the first place.
>>
>>A further goodie enabled by lazy class loading for lazy-init beans is 
>>that a PropertyPlaceholderConfigurer can even resolve placeholders in 
>>bean class names now, at least for beans marked as lazy-init.
>>
>>So the recommended solution in case of default-lazy-init=true would be 
>>to explicitly mark all affected beans (the ones supposed to be 
>>autodetected) as lazy-init=false.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On 
>>Behalf Of Claus Nordahl
>>Sent: Sunday, June 11, 2006 2:26 AM
>>To: spr...@li...
>>Subject: [Springframework-developer] Changed behavior for 
>>default-lazy-init="true" in 2.0 M5
>>
>>Hi all,
>>
>>When using default-lazy-init="true" with the 2.0 M5 release, I find 
>>that neither does my PropertyPlaceholderConfigurer's do its stuff nor 
>>does my ApplicationListener's receive any events as they all did with 
>>previous releases.
>>
>>Is this expected behavior?
>>
>>Regards,
>>Claus Nordahl
>>
>>
>>
>>
>>_______________________________________________
>>Springframework-developer mailing list 
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>_______________________________________________
>>Springframework-developer mailing list 
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
>
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 



_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changed behavior for default-lazy-init="true" in 2.0 M5

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

Absolutely.

Maybe we should have a setting to switch to Spring 1.x lazy-init semantics?

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, June 19, 2006 2:01 AM
Subject: Re: [Springframework-developer] Changed behavior for 
default-lazy-init="true" in 2.0 M5


>I think this makes sense, personally, although it does mean most apps
> marked with the default lazy init set to true will probably have to have
> their config tweaked. I guess we need to really emphasize this change in
> the change docs.
>
> Colin
>
> On 6/18/2006 7:40 PM, Juergen Hoeller wrote:
>
>>This is actually expected behavior: lazy-init has stronger effect in 
>>Spring
>>2.0 now, not even loading the affected bean classes until they are
>>explicitly accessed.
>>
>>For an application context's type detection (such as
>>BeanFactoryPostProcessor detection or ApplicationListener detection), we
>>only check beans that allow for eager initialization now (i.e. that are 
>>not
>>marked as lazy-init and are not FactoryBeans).
>>
>>Else we'd have to load each and every bean class just to find out those
>>special beans, which would require all bean classes to be present and
>>loadable - and exactly that is what we intend to avoid with the new
>>semantics in the first place.
>>
>>A further goodie enabled by lazy class loading for lazy-init beans is that 
>>a
>>PropertyPlaceholderConfigurer can even resolve placeholders in bean class
>>names now, at least for beans marked as lazy-init.
>>
>>So the recommended solution in case of default-lazy-init=true would be to
>>explicitly mark all affected beans (the ones supposed to be autodetected) 
>>as
>>lazy-init=false.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>Of Claus Nordahl
>>Sent: Sunday, June 11, 2006 2:26 AM
>>To: spr...@li...
>>Subject: [Springframework-developer] Changed behavior for
>>default-lazy-init="true" in 2.0 M5
>>
>>Hi all,
>>
>>When using default-lazy-init="true" with the 2.0 M5 release, I find that
>>neither does my PropertyPlaceholderConfigurer's do its stuff nor does my
>>ApplicationListener's receive any events as they all did with previous
>>releases.
>>
>>Is this expected behavior?
>>
>>Regards,
>>Claus Nordahl
>>
>>
>>
>>
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

Re: [Springframework-developer] Changed behavior for default-lazy-init="true" in 2.0 M5

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

I think this makes sense, personally, although it does mean most apps 
marked with the default lazy init set to true will probably have to have 
their config tweaked. I guess we need to really emphasize this change in 
the change docs.

Colin

On 6/18/2006 7:40 PM, Juergen Hoeller wrote:

>This is actually expected behavior: lazy-init has stronger effect in Spring
>2.0 now, not even loading the affected bean classes until they are
>explicitly accessed.
>
>For an application context's type detection (such as
>BeanFactoryPostProcessor detection or ApplicationListener detection), we
>only check beans that allow for eager initialization now (i.e. that are not
>marked as lazy-init and are not FactoryBeans).
>
>Else we'd have to load each and every bean class just to find out those
>special beans, which would require all bean classes to be present and
>loadable - and exactly that is what we intend to avoid with the new
>semantics in the first place.
>
>A further goodie enabled by lazy class loading for lazy-init beans is that a
>PropertyPlaceholderConfigurer can even resolve placeholders in bean class
>names now, at least for beans marked as lazy-init.
>
>So the recommended solution in case of default-lazy-init=true would be to
>explicitly mark all affected beans (the ones supposed to be autodetected) as
>lazy-init=false.
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf
>Of Claus Nordahl
>Sent: Sunday, June 11, 2006 2:26 AM
>To: spr...@li...
>Subject: [Springframework-developer] Changed behavior for
>default-lazy-init="true" in 2.0 M5
>
>Hi all,
>
>When using default-lazy-init="true" with the 2.0 M5 release, I find that
>neither does my PropertyPlaceholderConfigurer's do its stuff nor does my
>ApplicationListener's receive any events as they all did with previous
>releases.
>
>Is this expected behavior?
>
>Regards,
>Claus Nordahl
>
>
>
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

Re: [Springframework-developer] Changed behavior for default-lazy-init="true" in 2.0 M5

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

This is actually expected behavior: lazy-init has stronger effect in Spring
2.0 now, not even loading the affected bean classes until they are
explicitly accessed.

For an application context's type detection (such as
BeanFactoryPostProcessor detection or ApplicationListener detection), we
only check beans that allow for eager initialization now (i.e. that are not
marked as lazy-init and are not FactoryBeans).

Else we'd have to load each and every bean class just to find out those
special beans, which would require all bean classes to be present and
loadable - and exactly that is what we intend to avoid with the new
semantics in the first place.

A further goodie enabled by lazy class loading for lazy-init beans is that a
PropertyPlaceholderConfigurer can even resolve placeholders in bean class
names now, at least for beans marked as lazy-init.

So the recommended solution in case of default-lazy-init=true would be to
explicitly mark all affected beans (the ones supposed to be autodetected) as
lazy-init=false.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Claus Nordahl
Sent: Sunday, June 11, 2006 2:26 AM
To: spr...@li...
Subject: [Springframework-developer] Changed behavior for
default-lazy-init="true" in 2.0 M5

Hi all,

When using default-lazy-init="true" with the 2.0 M5 release, I find that
neither does my PropertyPlaceholderConfigurer's do its stuff nor does my
ApplicationListener's receive any events as they all did with previous
releases.

Is this expected behavior?

Regards,
Claus Nordahl




_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring build.49 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Spring 2.0-M5DefaultMessageListenerContainer.executeListener() infinite loop

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

Andrew,

I've reworked DefaultMessageListenerContainer's exception handling for 2.0
RC1. There is an explicit "handleListenerSetupFailure" callback now, a
sibling of "handleListenerException" that will be invoked for
Session/MessageConsumer failures. DefaultMessageListenerContainer also
invokes a specified JMS ExceptionListener for listener setup failures as
well now.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Andrew Smallbone
Sent: Tuesday, June 13, 2006 7:39 PM
To: spr...@li...
Subject: [Springframework-developer] Spring
2.0-M5DefaultMessageListenerContainer.executeListener() infinite loop

I'm exploring the jms features in spring 2.0-M5 - In particular the
listener/containers.
I think I've found a bug (or a feature when using TIB EMS) I'm trying to
write an ExceptionListener which will be able to recover from JMS server
connection failures.
If I kill the network connection from my application to the JMS server, TIB
throws an exception when MessageConsumer.receive() is next called.
DefaultMessageListenerContainer.executeListener() treats this as a listener
exception, logs it, and calls receive again, resulting in an infinite loop
(trace below).

Is this the correct behaviour or should the ExceptionListener be called for
this kind of error?
Any other approaches to recovering from connection failures?
regards
Andrew



[ERROR] 13:19:27,661
springframework.jms.listener.DefaultMessageListenerContainer - Execution of
JMS message listener failed
javax.jms.IllegalStateException: Consumer is closed
        at
com.tibco.tibjms.TibjmsMessageConsumer._receive(TibjmsMessageConsumer.java:2
06)
        at
com.tibco.tibjms.TibjmsMessageConsumer.receive(TibjmsMessageConsumer.java:35
5)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer.doExecuteLi
stener(DefaultMessageListenerContainer.java:301)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer.executeList
ener(DefaultMessageListenerContainer.java:292)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessag
eListenerInvoker.run(DefaultMessageListenerContainer.java:369)
        at
org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingR
unnable.run(SimpleAsyncTaskExecutor.java:203)
        at java.lang.Thread.run(Thread.java:595)
Java Result: 1



--
Andrew Smallbone <an...@ro...>


_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring build.48 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.47 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.46 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.45 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.44 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.44 SUCCEEDED

[<ale...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.43 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring 2.0-M5 DefaultMessageListenerContainer.executeListener() infinite loop

[Andrew S. <an...@ro...>]

I'm exploring the jms features in spring 2.0-M5 - In particular the
listener/containers.
I think I've found a bug (or a feature when using TIB EMS)
I'm trying to write an ExceptionListener which will be able to recover
from JMS server connection failures.
If I kill the network connection from my application to the JMS
server, TIB throws an exception when MessageConsumer.receive() is next
called.
DefaultMessageListenerContainer.executeListener() treats this as a
listener exception, logs it, and calls receive again, resulting in an
infinite loop (trace below).

Is this the correct behaviour or should the ExceptionListener be
called for this kind of error?
Any other approaches to recovering from connection failures?
regards
Andrew



[ERROR] 13:19:27,661
springframework.jms.listener.DefaultMessageListenerContainer -
Execution of JMS message listener failed
javax.jms.IllegalStateException: Consumer is closed
        at
com.tibco.tibjms.TibjmsMessageConsumer._receive(TibjmsMessageConsumer.java:206)
        at
com.tibco.tibjms.TibjmsMessageConsumer.receive(TibjmsMessageConsumer.java:355)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer.doExecuteListener(DefaultMessageListenerContainer.java:301)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer.executeListener(DefaultMessageListenerContainer.java:292)
        at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:369)
        at
org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsyncTaskExecutor.java:203)
        at java.lang.Thread.run(Thread.java:595)
Java Result: 1



-- 
Andrew Smallbone <an...@ro...>

[Springframework-developer] Spring build.42 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] org/springframework/ui/freemarker notin spring-context.jar

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

This is part of a deliberate repackaging in M5: the UI support classes now
reside in spring-support.jar rather than spring-context.jar, mainly to keep
the latter focused on the core container rather than integration code. 

The exact separation between the module jars for Spring 2.0 is still open
for debate. The hard part there is to draw the line between "natural"
modules from the framework perspective on the one hand and typical usage
models from the application perspective on the other hand, in combination
with the external dependencies implied by each jar.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of fi...@ex...
Sent: Tuesday, June 13, 2006 4:03 AM
To: spr...@li...
Subject: [Springframework-developer] org/springframework/ui/freemarker notin
spring-context.jar


It appears the spring-framework-2.0-rc1-build.41-20060613.zip and
spring-framework-2.0-m5.zip both contain
spring-framework*/dist/modules/spring-context.jar, but that jar file does
not contain the package org/springframework/ui/freemarker and contained
class files.  As of the M4 build spring-context.jar contained that package.
The spring.jar file does contain that package, so it looks like it may be a
build configuration error.  This is true for both the with-dependencies and
normal zip files.



Is this an intentional change, or a bug?  

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!




_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] org/springframework/ui/freemarker not in spring-context.jar

[<fi...@ex...>]

It appears the spring-framework-2.0-rc1-build.41-20060613.zip and spring-framework-2.0-m5.zip both contain spring-framework*/dist/modules/spring-context.jar, but that jar file does not contain the package org/springframework/ui/freemarker and contained class files.  As of the M4 build spring-context.jar contained that package.  The spring.jar file does contain that package, so it looks like it may be a build configuration error.  This is true for both the with-dependencies and normal zip files.



Is this an intentional change, or a bug?  

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

[Springframework-developer] Spring build.41 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring Web Service 1.0 M1 Released

[Arjen P. <ar...@in...>]

Dear Spring community,

I'm pleased to announce that Spring Web Services 1.0 M1 has been  
released. 1.0 M1 is the first milestone of Spring-WS: a product of  
the Spring community focused on creating document-driven Web services.

Spring-WS 1.0 M1 includes a streaming SOAP message model based on  
Apache Axiom, WS-Security support that integrates with Acegi, JAXB  
2.0 marshaller support, and many further improvements. It also  
contains numerous fixes for issues discovered since 0.9.1.

The main sample application in this release is an airline  
application, which shows the diverse ways of handling XML (including  
XML marshalling), and also contains an endpoint which uses a WS- 
Security Usertoken to authenticate against an Acegi authentication  
manager. The sample contains two clients: one in C# and one in Java,  
using SAAJ.

Cheers,

Arjen

---
Arjen Poutsma
Interface21
E: ar...@in...
W: www.interface21.com
B: blog.interface21.com/arjen

[Springframework-developer] Spring build.40 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] =?utf-8?q?Changed_behavior_for_defaul?= =?utf-8?b?dC1sYXp5LWluaXQ94oCddHJ1ZeKAnSBpbiAyLjAgTTU=?=

[Claus N. <cla...@ho...>]

Hi all,

When using default-lazy-init=”true” with the 2.0 M5 release, I find that 
neither does my PropertyPlaceholderConfigurer’s do its stuff nor does my 
ApplicationListener’s receive any events as they all did with previous 
releases.

Is this expected behavior?

Regards,
Claus Nordahl