springframework-developer — Spring Framework developers list

Re: [Springframework-developer] webflow: validators

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

At the moment SWF does not have any direct binding & validation support of 
its own: it just uses the Spring binding and validation infrastructure 
(DataBinder, Errors, Validator). I don't think binding and validation is 
really a feature that we should build *into* SWF. Instead we need to 
integrate with existing solutions.

Could you elaborate on the "XWork validators" a bit?

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Saturday, April 09, 2005 3:09 PM
Subject: [Springframework-developer] webflow: validators


> Hi guys,
>
> Do you guys support the notion of validators like XWork validators?
> Since WebFlow uses Spring validators could be configured
> declaratively. If you're interested I would be happy to create a BNF
> file for something like this:
>
> { firstname : length of form.firstname > 0 : "First name must not be 
> empty" }
> { firstname : length of form.firstname <= 30 : "First name must be no
> longer than 30 characters" }
> { age : form.age is number : "[${form.age}] is not a valid number" }
> { age : form.age > 18 : "You must be 18 years or older" }
> { age : form.age <= 110 : "We do not do business with the undead" }
>
> Kind regards
>
> Steven Devijver
>
> -- 
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
>
>
> -------------------------------------------------------
> 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] webflow: action tag without method name

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

It defaults to a method with the name of the current state.

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>; 
<spr...@li...>
Sent: Saturday, April 09, 2005 2:49 PM
Subject: [Springframework-developer] webflow: action tag without method name


> Hi guys,
>
> Which method is called on an action bean when no method name is
> specified in the action tag?
>
> Kind regards
>
> Steven
>
> -- 
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
>
>
> -------------------------------------------------------
> 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] webflow: validators

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

Hi guys,

Do you guys support the notion of validators like XWork validators?
Since WebFlow uses Spring validators could be configured
declaratively. If you're interested I would be happy to create a BNF
file for something like this:

{ firstname : length of form.firstname > 0 : "First name must not be empty" }
{ firstname : length of form.firstname <= 30 : "First name must be no
longer than 30 characters" }
{ age : form.age is number : "[${form.age}] is not a valid number" }
{ age : form.age > 18 : "You must be 18 years or older" }
{ age : form.age <= 110 : "We do not do business with the undead" }

Kind regards

Steven Devijver

-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

[Springframework-developer] webflow: action tag without method name

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

Hi guys,

Which method is called on an action bean when no method name is
specified in the action tag?

Kind regards

Steven

-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] verbosity of XML property declaration

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

> thx for pointing out and boy, its hard to follow all that new 
> features, which is good of course <g>.
>
Well, sometimes taking a look at the changelog when a new release ships 
could be useful:

* added "value"/"ref" attributes to XML "property"/"constructor-arg" 
tag, as shortcut alternative to child elements
* added "key" sub-element to XML "entry" tag for maps, allowing for 
inner beans, refs, values etc specified as key
* added "key-ref" attribute to XML "entry" tag for maps, as shortcut 
alternative to a key element with "ref bean=" ...

:-)

Cheers,
Dmitriy.

Re: [Springframework-developer] verbosity of XML property declaration

[Marc L. <ma...@lo...>]

Hi,

wasnt aware of that new feature of RC1, thats nice. Its the halfway of 
my proposal ;-) Of course you are right by saying that auto-wiring will 
help me here but call me conservative, i am not a big fan of it because 
of possible sideeffects and i want to have documented on bean basis what 
will be injected and what not.

But the "ref" attribute in RC1 is a fair tradeoff between 
readability/flexibility and verbosity. I will go this route.

thx for pointing out and boy, its hard to follow all that new features, 
which is good of course <g>.

Juergen Hoeller wrote:
> On a related note: Since Spring 1.2 RC1, there are "ref" and "value"
> shortcut attributes on the <property> tag (and others):
> 
> <property name="logisticProviderManagerService"
> ref="logisticProviderManagerService"/>
> 
> Of course, this still explicitly mentions the name of the bean. As I said,
> autowire-by-name is probably what you're looking for then.
> 

-- 
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: [Springframework-developer] verbosity of XML property declaration

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

On a related note: Since Spring 1.2 RC1, there are "ref" and "value"
shortcut attributes on the <property> tag (and others):

<property name="logisticProviderManagerService"
ref="logisticProviderManagerService"/>

Of course, this still explicitly mentions the name of the bean. As I said,
autowire-by-name is probably what you're looking for then.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Saturday, April 09, 2005 12:40 AM
To: spr...@li...
Subject: Re: [Springframework-developer] verbosity of XML property
declaration


Well, if it's about avoiding to express the "logisticProviderManagerService"
name twice: why not use autowiring-by-name? This can be defined on a
per-bean basis, and automatically wires all bean properties that have
matching beans in the context (with the bean name matching the property
name).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Saturday, April 09, 2005 12:28 AM
To: spr...@li...
Subject: [Springframework-developer] verbosity of XML property
declaration


Hi,

i ve followed with great interest the xml namespace discussion today and
my concern is also in the area of xml verbosity. While looking at my
context XML files (which allready reached 800 lines after 3 weeks of
project programming), i saw that i have plenty of definitions which go
like this:

<bean...>
<property name="logisticProviderManagerService"><ref
bean="logisticProviderManagerService"/></property>
</bean>

If its not only me who prefers (whenever possible) to have the same
attribute name than the bean name/id, it would be nice to have something
like this:

<bean...>
<property name="logisticProviderManagerService" refbean="true"/>
</bean>

or

<property name="logisticProviderManagerService" bean="ref|local"/>

But i really dont know how many others do it this way. So i dont know if
this is of common interest here. If its not of common interest, or if i
feel that this is a must have, i assume that the package
org.springframework.beans.factory.xml is my friend right? ;-)

--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de


-------------------------------------------------------
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] verbosity of XML property declaration

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

Well, if it's about avoiding to express the "logisticProviderManagerService"
name twice: why not use autowiring-by-name? This can be defined on a
per-bean basis, and automatically wires all bean properties that have
matching beans in the context (with the bean name matching the property
name).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Saturday, April 09, 2005 12:28 AM
To: spr...@li...
Subject: [Springframework-developer] verbosity of XML property
declaration


Hi,

i ve followed with great interest the xml namespace discussion today and
my concern is also in the area of xml verbosity. While looking at my
context XML files (which allready reached 800 lines after 3 weeks of
project programming), i saw that i have plenty of definitions which go
like this:

<bean...>
<property name="logisticProviderManagerService"><ref
bean="logisticProviderManagerService"/></property>
</bean>

If its not only me who prefers (whenever possible) to have the same
attribute name than the bean name/id, it would be nice to have something
like this:

<bean...>
<property name="logisticProviderManagerService" refbean="true"/>
</bean>

or

<property name="logisticProviderManagerService" bean="ref|local"/>

But i really dont know how many others do it this way. So i dont know if
this is of common interest here. If its not of common interest, or if i
feel that this is a must have, i assume that the package
org.springframework.beans.factory.xml is my friend right? ;-)

--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de


-------------------------------------------------------
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] spring build.240 Build Successful

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

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050409001605Lbuild.240

[Springframework-developer] verbosity of XML property declaration

[Marc L. <ma...@lo...>]

Hi,

i ve followed with great interest the xml namespace discussion today and 
my concern is also in the area of xml verbosity. While looking at my 
context XML files (which allready reached 800 lines after 3 weeks of 
project programming), i saw that i have plenty of definitions which go 
like this:

<bean...>
<property name="logisticProviderManagerService"><ref 
bean="logisticProviderManagerService"/></property>
</bean>

If its not only me who prefers (whenever possible) to have the same 
attribute name than the bean name/id, it would be nice to have something 
like this:

<bean...>
<property name="logisticProviderManagerService" refbean="true"/>
</bean>

or

<property name="logisticProviderManagerService" bean="ref|local"/>

But i really dont know how many others do it this way. So i dont know if 
this is of common interest here. If its not of common interest, or if i 
feel that this is a must have, i assume that the package 
org.springframework.beans.factory.xml is my friend right? ;-)

-- 
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

RE: [Springframework-developer] Spring 1.2 and JMX 1.0

[Thierry T. <te...@ya...>]

Rob,

I have made some tests with WAS 5.1.2. The exportation
of beans (simple mbeans) works fine... Is it the only
thing to test for the jmx support?
Thierry

> Please do. I'm just downloading WAS 5.0 now for my
> testing session tomorrow.
> 
> Rob

Take a look at my blog:
http://templth.blogspot.com/


	

	
		
__________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

RE: [Springframework-developer] Trouble retrieving CVS HEAD

[Nanda F. <nan...@gm...>]

Same here...

--
Nanda Firdausi 

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Matt Sgarlata
> Sent: 08 April 2005 18:58
> To: spr...@li...
> Subject: [Springframework-developer] Trouble retrieving CVS HEAD
> 
> I can't retrieve the latest code from CVS anymore for some 
> reason.  Does the Spring project need to request more space 
> from SourceForge?
> 
> The server reported an error: No space left on device
>    Spring: cannot create_adm_p
> /tmp/cvs-serv27404/sandbox/org/springframework/aop
>    The server reported an error: No space left on device
> 
> Matt
> 
> 
> 
> -------------------------------------------------------
> 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] Portlet MVC - Status?

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

All,

I've been integrating Portlet support into the Spring Web Flow system and 
today I also added a portlet based version of the PhoneBook sample 
application.

SWF Portlet support builds on the Spring Portlet MVC framework, which brings 
me to the question: what is the status of Spring Portlet MVC? A recent 
discussion on the DEV list states that it will be a key feature of Spring 
1.3. However, there also seems to be a lot of confusion as to how up-to-date 
the sources in CVS are 
(http://article.gmane.org/gmane.comp.java.springframework.devel/7997) and 
who is actually working on it/maintaining it. The Wiki page 
(http://opensource.atlassian.com/confluence/spring/display/JSR168/Home) also 
seems to given the impression that's it's not ready for prime-time yet.

Since SWF is now dependent on Spring Portlet MVC, we need to make sure it is 
ready for release in the 1.3 timeframe. Also, since SWF is already releasing 
preview releases (we have preview 2 coming up this weekend!), we need to 
make sure the Portlet MVC code we're shipping with that (which is the code 
from CVS) is actually in up-to-date!

Could somebody please try to clarify the Spring Portlet MVC situation a bit?

Erwin Vervaet
erw...@er... 

[Springframework-developer] Trouble retrieving CVS HEAD

[Matt S. <sga...@us...>]

I can't retrieve the latest code from CVS anymore for some reason.  Does 
the Spring project need to request more space from SourceForge?

The server reported an error: No space left on device
   Spring: cannot create_adm_p 
/tmp/cvs-serv27404/sandbox/org/springframework/aop
   The server reported an error: No space left on device

Matt

[Springframework-developer] Re: LocaleContext

[Matt S. <sga...@us...>]

I agree that you want the DispatcherServlet to work as it used to and 
not require a new filter to be added to Spring MVC apps.  I'm just 
suggesting that making some of the DispatcherServlet's functionality 
accessible to non-Spring MVC users could be beneficial.  It could also 
make the implementation of the <spring> tags more straightforward.

Matt

Colin Sampaleanu wrote:
> Matt Raible wrote:
> 
>>
>> On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote:
>>
>>> Are you proposing to remove the Context interface or to move it to 
>>> Spring core?  I think moving it to Spring core could be good.  
>>> However, I would make it a blank interface and add a 
>>> ValidatableContext subinterface that defines the validate() method.
>>>
>>> Could we have the LocaleContext also be automatically setup in the 
>>> DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
>>> some of the work that's currently done by the DispatcherServlet could 
>>> be moved to a servlet filter that could work with any web 
>>> application?  For backwards compatability, the DispatcherServlet 
>>> could detect whether the new filter has already been invoked, and if 
>>> not invoke it manually.
>>
>>
>>
>> If I understand these classes correctly, it should be fairly simple to 
>> add this to your own filter:
>>
>> LocaleContextHolder.setLocale(request.getLocale());
>>
>> I wonder if adding this to the CharacterEncodingFilter would make any 
>> sense?
>>
> For people using Spring MVC you definitely still want to have 
> DispatcherServlet do it (whether directly as now, or by reusing common 
> code), without people having to put in the filter. I'm not so sure about 
> combining the functionality into the CharacterEncodingFilter. Somewhat 
> different concerns here, and you might want to handle the locale without 
> touching the character encoding...
> 

Re: [Springframework-developer] Re: LocaleContext

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

On Apr 8, 2005, at 10:19 AM, Colin Sampaleanu wrote:

> Matt Raible wrote:
>
>>
>> On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote:
>>
>>> Are you proposing to remove the Context interface or to move it to 
>>> Spring core?  I think moving it to Spring core could be good.  
>>> However, I would make it a blank interface and add a 
>>> ValidatableContext subinterface that defines the validate() method.
>>>
>>> Could we have the LocaleContext also be automatically setup in the 
>>> DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
>>> some of the work that's currently done by the DispatcherServlet 
>>> could be moved to a servlet filter that could work with any web 
>>> application?  For backwards compatability, the DispatcherServlet 
>>> could detect whether the new filter has already been invoked, and if 
>>> not invoke it manually.
>>
>>
>> If I understand these classes correctly, it should be fairly simple 
>> to add this to your own filter:
>>
>> LocaleContextHolder.setLocale(request.getLocale());
>>
>> I wonder if adding this to the CharacterEncodingFilter would make any 
>> sense?
>>
> For people using Spring MVC you definitely still want to have 
> DispatcherServlet do it (whether directly as now, or by reusing common 
> code), without people having to put in the filter. I'm not so sure 
> about combining the functionality into the CharacterEncodingFilter. 
> Somewhat different concerns here, and you might want to handle the 
> locale without touching the character encoding...

Right, but for those using something like Tapestry or JSF - they'll 
need to write their own filter.  Since it's such little code, I don't 
see the need to provide a Spring Filter as part of the core, but it 
might be a good idea to note the Filter (and code) in the 
LocaleContextHolder's javadoc.

I agree that it probably shouldn't go in the CharacterEncodingFilter - 
I'm just always looking for filter consolidation.  I can probably add 
the above code to an existing filter.

Matt

>
> -- 
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
>
> -------------------------------------------------------
> 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: LocaleContext

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

I'm proposing to remove the generic Context interface completely. It seems
to me that Acegi should concentrate on its specific SecureContext, held in a
SecureContextHolder. It will only ever hold a SecureContext; after all, it's
a security framework, isn't it :-)

A single holder for a generic Context doesn't help much unless you have a
central controlling place where you manage the Context (which somewhat goes
against Spring's philosophy). For loosely coupled code, it's better to have
a specific Context for each subsystem, managed independently (in independent
ThreadLocals, i.e. independent holder classes).

Regarding LocaleContext management outside DispatcherServlet: Note that
DispatcherServlet does something very specific there - it delegates to its
LocaleResolver to resolve the Locale. Outside of Spring Web MVC, there is no
such LocaleResolver. We could probably extend our Struts support to expose
the Struts-determined Locale as a LocaleContext, though.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Sgarlata
Sent: Friday, April 08, 2005 3:32 PM
To: spr...@li...
Subject: [Springframework-developer] Re: LocaleContext


Are you proposing to remove the Context interface or to move it to
Spring core?  I think moving it to Spring core could be good.  However,
I would make it a blank interface and add a ValidatableContext
subinterface that defines the validate() method.

Could we have the LocaleContext also be automatically setup in the
DelegatingRequestProcessor for Struts users?  Alternatively, perhaps
some of the work that's currently done by the DispatcherServlet could be
moved to a servlet filter that could work with any web application?  For
backwards compatability, the DispatcherServlet could detect whether the
new filter has already been invoked, and if not invoke it manually.

Matt

PS - Spring MVC is soooo much better than Struts, but I simply don't
have the time to switch to it.  We already have too much momentum with
Struts.

Juergen Hoeller wrote:
> I've introduced a LocaleContext abstraction and LocaleContextHolder class
in
> "org.springframework.context.i18n". DispatcherServlet automatically
> populates LocaleContextHolder's ThreadLocal (delegating to
LocaleResolver),
> and MessageSourceAccessor automatically uses the current Locale from there
> (falling back to the system default Locale).
>
> The LocaleContext is essentially analogous to Acegi's SecurityContext. I
> guess it's better to keep such contexts separate, though, else it'll be
> unclear who choses the Context implementation to use etc. To express this,
> it might make sense to remove the generic Context interface from Acegi,
only
> keeping a SecurityContext, held in a SecurityContextHolder.
>
> Thoughts?
>
> 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



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

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

Matt Raible wrote:

>
> On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote:
>
>> Are you proposing to remove the Context interface or to move it to 
>> Spring core?  I think moving it to Spring core could be good.  
>> However, I would make it a blank interface and add a 
>> ValidatableContext subinterface that defines the validate() method.
>>
>> Could we have the LocaleContext also be automatically setup in the 
>> DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
>> some of the work that's currently done by the DispatcherServlet could 
>> be moved to a servlet filter that could work with any web 
>> application?  For backwards compatability, the DispatcherServlet 
>> could detect whether the new filter has already been invoked, and if 
>> not invoke it manually.
>
>
> If I understand these classes correctly, it should be fairly simple to 
> add this to your own filter:
>
> LocaleContextHolder.setLocale(request.getLocale());
>
> I wonder if adding this to the CharacterEncodingFilter would make any 
> sense?
>
For people using Spring MVC you definitely still want to have 
DispatcherServlet do it (whether directly as now, or by reusing common 
code), without people having to put in the filter. I'm not so sure about 
combining the functionality into the CharacterEncodingFilter. Somewhat 
different concerns here, and you might want to handle the locale without 
touching the character encoding...

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Re: LocaleContext

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

On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote:

> Are you proposing to remove the Context interface or to move it to 
> Spring core?  I think moving it to Spring core could be good.  
> However, I would make it a blank interface and add a 
> ValidatableContext subinterface that defines the validate() method.
>
> Could we have the LocaleContext also be automatically setup in the 
> DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
> some of the work that's currently done by the DispatcherServlet could 
> be moved to a servlet filter that could work with any web application? 
>  For backwards compatability, the DispatcherServlet could detect 
> whether the new filter has already been invoked, and if not invoke it 
> manually.

If I understand these classes correctly, it should be fairly simple to 
add this to your own filter:

LocaleContextHolder.setLocale(request.getLocale());

I wonder if adding this to the CharacterEncodingFilter would make any 
sense?

Matt

>
> Matt
>
> PS - Spring MVC is soooo much better than Struts, but I simply don't 
> have the time to switch to it.  We already have too much momentum with 
> Struts.
>
> Juergen Hoeller wrote:
>> I've introduced a LocaleContext abstraction and LocaleContextHolder 
>> class in
>> "org.springframework.context.i18n". DispatcherServlet automatically
>> populates LocaleContextHolder's ThreadLocal (delegating to 
>> LocaleResolver),
>> and MessageSourceAccessor automatically uses the current Locale from 
>> there
>> (falling back to the system default Locale).
>> The LocaleContext is essentially analogous to Acegi's 
>> SecurityContext. I
>> guess it's better to keep such contexts separate, though, else it'll 
>> be
>> unclear who choses the Context implementation to use etc. To express 
>> this,
>> it might make sense to remove the generic Context interface from 
>> Acegi, only
>> keeping a SecurityContext, held in a SecurityContextHolder.
>> Thoughts?
>> 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
>
>
>
> -------------------------------------------------------
> 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] FW: OGNL sample

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

groovy.

On Apr 8, 2005 4:42 PM, Keith Donald <ke...@in...> wrote:
> Yes - everything is accessible via the RequestContext, the root object on
> the value stack.  So lastEvent is a prop, flowScope is a prop, "sale" is a
> bean stored in flowScope, Boolean "shipping" is a prop on that bean.  The
> "on" condition must be a boolean expression.
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Steven Devijver
> Sent: Friday, April 08, 2005 10:37 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] FW: OGNL sample
> 
> Thanks guys.
> 
> I suppose the "lastEvent" and "flowScope" variables are always
> available on the OGNL value stack. I furthermore suppose that "scope"
> is a key in the flow request context and that "shipping" is a boolean
> property on the instance associated with said key.
> 
> Cheers
> 
> Steven
> 
> On Apr 8, 2005 4:29 PM, Erwin Vervaet <erw...@er...> wrote:
> > should that be "threesome-programming"? ;)
> >
> > Erwin Vervaet
> > erw...@er...
> > ----- Original Message -----
> > From: "Keith Donald" <ke...@in...>
> > To: <spr...@li...>
> > Sent: Friday, April 08, 2005 4:17 PM
> > Subject: [Springframework-developer] FW: OGNL sample
> >
> > > FYI if this wasn't posted here already: the below feature is the result
> of
> > > Erwin, Rob, and I's "tri-programming" over skype yesterday.  Steven,
> this
> > > is
> > > an example of conditional transitions expressed in OGNL, to help with
> your
> > > article.
> > >
> > > Keith
> > >
> > > -----Original Message-----
> > > From: Erwin Vervaet [mailto:erw...@er...]
> > > Sent: Friday, April 08, 2005 3:09 AM
> > > To: Keith Donald; Rob Harrop
> > > Subject: OGNL sample
> > >
> > > Hey guys,
> > >
> > > I just added OGNL based conditional transitions to our sellitem sample
> > > app:
> > >
> > > <action-state id="bindAndValidateCategory">
> > >   <action bean="sellItemAction" method="bindAndValidate"/>
> > >   <transition on="${lastEvent.id == 'success' and
> > > flowScope.sale.shipping}"
> > >
> > > to="enterShippingDetails"/>
> > >   <transition on="${lastEvent.id == 'success' and
> > > !flowScope.sale.shipping}" to="showCostOverview"/>
> > >   <transition on="error" to="enterCategory"/>
> > > </action-state>
> > >
> > > Sweet! I tested this and it's working nicely.
> > >
> > > Erwin Vervaet
> > > erw...@er...
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> >
> >
> 
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 
> -------------------------------------------------------
> 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
> 
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

RE: [Springframework-developer] FW: OGNL sample

[Keith D. <ke...@in...>]

Yes - everything is accessible via the RequestContext, the root object on
the value stack.  So lastEvent is a prop, flowScope is a prop, "sale" is a
bean stored in flowScope, Boolean "shipping" is a prop on that bean.  The
"on" condition must be a boolean expression.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Steven Devijver
Sent: Friday, April 08, 2005 10:37 AM
To: spr...@li...
Subject: Re: [Springframework-developer] FW: OGNL sample

Thanks guys.

I suppose the "lastEvent" and "flowScope" variables are always
available on the OGNL value stack. I furthermore suppose that "scope"
is a key in the flow request context and that "shipping" is a boolean
property on the instance associated with said key.


Cheers

Steven

On Apr 8, 2005 4:29 PM, Erwin Vervaet <erw...@er...> wrote:
> should that be "threesome-programming"? ;)
> 
> Erwin Vervaet
> erw...@er...
> ----- Original Message -----
> From: "Keith Donald" <ke...@in...>
> To: <spr...@li...>
> Sent: Friday, April 08, 2005 4:17 PM
> Subject: [Springframework-developer] FW: OGNL sample
> 
> > FYI if this wasn't posted here already: the below feature is the result
of
> > Erwin, Rob, and I's "tri-programming" over skype yesterday.  Steven,
this
> > is
> > an example of conditional transitions expressed in OGNL, to help with
your
> > article.
> >
> > Keith
> >
> > -----Original Message-----
> > From: Erwin Vervaet [mailto:erw...@er...]
> > Sent: Friday, April 08, 2005 3:09 AM
> > To: Keith Donald; Rob Harrop
> > Subject: OGNL sample
> >
> > Hey guys,
> >
> > I just added OGNL based conditional transitions to our sellitem sample
> > app:
> >
> > <action-state id="bindAndValidateCategory">
> >   <action bean="sellItemAction" method="bindAndValidate"/>
> >   <transition on="${lastEvent.id == 'success' and
> > flowScope.sale.shipping}"
> >
> > to="enterShippingDetails"/>
> >   <transition on="${lastEvent.id == 'success' and
> > !flowScope.sale.shipping}" to="showCostOverview"/>
> >   <transition on="error" to="enterCategory"/>
> > </action-state>
> >
> > Sweet! I tested this and it's working nicely.
> >
> > Erwin Vervaet
> > erw...@er...
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> 
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
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] FW: OGNL sample

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

Thanks guys.

I suppose the "lastEvent" and "flowScope" variables are always
available on the OGNL value stack. I furthermore suppose that "scope"
is a key in the flow request context and that "shipping" is a boolean
property on the instance associated with said key.


Cheers

Steven

On Apr 8, 2005 4:29 PM, Erwin Vervaet <erw...@er...> wrote:
> should that be "threesome-programming"? ;)
> 
> Erwin Vervaet
> erw...@er...
> ----- Original Message -----
> From: "Keith Donald" <ke...@in...>
> To: <spr...@li...>
> Sent: Friday, April 08, 2005 4:17 PM
> Subject: [Springframework-developer] FW: OGNL sample
> 
> > FYI if this wasn't posted here already: the below feature is the result of
> > Erwin, Rob, and I's "tri-programming" over skype yesterday.  Steven, this
> > is
> > an example of conditional transitions expressed in OGNL, to help with your
> > article.
> >
> > Keith
> >
> > -----Original Message-----
> > From: Erwin Vervaet [mailto:erw...@er...]
> > Sent: Friday, April 08, 2005 3:09 AM
> > To: Keith Donald; Rob Harrop
> > Subject: OGNL sample
> >
> > Hey guys,
> >
> > I just added OGNL based conditional transitions to our sellitem sample
> > app:
> >
> > <action-state id="bindAndValidateCategory">
> >   <action bean="sellItemAction" method="bindAndValidate"/>
> >   <transition on="${lastEvent.id == 'success' and
> > flowScope.sale.shipping}"
> >
> > to="enterShippingDetails"/>
> >   <transition on="${lastEvent.id == 'success' and
> > !flowScope.sale.shipping}" to="showCostOverview"/>
> >   <transition on="error" to="enterCategory"/>
> > </action-state>
> >
> > Sweet! I tested this and it's working nicely.
> >
> > Erwin Vervaet
> > erw...@er...
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> 
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] FW: OGNL sample

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

should that be "threesome-programming"? ;)

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Keith Donald" <ke...@in...>
To: <spr...@li...>
Sent: Friday, April 08, 2005 4:17 PM
Subject: [Springframework-developer] FW: OGNL sample


> FYI if this wasn't posted here already: the below feature is the result of
> Erwin, Rob, and I's "tri-programming" over skype yesterday.  Steven, this 
> is
> an example of conditional transitions expressed in OGNL, to help with your
> article.
>
> Keith
>
> -----Original Message-----
> From: Erwin Vervaet [mailto:erw...@er...]
> Sent: Friday, April 08, 2005 3:09 AM
> To: Keith Donald; Rob Harrop
> Subject: OGNL sample
>
> Hey guys,
>
> I just added OGNL based conditional transitions to our sellitem sample 
> app:
>
> <action-state id="bindAndValidateCategory">
>   <action bean="sellItemAction" method="bindAndValidate"/>
>   <transition on="${lastEvent.id == 'success' and 
> flowScope.sale.shipping}"
>
> to="enterShippingDetails"/>
>   <transition on="${lastEvent.id == 'success' and
> !flowScope.sale.shipping}" to="showCostOverview"/>
>   <transition on="error" to="enterCategory"/>
> </action-state>
>
> Sweet! I tested this and it's working nicely.
>
> Erwin Vervaet
> erw...@er...
>
>
>
>
> -------------------------------------------------------
> 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] FW: OGNL sample

[Keith D. <ke...@in...>]

FYI if this wasn't posted here already: the below feature is the result of
Erwin, Rob, and I's "tri-programming" over skype yesterday.  Steven, this is
an example of conditional transitions expressed in OGNL, to help with your
article.

Keith

-----Original Message-----
From: Erwin Vervaet [mailto:erw...@er...] 
Sent: Friday, April 08, 2005 3:09 AM
To: Keith Donald; Rob Harrop
Subject: OGNL sample

Hey guys,

I just added OGNL based conditional transitions to our sellitem sample app:

<action-state id="bindAndValidateCategory">
   <action bean="sellItemAction" method="bindAndValidate"/>
   <transition on="${lastEvent.id == 'success' and flowScope.sale.shipping}"

to="enterShippingDetails"/>
   <transition on="${lastEvent.id == 'success' and 
!flowScope.sale.shipping}" to="showCostOverview"/>
   <transition on="error" to="enterCategory"/>
</action-state>

Sweet! I tested this and it's working nicely.

Erwin Vervaet
erw...@er... 

[Springframework-developer] Re: LocaleContext

[Matt S. <sga...@us...>]

Are you proposing to remove the Context interface or to move it to 
Spring core?  I think moving it to Spring core could be good.  However, 
I would make it a blank interface and add a ValidatableContext 
subinterface that defines the validate() method.

Could we have the LocaleContext also be automatically setup in the 
DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
some of the work that's currently done by the DispatcherServlet could be 
moved to a servlet filter that could work with any web application?  For 
backwards compatability, the DispatcherServlet could detect whether the 
new filter has already been invoked, and if not invoke it manually.

Matt

PS - Spring MVC is soooo much better than Struts, but I simply don't 
have the time to switch to it.  We already have too much momentum with 
Struts.

Juergen Hoeller wrote:
> I've introduced a LocaleContext abstraction and LocaleContextHolder class in
> "org.springframework.context.i18n". DispatcherServlet automatically
> populates LocaleContextHolder's ThreadLocal (delegating to LocaleResolver),
> and MessageSourceAccessor automatically uses the current Locale from there
> (falling back to the system default Locale).
> 
> The LocaleContext is essentially analogous to Acegi's SecurityContext. I
> guess it's better to keep such contexts separate, though, else it'll be
> unclear who choses the Context implementation to use etc. To express this,
> it might make sense to remove the generic Context interface from Acegi, only
> keeping a SecurityContext, held in a SecurityContextHolder.
> 
> Thoughts?
> 
> 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