springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Changes to jdbc.object.StroredProcedure class

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

> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
> 
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
> 
> The first solution is simpler and less code, but maybe not as clear as
> the second one.


I vote for 1. Simple and backward compatible.

Thanks for raising the issue.

Rod

[Springframework-developer] Changes to jdbc.object.StroredProcedure class

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

Hi guys,

I have just joined the group and I'm really looking forward to working
on this framework.  Great stuff so far.  I have e-mailed Rod with a few
suggestions for the SQLExceptionTranslater functionality, we should be
able to add some of the new features to CVS real soon.

While testing the changes to the SQLTranslation logic on different
databases I ran across a problem with using the StoredProcedure class
from the jdbc.object package.  

It currently only supports the "{call my_proc(?, ?)}" syntax and this
worked fine for procedures but not for stored functions.  With functions
you have to use the following call syntax "{? = call my_func(?)}". Since
all stored procedures in Postgres are declared as functions (CREATE
FUNCTION ...) it was a problem.  

I came up with two solutions, and would like to know which one you would
prefer.

1.  Add a boolean instance variable isFunction = false to the
StoredProcedure.  This could be set to true if the call is to a function
or left false if it is to a procedure.  Then the StoredProcedure could
use the correct syntax while it is "compiling" the callString

2.  Create a StoredFunction class that does the same thing the current
StoredProcedure does, except for the call syntax.  We could use
sub-classing to avoid code duplication

The first solution is simpler and less code, but maybe not as clear as
the second one.

This would be a good feature not only for Postgres, but for any database
that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...

Let me know what you think.

Also - is anybody working on any other parts of the jdbc package?  I'd
be interested to look at other issues, but I don't want to solve/fix
something that someone else is already looking at.


 -- Thomas
 

Fw: [Springframework-developer] Struts (and Re: ErrorCoded/MessageSource)

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

Damn this reply-to!

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jh...@we...>
Sent: Monday, February 24, 2003 6:57 PM
Subject: Re: [Springframework-developer] Struts (and Re:
ErrorCoded/MessageSource)


> > Concerning Struts: Despite all of its shortcomings, Struts does have a
lot
> of features. I've had a detailed look at Struts 1.1b3 recently, especially
> analyzing Struts' way of doing things. There are some things worth looking
> at: dispatch actions, dynamic forms, error message handling, request
tokens,
> declarative validation, multipart request processing, "modules", Tiles
> integration.
>
> I agree, there's lots of stuff there, and things we can learn from.
However,
> wrt the dispatch action, our
> com.interface21.web.servlet.mvc.multiaction.MultiActionController does the
> same thing but is much more powerful.
>
> Rod
>

[Springframework-developer] File upload aka multipart request handling

[<jue...@li...>]

Hi everybody,

I'd like to communicate an idea that I've been thinking about for quite a
while. Currently hanging around at home being a bit sick, this is a good way
to use the time... ;-) Anyway, I've already raised the topic of utility
libraries on the Wrox forum some time ago, and I've done some research
since. The main issue is file upload aka multipart request handling.

There are currently 2 noteworthy reusable upload libraries:
- Jason Hunter's COS (com.oreilly.servlet): the classic, under Jason's "buy
my book" license;
- Jakarta's Commons FileUpload (currently 1.0 beta): a new alternative,
under the Apache license.

The latter is now the default implementation of Struts 1.1's
MultipartRequestHandler (alternatively, Struts still has the old 1.0
implementation, the simple DiskMultipartRequestHandler). COS may be older
and better tested, but Commons FileUpload is more sophisticated: For
example, it can keep uploaded files smaller than a specified threshold in
memory instead of writing everything temporarily to disk.

My goal is to support file upload within Spring's web package, in a
straightforward and pluggable way. The obvious way would be some multipart
check in ControllerServlet's doService method that exchanges the standard
HttpServletRequest with a wrapping MultipartServletRequest (an interface
derived from HttpServletRequest) if it detects a multipart request.
Controller implementations can check for a multipart request via "request
instanceof MultipartServletRequest", or simply cast to the class if they
expect one.

The following proposal for Spring's multipart handler interfaces is
obviously inspired by both COS' MultipartRequest and Commons FileUpload's
FileItem classes, so don't blame me! ;-) It should be easy to write
implementations for COS and Commons FileUpload that we could include out of
the box. Of course, we are only allowed to include Commons FileUpload in a
Spring distribution, in terms of license. Whoever wants to use COS could
simply download it, add it to his web app libraries, and configure affected
Spring controller servlets accordingly.

The MultipartServletRequest interface needs to support getParameter and
associated methods, to be able to handle simple parameters in a multipart
request transparently, just like when dealing with a normal request. For
file handling, I propose to add the following methods beyond
HttpServletRequest, analogous to parameter handling:
- MultipartFile getFile(String name)... returning a file descriptor for the
specified file, or null
- Map getFileMap()... returning a Map with file names as keys and
MultipartFile instances as values
- clearFileResources()... clearing all temporary file resources
(automatically called by ControllerServlet after Controller processing)

MultipartFile is an interface with the following methods:
- InputStream getInputStream()... returning an input stream with the
contents of the file
- String getFileName()... returning the original file name given by the
client
- String getContentType()... returning the content type given by the client

These should allow for both simple implementations and simple usage by
custom controller implementations. The interfaces could even be used by
JSPs, as the wrapped request will also be used when forwarding, although
that is not recommended practice. Normally, a custom upload controller will
evaluate the uploaded files and parameters, and transfer them to some
application-specific storage location that could be a filesystem or a
database. For application programmers, it is not important where the files
are stored temporarily or if they are stored on disk at all, therefore the
interfaces do not cover such aspects. Essentially, multipart handling should
be as easy and transparent as possible.

Finally, how will a ControllerServlet retrieve a MultipartServletRequest
instance, using the toolkit of the application's choice? A straightforward
Spring way would be to define a standard bean name "multipartResolver"
(analogous to "viewResolver" and "localeResolver") that needs to implement
the interface MultipartResolver:
- MultipartServletRequest createMultipartRequest(HttpServletRequest
request)... creating a wrapper
- boolean hasMultipartContent(HttpServletRequest request)... checking the
content type

Of course, ControllerServlet should simply ignore multipart handling when
there's no "multipartResolver" bean, maybe log a warning on initialization.

What do you think? If we settle on the proposal, I could implement it
promptly (right after locale resolution). I definitely consider file upload
a 1.0 issue, as both Struts and WebWork have built-in support for it.

Juergen


P.S.:

Concerning 2 other utility issues:

For FTP and other Internet protocols that are not supported with J2SE,
there's a new alternative too: Jakarta's Commons Net. I guess we won't need
special support for it withing Spring.

HTML escaping/unescaping: This is so fundamental and yet so simple that I've
always wondered about the lack of standard support for it. Not even Struts
1.1 does include a respective utility class. So everyone seems to write his
own... I'd like to include a HtmlUtils class providing static htmlEscape and
htmlUnescape methods in Spring's web.util package, if no one objects.

RE: [Springframework-developer] Explicit locales

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

Trevor,

I agree that we don't need to let backward compatibility 
cause us to end up with a sub-optimal result for 1.0.

Regards,
Rod

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

What you wrote sounded right, and I think I understand what you are planning
now, and it should workwell.  Its just a much different implementation than
what I was thinking, so my own preconceived ideas were clouding my ability
to see your idea.  Anyway, the working code should reveal all. :)

On a more general note:
>>BTW, the time before 1.0 is still our greatest chance to get 
>>it right, without the burden of backward compatibility.
I totally agree, but want to make sure that everyone is on the same page.
My understanding is that whatever we choose for our "0.8" or "early access"
release is not guarenteed to be compatible with our 1.0 release.  We
obviously want to encourage people to start developing with it, but we won't
be burdened by backwards compatibility to support it.  If, for example, we
discover a glaring hole in the code, we can change it for 1.0 even if it
breaks any applications coded against 0.8.  Is this correct?

Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

VHJldm9yLA0KDQo8cXVvdGU+DQpXaGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgYW4gaW1wbGVtZW50
YXRpb24gYXMgZm9sbG93czogDQoNCnB1YmxpYyBpbnRlcmZhY2UgTG9jYWxlUmVzb2x2ZXIgeyAN
CiAgICAgICAgDQogICAgLy8gZ2V0IHRoZSBjdXJyZW50bHkgcmVzb2x2ZWQgbG9jYWxlIA0KICAg
IExvY2FsZSBnZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QpOyANCg0KICAgIC8v
IHNldCB0aGUgbG9jYWxlIGZyb20gdGhlIGFwcGxpY2F0aW9uIGNvZGUgDQogICAgdm9pZCBzZXRM
b2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVz
cG9uc2UsIExvY2FsZSBsb2NhbGUpOyANCg0KICAgIC8vIHJlc29sdmUgdGhlIGN1cnJlbnQgbG9j
YWxlIA0KICAgIHZvaWQgcmVzb2x2ZUxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwg
SHR0cFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSwgTG9jYWxlIGxvY2FsZSk7IA0KfQ0KPC9xdW90
ZT4NCg0KSSdtIG5vdCBzdXJlIHdoYXQgdGhlIHJlc29sdmVMb2NhbGUgbWV0aG9kIGlzIGZvci4g
WW91ciBnZXRMb2NhbGUgKD0gcmV0cmlldmVMb2NhbGUgaW4gbXkgbGF0ZXN0IHByb3Bvc2FsKSBy
ZXRyaWV2ZXMgdGhlIGN1cnJlbnQgbG9jYWxlLCBubyBtYXR0ZXIgaWYgc2V0IGluIGEgcHJldmlv
dXMgcmVxdWVzdCBvciBzZXQgZHVyaW5nIHByb2Nlc3NpbmcgdGhlIGN1cnJlbnQgcmVxdWVzdCBi
eSBhIHNldExvY2FsZSBjYWxsLiBzZXRMb2NhbGUgaXMgZXhhY3RseSBmb3IgY2hhbmdpbmcgdGhl
IHVzZXIncyBsb2NhbGUgdG8gYSBuZXcgbG9jYWxlIGluIGFwcGxpY2F0aW9uIGNvZGUsIGkuZS4g
aW4gYSBjdXN0b20gY29udHJvbGxlciBpbXBsZW1lbnRhdGlvbi4gQXMgZ2V0TG9jYWxlIHdpbGwg
cmV0dXJuIGEgbmV3IGxvY2FsZSBzZXQgZHVyaW5nIHByb2Nlc3NpbmcgdGhlIGN1cnJlbnQgcmVx
dWVzdCwgSSBzZWUgbm8gbmVlZCBmb3IgYW4gYWRkaXRpb25hbCByZXNvbHZlTG9jYWxlIG1ldGhv
ZCB3aXRoIDMgcGFyYW1ldGVycy4NCg0KPHF1b3RlPg0KVGhlIHByb2JsZW0gSSBzZWUgd2l0aCB0
aGlzIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGlzIGZvcmNlZCB0byB1c2Ugd2hhdGV2ZXIgbWV0
aG9kIHdlIGRlZmluZSBpbiBvcmRlciB0byBjaGFuZ2UgbG9jYWxlcy4gIEZvciBleGFtcGxlLCB0
aGV5IHdvdWxkIGJlIHJlcXVpcmVkIHRvIGhhdmUgYSBxdWVyeSBwYXJhbWV0ZXIgbGlrZSAiP2xv
Y2FsZT1mckNBIi4NCjwvcXVvdGU+DQoNCldlIHJlYWxseSBtaWdodCBtaXN1bmRlcnN0YW5kIGVh
Y2ggb3RoZXIuIE5vLCB3ZSB3b3VsZG4ndCBuZWVkIHN1Y2ggYSBzdGFuZGFyZCBxdWVyeSBwYXJh
bWV0ZXIgb3IgdGhlIGxpa2UgYXQgYWxsLiBDdXN0b20gY29udHJvbGxlciBpbXBsZW1lbnRhdGlv
bnMgY2FuIGNhbGwgTG9jYWxlUmVzb2x2ZXIuc2V0TG9jYWxlIGFueSB0aW1lIHRoZXkgd2FudCwg
b24gd2hhdGV2ZXIgb2NjYXNpb24gdGhhdCBkZW1hbmRzIGl0LCBkdWUgdG8gd2hhdGV2ZXIgcGFy
YW1ldGVyIHRoZXkgY29uc2lkZXIgZml0LiBBbiBleGFtcGxlOg0KDQpwdWJsaWMgY2xhc3MgTG9j
YWxlQ2hhbmdlQ29udHJvbGxlciBpbXBsZW1lbnRzIENvbnRyb2xsZXIsIExvY2FsZVJlc29sdmVy
QXdhcmUgew0KDQogICAgcHJpdmF0ZSBMb2NhbGVSZXNvbHZlciBsb2NhbGVSZXNvbHZlcjsNCg0K
ICAgIHB1YmxpYyBMb2NhbGVSZXNvbHZlciBnZXRMb2NhbGVSZXNvbHZlcigpIHsNCiAgICAgICAg
cmV0dXJuIHRoaXMubG9jYWxlUmVzb2x2ZXI7DQogICAgfQ0KDQogICAgLy8gcHJvcGFnYXRlZCB0
byB0aGlzIGNvbnRyb2xsZXIgYnkgQ29udHJvbGxlclNlcnZsZXQgdmlhIEhhbmRsZXJBZGFwdGVy
DQogICAgcHVibGljIHZvaWQgc2V0TG9jYWxlUmVzb2x2ZXIoKSB7DQogICAgICAgIHRoaXMubG9j
YWxlUmVzb2x2ZXIgPSBsb2NhbGVSZXNvbHZlcjsNCiAgICB9DQoNCiAgICBwdWJsaWMgTW9kZWxB
bmRWaWV3IGhhbmRsZVJlcXVlc3QoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2
bGV0UmVzcG9uc2UgcmVzcG9uc2UpIHsNCiAgICAgICAgU3RyaW5nIG5ld0xhbmd1YWdlID0gcmVx
dWVzdC5nZXRQYXJhbWV0ZXIoIm5ld0xhbmd1YWdlIik7DQogICAgICAgIGdldExvY2FsZVJlc29s
dmVyKCkuc2V0TG9jYWxlKHJlcXVlc3QsIHJlc3BvbnNlLCBuZXcgTG9jYWxlKG5ld0xhbmd1YWdl
LCAiIikpOw0KICAgIH0NCn0NCg0KQWZ0ZXIgZXhlY3V0aW9uIG9mIHN1Y2ggYSBDb250cm9sbGVy
IGluc3RhbmNlLCBDb250cm9sbGVyU2VydmxldCB3aWxsIGluIHR1cm4gY2FsbCB0aGUgTG9jYWxl
UmVzb2x2ZXIncyByZXNvbHZlTG9jYWxlKHJlcXVlc3QpIG1ldGhvZCB0byBkZXRlcm1pbmUgdGhl
IHZpZXcgbG9jYWxlIC0gYW5kIGNvcnJlY3RseSBwaWNrIHVwIHRoZSBuZXcgbG9jYWxlLiBCZWZv
cmUgaXRzIGV4ZWN1dGlvbiwgcmVzb2x2ZUxvY2FsZShyZXF1ZXN0KSB3b3VsZCByZXN1bHQgaW4g
dGhlIG9sZCBsb2NhbGUsIG9mIGNvdXJzZSAtIGJ1dCB0aGVyZSdzIG5vIG5lZWQgdG8gcmVzb2x2
ZSB0aGUgbG9jYWxlIHNvIGVhcmx5Lg0KDQo8cXVvdGU+DQpJJ20gbm90IHN1cmUgaWYgd2UgYXJl
IHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcgYW5kIG5vdCB1bmRlcnN0YW5kaW5nIGVhY2gg
b3RoZXIsIG9yIGlmIHdlIGFyZSBhY3R1YWxseSB0YWxraW5nIGFib3V0IGRpZmZlcmVudCB0aGlu
Z3MuICBIb3dldmVyLCBJIHRoaW5rIHRoZSBvbmx5IHdheSBlaXRoZXIgb2YgdXMgY2FuIGJlIG1v
cmUgY2xlYXIgaXMgd2l0aCB3b3JraW5nIGNvZGUuICBZb3Ugc2VlbSB0byB1bmRlcnN0YW5kIHRo
ZSBpc3N1ZXMsIHNvIGp1c3QgY29kZSBpdCBob3cgeW91J3JlIHBsYW5uaW5nLiAgV29yc3QgY2Fz
ZSwgd2UganVzdCByZWZhY3RvciBhbnkgcHJvYmxlbXMgbGF0ZXIuDQo8L3F1b3RlPg0KDQpHb29k
IGlkZWEsIHdvcmtpbmcgY29kZSBpcyBwcm9iYWJseSBzdGlsbCB0aGUgYmVzdCB0aGluZyB0aGF0
IGRldmVsb3BlcnMgY2FuIGRpc2N1c3MgYWJvdXQhIEknbGwgaW1wbGVtZW50IGlzIEFTQVAgKE1v
bmRheSBvciBUdWVzZGF5LCBpZiBJIGRvbid0IGZhbGwgaWxsIC0gSSBkb24ndCBmZWVsIGdvb2Qg
Y3VycmVudGx5KSwgYW5kIHdlJ2xsIHNlZSB3aGVyZSB0aGUgZ2FwcyBhcmUsIGlmIGFueS4gTWF5
YmUgdGhlIGVsYWJvcmF0aW9uIGFib3ZlIGhhcyBoZWxwZWQsIGVsc2Ugd2UgcmVzb3J0IHRvIGNv
ZGUuIEJUVywgdGhlIHRpbWUgYmVmb3JlIDEuMCBpcyBzdGlsbCBvdXIgZ3JlYXRlc3QgY2hhbmNl
IHRvIGdldCBpdCByaWdodCwgd2l0aG91dCB0aGUgYnVyZGVuIG9mIGJhY2t3YXJkIGNvbXBhdGli
aWxpdHkuDQoNCkp1ZXJnZW4NCg0K

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

>>I've just been confused by your remarks quoted above: The first paragraph 
>>talks about a setLocale method without a locale parameter, and the third 
>>paragraph proposes a setLocale method with exactly a locale parameter.

What I was proposing was an implementation as follows:

public interface LocaleResolver {
	
	// get the currently resolved locale
	Locale getLocale(HttpServletRequest request);

	// set the locale from the application code
	void setLocale(HttpServletRequest request, HttpServletResponse
response, Locale locale);

	// resolve the current locale
	void resolveLocale(HttpServletRequest request, HttpServletResponse
response, Locale locale);
}


>>CookieLocaleResolver.resolveLocale has to look for such a request 
>>attribute before looking for a cookie. Thus, it will retrieve the 
>>new locale even if the request still contains the old locale cookie.
The problem I see with this is that the application is forced to use
whatever method we define in order to change locales.  For example, they
would be required to have a query parameter like "?locale=frCA".


I'm not sure if we are talking about the same thing and not understanding
each other, or if we are actually talking about different things.  However,
I think the only way either of us can be more clear is with working code.
You seem to understand the issues, so just code it how you're planning.
Worst case, we just refactor any problems later.

Trevor D. Cook

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

VHJldm9yLA0KDQo8cXVvdGU+DQoNCkludGVyZmFjZSAtIHJlYWxseSBnb29kLCBidXQgSSBkb24n
dCB0aGluayBpdCdzIG5lY2Vzc2FyeSB0byBoYXZlIGxvY2FsZSBhcyBhIHBhcmFtZXRlciBvZiBz
ZXRMb2NhbGUsIHNpbmNlIHRoYXQgbWV0aG9kIHdpbGwgYmUgZGV0ZXJtaW5pbmcgdGhlIGFjdHVh
bCBsb2NhbGUuIFdoYXQgdmFsdWUgYmUgcGFzc2VkIGJ5IHRoZSBDb250cm9sbGVyU2VydmxldCBm
b3IgdGhpcyBwYXJhbWV0ZXI/ICBNYXliZSBpdCB3b3VsZCBiZSBsZXNzIGNvbmZ1c2luZyB0byBt
YWtlIHRoZSBzaWduYXR1cmU6DQoNCkxvY2FsZSByZXNvbHZlTG9jYWxlKEh0dHBTZXJ2bGV0UmVx
dWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJlc3BvbnNlKTsgDQpUaGUgc2lnbmF0
dXJlIG5vdyBtYWtlcyBpdCBjbGVhciB0aGF0IHdlIGFyZSBub3QgInNldHRpbmcgaXQiIHNvIG11
Y2ggYXMgYXNraW5nIHRoZSBtZXRob2QgdG8gZGV0ZXJtaW5lIGhvdyBpdCBzaG91bGQgYmUgc2V0
LiAgSXQgYWxzbyBtYXRjaGVzIHRoZSB2aWV3UmVzb2x2ZXIgdXNhZ2UuIEFuIGFkZGl0aW9uYWwg
InNldExvY2FsZSIgbWV0aG9kIHdpdGggdGhlIHNpZ25hdHVyZSB5b3UgcHJvdmlkZWQ6DQoNCnZv
aWQgc2V0TG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3Bv
bnNlIHJlc3BvbnNlLCBMb2NhbGUgbG9jYWxlKTsgDQpjb3VsZCBiZSB1c2VkIHRvIGV4cGxpY2l0
bHkgb3ZlcnJpZGUgdGhlIExvY2FsZSBkZXRlcm1pbmVkIGJ5IHRoZSByZXNvbHZlTG9jYWxlIG1l
dGhvZC4gIFRoaXMgd291bGQgYmVuZWZpdCBDb250cm9sbGVyIHNwZWNpZmljIG92ZXJyaWRlcyAo
YWRkcmVzc2VkIGJlbG93KS4gIEFzIHlvdSBub3RlZCwgdGhlIHJlc3BvbnNlIGlzIG5lY2Vzc2Fy
eSBmb3IgY29va2llLWJhc2VkIGltcGxlbWVudGF0aW9ucyAoZ29vZCBjYXRjaCkuDQoNCjwvcXVv
dGU+DQoNCkkgYmVsaWV2ZSB3ZSBtZWFuIHRoZSBzYW1lIHRoaW5nLCBhYnNvbHV0ZWx5LiBJJ20g
cGVyZmVjdGx5IGF3YXJlIHRoYXQgd2UgbmVlZCBhIHNldExvY2FsZSBtZXRob2QgdG8gYmUgYWJs
ZSB0byBjaGFuZ2UgdGhlIGN1cnJlbnQgbG9jYWxlIGluIGFuIExvY2FsZVJlc29sdmVyLWltcGxl
bWVudGF0aW9uLWFnbm9zdGljIHdheSwgdGhhdCB3YXMgbXkgb3JpZ2luYWwgaW50ZW50LiBJJ3Zl
IGp1c3QgYmVlbiBjb25mdXNlZCBieSB5b3VyIHJlbWFya3MgcXVvdGVkIGFib3ZlOiBUaGUgZmly
c3QgcGFyYWdyYXBoIHRhbGtzIGFib3V0IGEgc2V0TG9jYWxlIG1ldGhvZCB3aXRob3V0IGEgbG9j
YWxlIHBhcmFtZXRlciwgYW5kIHRoZSB0aGlyZCBwYXJhZ3JhcGggcHJvcG9zZXMgYSBzZXRMb2Nh
bGUgbWV0aG9kIHdpdGggZXhhY3RseSBhIGxvY2FsZSBwYXJhbWV0ZXIuDQoNCkNvbmNlcm5pbmcg
eW91ciBpc3N1ZSBvZiB3aGljaCBsb2NhbGUgZ2V0cyB1c2VkIGZvciB0aGUgY3VycmVudCByZXF1
ZXN0IGlmIHRoZSBjb250cm9sbGVyIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgY2hhbmdlcyB0aGUg
bG9jYWxlLiBMZXQncyBzdGljayB0byBhIExvY2FsZVJlc29sdmVyIGludGVyZmFjZSBsaWtlIHRo
ZSBvbmUgYmVsb3cgKGFuYWxvZ291cyB0byBteSBvcmlnaW5hbCBwcm9wb3NhbCwganVzdCBhZGFw
dGVkIG5hbWluZyk6DQoNCnB1YmxpYyBpbnRlcmZhY2UgTG9jYWxlUmVzb2x2ZXIgew0KDQogIExv
Y2FsZSByZXNvbHZlTG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KTsNCg0KICB2b2lk
IHNldExvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwgSHR0cFNlcnZsZXRSZXNwb25z
ZSByZXNwb25zZSwgTG9jYWxlIGxvY2FsZSk7DQoNCn0NCg0KSSB1bmRlcnN0YW5kIHRoYXQsIHdp
dGggYSBDb29raWVMb2NhbGVSZXNvbHZlciwgaWYgeW91IHNldCBhIG5ldyBsb2NhbGUgY29va2ll
IG9uIHRoZSByZXNwb25zZSBpbiB0aGUgY3VycmVudCByZXF1ZXN0LCB0aGUgbG9jYWxlIHJlc29s
dXRpb24gZm9yIHRoZSBjdXJyZW50IHJlcXVlc3Qgd2lsbCBzdGlsbCByZXN1bHQgaW4gdGhlIGZv
cm1lciBvbmUgd2l0aG91dCBzcGVjaWFsIHRyZWF0bWVudC4gQlRXLCB0aGlzIHByb2JsZW0gY2Fu
bm90IG9jY3VyIHdpdGggc2Vzc2lvbi1iYXNlZCByZXNvbHV0aW9uLCBhcyB0aGUgcmVzb2x2ZUxv
Y2FsZSBtZXRob2Qgd291bGQgZmV0Y2ggdGhlIGZyZXNoIG5ldyBsb2NhbGUgZnJvbSB0aGUgc2Vz
c2lvbiBldmVuIGFmdGVyIGEgcHJlY2VkaW5nIHNldExvY2FsZSBjYWxsIGluIHRoZSBzYW1lIHJl
cXVlc3QuDQoNCkJ1dCBuZXZlcnRoZWxlc3MsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBwcm9k
dWNlIGNvcnJlY3QgYmVoYXZpb3Igd2l0aCBjb29raWUtYmFzZWQgcmVzb2x1dGlvbiBpbiB0aGlz
IGNhc2UuIFRvIGFjaGlldmUgdGhpcywgQ29va2llTG9jYWxlUmVzb2x2ZXIuc2V0TG9jYWxlIGhh
cyB0byBhZGQgYSByZXNwZWN0aXZlIGNvb2tpZSB0byB0aGUgcmVzcG9uc2UgYW5kIGEgcmVzcGVj
dGl2ZSBhdHRyaWJ1dGUgdG8gdGhlIHJlcXVlc3QgKHRoZSBuZXcgTG9jYWxlIHdpdGggYSBzcGVj
aWZpYyBhdHRyaWJ1dGUgbmFtZSkuIENvb2tpZUxvY2FsZVJlc29sdmVyLnJlc29sdmVMb2NhbGUg
aGFzIHRvIGxvb2sgZm9yIHN1Y2ggYSByZXF1ZXN0IGF0dHJpYnV0ZSBiZWZvcmUgbG9va2luZyBm
b3IgYSBjb29raWUuIFRodXMsIGl0IHdpbGwgcmV0cmlldmUgdGhlIG5ldyBsb2NhbGUgZXZlbiBp
ZiB0aGUgcmVxdWVzdCBzdGlsbCBjb250YWlucyB0aGUgb2xkIGxvY2FsZSBjb29raWUuDQoNCkV4
YW1wbGU6IEEgY29udHJvbGxlciBzZXRzIGEgbmV3IGxvY2FsZS4gTGF0ZXIgaW4gcHJvY2Vzc2lu
ZyB0aGUgc2FtZSByZXF1ZXN0LCBhZnRlciBleGVjdXRpb24gb2YgdGhlIGNvbnRyb2xsZXIgdGhh
dCBqdXN0IGNoYW5nZWQgdGhlIGxvY2FsZSwgQ29udHJvbGxlclNlcnZsZXQgY2FsbHMgcmVzb2x2
ZUxvY2FsZSB0byBkZXRlcm1pbmUgdGhlIHZpZXcgbG9jYWxlLiBJdCB3aWxsIHJldHJpZXZlIHRo
ZSBjb3JyZWN0IGxvY2FsZSwgYmVjYXVzZSByZXNvbHZlTG9jYWxlIHdpbGwgZmluZCBhIHJlcXVl
c3QgYXR0cmlidXRlIGNvbnRhaW5pbmcgdGhlIG5ldyBsb2NhbGUgYW5kIG5vdCBldmVuIGNoZWNr
IGNvb2tpZXMuDQoNCkkgaG9wZSBJIHVuZGVyc3Rvb2QgeW91ciByZXF1aXJlbWVudCBjb3JyZWN0
bHkuIElNTyB0aGUgYWJvdmUgbWVudGlvbmVkIGFsZ29yaXRobSB3aWxsIGxlYWQgdG8gY29ycmVj
dCByZXN1bHRzIGluIGFueSBjYXNlLiBCVFcsIEkgY29uc2lkZXIgdGhlIGFic3RyYWN0aW9uIGZh
aXJseSBwb3dlcmZ1bDogQ29udHJvbGxlciBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IGhhdmUgdG8g
a25vdyB0aGUgbG9jYWxlIHJlc29sdXRpb24gbWVjaGFuaXNtIGF0IGFsbCwgdGhleSBkbyBub3Qg
aGF2ZSB0byBjYXJlIGFib3V0IHN1Y2ggdHJpY2tzLiBBbmQgdGhhbmtzIHRvIHRoZSBiZWFuIGZh
Y3RvcnksIExvY2FsZVJlc29sdmVyIGltcGxlbWVudGF0aW9ucyBjYW4gZWFzaWx5IGhhdmUgY29u
ZmlndXJhdGlvbiBwcm9wZXJ0aWVzLCBsaWtlIHRoZSBuYW1lIG9mIHRoZSBsb2NhbGUgY29va2ll
Lg0KDQpKdWVyZ2VuDQoNCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0g
DQoJVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRvOnRjb29rQGludGVycHJpc2Vzb2Z0d2FyZS5jb21d
IA0KCUdlc2VuZGV0OiBTYSAyMi4wMi4yMDAzIDIxOjMwIA0KCUFuOiBTcHJpbmcgRGV2ZWxvcGVy
cyAoRS1tYWlsKSANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBFeHBsaWNpdCBsb2NhbGVzDQoJDQoJDQoNCglUaGUgcmVhc29uIEkgaGFkIHNldExvY2Fs
ZSB3YXMgdG8gYWxsb3cgYSBDb250cm9sbGVyIGFjY2VzcyB0byBjaGFuZ2UgdGhlIGV4cGxpY2l0
IGxvY2FsZS4gIEkgdGhpbmsgdGhlIGVhc2llc3Qgd2F5IHRvIGV4cGxhaW4gdGhpcyBpcyB3aXRo
IG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMgc2hvdWxkIHdvcmsgd2l0aCBhICJjb29raWUi
IGltcGxlbWVudGF0aW9uLg0KDQoJV2hlbiBhIHJlcXVlc3QgaXMgbWFkZSwgaXQgZ29lcyBpbnRv
IHRoZSBDb250cm9sbGVyU2VydmxldC4gIFRoZSBDb250cm9sbGVyU2VydmxldCB0aGFuIGNhbGxz
IHRoZSBDb29raWVMb2NhbGVSZXNvdmxlciByZXNvbHZlTG9jYWxlLiAgSW4gdGhlIHJlc29sdmUg
bWV0aG9kLCBpdCBsb29rcyBmb3IgYSBjb29raWUuICBJZiBpdCBleGlzdHMsIGl0IHNldHMgdGhl
IGxvY2FsZSB0byB0aGUgdmFsdWUgZnJvbSB0aGUgY29va2llLiAgSWYgaXQgZG9lc24ndCBleGlz
dCwgaXQgdXNlcyB0aGUgZGVmYXVsdCAoYnJvd3NlcikgbG9jYWxlIChmcm9tIHRoZSByZXF1ZXN0
IG9iamVjdCkuICBIb3dldmVyLCB0aGlzIG9ubHkgd29ya3MgaWYgdGhlIGNvb2tpZSBpcyBBTFJF
QURZIFNFVC4gIElmIHRoZXJlIGlzIG5vIGNvb2tpZSBpdCByZXNvcnRzIHRvIHRoZSBkZWZhdWx0
IGxvY2FsZS4NCg0KCVRoaXMgYnJpbmdzIHVwIGhvdyB0byBzZXQgdGhlIGNvb2tpZS4gIEZvciBt
eSBhcHBsaWNhdGlvbiwgSSB3aWxsIHByb2JhYmx5IGhhdmUgYSBxdWVyeSBzdHJpbmcgcGFyYW1l
dGVyIGFkZGVkIHRvIHRoZSB1cmwgZm9yIHRoZSBjdXJyZW50IHBhZ2UuICBUaGlzIG1lYW5zIHRo
YXQgaWYgeW91IGFyZSBvbiB0aGUgImFib3V0IiBwYWdlIGFuZCBjbGljayB0aGUgImZyZW5jaCIg
YnV0dG9uLCB5b3UgcmVjZWl2ZSB0aGUgZnJlbmNoIGFib3V0IHBhZ2UuICBTb21lYm9keSBlbHNl
IG1heSBoYXZlIGFuIGV4cGxpY2l0ICJmcmVuY2giIHVybCB3aGljaCByZXR1cm5zIGEgcGFnZSBz
YXlpbmcgInRoYW5rcyBmb3IgY2hvb3NpbmcgZnJlbmNoIi4gIEJlY2F1c2UgZGlmZmVyZW50IGFw
cGxpY2F0aW9ucyBtaWdodCBoYXZlIGRpZmZlcmVudCBtZXRob2RzIG9mIGFsbG93aW5nIHRoZSB1
c2VyIHRvIHNlbGVjdCB0aGUgbG9jYWxlLCB0aGV5IG5lZWQgdG8gYmUgYWJsZSB0byBzZXQgdGhl
IGNvb2tpZSAob3Igc2V0IHRoZSBzZXNzaW9uIHZhcmlhYmxlIGZvciB0aGUgb3RoZXIgaW1wbGVt
ZW50YXRpb24pLiBUbyBwcmV2ZW50IHRoaXMgcHJvYmxlbSwgd2UgY291bGQgZm9yY2UgYXBwbGlj
YXRpb25zIHRvIHVzZSBhIHNpbmdsZSBtZXRob2Qgb2Ygc2V0dGluZyB0aGUgbG9jYWxlLCBidXQg
SSBkb24ndCB0aGluayB0aGlzIGlzIGZsZXhpYmxlIGVub3VnaCwgc28gdGhpcyBicmluZ3MgdXMg
dG8gaG93IGEgQ29udHJvbGxlciB3b3VsZCBzZXQgdGhlIGxvY2FsZS4NCg0KCUlmIHdlIGRvbid0
IGhhdmUgYSAic2V0TG9jYWxlIiBtZXRob2QsIHdlIG5lZWQgdG8gZXhwb3NlIGludGVybmFsIGlt
cGxlbWVudGF0aW9uIGRldGFpbHMuICBJZiB5b3UgdXNlIGEgY29va2llIHZlcnNpb24sIHlvdSBu
ZWVkIHRvIGtub3cgdGhlIGNvb2tpZSBuYW1lIHVzZWQgYnkgdGhlIHJlc29sdmVyLCBjcmVhdGUg
dGhlIGNvb2tpZSwgYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZSBsb2NhbGUgZm9yIHRoZSBDVVJSRU5U
IFJFUVVFU1QgYmVpbmcgaGFuZGxlZCB3aWxsIGJlIHVwZGF0ZWQgKHNlZSBleHBsYW5hdGlvbiBv
ZiB0aGlzIGJlbG93KS4gIEhvd2V2ZXIsIGEgc2Vzc2lvbiBpbXBsZW1lbnRhdGlvbiB3aWxsIG5l
ZWQgdG8ga25vdyB0aGUgbmFtZSBvZiB0aGUgc2Vzc2lvbiBhdHRyaWJ1dGUgdXNlZCBieSBpdHMg
cmVzb2x2ZXIsIGFkZCB0aGUgbG9jYWxlIHRvIHRoZSBzZXNzaW9uLCBhbmQgYWdhaW4gZW5zdXJl
IHRoZSBjdXJyZW50IHJlcXVlc3QgbG9jYWxlLiAgQmVjYXVzZSB0aGVzZSAyIGltcGxlbWVudGF0
aW9ucyBoYXZlIGRpZmZlcmVudCB3YXlzIG9mIGJlaW5nIHNldCwgdGhlIGNvbnRyb2xsZXIgd2hp
Y2ggc2V0cyB0aGVtIGlzIHRoZW4gYm91bmQgdG8gdGhlIHNwZWNpZmljIGltcGxlbWVudGF0aW9u
IChjb29raWUgLyBzZXNzaW9uKS4NCg0KCUlmIHdlIGhhdmUgYSAic2V0TG9jYWxlIiBtZXRob2Qs
IHRoZSBDb250cm9sbGVyIHNpbXBseSBjYWxscyB0aGUgaW50ZXJmYWNlIHNldExvY2FsZSBtZXRo
b2QsIGFuZCB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gc2V0cyB0aGUgYXBwcm9wcmlhdGUg
Y29va2llIC9zZXNzaW9uLiAgVGhpcyBoYXMgdGhlIGJlbmVmaXQgb2YgYWxsb3dpbmcgZWFjaCBh
cHBsaWNhdGlvbiB0byBkZWNpZGUgaG93IHRvIGFsbG93IHVzZXJzIHRvIGV4cGxpY2l0bHkgc2V0
IGEgbG9jYWxlLCBidXQgZG9lcyBub3QgdGllIHRoZSBDb250cm9sbGVyIHRvIGEgc3BlY2lmaWMg
aW1wbGVtZW50YXRpb24uICBUaGlzIGFsc28gYWxsb3dzIHRoZW0gdG8gY2hhbmdlIGZyb20gYSBj
b29raWUgcmVzb2x2ZXIgdG8gYSBzZXNzaW9uIHJlc29sdmVyIGJ5IG1vZGlmeWluZyB0aGUgY2xh
c3MgaW4gdGhlIGNvbmZpZyBmaWxlIHdpdGhvdXQgdG91Y2hpbmcgY29kZS4NCg0KCUkgbWF5IGJl
IG1pc3VuZGVyc3RhbmRpbmcgaG93IHlvdSBwbGFuIHRvIGltcGxlbWVudCBpdCwgYnV0IHRoZSB3
YXkgSSB3b3VsZCBpbXBsZW1lbnQgaXQgaGFkIHRoZSBwcm9ibGVtIEkndmUganVzdCBkZXNjcmli
ZWQsIHByb21wdGluZyB0aGUgdGhpcmQgInNldExvY2FsZSIgbWV0aG9kLg0KDQoJQWJvdmUgSSBt
ZW50aW9uZWQgIm1ha2Ugc3VyZSB0aGF0IHRoZSBsb2NhbGUgZm9yIHRoZSBDVVJSRU5UIFJFUVVF
U1QgYmVpbmcgaGFuZGxlZCB3aWxsIGJlIHVwZGF0ZWQiLiAgV2hlbiBJIGRpZCBteSBwcm90b3R5
cGUgaW1wbGVtZW50YXRpb24sIEkgZm91bmQgdGhhdCBJIHdvdWxkIHNldCB0aGUgY29va2llIGFu
ZCB0aGVuIHJldHVybiBhIHBhZ2UsIGJ1dCB0aGUgbGFuZ3VhZ2Ugd291bGRuJ3QgY2hhbmdlLiAg
T24gcmV2aWV3IEkgbm90aWNlZCB0aGUgZm9sbG93aW5nIHNlcXVlbmNlIG9mIGV2ZW50cy4NCg0K
CSAgICAgICAgLSByZXF1ZXN0IHNlbnQgdG8gc2VydmxldCBjb250cm9sbGVyIA0KCSAgICAgICAg
LSBzZXJ2bGV0Q29udHJvbGxlciBjaGVja3MgZm9yIGNvb2tpZSBhbmQgc2V0cyBsb2NhbGUgDQoJ
ICAgICAgICAtIGNvbnRyb2xsZXIgY2hlY2tzIGlmIGxvY2FsZSBpbiBxdWVyeSBzdHJpbmcgYW5k
IHNldHMgY29va2llIA0KCSAgICAgICAgLSBjb250cm9sbGVyIHJldHVybnMgcGFnZSANCglCZWNh
dXNlIHRoZSBzZXJ2bGV0Q29udHJvbGxlciBzZXQgdGhlIGxvY2FsZSBiZWZvcmUgY29udHJvbGxl
ciBwcm9jZXNzaW5nLCBzZXR0aW5nIHRoZSBjb29raWUgZGlkbid0IGNoYW5nZSB0aGUgbG9jYWxl
IGZvciB0aGUgY3VycmVudCByZXF1ZXN0LiAgSWYgSSBtb3ZlZCB0aGUgc2VydmxldENvbnRyb2xs
ZXIgY2hlY2sgYWZ0ZXIgdGhlIGNvbnRyb2xsZXIgaXMgZG9uZSwgaXQgaXNuJ3QgYWJsZSB0byBk
byBhbnkgcHJvY2Vzc2luZyBiYXNlZCBvbiB0aGUgZXhwbGljaXRseSBzZXQgbG9jYWxlLiAgVGhp
cyBwb2ludGVkIG91dCBteSBvdmVyc2lnaHQgdGhhdCB3aGVuIEkgc2V0IHRoZSBjb29raWUgSSBh
bHNvIG5lZWQgdG8gdG8gc2V0IHRoZSBjdXJyZW50IGxvY2FsZSAoZXZlbiB0aG91Z2ggdGhlIHNl
cnZsZXRDb250cm9sbGVyIHByZXZpb3VzbHkgbWFkZSB0aGUgY2hlY2spLiAgVGhpcyBhbGxvd3Mg
Y29udHJvbGxlcnMgdG8ga25vdyB3aGljaCBsb2NhbGUgd2FzIGV4cGxpY2l0bHkgc2V0LCBidXQg
YWxzbyBhbGxvd3MgdGhlbSB0byBjaGFuZ2UgdGhhdCB2YWx1ZS4gIFlvdSBndXlzIG1heSBoYXZl
IHRob3VnaHQgb2YgdGhpcyBwcm9ibGVtIGFscmVhZHksIGJ1dCBpdCBjYXVnaHQgbWUgb2ZmIGd1
YXJkIChhbmQgY29zdCBtZSAyMCBtaW4gdG8gZmluZCB0aGUgc291cmNlIDooICkuDQoNCglUcmV2
b3IgRC4gQ29vaw0KDQo=

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

The reason I had setLocale was to allow a Controller access to change the
explicit locale.  I think the easiest way to explain this is with my
understanding of how this should work with a "cookie" implementation.

When a request is made, it goes into the ControllerServlet.  The
ControllerServlet than calls the CookieLocaleResovler resolveLocale.  In the
resolve method, it looks for a cookie.  If it exists, it sets the locale to
the value from the cookie.  If it doesn't exist, it uses the default
(browser) locale (from the request object).  However, this only works if the
cookie is ALREADY SET.  If there is no cookie it resorts to the default
locale.

This brings up how to set the cookie.  For my application, I will probably
have a query string parameter added to the url for the current page.  This
means that if you are on the "about" page and click the "french" button, you
receive the french about page.  Somebody else may have an explicit "french"
url which returns a page saying "thanks for choosing french".  Because
different applications might have different methods of allowing the user to
select the locale, they need to be able to set the cookie (or set the
session variable for the other implementation). To prevent this problem, we
could force applications to use a single method of setting the locale, but I
don't think this is flexible enough, so this brings us to how a Controller
would set the locale.

If we don't have a "setLocale" method, we need to expose internal
implementation details.  If you use a cookie version, you need to know the
cookie name used by the resolver, create the cookie, and make sure that the
locale for the CURRENT REQUEST being handled will be updated (see
explanation of this below).  However, a session implementation will need to
know the name of the session attribute used by its resolver, add the locale
to the session, and again ensure the current request locale.  Because these
2 implementations have different ways of being set, the controller which
sets them is then bound to the specific implementation (cookie / session).

If we have a "setLocale" method, the Controller simply calls the interface
setLocale method, and the specific implementation sets the appropriate
cookie /session.  This has the benefit of allowing each application to
decide how to allow users to explicitly set a locale, but does not tie the
Controller to a specific implementation.  This also allows them to change
from a cookie resolver to a session resolver by modifying the class in the
config file without touching code.

I may be misunderstanding how you plan to implement it, but the way I would
implement it had the problem I've just described, prompting the third
"setLocale" method.

Above I mentioned "make sure that the locale for the CURRENT REQUEST being
handled will be updated".  When I did my prototype implementation, I found
that I would set the cookie and then return a page, but the language
wouldn't change.  On review I noticed the following sequence of events.
	- request sent to servlet controller
	- servletController checks for cookie and sets locale
	- controller checks if locale in query string and sets cookie
	- controller returns page
Because the servletController set the locale before controller processing,
setting the cookie didn't change the locale for the current request.  If I
moved the servletController check after the controller is done, it isn't
able to do any processing based on the explicitly set locale.  This pointed
out my oversight that when I set the cookie I also need to to set the
current locale (even though the servletController previously made the
check).  This allows controllers to know which locale was explicitly set,
but also allows them to change that value.  You guys may have thought of
this problem already, but it caught me off guard (and cost me 20 min to find
the source :( ).

Trevor D. Cook

-----Original Message-----
From: jürgen höller [werk3AT] [mailto:jh...@we...]
Sent: February 22, 2003 1:57 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Explicit locales


Trevor,
 
The name "LocaleResolver" is fine, and naming the retrieval method
"resolveLocale" too, analogous to ViewResolver. But I'm not sure what you
mean concerning the setLocale method and its Locale parameter: We need a way
of telling the resolver that the user has chosen a specific locale - just
like you note in your 4th paragraph. I.e. one resolution method and one
modification method.
 
I also prefer the "viewResolver" bean reference, looked up by the
ControllerServlet, without individual LocaleResolver instances per
controller. Of course, controllers need a way to both retrieve and set the
current locale. So we should probably propagate the ControllerServlet's
LocaleResolver instance via HandlerMapping to Controller instances that
implement LocaleResolverAware (as I've already proposed), analogous to
ApplicationContext and ApplicationContextAware.
 
Concerning LocaleResolver implementations: Maybe call the default
implementation "BrowserSettingLocaleResolver"? And yes, we should provide a
"SessionLocaleResolver" and a "CookieLocaleResolver" out of the box.
 
I like that locale resolution support: fairly sophisticated, but still
reasonably simple!
 
Juergen
 
 

	-----Ursprüngliche Nachricht----- 
	Von: Trevor Cook [mailto:tc...@in...] 
	Gesendet: Sa 22.02.2003 17:30 
	An: spr...@li... 
	Cc: 
	Betreff: RE: [Springframework-developer] Explicit locales
	
	

	Naming - I agree that LocaleHandler is confusing. I like
LocaleResolver, since it is consistent with the the ViewResolver classes. 

	Interface - really good, but I don't think it's necessary to have
locale as a parameter of setLocale, since that method will be determining
the actual locale. What value be passed by the ControllerServlet for this
parameter?  Maybe it would be less confusing to make the signature:

	        Locale resolveLocale(HttpServletRequest request,
HttpServletResponse response); 
	The signature now makes it clear that we are not "setting it" so
much as asking the method to determine how it should be set.  It also
matches the viewResolver usage. An additional "setLocale" method with the
signature you provided:

	        void setLocale(HttpServletRequest request,
HttpServletResponse response, Locale locale); 
	could be used to explicitly override the Locale determined by the
resolveLocale method.  This would benefit Controller specific overrides
(addressed below).  As you noted, the response is necessary for cookie-based
implementations (good catch).

	Configuration - I think that loading it as a bean reference (like
"viewResolver") makes the most sense.  If we provide an access method, this
would allow individual Controllers to get a reference to the resolver and
override the locale using the setLocale method mentioned above.  I think the
ControllerServlet should handle the locale resolution rather than a
"LocaleHandler-per-Controller".  If someone needs "normal" locale handling,
I think the per-Controller method would require too much cut-n-paste type
code.  However, the exposed setLocale method would allow those who need to
set it on a per-Controller basis the ability to do so.

	DefaultImplementation - I think "ClientLocaleHandler" is too
general, since all LocaleHandlers (or LocaleResolvers as I prefer :) ) are
making decisions based on the client.  The default will be using the
servlets default mechanism, so maybe "ServletLocaleResolver" or
"RequestLocaleResolver" (although again, too me they're too general - I
can't think of a really good name).  We should also create additional
implementations for distribution such as the cookie and session based
versions, rather than requiring each client to code one themselves (although
they will have the oppurtunity to do so).

	Great analysis Juergen! 


	Trevor D. Cook 
	
	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
	  

NHY޵隊X'u'$ح"wzyN\jkz+jw_bnWמv+h*.quڲ׫
"Z0.fj+xTD}k$뉩p
%v+\oy+䩮)~{
+ׯzZ)zXX*kxŠuޖ^X(~zwilqzlX)ߣ))~{
+ׯzZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

VHJldm9yLA0KIA0KVGhlIG5hbWUgIkxvY2FsZVJlc29sdmVyIiBpcyBmaW5lLCBhbmQgbmFtaW5n
IHRoZSByZXRyaWV2YWwgbWV0aG9kICJyZXNvbHZlTG9jYWxlIiB0b28sIGFuYWxvZ291cyB0byBW
aWV3UmVzb2x2ZXIuIEJ1dCBJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBjb25jZXJuaW5nIHRo
ZSBzZXRMb2NhbGUgbWV0aG9kIGFuZCBpdHMgTG9jYWxlIHBhcmFtZXRlcjogV2UgbmVlZCBhIHdh
eSBvZiB0ZWxsaW5nIHRoZSByZXNvbHZlciB0aGF0IHRoZSB1c2VyIGhhcyBjaG9zZW4gYSBzcGVj
aWZpYyBsb2NhbGUgLSBqdXN0IGxpa2UgeW91IG5vdGUgaW4geW91ciA0dGggcGFyYWdyYXBoLiBJ
LmUuIG9uZSByZXNvbHV0aW9uIG1ldGhvZCBhbmQgb25lIG1vZGlmaWNhdGlvbiBtZXRob2QuDQog
DQpJIGFsc28gcHJlZmVyIHRoZSAidmlld1Jlc29sdmVyIiBiZWFuIHJlZmVyZW5jZSwgbG9va2Vk
IHVwIGJ5IHRoZSBDb250cm9sbGVyU2VydmxldCwgd2l0aG91dCBpbmRpdmlkdWFsIExvY2FsZVJl
c29sdmVyIGluc3RhbmNlcyBwZXIgY29udHJvbGxlci4gT2YgY291cnNlLCBjb250cm9sbGVycyBu
ZWVkIGEgd2F5IHRvIGJvdGggcmV0cmlldmUgYW5kIHNldCB0aGUgY3VycmVudCBsb2NhbGUuIFNv
IHdlIHNob3VsZCBwcm9iYWJseSBwcm9wYWdhdGUgdGhlIENvbnRyb2xsZXJTZXJ2bGV0J3MgTG9j
YWxlUmVzb2x2ZXIgaW5zdGFuY2UgdmlhIEhhbmRsZXJNYXBwaW5nIHRvIENvbnRyb2xsZXIgaW5z
dGFuY2VzIHRoYXQgaW1wbGVtZW50IExvY2FsZVJlc29sdmVyQXdhcmUgKGFzIEkndmUgYWxyZWFk
eSBwcm9wb3NlZCksIGFuYWxvZ291cyB0byBBcHBsaWNhdGlvbkNvbnRleHQgYW5kIEFwcGxpY2F0
aW9uQ29udGV4dEF3YXJlLg0KIA0KQ29uY2VybmluZyBMb2NhbGVSZXNvbHZlciBpbXBsZW1lbnRh
dGlvbnM6IE1heWJlIGNhbGwgdGhlIGRlZmF1bHQgaW1wbGVtZW50YXRpb24gIkJyb3dzZXJTZXR0
aW5nTG9jYWxlUmVzb2x2ZXIiPyBBbmQgeWVzLCB3ZSBzaG91bGQgcHJvdmlkZSBhICJTZXNzaW9u
TG9jYWxlUmVzb2x2ZXIiIGFuZCBhICJDb29raWVMb2NhbGVSZXNvbHZlciIgb3V0IG9mIHRoZSBi
b3guDQogDQpJIGxpa2UgdGhhdCBsb2NhbGUgcmVzb2x1dGlvbiBzdXBwb3J0OiBmYWlybHkgc29w
aGlzdGljYXRlZCwgYnV0IHN0aWxsIHJlYXNvbmFibHkgc2ltcGxlIQ0KIA0KSnVlcmdlbg0KIA0K
IA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFRyZXZvciBD
b29rIFttYWlsdG86dGNvb2tAaW50ZXJwcmlzZXNvZnR3YXJlLmNvbV0gDQoJR2VzZW5kZXQ6IFNh
IDIyLjAyLjIwMDMgMTc6MzAgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMu
c291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCg0KCU5hbWluZyAtIEkgYWdyZWUgdGhh
dCBMb2NhbGVIYW5kbGVyIGlzIGNvbmZ1c2luZy4gSSBsaWtlIExvY2FsZVJlc29sdmVyLCBzaW5j
ZSBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHRoZSBWaWV3UmVzb2x2ZXIgY2xhc3Nlcy4gDQoN
CglJbnRlcmZhY2UgLSByZWFsbHkgZ29vZCwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncyBuZWNlc3Nh
cnkgdG8gaGF2ZSBsb2NhbGUgYXMgYSBwYXJhbWV0ZXIgb2Ygc2V0TG9jYWxlLCBzaW5jZSB0aGF0
IG1ldGhvZCB3aWxsIGJlIGRldGVybWluaW5nIHRoZSBhY3R1YWwgbG9jYWxlLiBXaGF0IHZhbHVl
IGJlIHBhc3NlZCBieSB0aGUgQ29udHJvbGxlclNlcnZsZXQgZm9yIHRoaXMgcGFyYW1ldGVyPyAg
TWF5YmUgaXQgd291bGQgYmUgbGVzcyBjb25mdXNpbmcgdG8gbWFrZSB0aGUgc2lnbmF0dXJlOg0K
DQoJICAgICAgICBMb2NhbGUgcmVzb2x2ZUxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVz
dCwgSHR0cFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSk7IA0KCVRoZSBzaWduYXR1cmUgbm93IG1h
a2VzIGl0IGNsZWFyIHRoYXQgd2UgYXJlIG5vdCAic2V0dGluZyBpdCIgc28gbXVjaCBhcyBhc2tp
bmcgdGhlIG1ldGhvZCB0byBkZXRlcm1pbmUgaG93IGl0IHNob3VsZCBiZSBzZXQuICBJdCBhbHNv
IG1hdGNoZXMgdGhlIHZpZXdSZXNvbHZlciB1c2FnZS4gQW4gYWRkaXRpb25hbCAic2V0TG9jYWxl
IiBtZXRob2Qgd2l0aCB0aGUgc2lnbmF0dXJlIHlvdSBwcm92aWRlZDoNCg0KCSAgICAgICAgdm9p
ZCBzZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9u
c2UgcmVzcG9uc2UsIExvY2FsZSBsb2NhbGUpOyANCgljb3VsZCBiZSB1c2VkIHRvIGV4cGxpY2l0
bHkgb3ZlcnJpZGUgdGhlIExvY2FsZSBkZXRlcm1pbmVkIGJ5IHRoZSByZXNvbHZlTG9jYWxlIG1l
dGhvZC4gIFRoaXMgd291bGQgYmVuZWZpdCBDb250cm9sbGVyIHNwZWNpZmljIG92ZXJyaWRlcyAo
YWRkcmVzc2VkIGJlbG93KS4gIEFzIHlvdSBub3RlZCwgdGhlIHJlc3BvbnNlIGlzIG5lY2Vzc2Fy
eSBmb3IgY29va2llLWJhc2VkIGltcGxlbWVudGF0aW9ucyAoZ29vZCBjYXRjaCkuDQoNCglDb25m
aWd1cmF0aW9uIC0gSSB0aGluayB0aGF0IGxvYWRpbmcgaXQgYXMgYSBiZWFuIHJlZmVyZW5jZSAo
bGlrZSAidmlld1Jlc29sdmVyIikgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UuICBJZiB3ZSBwcm92aWRl
IGFuIGFjY2VzcyBtZXRob2QsIHRoaXMgd291bGQgYWxsb3cgaW5kaXZpZHVhbCBDb250cm9sbGVy
cyB0byBnZXQgYSByZWZlcmVuY2UgdG8gdGhlIHJlc29sdmVyIGFuZCBvdmVycmlkZSB0aGUgbG9j
YWxlIHVzaW5nIHRoZSBzZXRMb2NhbGUgbWV0aG9kIG1lbnRpb25lZCBhYm92ZS4gIEkgdGhpbmsg
dGhlIENvbnRyb2xsZXJTZXJ2bGV0IHNob3VsZCBoYW5kbGUgdGhlIGxvY2FsZSByZXNvbHV0aW9u
IHJhdGhlciB0aGFuIGEgIkxvY2FsZUhhbmRsZXItcGVyLUNvbnRyb2xsZXIiLiAgSWYgc29tZW9u
ZSBuZWVkcyAibm9ybWFsIiBsb2NhbGUgaGFuZGxpbmcsIEkgdGhpbmsgdGhlIHBlci1Db250cm9s
bGVyIG1ldGhvZCB3b3VsZCByZXF1aXJlIHRvbyBtdWNoIGN1dC1uLXBhc3RlIHR5cGUgY29kZS4g
IEhvd2V2ZXIsIHRoZSBleHBvc2VkIHNldExvY2FsZSBtZXRob2Qgd291bGQgYWxsb3cgdGhvc2Ug
d2hvIG5lZWQgdG8gc2V0IGl0IG9uIGEgcGVyLUNvbnRyb2xsZXIgYmFzaXMgdGhlIGFiaWxpdHkg
dG8gZG8gc28uDQoNCglEZWZhdWx0SW1wbGVtZW50YXRpb24gLSBJIHRoaW5rICJDbGllbnRMb2Nh
bGVIYW5kbGVyIiBpcyB0b28gZ2VuZXJhbCwgc2luY2UgYWxsIExvY2FsZUhhbmRsZXJzIChvciBM
b2NhbGVSZXNvbHZlcnMgYXMgSSBwcmVmZXIgOikgKSBhcmUgbWFraW5nIGRlY2lzaW9ucyBiYXNl
ZCBvbiB0aGUgY2xpZW50LiAgVGhlIGRlZmF1bHQgd2lsbCBiZSB1c2luZyB0aGUgc2VydmxldHMg
ZGVmYXVsdCBtZWNoYW5pc20sIHNvIG1heWJlICJTZXJ2bGV0TG9jYWxlUmVzb2x2ZXIiIG9yICJS
ZXF1ZXN0TG9jYWxlUmVzb2x2ZXIiIChhbHRob3VnaCBhZ2FpbiwgdG9vIG1lIHRoZXkncmUgdG9v
IGdlbmVyYWwgLSBJIGNhbid0IHRoaW5rIG9mIGEgcmVhbGx5IGdvb2QgbmFtZSkuICBXZSBzaG91
bGQgYWxzbyBjcmVhdGUgYWRkaXRpb25hbCBpbXBsZW1lbnRhdGlvbnMgZm9yIGRpc3RyaWJ1dGlv
biBzdWNoIGFzIHRoZSBjb29raWUgYW5kIHNlc3Npb24gYmFzZWQgdmVyc2lvbnMsIHJhdGhlciB0
aGFuIHJlcXVpcmluZyBlYWNoIGNsaWVudCB0byBjb2RlIG9uZSB0aGVtc2VsdmVzIChhbHRob3Vn
aCB0aGV5IHdpbGwgaGF2ZSB0aGUgb3BwdXJ0dW5pdHkgdG8gZG8gc28pLg0KDQoJR3JlYXQgYW5h
bHlzaXMgSnVlcmdlbiEgDQoNCg0KCVRyZXZvciBELiBDb29rIA0KCQ0KCS0tLQ0KCU91dGdvaW5n
IG1haWwgaXMgY2VydGlmaWVkIFZpcnVzIEZyZWUuDQoJQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1
cyBzeXN0ZW0gKGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KCVZlcnNpb246IDYuMC40NTYgLyBW
aXJ1cyBEYXRhYmFzZTogMjU2IC0gUmVsZWFzZSBEYXRlOiAyLzE4LzAzDQoJICANCg0K

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

SmVhbi1QaWVycmUsDQogDQpDb25jZXJuaW5nIHlvdXIgSlNUTCBoYW5kbGluZzogSSBhc3N1bWUg
aXQgaXMgYWJvdXQgZXhwb3NpbmcgU3ByaW5nJ3MgbWVzc2FnZSByZXNvdXJjZSBidW5kbGUgYW5k
IHRoZSBjdXJyZW50IGxvY2FsZSB0byBKU1RMIHRhZ3MuIFdlIHNob3VsZCByZWFsbHkgdGhpbmsg
YWJvdXQgc3VwcG9ydGluZyB0aGlzIHdpdGhpbiBTcHJpbmcuDQogDQpKU1RMIGRlZmluZXMgc3Rh
bmRhcmQgYXR0cmlidXRlIG5hbWVzLCB1c2FibGUgYXQgYWxsIHNjb3BlIGxldmVscywgZm9yIHN0
YW5kYXJkIExvY2FsZSBhbmQgZm9yIGl0cyBzcGVjaWZpYyBjbGFzcyBMb2NhbGl6YXRpb25Db250
ZXh0IHRoYXQgY29tYmluZXMgUmVzb3VyY2VCdW5kbGUgYW5kIExvY2FsZSBwcm9wZXJ0aWVzLiBU
aGUgYXBwcm9wcmlhdGUgbGV2ZWwgZm9yIFNwcmluZyBzdXBwb3J0IGlzIHByb2JhYmx5IGV4cG9z
aW5nIGEgTG9jYWxpemF0aW9uQ29udGV4dCBhdCByZXF1ZXN0IHNjb3BlLiBFeHBvc2luZyBzaG91
bGQgaGFwcGVuIGFmdGVyIHJlcXVlc3QgcHJvY2Vzc2luZywgYXMgYSBjb250cm9sbGVyIGNvdWxk
IGNoYW5nZSB0aGUgdXNlcidzIGN1cnJlbnQgbG9jYWxlLg0KIA0KT2YgY291cnNlLCB0aGVyZSBh
cmUgdmFyaW91cyB3YXlzIG9mIHN1cHBvcnQ6IFdlIGNvdWxkIG1ha2UgdGhlIENvbnRyb2xsZXJT
ZXJ2bGV0IGV4cG9zZSB0aGUgTG9jYWxpemF0aW9uQ29udGV4dCwgb3IgbGVhdmUgdGhhdCB0byBl
YWNoIGNvbnRyb2xsZXIgaW1wbGVtZW50YXRpb24uIEJ1dCBJIGNvbnNpZGVyIGEgSlNUTC1zcGVj
aWZpYyBWaWV3IGltcGxlbWVudGF0aW9uIHRoZSBiZXN0IGNob2ljZSwgaS5lLiBhIEpzdGxWaWV3
IGNsYXNzLiBUaGUgbGF0dGVyIHNob3VsZCBiYXNpY2FsbHkgYmVoYXZlIGxpa2UgYW4gSW50ZXJu
YWxSZXNvdXJjZVZpZXcsIGJ1dCBhZGRpdGlvbmFsbHkgcmV0cmlldmUgdGhlIFdlYkFwcGxpY2F0
aW9uQ29udGV4dCdzIG1lc3NhZ2UgcmVzb3VyY2UgYnVuZGxlIGFuZCB0aGUgY3VycmVudCBsb2Nh
bGUgKHZpYSBvdXIgbmV3bHkgcHJvcG9zZWQgTG9jYWxlUmVzb2x2ZXIpLCBhbmQgZXhwb3NlIHRo
ZW0gYXMgYSBKU1RMIExvY2FsaXphdGlvbkNvbnRleHQuDQogDQpUaGVyZSdzIG9uZSBkcmF3YmFj
azogU3ByaW5nJ3MgTWVzc2FnZVNvdXJjZSBpcyBhIGdlbmVyaWMgaW50ZXJmYWNlLCBhbmQgUmVz
b3VyY2VCdW5kbGVNZXNzYWdlU291cmNlIGp1c3Qgb25lIGltcGxlbWVudGF0aW9uIG9mIGl0LiBK
U1RMIGV4cGVjdHMgYSBSZXNvdXJjZUJ1bmRsZSwgYnV0IHdlIGRvbid0IHdhbnQgdG8gdGllIG91
ciBzdXBwb3J0IHRvIFJlc291cmNlQnVuZGxlTWVzc2FnZVNvdXJjZXMuIEZvcnR1bmF0ZWx5LCB0
aGlzIGlzIG5vdCBoYXJkIHRvIHNvbHZlOiBSZXNvdXJjZUJ1bmRsZSBpcyBhbiBhYnN0cmFjdCBj
bGFzcywgcmVxdWlyaW5nIGFuICJPYmplY3QgaGFuZGxlR2V0T2JqZWN0KFN0cmluZyBrZXkpIiBp
bXBsZW1lbnRhdGlvbi4gV2UgY2FuIGludHJvZHVjZSBhIE1lc3NhZ2VTb3VyY2VSZXNvdXJjZUJ1
bmRsZSBjbGFzcyAocHVuIGludGVuZGVkKSB0aGF0IGRlbGVnYXRlcyB0byAiTWVzc2FnZVNvdXJj
ZS5nZXRNZXNzYWdlKFN0cmluZyBjb2RlLCBMb2NhbGUgbG9jYWxlKS4gQW4gaW5zdGFuY2Ugb2Yg
aXQgY291bGQgYmUgY3JlYXRlZCBvbi10aGUtZmx5IGJ5IEpzdGxWaWV3LCB1c2luZyB0aGUgY3Vy
cmVudCBsb2NhbGUuDQogDQpXaGF0IGRvIHlvdSB0aGluaywgd291bGQgc3VjaCBhIHNvbHV0aW9u
IGJlIGFwcHJvcHJpYXRlPyBJZiB5ZXMsIHRoZW4gSSdtIGdvbm5hIGFkZCBpdCBwcm9tcHR5IGlu
IHRoZSBjb3Vyc2Ugb2YgbXkgY3VycmVudCB3ZWIgcGFja2FnZSBwb2xpc2hpbmcuIEl0IGlzIHNp
bXBsZSBidXQgbmV2ZXJ0aGVsZXNzIHZlcnkgY29udmVuaWVudCwgSU1ITy4NCiANCkp1ZXJnZW4N
CiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBKUCBQ
QVdMQUsoVGlzY2FsaSkgW21haWx0bzpqcC5wYXdsYWtAdGlzY2FsaS5mcl0gDQoJR2VzZW5kZXQ6
IEZyIDIxLjAyLjIwMDMgMDg6MDMgDQoJQW46IFNwcmluZyBEZXZlbG9wZXJzIChFLW1haWwpIA0K
CUNjOiANCglCZXRyZWZmOiBUUiA6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBFeHBsaWNp
dCBsb2NhbGVzDQoJDQoJDQoNCglFbnZvecOpIDogamV1ZGkgMjAgZsOpdnJpZXIgMjAwMyAyMjo1
MA0KCcOAIDogJ1RyZXZvciBDb29rJw0KCU9iamV0IDogUkUgOiBbU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blcl0gRXhwbGljaXQgbG9jYWxlcw0KDQoJIA0KDQoJSSB1c2UgYSBzb2x1dGlvbiBuZWFy
IG9mIHlvdXJzIGJ1dCB3aXRoIGEgbW9yZSBnZW5lcmFsaXN0IGFwcHJvYWNoLiBUbyBrZWVwIHRo
ZSB1c2VycyBsb2NhbGUsIGRpZmZlcmVudCBwb3NzaWJpbGl0aWVzIGV4aXN0OiBzZXNzaW9uLCBj
b29raWUsIFVSTC4gQnV0IGVhY2ggc29sdXRpb24gY2FuIGJlIGhhbmRsZWQga25vd2luZyB0aGUg
cmVxdWVzdCBvYmplY3QuIFNvIEkgdXNlIGEgYmVhbiBmb3IgaW1wbGVtZW50aW5nIHRoZSBlZmZl
Y3RpdmUgc3RyYXRlZ3kgaW4gdGhlIHdheSBvZiB0aGUgZ2VuZXJhbCBzcGlyaXQgb2YgU3ByaW5n
Lg0KDQoJIDEpIENyZWF0ZSBhIHNpbXBsZSBpbnRlcmZhY2UgbGlrZSB0aGlzOg0KDQoJcHVibGlj
IGludGVyZmFjZSBMb2NhbGVMb2NhdG9yIHsNCg0KCSAgICAgIExvY2FsZSBnZXRTZXNzaW9uTG9j
YWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KTsNCg0KCSAgICAgIHZvaWQgc2V0U2Vzc2lv
bkxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwgTG9jYWxlIHNlc3Npb25Mb2NhbGUp
Ow0KDQoJfQ0KDQoJMikgQ3JlYXRlIGFuIGltcGxlbWVudGF0aW9uIGNsYXNzIHdoaWNoIGluIHlv
dXIgY2FzZSBoYW5kbGVzIHdpdGggdGhlIGNvb2tpZXMsIGJ1dCB3aGljaCBjYW4gdXNlIHRoZSBz
ZXNzaW9uIG9yIHdoYXQgbWV0aG9kIHlvdSBsaWtlLg0KDQoJMykgT3ZlcnJpZGluZyB0aGUgQ29u
dHJvbGxlclNlcnZsZXQgdG8gdXNlIGEgTG9jYWxlTG9jYXRvciBwcm9wZXJ0eSB3aXRoIGF0IGxl
YXN0IHRoZSBzZXR0ZXIsIHNvIHRoZSBpbXBsZW1lbnRhdGlvbiBjbGFzcyBjYW4gYmUgZG9uZSBp
biB0aGUgc2VydmxldC1jb25maWd1cmF0aW9uIGZpbGUuDQoNCgkgICAgICA8YmVhbiBuYW1lPSJs
b2NhbGVMb2NhdG9yIiBzaW5nbGV0b249InRydWUiIGNsYXNzPSJwZXJzby5qcHAuZndrLndlYi5M
b2NhbGVMb2NhdG9ySW1wbCIgLz4gICAgDQoNCgkgICAgICA8YmVhbiBuYW1lPSJqc3RsSGFuZGxl
ciIgc2luZ2xldG9uPSJ0cnVlIiBjbGFzcz0icGVyc28uanBwLmZ3ay53ZWIuSnN0bEhhbmRsZXJJ
bXBsIiA+ICAgICAgDQoNCgkgICAgICAgICAgICA8cHJvcGVydHkgbmFtZT0iYnVuZGxlTmFtZSI+
YWNoYXBwcm88L3Byb3BlcnR5Pg0KDQoJICAgICAgPC9iZWFuPg0KDQoJIA0KDQoJY29kZSBhZGRl
ZCBpbiBkZWNsYXJhdGlvbiBwYXJ0Og0KDQoJICAgICAgLy8gQWRkZWQgYnkgSlBQDQoNCgkgICAg
ICAvKiogVGhlIGJlYW4gbmFtZSBhbGxvd2luZyB0aGUgdXNlciBzZXNzaW9uIGxvY2FsZSB0byBi
ZSByZXRyaWV2ZWQgKi8gDQoNCgkgICAgICBwdWJsaWMgc3RhdGljIGZpbmFsIFN0cmluZyBMT0NB
TEVfTE9DQVRPUiA9ICJsb2NhbGVMb2NhdG9yIjsNCg0KCSANCg0KCSAgICAgIC8qKiBUaGUgYmVh
biBuYW1lIGFsbG93aW5nIHRoZSBqc3RsIHJlc3NvdWVjZSBidW5kbGUgdG8gYmUgc2V0ICovIA0K
DQoJICAgICAgcHVibGljIHN0YXRpYyBmaW5hbCBTdHJpbmcgSlNUTF9IQU5ETEVSID0gImpzdGxI
YW5kbGVyIjsNCg0KCSANCg0KCSAgICAgIC8qKiBMb2NhbGVMb2NhdG9yIHVzZWQgYnkgdGhpcyBz
ZXJ2bGV0DQoNCgkgICAgICAgKiBJZiBub3QgcHJvdmlkZWQsIHJlcXVlc3QuZ2V0TG9jYWxlKCkg
d2lsbCBiZSB1c2VkIGluc3RlYWQgKi8gIA0KDQoJICAgICAgcHJpdmF0ZSBMb2NhbGVMb2NhdG9y
IGxvY2FsZUxvY2F0b3I7DQoNCgkgICAgICAvLyBFbmQgYWRkZWQNCg0KCSANCg0KCSANCg0KCWNv
ZGUgYWRkZWQgaW4gQ29udHJvbGxlclNlcnZsZXQgKG9yIGRlc2NlbmRlbnQpIGF0IGVuZCBvZiBp
bml0RnJhbWV3b3JrU2VydmxldCA6DQoNCgkgICAgICAgICAgICBpbml0Vmlld1Jlc29sdmVyKCk7
DQoNCgkgICAgICAgICAgICANCg0KCSAgICAgICAgICAgIC8vIEFkZGVkIGJ5IEpQUA0KDQoJICAg
ICAgICAgICAgdHJ5IHsNCg0KCSAgICAgICAgICAgICAgICAgIGxvY2FsZUxvY2F0b3IgPSAoTG9j
YWxlTG9jYXRvcikNCg0KCSAgICAgICAgICAgICAgICAgICAgICAgIGdldFdlYkFwcGxpY2F0aW9u
Q29udGV4dCgpLmdldEJlYW4oTE9DQUxFX0xPQ0FUT1IpOyANCg0KCSAgICAgICAgICAgICAgICAg
IGxvZ2dlci5jb25maWcoImxvY2FsZUxvY2F0b3IgZm91bmQgaW4gc2VydmxldCAnIiArIGdldFNl
cnZsZXROYW1lKCkgDQoNCgkgICAgICAgICAgICAgICAgICAgICAgICArICInIDogIiArIGxvY2Fs
ZUxvY2F0b3IuZ2V0Q2xhc3MoKS5nZXROYW1lKCkpOw0KDQoJICAgICAgICAgICAgfSBjYXRjaChF
eGNlcHRpb24gZSkgew0KDQoJICAgICAgICAgICAgICAgICAgbG9jYWxlTG9jYXRvciA9IG51bGw7
ICAgLy8gTm90IHJlcXVpcmVkIGFzIGl0IHNob3VsZCB5ZXQgYmVlbiBudWxsDQoNCgkgICAgICAg
ICAgICAgICAgICBsb2dnZXIuY29uZmlnKCJObyBsb2NhbGVMb2NhdG9yIGZvdW5kIGluIHNlcnZs
ZXQgJyIgKyBnZXRTZXJ2bGV0TmFtZSgpICsgIicsIHJlcXVlc3QgTG9jYWxlIHdpbGwgYmUgdXNl
ZC4iKTsNCg0KCSAgICAgICAgICAgIH0NCg0KCSAgICAgICAgICAgIC8vIEpzdGwgaGFuZGxpbmcN
Cg0KCSAgICAgICAgICAgIC8vIFB1dCBvbmx5IGluIGEgc3ViY2xhc3MgPyBCdXQgSnN0bCBpcyBh
Z2VuZXJpYyB1c2UNCg0KCSAgICAgICAgICAgIC8vIFRoZSBBcHBsaWNhdGlvbkNvbnRleHRBd2Fy
ZSBkb2Vzbid0IHByb3ZpZGUgYW4gYWNjZXNzIHRvIHRoZSBzZXJ2bGV0Q29udGV4dA0KDQoJICAg
ICAgICAgICAgLy8gSXQncyB0aGUgcmVhc29uIG9mIGFuIGluaXRpYWxpc2F0aW9uIGhlcmUuIEV4
aXN0cyBhIGJlc3QgYXBwcm9hY2ggPw0KDQoJICAgICAgICAgICAgdHJ5IHsNCg0KCSAgICAgICAg
ICAgICAgICAgIEpzdGxIYW5kbGVyIGpzdGxIYW5kbGVyID0gKEpzdGxIYW5kbGVyKSAgDQoNCgkg
ICAgICAgICAgICAgICAgICAgICAgICBnZXRXZWJBcHBsaWNhdGlvbkNvbnRleHQoKS5nZXRCZWFu
KEpTVExfSEFORExFUik7IA0KDQoJICAgICAgICAgICAgICAgICAganN0bEhhbmRsZXIuc2V0U2Vy
dmxldEN0eCh0aGlzLmdldFNlcnZsZXRDb250ZXh0KCkpOw0KDQoJICAgICAgICAgICAgICAgICAg
bG9nZ2VyLmNvbmZpZygianN0bEhhbmRsZXIgZm91bmQgaW4gc2VydmxldCAnIiArIGdldFNlcnZs
ZXROYW1lKCkgDQoNCgkgICAgICAgICAgICAgICAgICAgICAgICArICInIDogIiArIGpzdGxIYW5k
bGVyLmdldENsYXNzKCkuZ2V0TmFtZSgpKTsNCg0KCSAgICAgICAgICAgIH0gY2F0Y2goRXhjZXB0
aW9uIGUpIHsNCg0KCSAgICAgICAgICAgICAgICAgIGxvZ2dlci5jb25maWcoIk5vIGpzdGxIYW5k
bGVyIGZvdW5kIGluIHNlcnZsZXQgJyIgKyBnZXRTZXJ2bGV0TmFtZSgpKTsNCg0KCSAgICAgICAg
ICAgIH0NCg0KCSAgICAgICAgICAgIA0KDQoJICAgICAgICAgICAgLy8gRW5kIGFkZGVkDQoNCgkg
DQoNCgk0KSBBcyB5b3UgY2FuIHNlZSwgSSBoYW5kbGUgSSBhIHNhbWUgd2F5IHRoZSBkZWZpbml0
aW9uIG9mIGxvY2FsZSBhbmQgYnVuZGxlIGZvciBKU1RMLg0KDQoJNSkgVGhlIExvY2FsZUxvY2F0
b3IgY2FuIGJlIGRvbmF0ZWQgYnkgYmVhbnJlZiBwcm9wZXJ0eSB0byBvYmplY3RzIHdoaWNoIGhh
dmUgdG8ga25vdyB0aGUgY3VycmVudCBsb2NhbGUgaGF2aW5nIHRoZSByZXF1ZXN0IG9iamVjdC4N
Cg0KCSANCg0KCUkgaG9wZSB0aGlzIHdpbGwgYmUgYSB1c2VmdWwgYWRkLW9uIGluIHRoaXMgZGlz
Y3Vzc2lvbi4gSSBzdWdnZXN0IHRvIGludGVncmF0ZSBhIHN1Y2ggYmVoYXZpb3VyIGluIHRoZSBv
cmlnaW5hbCBDb250cm9sbGVyU2VydmxldCBhcyB0aGVzIG5lZWRzIGFyZSB2ZXJ5IGdlbmVyYWxs
eS4NCg0KCSANCg0KCVJlZ2FyZHMsDQoNCglKZWFuLVBpZXJyZQ0KDQoJIA0KDQoNCi0tLQ0KT3V0
Z29pbmcgbWFpbCBpcyBjZXJ0aWZpZWQgVmlydXMgRnJlZS4NCkNoZWNrZWQgYnkgQVZHIGFudGkt
dmlydXMgc3lzdGVtIChodHRwOi8vd3d3LmdyaXNvZnQuY29tKS4NClZlcnNpb246IDYuMC40NTYg
LyBWaXJ1cyBEYXRhYmFzZTogMjU2IC0gUmVsZWFzZSBEYXRlOiAyLzE4LzAzDQoNCg0K

[Springframework-developer] Struts (and Re: ErrorCoded/MessageSource)

[<jh...@we...>]

VG9ueSwgUm9kLCBldmVyeW9uZSwNCiANClN1cHBvcnQgZm9yIGVycm9yIGFyZ3VtZW50cyBpcyBp
bmRlZWQgYSB2YWx1YWJsZSBjb250cmlidXRpb24gdGhhdCBmaWxscyBhIGdhcC4gTGV0J3MgZ2V0
IGl0IGludG8gQ1ZTIQ0KIA0KQ29uY2VybmluZyBTdHJ1dHM6IERlc3BpdGUgYWxsIG9mIGl0cyBz
aG9ydGNvbWluZ3MsIFN0cnV0cyBkb2VzIGhhdmUgYSBsb3Qgb2YgZmVhdHVyZXMuIEkndmUgaGFk
IGEgZGV0YWlsZWQgbG9vayBhdCBTdHJ1dHMgMS4xYjMgcmVjZW50bHksIGVzcGVjaWFsbHkgYW5h
bHl6aW5nIFN0cnV0cycgd2F5IG9mIGRvaW5nIHRoaW5ncy4gVGhlcmUgYXJlIHNvbWUgdGhpbmdz
IHdvcnRoIGxvb2tpbmcgYXQ6IGRpc3BhdGNoIGFjdGlvbnMsIGR5bmFtaWMgZm9ybXMsIGVycm9y
IG1lc3NhZ2UgaGFuZGxpbmcsIHJlcXVlc3QgdG9rZW5zLCBkZWNsYXJhdGl2ZSB2YWxpZGF0aW9u
LCBtdWx0aXBhcnQgcmVxdWVzdCBwcm9jZXNzaW5nLCAibW9kdWxlcyIsIFRpbGVzIGludGVncmF0
aW9uLg0KIA0KT2YgY291cnNlLCBTdHJ1dHMnIEFQSSBhbmQgaW1wbGVtZW50YXRpb24gYXJlIGEg
bWF0dGVyIG9mIHRhc3RlIGF0IGJlc3QuIEl0cyBhcmNoaXRlY3R1cmUgaXMgZnVsbCBvZiBzaWdu
aWZpY2FudCBxdWlya3MuIFNvbWUgdGhpbmdzIGFyZSB1bmZsZXhpYmxlLCBsaWtlIHR5aW5nIGV2
ZXJ5dGhpbmcgdG8gQWN0aW9uU2VydmxldC9BY3Rpb25Gb3JtL0FjdGlvbiBhbmQgdHJlYXRpbmcg
ZXZlcnkgcmVxdWVzdCBhcyBhIGZvcm0uIFNvbWUgdGhpbmdzIGFyZSBvYnZpb3VzbHkgcmVzdWx0
cyBvZiBpbnRyb2R1Y2luZyBiYXNpYyBjaGFuZ2VzIHdpdGggMS4xLCBkZXByZWNhdGluZyBhIGxv
dCBvZiAxLjAgbWV0aG9kcywgbGVhdmluZyB0aGUgaW1wcmVzc2lvbiBvZiBzdWJvcHRpbWFsIHNv
bHV0aW9ucy4NCiANCkdlbmVyYWxseSwgdGhlcmUgYXJlIGhhcmRseSBhbnkgaW50ZXJmYWNlcyAt
IGFuZCB0aHVzIGhhcmRseSBhbnkgZGVsZWdhdGlvbiAtIHdpdGhpbiBTdHJ1dHM6IDE4IGluIHRv
dGFsLCA4IG9mIHRoZW0gaW4gdGhlIHRhZ2xpYiBpbXBsZW1lbnRhdGlvbiBhbmQgNSBpbiB0aGUg
dGlsZXMgcGx1Z2luOyBsZWF2aW5nIDUgaW50ZXJmYWNlcyBpbiB0aGUgZnJhbWV3b3JrIGl0c2Vs
ZiwgMiBvZiB0aGVtIGluIHRoZSB1cGxvYWQgcGFja2FnZSAoYXMgb2YgMS4xYjMpLiBJbnN0ZWFk
LCBTdHJ1dHMgcmVsaWVzIGhlYXZpbHkgb24gc3ViY2xhc3Npbmcgc3BlY2lmaWMgZnJhbWV3b3Jr
IGNsYXNzZXMsIGUuZy4gQWN0aW9uIGFuZCBBY3Rpb25Gb3JtLg0KIA0KSW4gY29tcGFyaXNvbiwg
U3ByaW5nIGhhcyBjdXJyZW50bHkgbW9yZSB0aGFuIDQwIGludGVyZmFjZXMgaW4gdGhlIGZyYW1l
d29yayBpdHNlbGYsIGFuZCBtb2RlbHMgYXMgbXVjaCBhcyBwb3NzaWJsZSB2aWEgZGVsZWdhdGlv
bi4gQ3VzdG9tIGFwcGxpY2F0aW9ucyBvbmx5IGhhdmUgdG8gaW1wbGVtZW50IFNwcmluZy1zcGVj
aWZpYyBpbnRlcmZhY2VzIG9yIGV4dGVuZCBTcHJpbmctc3BlY2lmaWMgY2xhc3NlcyB3aGVuIHJl
YWxseSBuZWNlc3NhcnkuIFRoZXJlJ3MgYSBjbGVhciBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zLCBh
bmQgcGFydGljdWxhcmx5IGltcG9ydGFudCwgYSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gZ2Vu
ZXJpYyBpbmZyYXN0cnVjdHVyZSBhbmQgd2ViIHN1cHBvcnQuIEluIGNvbnRyYXN0IHRvIFN0cnV0
cywgU3ByaW5nIGlzIGEgZ2VuZXJpYyBhcHBsaWNhdGlvbiBmcmFtZXdvcmssIHdlbGwgc3VpdGVk
IGZvciBjcmVhdGluZyByZXVzYWJsZSBidXNpbmVzcyBsb2dpYyBmb3IgYWxsIGtpbmRzIG9mIGFw
cGxpY2F0aW9ucywgd2l0aCBhIHNwZWNpYWwgd2ViIGFwcGxpY2F0aW9uIGZyYW1ld29yayBvbiB0
b3Agb2YgaXQuDQogDQpCdXQgaWYgd2UgZmluZCBzb21lIG5pY2UgU3RydXRzIGZlYXR1cmVzIHRo
YXQgd2UgY2FuIGltcGxlbWVudCB3aXRoaW4gU3ByaW5nIGluIGEgY2xlYW4gd2F5LCB0aGVuIHdl
IHNob3VsZG4ndCBoZXNpdGF0ZSB0byBkbyBzbyENCiANClJlZ2FyZHMsDQpKdWVyZ2VuDQogDQog
DQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9kIEpvaG5z
b24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBGciAy
MS4wMi4yMDAzIDE2OjQ4IA0KCUFuOiBUb255IEZhbGFiZWxsYTsgc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFJlOiBbU3By
aW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gbW9kaWZpY2F0aW9uIHJlcXVlc3QgZm9yIGludGVyZmFj
ZSBFcnJvckNvZGVkIEFORCBNZXNzYWdlU291cmNlDQoJDQoJDQoNCglUb255LA0KCQ0KCUkgdGhp
bmsgdGhpcyBpcyBhIHZhbHVhYmxlIGNvbnRyaWJ1dGlvbi4gSW5kZWVkLCBpdCBpcyBhIGdhcCBp
biB0aGUgcHJlc2VudA0KCWluY2FybmF0aW9uIG9mIFNwcmluZy4gQW5kIGl0IGlzIGEgMS4wIHRo
aW5nICh0byBnbyB3aXRoIHRoZSBmb3J0aGNvbWluZw0KCWludGVybmF0aW9uYWxpemF0aW9uIHN1
cHBvcnQgaW4gdGhlIHdlYiBzdHVmZikuDQoJDQoJSSBoYXZlIHNvbWUgY29tbWVudHMgdGhhdCBJ
J2xsIGFkZCB0byB5b3VyIGRvY3VtZW50IGFuZCBmZWVkIGJhY2sgdG8geW91DQoJKGp1c3QgYSBx
dWVzdGlvbiBvZiB3aGVuOiBwcm9iYWJseSBTdW5kYXkpLg0KCQ0KCUknbSBwbGFubmluZyB0byBn
aXZlIHlvdSBkZXZlbG9wZXIgcmlnaHRzIGFuZCBzYXkgbWFrZSB0aGUgY2hhbmdlcywgd2l0aA0K
CXNvbWUgbWlub3IgdHdlYWtzLg0KCQ0KCVRlYW0sIGFueSBvYmplY3Rpb25zIHRvIG1vdmluZyBh
aGVhZCB3aXRoIHRoaXM/DQoJDQoJVGhhbmtzIGZvciB0aGUgbmV3IHRlc3RzLCBieSB0aGUgd2F5
LiBBcyB5b3Uga25vdyBJJ20ga2VlbiBvbiB0ZXN0aW5nIGFuZA0KCUknbSBkZWxpZ2h0ZWQgdG8g
c2VlIGNvbnRyaWJ1dGlvbnMgdGhhdCBpbXByb3ZlIG92ZXJhbGwgdGVzdCBjb3ZlcmFnZSENCgkN
CglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9t
OiAiVG9ueSBGYWxhYmVsbGEiIDx0b255X2ZhbGFiZWxsYUB5YWhvby5jb20+DQoJVG86IDxzcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NCglTZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMjAsIDIwMDMgNToyOSBBTQ0KCVN1YmplY3Q6IFtTcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyXSBtb2RpZmljYXRpb24gcmVxdWVzdCBmb3IgaW50ZXJmYWNlDQoJRXJyb3JD
b2RlZCBBTkQgTWVzc2FnZVNvdXJjZQ0KCQ0KCQ0KCT4NCgk+IFJvZCwNCgk+DQoJPiAocG9zdGlu
ZyB0aGlzIGFnYWluIHNpbmNlIGdvdCBhbiAidG9vIGxhcmdlIiBtZXNzYWdlIGZyb20gbGlzdCBz
ZXJ2ZXINCglmaXJzdCB0aW1lKSwNCgk+DQoJPiBBcyBpdCBjdXJyZW50bHkgc3RhbmRzIHlvdXIg
aW50ZXJmYWNlIGNvbS5pbnRlcmZhY2UyMS5jb3JlLkVycm9yQ29kZWQgb25seQ0KCWhhcyB0aGUg
Zm9sbG93aW5nIG1ldGhvZDoNCgk+ICAgIFN0cmluZyBnZXRFcnJvckNvZGUoKQ0KCT4NCgk+IEkg
c2VlIGdyZWF0IHZhbHVlIGluIGhhdmluZyBhbiBpbnRlcmZhY2UgdGhhdCB3aWxsIGFsbG93IG1l
c3NhZ2VzIHRoYXQgeW91DQoJd2lzaCB0byBkaXNwbGF5IHRvIHVzZXJzIHRvIHJldHVybiBhbiBl
cnJvckNvZGUuICBUaGUgbWFpbiBwcmVtaXNlcyBJIHNlZQ0KCWJlaGluZCB0aGlzIGFyZToNCgk+
IDEpIEFuIGVycm9yQ29kZSBjYW4gYmUgdXNlZCB0byBsb29rIHVwIGFuIGFjdHVhbCBlcnJvciBp
biBhIG1lc3NhZ2UNCgljYXRhbG9nLiAgVGhpcyB3aWxsIGFsbG93IHN1cHBvcnRpbmcgaW50ZXJu
YXRpb25hbGl6YXRpb24gYW5kIGNhbiBhbGxvdw0KCWtlZXBpbmcgYW4gZXJyb3IgbWVzc2FnZSdz
IHRleHQgaW4gYSBzaW5nbGUgY29tbW9uIGFyZWEuDQoJPiAyKSBIYXZpbmcgYW4gZXhjZXB0aW9u
IHRoYXQgaXMgYWJsZSB0byByZXR1cm4gYW4gZXJyb3JDb2RlIGNhbiBhbGxvdyBmb3INCglHVUkg
ZmllbGQvZXJyb3JDb2RlIG1hcHBpbmcgdGFibGVzIHRvIGJlIGNvbXB1dGVkLiAgVGhpcyBpcyBo
ZWxwZnVsIGZvciBmYXQNCgljbGllbnRzIHRoYXQgd2lzaCB0byBjaGFuZ2UgY2VydGFpbiBmaWVs
ZHMgYSBkaWZmZXJlbnQgY29sb3Igd2hlbiB2YXJpb3VzDQoJZXJyb3JzIG9jY3VyLCBpbmRpY2F0
aW5nIHdoYXQgZmllbGRzIG1heSBoYXZlIGludmFsaWQgZGF0YS4NCgk+DQoJPiBBcyB0aGUgY29k
ZSBjdXJyZW50bHkgc3RhbmRzIGhvd2V2ZXIsIEkgZG8gc2VlIGEgZmFpcmx5IGJpZyBsaW1pdGF0
aW9uLg0KCVRoYXQgYmVpbmcgdGhhdCBxdWl0ZSBvZnRlbiBhbiBlcnJvciBtZXNzYWdlIG11c3Qg
aGF2ZSBhcmd1bWVudHMgc3VwcGxpZWQgdG8NCglpdCB0byBtYWtlIGEgbW9yZSBtZWFuaW5nZnVs
IGVycm9yIG1lc3NhZ2UuICBGb3IgZXhhbXBsZSwgdGhlIFN0cnV0cw0KCW9yZy5hcGFjaGUuc3Ry
dXRzLnV0aWwuTWVzc2FnZVJlc291cmNlcyBjbGFzcyBjb250YWlucyB0aGUgZm9sbG93aW5nIG1l
dGhvZHMNCgkoSSB3aWxsIGxpbWl0IHRoZSBjb252ZW5pZW5jZSBmb3JtcyBvZiB0aGlzIG1ldGhv
ZCB0byBvbmx5IHNob3cgb25lIG9mDQoJdGhlbSk6DQoJPiAgICBwdWJsaWMgU3RyaW5nIGdldE1l
c3NhZ2UoTG9jYWxlIGxvY2FsZSwgU3RyaW5nIGtleSwgT2JqZWN0IGFyZ3NbXSkNCgk+ICAgIHB1
YmxpYyBTdHJpbmcgZ2V0TWVzc2FnZShMb2NhbGUgbG9jYWxlLCBTdHJpbmcga2V5LCBPYmplY3Qg
YXJnMCkNCgk+DQoJPiBXaGlsZSB0aGUgY29udmVuaWVuY2UgbWV0aG9kcyBTdHJ1dHMgaGFzIGFy
ZSBoZWxwZnVsLCBzaW5jZSBFcnJvckNvZGVkIGlzDQoJYW4gaW50ZXJmYWNlIHlvdSBkbyBub3Qg
aGF2ZSB0aGUgbHV4dXJ5IG9mIGhpZGluZyB0aGUgdmFyaW91cyBvdmVybG9hZHMgaW4NCglhbiBh
YnN0cmFjdCBzdXBlcmNsYXNzLg0KCT4NCgk+IFNvIG15IHByb3Bvc2FsIGlzIHRoYXQgeW91IGFk
ZCB0aGUgZm9sbG93aW5nIHRvIHRoZQ0KCWNvbS5pbnRlcmZhY2UyMS5jb3JlLkVycm9yQ29kZWQg
aW50ZXJmYWNlOg0KCT4gICAgT2JqZWN0W10gZ2V0RXJyb3JBcmdzKCkNCgk+IEFsc28gY2hhbmdl
IHRoZSBjb20uaW50ZXJmYWNlMjEuY29udGV4dC5NZXNzYWdlU291cmNlIGludGVyZmFjZSBtZXRo
b2QNCglzaWduYXR1cmVzIGxpa2Ugc286DQoJPiAgICBTdHJpbmcgZ2V0TWVzc2FnZShTdHJpbmcg
Y29kZSwgTG9jYWxlIGxvY2FsZSwgT2JqZWN0IGFyZ3NbXSkgdGhyb3dzDQoJTm9TdWNoTWVzc2Fn
ZUV4Y2VwdGlvbg0KCT4gICAgU3RyaW5nIGdldE1lc3NhZ2UoU3RyaW5nIGNvZGUsIExvY2FsZSBs
b2NhbGUsIE9iamVjdCBhcmdzW10sIFN0cmluZw0KCWRlZmF1bHRNZXNzYWdlKQ0KCT4NCgk+IEkn
dmUgYWxyZWFkeSBtYWRlIHRoaXMgY2hhbmdlIHRvIG15IHZlcnNpb24gb2YgdGhlIGZyYW1ld29y
ayBhbmQgd3JpdHRlbiBhDQoJZmV3IG5ldyBUZXN0U3VpdGUgY2xhc3NlcyB0byB0ZXN0IGl0LiAg
SSd2ZSBnb3QgYSB6aXBwZWQgZmlsZSBjb250YWluaW5nIGFsbA0KCXRoZSBuZWNlc3NhcnkgY29k
ZSB0byBpbmNvcnBvcmF0ZSBmb3IgdGhpcyBjaGFuZ2UgdGhhdCBJIGNhbiBtYWlsIHRvIHlvdS4N
Cgk+DQoJPiBXaGF0IGRvZXMgdGhlIGdyb3VwIHRoaW5rIGFib3V0IG1lc3NhZ2VzIGJlaW5nIGFi
bGUgdG8gdGFrZSBhcmd1bWVudHMgaW4NCgliZWZvcmUgdGhleSBhcmUgZGlzcGxheWVkPw0KCT4N
Cgk+DQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU2xp
Y2tFZGl0IEluYy4gRGV2ZWxvcCBhbiBlZGdlLg0KCVRoZSBtb3N0IGNvbXByZWhlbnNpdmUgYW5k
IGZsZXhpYmxlIGNvZGUgZWRpdG9yIHlvdSBjYW4gdXNlLg0KCUNvZGUgZmFzdGVyLiBDL0MrKywg
QyMsIEphdmEsIEhUTUwsIFhNTCwgbWFueSBtb3JlLiBGUkVFIDMwLURheSBUcmlhbC4NCgl3d3cu
c2xpY2tlZGl0LmNvbS9zb3VyY2Vmb3JnZQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxp
c3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0
dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXINCgkNCg0K

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

Naming - I agree that LocaleHandler is confusing. I like LocaleResolver,
since it is consistent with the the ViewResolver classes. 

Interface - really good, but I don't think it's necessary to have locale as
a parameter of setLocale, since that method will be determining the actual
locale. What value be passed by the ControllerServlet for this parameter?
Maybe it would be less confusing to make the signature:
	Locale resolveLocale(HttpServletRequest request, HttpServletResponse
response);
The signature now makes it clear that we are not "setting it" so much as
asking the method to determine how it should be set.  It also matches the
viewResolver usage. An additional "setLocale" method with the signature you
provided:
	void setLocale(HttpServletRequest request, HttpServletResponse
response, Locale locale);
could be used to explicitly override the Locale determined by the
resolveLocale method.  This would benefit Controller specific overrides
(addressed below).  As you noted, the response is necessary for cookie-based
implementations (good catch).

Configuration - I think that loading it as a bean reference (like
"viewResolver") makes the most sense.  If we provide an access method, this
would allow individual Controllers to get a reference to the resolver and
override the locale using the setLocale method mentioned above.  I think the
ControllerServlet should handle the locale resolution rather than a
"LocaleHandler-per-Controller".  If someone needs "normal" locale handling,
I think the per-Controller method would require too much cut-n-paste type
code.  However, the exposed setLocale method would allow those who need to
set it on a per-Controller basis the ability to do so.

DefaultImplementation - I think "ClientLocaleHandler" is too general, since
all LocaleHandlers (or LocaleResolvers as I prefer :) ) are making decisions
based on the client.  The default will be using the servlets default
mechanism, so maybe "ServletLocaleResolver" or "RequestLocaleResolver"
(although again, too me they're too general - I can't think of a really good
name).  We should also create additional implementations for distribution
such as the cookie and session based versions, rather than requiring each
client to code one themselves (although they will have the oppurtunity to do
so).

Great analysis Juergen!


Trevor D. Cook

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

SGkgZXZlcnlib2R5LA0KIA0KSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoZSBpc3N1ZSBmb3Ig
cXVpdGUgYSB3aGlsZSwgYW5kIGFjdHVhbGx5IEkgbGlrZSB0aGUgaWRlYSBvZiBhbiBpbnRlcmZh
Y2UtYmFzZWQgc29sdXRpb24gdG9vLiBBbGxvd2luZyBmb3IgdXNlci1jaG9zZW4gbG9jYWxlcyB3
aXRob3V0IHJlcXVpcmluZyBhIHNlc3Npb24gZGVtYW5kcyBmb3IgYSBtb3JlIHNvcGhpc3RpY2F0
ZWQgc29sdXRpb24uIEkgd29uZGVyIGFib3V0IHRoZSBuYW1lOiBMb2NhbGVMb2NhdG9yPyBMb2Nh
bGVQcm92aWRlcj8gTG9jYWxlUmVzb2x2ZXI/IExvY2FsZU1hbmFnZXI/IExvY2FsZUhhbmRsZXI/
IE9ubHkgdGhlIGxhdHRlciAyIGltcGx5IHJldHJpZXZhbCBhbmQgbWFuaXB1bGF0aW9uLiBQZXJz
b25hbGx5LCBJIHByZWZlciBMb2NhbGVIYW5kbGVyIC0gdGhlIGRyYXdiYWNrIGJlaW5nIHRoYXQg
Y29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0IGFscmVhZHkgY29udGFpbnMgSGFuZGxlckFkYXB0
ZXIgYW5kIEhhbmRsZXJNYXBwaW5nLCB3aGljaCBjYW4gbGVhZCB0byBtaW5vciBjb25mdXNpb24u
DQogDQpTbyB0aGUgaW50ZXJmYWNlIG1pZ2h0IGxvb2sgbGlrZSB0aGlzIChsZXQncyBvbWl0IHRo
ZSB3b3JkICJzZXNzaW9uIiwgYXMgaXQgd291bGQgaW1wbHkgYSBIdHRwU2Vzc2lvbiBiZWluZyBp
bnZvbHZlZCkgOg0KIA0KICBwdWJsaWMgaW50ZXJmYWNlIExvY2FsZUhhbmRsZXIgew0KICAgIExv
Y2FsZSBnZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QpOw0KICAgIHZvaWQgc2V0
TG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJl
c3BvbnNlLCBMb2NhbGUgbG9jYWxlKTsNCiAgfQ0KIA0KTm90ZTogSSBjb25zaWRlciBzZXRMb2Nh
bGUncyByZXNwb25zZSBwYXJhbWV0ZXIgbmVjZXNzYXJ5IHRvIGVuYWJsZSBjb29raWUtYmFzZWQg
aW1wbGVtZW50YXRpb25zIHRoYXQgbmVlZCB0byBjYWxsIGFkZENvb2tpZS4NCiANCkNvbmNlcm5p
bmcgdXNhZ2Ugb2YgdGhpcyBpbnRlcmZhY2UsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBjb25jcmV0
ZSByZXF1aXJlbWVudHM6DQotIExvY2FsZUhhbmRlciBpbnN0YW5jZXMgc2hvdWxkIGJlIGNvbmZp
Z3VyYWJsZSB2aWEgdGhlIEJlYW5GYWN0b3J5Ow0KLSBhIENvbnRyb2xsZXJTZXJ2bGV0IG5lZWRz
IGEgTG9jYWxlSGFuZGxlciBmb3IgY2hvb3NpbmcgYSB2aWV3Ow0KLSBhIENvbnRyb2xsZXIgaW5z
dGFuY2UgbWF5IG5lZWQgYSBMb2NhbGVIYW5kbGVyIGZvciBsb2NhbGUtZGVwZW5kZW50IGFjdGlv
bnMgYW5kL29yIHNldHRpbmcgYSB1c2VyIGxvY2FsZS4NCiANClRoZSBxdWVzdGlvbiBpczogSG93
IHRvIGNvbmZpZ3VyZSBMb2NhbGVIYW5kbGVycz8gU29tZSBpc3N1ZXM6DQotIEEgQ29udHJvbGxl
clNlcnZsZXQgY2Fubm90IGdldCBhIExvY2FsZUhhbmRsZXIgYXMgYSBzcGVjaWZpZWQgYmVhbiBy
ZWZlcmVuY2UsIHNvIGl0IHdvdWxkIGhhdmUgdG8gbG9vayBpdCB1cCBpbiBpdHMgYmVhbiBkZWZp
bml0aW9ucyB1c2luZyBhIHN0YW5kYXJkIG5hbWUgKHNpbWlsYXIgdG8gInZpZXdSZXNvbHZlciIg
YW5kICJtZXNzYWdlU291cmNlIikuDQotIEEgQ29udHJvbGxlciBjb3VsZCBnZXQgYSBMb2NhbGVI
YW5kbGVyIGFzIGEgYmVhbiByZWZlcmVuY2UsIHNwZWNpZmllZCBhcyB1c3VhbCBpbiB0aGUgYmVh
biBkZWZpbml0aW9ucyBvZiB0aGUgYXNzb2NpYXRlZCBDb250cm9sbGVyU2VydmxldC4gQSBjb3Jy
ZXNwb25kaW5nIHByb3BlcnR5IHdpdGggYWNjZXNzIG1ldGhvZHMgY291bGQgYmUgcHJvdmlkZWQg
YnkgQWJzdHJhY3RDb250cm9sbGVyLg0KLSBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCB0cnkgdG8g
c2V0IHRoZSBDb250cm9sbGVyU2VydmxldCdzIExvY2FsZUhhbmRsZXIgb24gQ29udHJvbGxlciBp
bnN0YW5jZXMgdGhhdCBpbXBsZW1lbnQgYSBMb2NhbGVIYW5kbGVyQXdhcmUgaW50ZXJmYWNlLiBU
aGlzIHdvdWxkIGludm9sdmUgbWFraW5nIEhhbmRsZXJNYXBwaW5nIGltcGxlbWVudCBMb2NhbGVI
YW5kbGVyQXdhcmUgdG9vLCBhbmQgcHVzaGluZyB0aGUgTG9jYWxlSGFuZGxlciBmcm9tIENvbnRy
b2xsZXJTZXJ2bGV0IHZpYSBIYW5kbGVyTWFwcGluZyB0byBDb250cm9sbGVyIGluc3RhbmNlcyAo
dGh1cyBlZmZlY3RpdmVseSBvdmVyd3JpdGluZyByZXNwZWN0aXZlIGJlYW4gZmFjdG9yeSBzZXR0
aW5ncyBvZiB0aGUgQ29udHJvbGxlciBpbnN0YW5jZXMpLg0KLSBTbyB3ZSB3aWxsIGhhdmUgdG8g
ZGVjaWRlIGJldHdlZW4gYSBMb2NhbGVIYW5kbGVyLXBlci1Db250cm9sbGVyIGFwcHJvYWNoIGFu
ZCBhIExvY2FsZUhhbmRsZXItcGVyLUNvbnRyb2xsZXJTZXJ2bGV0IGFwcHJvYWNoLiBJIGd1ZXNz
IHRoYXQgaW4gYWxtb3N0IGFsbCBhcHBsaWNhdGlvbnMgdGhlIGxhdHRlciB3b3VsZCBiZSBlbm91
Z2guIE9mIGNvdXJzZSwgd2UgY291bGQgYWxzbyBzdXBwb3J0IGJvdGggd2F5cyBieSBtYWtpbmcg
dGhlIENvbnRyb2xsZXJTZXJ2bGV0J3MgcHVzaC10aHJvdWdoIGJlaGF2aW9yIGNvbmZpZ3VyYWJs
ZSwgYnV0IHRoYXQgd291bGQgcHJvYmFibHkgYmUgcmF0aGVyIGNvbmZ1c2luZyBhbmQgbm90IGFk
ZCBwcmFjdGljYWwgYmVuZWZpdHMuDQotIFRoZSBkZWZhdWx0IExvY2FsZUhhbmRsZXIgaW1wbGVt
ZW50YXRpb24gc2hvdWxkIGJlIENsaWVudExvY2FsZUhhbmRsZXIgKG9yIGEgY2xhc3Mgd2l0aCBh
IHNpbWlsYXIgbmFtZSksIHVzaW5nIHRoZSBjbGllbnQgcmVzcC4gYnJvd3NlciBzZXR0aW5nIHRo
YXQgSHR0cFNlcnZsZXRSZXF1ZXN0IHByb3ZpZGVzIChpbnN0ZWFkIG9mIG51bGwgYXMgZGVmYXVs
dCBMb2NhbGUgdmFsdWUpLg0KLSBBbiBhcHBsaWNhdGlvbiBwcm9ncmFtbWVyIHNob3VsZCBub3Qg
bmVlZCB0byBjYXJlIGFib3V0IExvY2FsZXMgYW5kIExvY2FsZUhhbmRsZXJzIGluIHNpbmdsZSBs
YW5ndWFnZSBhcHBsaWNhdGlvbnMuDQogDQpXaGF0IGRvIHlvdSBjb25zaWRlciBtb3N0IHZpYWJs
ZT8NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t
LS0gDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNv
bV0gDQoJR2VzZW5kZXQ6IEZyIDIxLjAyLjIwMDMgMTI6NDggDQoJQW46IHNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBGdzog
W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCg0KCVJl
cGx5LXRvIGFnYWluIQ0KCQ0KCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAi
Um9kIEpvaG5zb24iIDxyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb20+DQoJVG86ICJKUCBQQVdM
QUsoVGlzY2FsaSkiIDxqcC5wYXdsYWtAdGlzY2FsaS5mcj4NCglTZW50OiBGcmlkYXksIEZlYnJ1
YXJ5IDIxLCAyMDAzIDc6NTggQU0NCglTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCgk+IEplYW4tUGllcnJlJ3MgaW50ZXJmYWNl
LWJhc2VkIHNvbHV0aW9uICh3aGljaCBJIGhhZG4ndCBzZWVuIGJlY2F1c2UgdGhlDQoJPiBhdHRh
Y2htZW50IHdhcyB0b28gYmlnIGFuZCBJIGhhZCB0byBhcHByb3ZlIGl0IGZvciBpdCB0byBhcHBl
YXIpIGlzIGFsb25nDQoJPiB0aGUgbGluZXMgSSdkIGVudmlzYWdlZC4gQ29uc2lzdGVudCB3aXRo
IHRoZSBTcHJpbmcgd2F5LCBhcyBoZSBwb2ludHMgb3V0Lg0KCT4NCgk+IE9uZSBvZiB0aGUgaW1w
bGVtZW50YXRpb25zIG9mIHRoZSBpbnRlcmZhY2UgY291bGQgc2ltcGx5IHVzZSBhIHNlc3Npb24g
YXR0DQoJPiBhcyBKdWVyZ2VuIHN1Z2dlc3RzLg0KCT4NCgk+IEkgdGhpbmsgaXQgc2hvdWxkIGdv
IGludG8gdGhlIGNvbnRyb2xsZXIgc2VydmxldC4NCgk+DQoJPiBXaGVyZSBkbyB3ZSBjYWNoZSBs
b2NhbGUgaW5mb3JtYXRpb24/IEknbSBub3Qga2VlbiBvbiBjcmVhdGluZyBhIHNlc3Npb24NCglp
Zg0KCT4gb25lIGRvZXNuJ3QgZXhpc3QsIGFzIEkgdGhpbmsgU3RydXRzIGRvZXMsIGJlY2F1c2Ug
dGhpcyBjYW4gZ2V0IHVzIGludG8NCgk+IHJlcGxpY2F0aW9uIGlzc3VlcyBpbiBvdGhlcndpc2Ug
c3RhdGVsZXNzIHdlYiBhcHBzLg0KCT4NCgk+IFRoZSBMb2NhbGVMb2NhdG9yIGlzIGFsc28gcmVh
bGx5IGEgbWFuYWdlci4gTWF5YmUgb25lIGltcGxlbWVudGF0aW9uIGNvdWxkDQoJPiB1c2Ugc2Vz
c2lvbnMsIGFub3RoZXIgY291bGQgdXNlIGNvb2tpZXMgZXRjLiBBcyBKZWFuLVBpZXJyZSBoYXMg
ZG9uZSwgdGhlDQoJPiBiZWFuIGZhY3RvcnkgaXMgYSBwZXJmZWN0IHdheSB0byBjaG9vc2UuDQoJ
Pg0KCT4gUm9kDQoJDQoNCg==

Fw: [Springframework-developer] Explicit locales

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

Reply-to again!

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "JP PAWLAK(Tiscali)" <jp....@ti...>
Sent: Friday, February 21, 2003 7:58 AM
Subject: Re: [Springframework-developer] Explicit locales


> Jean-Pierre's interface-based solution (which I hadn't seen because the
> attachment was too big and I had to approve it for it to appear) is along
> the lines I'd envisaged. Consistent with the Spring way, as he points out.
>
> One of the implementations of the interface could simply use a session att
> as Juergen suggests.
>
> I think it should go into the controller servlet.
>
> Where do we cache locale information? I'm not keen on creating a session
if
> one doesn't exist, as I think Struts does, because this can get us into
> replication issues in otherwise stateless web apps.
>
> The LocaleLocator is also really a manager. Maybe one implementation could
> use sessions, another could use cookies etc. As Jean-Pierre has done, the
> bean factory is a perfect way to choose.
>
> Rod
>
> ----- Original Message -----
> From: "JP PAWLAK(Tiscali)" <jp....@ti...>
> To: "Spring Developers (E-mail)"
> <spr...@li...>
> Sent: Friday, February 21, 2003 7:03 AM
> Subject: TR : [Springframework-developer] Explicit locales
>
>
> Envoyé : jeudi 20 février 2003 22:50
> À : 'Trevor Cook'
> Objet : RE : [Springframework-developer] Explicit locales
>
>
>
> I use a solution near of yours but with a more generalist approach. To
> keep the users locale, different possibilities exist: session, cookie,
> URL. But each solution can be handled knowing the request object. So I
> use a bean for implementing the effective strategy in the way of the
> general spirit of Spring.
>
>  1) Create a simple interface like this:
>
> public interface LocaleLocator {
>
>       Locale getSessionLocale(HttpServletRequest request);
>
>       void setSessionLocale(HttpServletRequest request, Locale
> sessionLocale);
>
> }
>
> 2) Create an implementation class which in your case handles with the
> cookies, but which can use the session or what method you like.
>
> 3) Overriding the ControllerServlet to use a LocaleLocator property with
> at least the setter, so the implementation class can be done in the
> servlet-configuration file.
>
>       <bean name="localeLocator" singleton="true"
> class="perso.jpp.fwk.web.LocaleLocatorImpl" />
>
>       <bean name="jstlHandler" singleton="true"
> class="perso.jpp.fwk.web.JstlHandlerImpl" >
>
>             <property name="bundleName">achappro</property>
>
>       </bean>
>
>
>
> code added in declaration part:
>
>       // Added by JPP
>
>       /** The bean name allowing the user session locale to be retrieved
> */
>
>       public static final String LOCALE_LOCATOR = "localeLocator";
>
>
>
>       /** The bean name allowing the jstl ressouece bundle to be set */
>
>       public static final String JSTL_HANDLER = "jstlHandler";
>
>
>
>       /** LocaleLocator used by this servlet
>
>        * If not provided, request.getLocale() will be used instead */
>
>       private LocaleLocator localeLocator;
>
>       // End added
>
>
>
>
>
> code added in ControllerServlet (or descendent) at end of
> initFrameworkServlet :
>
>             initViewResolver();
>
>
>
>             // Added by JPP
>
>             try {
>
>                   localeLocator = (LocaleLocator)
>
>
> getWebApplicationContext().getBean(LOCALE_LOCATOR);
>
>                   logger.config("localeLocator found in servlet '" +
> getServletName()
>
>                         + "' : " + localeLocator.getClass().getName());
>
>             } catch(Exception e) {
>
>                   localeLocator = null;   // Not required as it should
> yet been null
>
>                   logger.config("No localeLocator found in servlet '" +
> getServletName() + "', request Locale will be used.");
>
>             }
>
>             // Jstl handling
>
>             // Put only in a subclass ? But Jstl is ageneric use
>
>             // The ApplicationContextAware doesn't provide an access to
> the servletContext
>
>             // It's the reason of an initialisation here. Exists a best
> approach ?
>
>             try {
>
>                   JstlHandler jstlHandler = (JstlHandler)
>
>
> getWebApplicationContext().getBean(JSTL_HANDLER);
>
>                   jstlHandler.setServletCtx(this.getServletContext());
>
>                   logger.config("jstlHandler found in servlet '" +
> getServletName()
>
>                         + "' : " + jstlHandler.getClass().getName());
>
>             } catch(Exception e) {
>
>                   logger.config("No jstlHandler found in servlet '" +
> getServletName());
>
>             }
>
>
>
>             // End added
>
>
>
> 4) As you can see, I handle I a same way the definition of locale and
> bundle for JSTL.
>
> 5) The LocaleLocator can be donated by beanref property to objects which
> have to know the current locale having the request object.
>
>
>
> I hope this will be a useful add-on in this discussion. I suggest to
> integrate a such behaviour in the original ControllerServlet as thes
> needs are very generally.
>
>
>
> Regards,
>
> Jean-Pierre
>
>
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Trevor Cook
> Envoyé : jeudi 20 février 2003 21:38
> À : Spring Developers (E-mail)
> Objet : RE: [Springframework-developer] Explicit locales
>
>
>
> It sounds like you're on the right track, and your approach should work
> for my stuff.  I've already implemented some of this (code below) by
> overriding ControllerServlet and checking for a cookie in doService
> before passing control up.  I store the locale in a persistent cookie so
> that no session is created for simple site browsing, and to remember
> chosen language for future visits.  I'm sure my approach could be
> improved alot, but it's just a prototype (so I could get my html guy to
> start working).
>
> When you're implementing it, a few suggestions/ideas/requests.  If this
> is put into the framework, you probably want to allow the developer to
> specify whether to make it cookie or session-based.  If it is
> cookie-based, you'll probably also need to allow the developer to
> specify browser or persistent (including max age).
>
> Trevor D. Cook
>
>
>
> public class LocaleServletController extends ControllerServlet {
>
> public static final String LOCALE_HANDLE = "locale";
>
> protected void doService(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> boolean debugMode)
>
> throws ServletException, IOException {
>
> String locale = request.getParameter(LOCALE_HANDLE);
>
> if (locale != null) {
>
> logger.info("Setting locale to: " + locale);
>
> setLocaleCookie(request, response, locale);
>
> } else {
>
> getLocale(request);
>
> }
>
> super.doService(request, response, debugMode);
>
> }
>
> private void getLocale(HttpServletRequest request) {
>
> Cookie[] cookies = request.getCookies();
>
> int cookiesSize = cookies.length;
>
> for (int i = 0; i < cookiesSize; i++) {
>
> if (LOCALE_HANDLE.equals(cookies[i].getName())) {
>
> String localeCookie = cookies[i].getValue();
>
> setLocale(request, localeCookie);
>
> }
>
> }
>
> }
>
> private void setLocaleCookie(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> String localeString) {
>
> Locale locale = setLocale(request, localeString);
>
> Cookie localeCookie = new Cookie(LOCALE_HANDLE, localeString);
>
> if (locale.equals(request.getLocale())) {
>
> localeCookie.setMaxAge(-1);
>
> } else {
>
> localeCookie.setMaxAge(365 * 24 * 60 * 60);
>
> }
>
> response.addCookie(localeCookie);
>
> }
>
> private Locale setLocale(
>
> HttpServletRequest request,
>
> String localeString) {
>
> Locale locale =
>
> new Locale(localeString.substring(0, 2), localeString.substring(2));
>
> request.setAttribute("locale", locale);
>
> return locale;
>
> }
>
> }
>
>
>
>
>
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: February 20, 2003 3:21 PM
> To: Spring Developers (E-mail)
> Subject: Re: [Springframework-developer] Explicit locales
>
> Trevor,
>
>
>
> I've noticed that issue too. We definitely need support for a manually
> set locale in the session, already for 1.0. I consider 1. the only
> viable option but I think of a very easy and generic way: Why not just
> define a Spring standard name for a session attribute that can contain a
> Locale instance? The ControllerServlet could first check the session for
> such an attribute and fall back to the request locale.
>
>
>
> A custom application will probably not support changing the locale with
> every possible action but rather with a special one controller URL. That
> controller implementation could put a respective attribute into the
> session, with the given standard name, and update user preferences in
> the database or set a respective cookie if desired. Of course, the
> user's locale has to be retrieved for a new session - that could happen
> after login in a login controller, or in a custom filter that checks for
> a certain cookie.
>
>
>
> So the minimal framework support needed seems to be the definition of a
> standard name for a session locale, and checking the session when
> determining a view in the ControllerServlet. Of course, custom
> applications can not only set that locale but also retrieve it in
> controllers that perform locale-specific actions.
>
>
>
> I'm currently in the process of polishing Spring's web part (probably
> taking over responsibility for it, at least for 1.0), so I could add
> such locale support easily. Would the outlined approach be sufficient
> for you? If yes, I will add that support prompty, probably commiting the
> changes at the beginning of next week.
>
>
>
> Regards,
>
> Juergen
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Trevor Cook [mailto:tc...@in...]
> Gesendet: Donnerstag, 20. Februar 2003 03:55
> An: Spring Developers (E-mail)
> Betreff: [Springframework-developer] Explicit locales
>
> I have a business requirement of handling multiple locales.
> Specifically, I live in Canada, and the application must be available in
> French and English.  However, due to multiple users on a single
> computer, we cannot rely solely on the users locale settings.  What we
> need to do is default to the users locale, but provide them with the
> ability to override these settings (probably by clicking an
> "English/French" link).
>
> Anyway, the framework question I have is "is there anyway to do this
> currently"?  Looking at the controller servlet, it returns a view based
> on "request.getLocale()".  This can't be changed, so I can't see any way
> to customize/change it.  My ideas are:
>
> 1. Have an explicit object in the request attribute for the locale with
> a "hook" to define how the default is determined (request locale,
> cookie, session, etc.).  The view (or any other locale "lookup") would
> be based on this attribute.
>
> 2. Wrap the request/response objects in the control servlet, and provide
> hooks for these wrappers (which could override the getLocale() method).
>
> 3. Have the view return a generic view, and have the view contain
> code/taglibs which do the locale stuff in it.
>
> 4. Any other ideas?
>
> My "rating" of my own arguments is that 1 is the best since it abstracts
> the locale to the start of the servlet request as an initial parameter
> (which is how I consider it).  2 requires a lot of customization to
> support what appears to be something others might use (however, the
> ability to override other methods might be desirable).  3 is ugly code,
> and removes all the benefits of Rod's framework for seamlessly handling
> the locale issues.
>
> We probably can't make any of these changes for the 1.0 release (if we
> can great, but I'm trying to be realistic) but I was looking for some
> ideas and counter-arguments.  I need to go ahead with this project (I'm
> actually waiting on this issue right now, but I think I've bought myself
> till Monday :) ) so I'll probably need to make my own modifications to a
> local copy of the code, but if my direction makes sense to everyone, I
> can probably polish/generalize my changes and roll it into the main
> stream in a future release.
>
> Trevor D. Cook
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
>
>
>
>

Re: [Springframework-developer] Explicit locales

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

Guys,

I was aware that this was something that needed to be addressed. Certainly
it's a 1.0 thing.

Juergen's proposal seems simple and effective. I think it's what Struts
does.

Trevor's suggestion of a "hook" is interesting. It would be great for
testing etc. to be able to configure it flexibly. Imagine if a user's locale
preferences were even held in a DB? Can we parameterize based on a
LocaleProvider interface? (Haven't had time to read Trevor's code--apologies
if you've already considered this).

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, February 20, 2003 8:20 PM
Subject: Re: [Springframework-developer] Explicit locales


Trevor,

I've noticed that issue too. We definitely need support for a manually set
locale in the session, already for 1.0. I consider 1. the only viable option
but I think of a very easy and generic way: Why not just define a Spring
standard name for a session attribute that can contain a Locale instance?
The ControllerServlet could first check the session for such an attribute
and fall back to the request locale.

A custom application will probably not support changing the locale with
every possible action but rather with a special one controller URL. That
controller implementation could put a respective attribute into the session,
with the given standard name, and update user preferences in the database or
set a respective cookie if desired. Of course, the user's locale has to be
retrieved for a new session - that could happen after login in a login
controller, or in a custom filter that checks for a certain cookie.

So the minimal framework support needed seems to be the definition of a
standard name for a session locale, and checking the session when
determining a view in the ControllerServlet. Of course, custom applications
can not only set that locale but also retrieve it in controllers that
perform locale-specific actions.

I'm currently in the process of polishing Spring's web part (probably taking
over responsibility for it, at least for 1.0), so I could add such locale
support easily. Would the outlined approach be sufficient for you? If yes, I
will add that support prompty, probably commiting the changes at the
beginning of next week.

Regards,
Juergen



-----Ursprüngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]
Gesendet: Donnerstag, 20. Februar 2003 03:55
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] Explicit locales



I have a business requirement of handling multiple locales.  Specifically, I
live in Canada, and the application must be available in French and English.
However, due to multiple users on a single computer, we cannot rely solely
on the users locale settings.  What we need to do is default to the users
locale, but provide them with the ability to override these settings
(probably by clicking an "English/French" link).

Anyway, the framework question I have is "is there anyway to do this
currently"?  Looking at the controller servlet, it returns a view based on
"request.getLocale()".  This can't be changed, so I can't see any way to
customize/change it.  My ideas are:

1. Have an explicit object in the request attribute for the locale with a
"hook" to define how the default is determined (request locale, cookie,
session, etc.).  The view (or any other locale "lookup") would be based on
this attribute.

2. Wrap the request/response objects in the control servlet, and provide
hooks for these wrappers (which could override the getLocale() method).

3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.

4. Any other ideas?

My "rating" of my own arguments is that 1 is the best since it abstracts the
locale to the start of the servlet request as an initial parameter (which is
how I consider it).  2 requires a lot of customization to support what
appears to be something others might use (however, the ability to override
other methods might be desirable).  3 is ugly code, and removes all the
benefits of Rod's framework for seamlessly handling the locale issues.

We probably can't make any of these changes for the 1.0 release (if we can
great, but I'm trying to be realistic) but I was looking for some ideas and
counter-arguments.  I need to go ahead with this project (I'm actually
waiting on this issue right now, but I think I've bought myself till Monday
:) ) so I'll probably need to make my own modifications to a local copy of
the code, but if my direction makes sense to everyone, I can probably
polish/generalize my changes and roll it into the main stream in a future
release.

Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03

TR : [Springframework-developer] Explicit locales

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Envoy=E9 : jeudi 20 f=E9vrier 2003 22:50
=C0 : 'Trevor Cook'
Objet : RE : [Springframework-developer] Explicit locales

=20

I use a solution near of yours but with a more generalist approach. To
keep the users locale, different possibilities exist: session, cookie,
URL. But each solution can be handled knowing the request object. So I
use a bean for implementing the effective strategy in the way of the
general spirit of Spring.

 1) Create a simple interface like this:

public interface LocaleLocator {

      Locale getSessionLocale(HttpServletRequest request);

      void setSessionLocale(HttpServletRequest request, Locale
sessionLocale);

}

2) Create an implementation class which in your case handles with the
cookies, but which can use the session or what method you like.

3) Overriding the ControllerServlet to use a LocaleLocator property with
at least the setter, so the implementation class can be done in the
servlet-configuration file.

      <bean name=3D"localeLocator" singleton=3D"true"
class=3D"perso.jpp.fwk.web.LocaleLocatorImpl" />   =20

      <bean name=3D"jstlHandler" singleton=3D"true"
class=3D"perso.jpp.fwk.web.JstlHandlerImpl" >     =20

            <property name=3D"bundleName">achappro</property>

      </bean>

=20

code added in declaration part:

      // Added by JPP

      /** The bean name allowing the user session locale to be retrieved
*/=20

      public static final String LOCALE_LOCATOR =3D "localeLocator";

=20

      /** The bean name allowing the jstl ressouece bundle to be set */=20

      public static final String JSTL_HANDLER =3D "jstlHandler";

=20

      /** LocaleLocator used by this servlet

       * If not provided, request.getLocale() will be used instead */ =20

      private LocaleLocator localeLocator;

      // End added

=20

=20

code added in ControllerServlet (or descendent) at end of
initFrameworkServlet :

            initViewResolver();

           =20

            // Added by JPP

            try {

                  localeLocator =3D (LocaleLocator)

=20
getWebApplicationContext().getBean(LOCALE_LOCATOR);=20

                  logger.config("localeLocator found in servlet '" +
getServletName()=20

                        + "' : " + localeLocator.getClass().getName());

            } catch(Exception e) {

                  localeLocator =3D null;   // Not required as it should
yet been null

                  logger.config("No localeLocator found in servlet '" +
getServletName() + "', request Locale will be used.");

            }

            // Jstl handling

            // Put only in a subclass ? But Jstl is ageneric use

            // The ApplicationContextAware doesn't provide an access to
the servletContext

            // It's the reason of an initialisation here. Exists a best
approach ?

            try {

                  JstlHandler jstlHandler =3D (JstlHandler) =20

=20
getWebApplicationContext().getBean(JSTL_HANDLER);=20

                  jstlHandler.setServletCtx(this.getServletContext());

                  logger.config("jstlHandler found in servlet '" +
getServletName()=20

                        + "' : " + jstlHandler.getClass().getName());

            } catch(Exception e) {

                  logger.config("No jstlHandler found in servlet '" +
getServletName());

            }

           =20

            // End added

=20

4) As you can see, I handle I a same way the definition of locale and
bundle for JSTL.

5) The LocaleLocator can be donated by beanref property to objects which
have to know the current locale having the request object.

=20

I hope this will be a useful add-on in this discussion. I suggest to
integrate a such behaviour in the original ControllerServlet as thes
needs are very generally.

=20

Regards,

Jean-Pierre

=20

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Trevor Cook
Envoy=E9 : jeudi 20 f=E9vrier 2003 21:38
=C0 : Spring Developers (E-mail)
Objet : RE: [Springframework-developer] Explicit locales

=20

It sounds like you're on the right track, and your approach should work
for my stuff.  I've already implemented some of this (code below) by
overriding ControllerServlet and checking for a cookie in doService
before passing control up.  I store the locale in a persistent cookie so
that no session is created for simple site browsing, and to remember
chosen language for future visits.  I'm sure my approach could be
improved alot, but it's just a prototype (so I could get my html guy to
start working).

When you're implementing it, a few suggestions/ideas/requests.  If this
is put into the framework, you probably want to allow the developer to
specify whether to make it cookie or session-based.  If it is
cookie-based, you'll probably also need to allow the developer to
specify browser or persistent (including max age).

Trevor D. Cook

=20

public class LocaleServletController extends ControllerServlet {

public static final String LOCALE_HANDLE =3D "locale";

protected void doService(

HttpServletRequest request,

HttpServletResponse response,

boolean debugMode)

throws ServletException, IOException {

String locale =3D request.getParameter(LOCALE_HANDLE);

if (locale !=3D null) {

logger.info("Setting locale to: " + locale);

setLocaleCookie(request, response, locale);=20

} else {

getLocale(request);

}

super.doService(request, response, debugMode);

}

private void getLocale(HttpServletRequest request) {

Cookie[] cookies =3D request.getCookies();

int cookiesSize =3D cookies.length;

for (int i =3D 0; i < cookiesSize; i++) {

if (LOCALE_HANDLE.equals(cookies[i].getName())) {

String localeCookie =3D cookies[i].getValue();

setLocale(request, localeCookie);

}

}

}

private void setLocaleCookie(

HttpServletRequest request,

HttpServletResponse response,

String localeString) {

Locale locale =3D setLocale(request, localeString);

Cookie localeCookie =3D new Cookie(LOCALE_HANDLE, localeString);

if (locale.equals(request.getLocale())) {

localeCookie.setMaxAge(-1);

} else {

localeCookie.setMaxAge(365 * 24 * 60 * 60);

}

response.addCookie(localeCookie);

}

private Locale setLocale(

HttpServletRequest request,

String localeString) {

Locale locale =3D

new Locale(localeString.substring(0, 2), localeString.substring(2));

request.setAttribute("locale", locale);

return locale;

}

}

=20

=20

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: February 20, 2003 3:21 PM
To: Spring Developers (E-mail)
Subject: Re: [Springframework-developer] Explicit locales

Trevor,

=20

I've noticed that issue too. We definitely need support for a manually
set locale in the session, already for 1.0. I consider 1. the only
viable option but I think of a very easy and generic way: Why not just
define a Spring standard name for a session attribute that can contain a
Locale instance? The ControllerServlet could first check the session for
such an attribute and fall back to the request locale.

=20

A custom application will probably not support changing the locale with
every possible action but rather with a special one controller URL. That
controller implementation could put a respective attribute into the
session, with the given standard name, and update user preferences in
the database or set a respective cookie if desired. Of course, the
user's locale has to be retrieved for a new session - that could happen
after login in a login controller, or in a custom filter that checks for
a certain cookie.

=20

So the minimal framework support needed seems to be the definition of a
standard name for a session locale, and checking the session when
determining a view in the ControllerServlet. Of course, custom
applications can not only set that locale but also retrieve it in
controllers that perform locale-specific actions.

=20

I'm currently in the process of polishing Spring's web part (probably
taking over responsibility for it, at least for 1.0), so I could add
such locale support easily. Would the outlined approach be sufficient
for you? If yes, I will add that support prompty, probably commiting the
changes at the beginning of next week.

=20

Regards,

Juergen

=20

=20

-----Urspr=FCngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]=20
Gesendet: Donnerstag, 20. Februar 2003 03:55
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] Explicit locales

I have a business requirement of handling multiple locales.
Specifically, I live in Canada, and the application must be available in
French and English.  However, due to multiple users on a single
computer, we cannot rely solely on the users locale settings.  What we
need to do is default to the users locale, but provide them with the
ability to override these settings (probably by clicking an
"English/French" link).

Anyway, the framework question I have is "is there anyway to do this
currently"?  Looking at the controller servlet, it returns a view based
on "request.getLocale()".  This can't be changed, so I can't see any way
to customize/change it.  My ideas are:

1. Have an explicit object in the request attribute for the locale with
a "hook" to define how the default is determined (request locale,
cookie, session, etc.).  The view (or any other locale "lookup") would
be based on this attribute.

2. Wrap the request/response objects in the control servlet, and provide
hooks for these wrappers (which could override the getLocale() method).

3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.=20

4. Any other ideas?=20

My "rating" of my own arguments is that 1 is the best since it abstracts
the locale to the start of the servlet request as an initial parameter
(which is how I consider it).  2 requires a lot of customization to
support what appears to be something others might use (however, the
ability to override other methods might be desirable).  3 is ugly code,
and removes all the benefits of Rod's framework for seamlessly handling
the locale issues.

We probably can't make any of these changes for the 1.0 release (if we
can great, but I'm trying to be realistic) but I was looking for some
ideas and counter-arguments.  I need to go ahead with this project (I'm
actually waiting on this issue right now, but I think I've bought myself
till Monday :) ) so I'll probably need to make my own modifications to a
local copy of the code, but if my direction makes sense to everyone, I
can probably polish/generalize my changes and roll it into the main
stream in a future release.

Trevor D. Cook=20

=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
 =20

=20

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

It sounds like you're on the right track, and your approach should work =
for
my stuff.  I've already implemented some of this (code below) by =
overriding
ControllerServlet and checking for a cookie in doService before passing
control up.  I store the locale in a persistent cookie so that no =
session is
created for simple site browsing, and to remember chosen language for =
future
visits.  I'm sure my approach could be improved alot, but it's just a
prototype (so I could get my html guy to start working).

When you're implementing it, a few suggestions/ideas/requests.  If this =
is
put into the framework, you probably want to allow the developer to =
specify
whether to make it cookie or session-based.  If it is cookie-based, =
you'll
probably also need to allow the developer to specify browser or =
persistent
(including max age).

Trevor D. Cook

=20

public class LocaleServletController extends ControllerServlet {

public static final String LOCALE_HANDLE =3D "locale";

protected void doService(

HttpServletRequest request,

HttpServletResponse response,

boolean debugMode)

throws ServletException, IOException {

String locale =3D request.getParameter(LOCALE_HANDLE);

if (locale !=3D null) {

logger.info("Setting locale to: " + locale);

setLocaleCookie(request, response, locale);=20

} else {

getLocale(request);

}

super.doService(request, response, debugMode);

}

private void getLocale(HttpServletRequest request) {

Cookie[] cookies =3D request.getCookies();

int cookiesSize =3D cookies.length;

for (int i =3D 0; i < cookiesSize; i++) {

if (LOCALE_HANDLE.equals(cookies[i].getName())) {

String localeCookie =3D cookies[i].getValue();

setLocale(request, localeCookie);

}

}

}

private void setLocaleCookie(

HttpServletRequest request,

HttpServletResponse response,

String localeString) {

Locale locale =3D setLocale(request, localeString);

Cookie localeCookie =3D new Cookie(LOCALE_HANDLE, localeString);

if (locale.equals(request.getLocale())) {

localeCookie.setMaxAge(-1);

} else {

localeCookie.setMaxAge(365 * 24 * 60 * 60);

}

response.addCookie(localeCookie);

}

private Locale setLocale(

HttpServletRequest request,

String localeString) {

Locale locale =3D

new Locale(localeString.substring(0, 2), localeString.substring(2));

request.setAttribute("locale", locale);

return locale;

}

}

=20

=20

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: February 20, 2003 3:21 PM
To: Spring Developers (E-mail)
Subject: Re: [Springframework-developer] Explicit locales


Trevor,
=20
I've noticed that issue too. We definitely need support for a manually =
set
locale in the session, already for 1.0. I consider 1. the only viable =
option
but I think of a very easy and generic way: Why not just define a =
Spring
standard name for a session attribute that can contain a Locale =
instance?
The ControllerServlet could first check the session for such an =
attribute
and fall back to the request locale.
=20
A custom application will probably not support changing the locale with
every possible action but rather with a special one controller URL. =
That
controller implementation could put a respective attribute into the =
session,
with the given standard name, and update user preferences in the =
database or
set a respective cookie if desired. Of course, the user's locale has to =
be
retrieved for a new session - that could happen after login in a login
controller, or in a custom filter that checks for a certain cookie.
=20
So the minimal framework support needed seems to be the definition of a
standard name for a session locale, and checking the session when
determining a view in the ControllerServlet. Of course, custom =
applications
can not only set that locale but also retrieve it in controllers that
perform locale-specific actions.
=20
I'm currently in the process of polishing Spring's web part (probably =
taking
over responsibility for it, at least for 1.0), so I could add such =
locale
support easily. Would the outlined approach be sufficient for you? If =
yes, I
will add that support prompty, probably commiting the changes at the
beginning of next week.
=20
Regards,
Juergen
=20
=20

-----Urspr=FCngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]=20
Gesendet: Donnerstag, 20. Februar 2003 03:55
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] Explicit locales



I have a business requirement of handling multiple locales.  =
Specifically, I
live in Canada, and the application must be available in French and =
English.
However, due to multiple users on a single computer, we cannot rely =
solely
on the users locale settings.  What we need to do is default to the =
users
locale, but provide them with the ability to override these settings
(probably by clicking an "English/French" link).

Anyway, the framework question I have is "is there anyway to do this
currently"?  Looking at the controller servlet, it returns a view based =
on
"request.getLocale()".  This can't be changed, so I can't see any way =
to
customize/change it.  My ideas are:

1. Have an explicit object in the request attribute for the locale with =
a
"hook" to define how the default is determined (request locale, cookie,
session, etc.).  The view (or any other locale "lookup") would be based =
on
this attribute.

2. Wrap the request/response objects in the control servlet, and =
provide
hooks for these wrappers (which could override the getLocale() method).

3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.=20

4. Any other ideas?=20

My "rating" of my own arguments is that 1 is the best since it =
abstracts the
locale to the start of the servlet request as an initial parameter =
(which is
how I consider it).  2 requires a lot of customization to support what
appears to be something others might use (however, the ability to =
override
other methods might be desirable).  3 is ugly code, and removes all the
benefits of Rod's framework for seamlessly handling the locale issues.

We probably can't make any of these changes for the 1.0 release (if we =
can
great, but I'm trying to be realistic) but I was looking for some ideas =
and
counter-arguments.  I need to go ahead with this project (I'm actually
waiting on this issue right now, but I think I've bought myself till =
Monday
:) ) so I'll probably need to make my own modifications to a local copy =
of
the code, but if my direction makes sense to everyone, I can probably
polish/generalize my changes and roll it into the main stream in a =
future
release.

Trevor D. Cook=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system ( HYPERLINK "http://www.grisoft.com"
\nhttp://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
 =20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
=20

Re: [Springframework-developer] Explicit locales

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

Trevor,
=20
I've noticed that issue too. We definitely need support for a manually =
set locale in the session, already for 1.0. I consider 1. the only =
viable option but I think of a very easy and generic way: Why not just =
define a Spring standard name for a session attribute that can contain a =
Locale instance? The ControllerServlet could first check the session for =
such an attribute and fall back to the request locale.
=20
A custom application will probably not support changing the locale with =
every possible action but rather with a special one controller URL. That =
controller implementation could put a respective attribute into the =
session, with the given standard name, and update user preferences in =
the database or set a respective cookie if desired. Of course, the =
user's locale has to be retrieved for a new session - that could happen =
after login in a login controller, or in a custom filter that checks for =
a certain cookie.
=20
So the minimal framework support needed seems to be the definition of a =
standard name for a session locale, and checking the session when =
determining a view in the ControllerServlet. Of course, custom =
applications can not only set that locale but also retrieve it in =
controllers that perform locale-specific actions.
=20
I'm currently in the process of polishing Spring's web part (probably =
taking over responsibility for it, at least for 1.0), so I could add =
such locale support easily. Would the outlined approach be sufficient =
for you? If yes, I will add that support prompty, probably commiting the =
changes at the beginning of next week.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----
	Von: Trevor Cook [mailto:tc...@in...]=20
	Gesendet: Donnerstag, 20. Februar 2003 03:55
	An: Spring Developers (E-mail)
	Betreff: [Springframework-developer] Explicit locales
=09
=09

	I have a business requirement of handling multiple locales.  =
Specifically, I live in Canada, and the application must be available in =
French and English.  However, due to multiple users on a single =
computer, we cannot rely solely on the users locale settings.  What we =
need to do is default to the users locale, but provide them with the =
ability to override these settings (probably by clicking an =
"English/French" link).

	Anyway, the framework question I have is "is there anyway to do this =
currently"?  Looking at the controller servlet, it returns a view based =
on "request.getLocale()".  This can't be changed, so I can't see any way =
to customize/change it.  My ideas are:

	1. Have an explicit object in the request attribute for the locale with =
a "hook" to define how the default is determined (request locale, =
cookie, session, etc.).  The view (or any other locale "lookup") would =
be based on this attribute.

	2. Wrap the request/response objects in the control servlet, and =
provide hooks for these wrappers (which could override the getLocale() =
method).

	3. Have the view return a generic view, and have the view contain =
code/taglibs which do the locale stuff in it.=20

	4. Any other ideas?=20

	My "rating" of my own arguments is that 1 is the best since it =
abstracts the locale to the start of the servlet request as an initial =
parameter (which is how I consider it).  2 requires a lot of =
customization to support what appears to be something others might use =
(however, the ability to override other methods might be desirable).  3 =
is ugly code, and removes all the benefits of Rod's framework for =
seamlessly handling the locale issues.

	We probably can't make any of these changes for the 1.0 release (if we =
can great, but I'm trying to be realistic) but I was looking for some =
ideas and counter-arguments.  I need to go ahead with this project (I'm =
actually waiting on this issue right now, but I think I've bought myself =
till Monday :) ) so I'll probably need to make my own modifications to a =
local copy of the code, but if my direction makes sense to everyone, I =
can probably polish/generalize my changes and roll it into the main =
stream in a future release.

	Trevor D. Cook=20


	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
	 =20

[Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

I have a business requirement of handling multiple locales.  Specifically, I
live in Canada, and the application must be available in French and English.
However, due to multiple users on a single computer, we cannot rely solely
on the users locale settings.  What we need to do is default to the users
locale, but provide them with the ability to override these settings
(probably by clicking an "English/French" link).

Anyway, the framework question I have is "is there anyway to do this
currently"?  Looking at the controller servlet, it returns a view based on
"request.getLocale()".  This can't be changed, so I can't see any way to
customize/change it.  My ideas are:

1. Have an explicit object in the request attribute for the locale with a
"hook" to define how the default is determined (request locale, cookie,
session, etc.).  The view (or any other locale "lookup") would be based on
this attribute.

2. Wrap the request/response objects in the control servlet, and provide
hooks for these wrappers (which could override the getLocale() method).

3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.

4. Any other ideas?

My "rating" of my own arguments is that 1 is the best since it abstracts the
locale to the start of the servlet request as an initial parameter (which is
how I consider it).  2 requires a lot of customization to support what
appears to be something others might use (however, the ability to override
other methods might be desirable).  3 is ugly code, and removes all the
benefits of Rod's framework for seamlessly handling the locale issues.

We probably can't make any of these changes for the 1.0 release (if we can
great, but I'm trying to be realistic) but I was looking for some ideas and
counter-arguments.  I need to go ahead with this project (I'm actually
waiting on this issue right now, but I think I've bought myself till Monday
:) ) so I'll probably need to make my own modifications to a local copy of
the code, but if my direction makes sense to everyone, I can probably
polish/generalize my changes and roll it into the main stream in a future
release.

Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
 

WG: [Springframework-developer] Optional dependencies

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

"Reply to" address, a second time...
=20
=20
-----Urspr=FCngliche Nachricht-----
Von: j=FCrgen h=F6ller [werk3AT]=20
Gesendet: Freitag, 14. Februar 2003 21:00
An: Rod Johnson
Betreff: Re: [Springframework-developer] Optional dependencies


Rod,
=20
Let's simply include the relevant JARs in the CVS lib directory. =
Developers shouldn't care about some additional JARs even if they aren't =
interested in them. The same rule applies to the current view =
implementations that depend on Velocity and co. Of course, a dependency =
table is a must, at least at the subpackage level of the Spring =
codebase.
=20
Regarding Struts: I guess it should be possible to include only the =
relevant JARs and ignore the convenience stuff, like some of the Commons =
packages. Ideally, that would mean just a struts.jar, not the whole army =
that comes with a Struts distribution. Of course, the unit tests need to =
be able to run, so this might be more sophisticated that I assume.
=20
Concerning the distribution: I don't mind including such classes in the =
standard Spring JARs, as they wouldn't need any of the third party =
libraries if they are not actually used at runtime. I've used that =
approach successfully numerous times within application projects, for =
example in terms of separation of remote client and server classes, or =
web application and applet codebase. Spring users that want to enable a =
plugin should have to download the respective libraries from the third =
party's site. That instructions need to be mentioned in a readme.=20
=20
Take for example Tomcat 4.x: Its distribution includes Tyrex-dependent =
factory classes for its JNDI resource manager even though it doesn't =
include the Tyrex libraries. Users have to download the Tyrex libraries =
themselves from the ExoLab site. I don't know about Tomcat's CVS =
contents, but I assume that the developers do have the Tyrex libraries =
there.
=20
In terms of repository size, including third party libraries should not =
make a big difference. I assume that those libraries will change rarely, =
at least in the Spring CVS, as we don't need to follow every minor =
update. So CVS updates will usually ignore them and not cause additional =
download traffic after initial checkout.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Rod Johnson [mailto:rod...@in...]=20
	Gesendet: Fr 14.02.2003 07:57=20
	An: spr...@li...=20
	Cc:=20
	Betreff: [Springframework-developer] Optional dependencies
=09
=09

	Guys,
=09
	I've just been discussing our forthcoming Struts integration with Yann =
and
	Paul.
=09
	This raises a problem that's likely to recur. This will probably =
involve
	adding a small number of classes that are Struts-dependent. But not all
	developers might be interested in them.
=09
	In the following, read "Struts" to mean "any third party product some
	classes will depend on but which aren't of interest to everyone".
=09
	How can we prevent our whole source tree being Struts-dependent and =
prevent
	developers uninterested in Struts from having to download the relevant =
Jars?
	* Make it a separate CVS module?  But this will lead to a profusion of =
CVS
	modules. Harder to build etc.
	* Put it in the main module and change the Ant build script to compile =
the
	necessary classes and run the the relevant tests only if it finds =
Struts on
	the classpath? This could eventually make the build script very long =
and
	complicated.
	* Better ideas I haven't thought off?? How do other projects handle =
this?
=09
	From a distribution point of view, many users won't want the Struts =
classes
	either. We could make them a sep download. Or we could just include =
them in
	one of the main Jars, and they wouldn't do any harm unless they were =
used
	without Struts.
=09
	From a documentation view, we'll also need a dependencies table, =
showing
	what depends on what.
=09
	Regards,
	Rod
=09
	____________________________________________________
	Rod Johnson
	J2EE Architect and Author
	+44 7973 409 132
=09
	Author of "Expert One-on-One J2EE Design and Development"
	(Wrox Press, October 2002).
	http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/
=09
	http://www.wrox.com/books/1861007841.htm
=09
	http://www.wrox.com/dynamic/books/find.aspx?author=3DRod+Johnson
=09
=09
=09
=09
	-------------------------------------------------------
	This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
	are you planning your Web Server Security? Click here to get a FREE
	Thawte SSL guide and find the answers to all your  SSL security issues.
	http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

Fw: [Springframework-developer] build.xml: VOTE

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

That xxx "reply to" address... ;-)


-----Urspr=FCngliche Nachricht-----
Von: j=FCrgen h=F6ller [werk3AT]=20
Gesendet: Montag, 17. Februar 2003 08:44
An: 'Rod Johnson'
Betreff: Re: [Springframework-developer] build.xml: VOTE


Fine!

> -----Urspr=FCngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sonntag, 16. Februar 2003 22:45
> An: spr...@li...
> Betreff: Fw: [Springframework-developer] build.xml: VOTE
>=20
>=20
> Oops, the "reply to" address got me again...
>=20
>=20
>  Sounds like a good idea to me. Can we vote on it?
>=20
> Rod
> >
> > ----- Original Message -----
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: "'spring-dev-list'"
> > <spr...@li...>
> > Sent: Friday, February 14, 2003 8:52 PM
> > Subject: [Springframework-developer] build.xml
> >
> >
> > > Just a thought. Why not move all the property declarations out of
> > build.xml
> > > into a property file. It's a best practice and makes a build file
> cleaner.
> > >
> > > Just my 2c.
> > >
> > > Dmitriy.
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by: FREE  SSL Guide from
> Thawte are
> > > you planning your Web Server Security? Click here to get a FREE
> > > Thawte SSL guide and find the answers to all your  SSL security=20
> > > issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/springframework-d
evelop
> > er
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Properties files

[Tim M. <mu...@on...>]

I've always felt it was most effective to only put properties that were 
likely to be changed for an individual's local environment. So 
something like the location of JBoss or JDBC information. Stuff like 
the location of the build directory probably won't change much and just 
clutters up the properties file. If you have one and only put things 
that are likely to change, it is much more obvious to a new user where 
to make mods.

--Tim

RE: [Springframework-developer] build.xml

[Kopylenko, D. <dko...@ac...>]

 Yes, I will do that as soon I get a chance. Right now I am stuck here in
Philadelphia with my girlfriend (I live in NJ) due to the big snow storm...
:-) Will be waiting until the conditions improve :-)

Later.

Dmitriy.

-----Original Message-----
From: Rod Johnson
To: Kopylenko, Dmitry; 'spring-dev-list'
Sent: 2/17/2003 4:12 AM
Subject: Re: [Springframework-developer] build.xml

Dmitriy,

Yes, this seems to be worth doing. Would you like to send me a modified
build.xml and the new properties file so that I can test it and check it
in?

Please update to build.xml 1.3 as the basis for your new version--I made
some changes last night.

Regards,
Rod

----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'spring-dev-list'"
<spr...@li...>
Sent: Friday, February 14, 2003 8:52 PM
Subject: [Springframework-developer] build.xml


> Just a thought. Why not move all the property declarations out of
build.xml
> into a property file. It's a best practice and makes a build file
cleaner.
>
> Just my 2c.
>
> Dmitriy.
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security
issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer