[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations

2009-04-21 Thread Andy Blower (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701141#action_12701141
 ] 

Andy Blower commented on TAP5-658:
--

You're correct about the calls to PersistentLocale.set() - I have no idea why I 
thought it was being called for every request, it's not. I do think that the 
symbol could be used to stop the checks for supported locale being the first 
part of a URL. It's never going to be if ENCODE_LOCALE_INTO_PATH is false.

Regarding LocalizationSetter, I have not rewritten CELE to handle locales, and 
I actually decided against doing it for our URL manipulation too - I advised 
the service instead which worked very nicely. (shame I couldn't just have 
decorated a service for 5.0 but that did it in the dispatcher...) 

It seems you're still conflating these two *separate* aspects of my Tapestry 
work: 

* URL manipulation, where I did mess with internals in 5.0 with full knowledge 
of the implications. (took less than a day to move this code to advice in T5.1, 
no problem at all once I figured out the best approach)

* Overriding locale persistence, where I did not touch the internals and there 
is still a backwards compatibility issue that seems to bother no one so it's 
pretty irrelevant.

So, what I've actually done to handle locales my own way in T5.1 is to follow 
the three steps from TAP5-577.

1) Set the ENCODE_LOCALE_INTO_PATH symbol to false.
2) Created an implementation of PersistentLocale and contribute it to the IOC. 
(same as 5.0 version we had)
3) Create a custom filter written and created to do the same job as the 5.0 
LocalizationFilter and contribute it to the IOC RequestHandler. This filter 
will need to call the LocalizationSetter setLocaleFromLocaleName() method 
instead of the old setThreadLocale() method.

I attached the relevant changes to our module for step 3 to TAP5-577, I don't 
know if you've seen that. If you take a look you can see that Locale is 
converted to a string just so it can be passed. I could add the functionality 
from LocalizationSetter to the LocalizationFilter I had to create, but that 
seems wrong if I've not rewritten CELE for locale functionality or anything 
else. I certainly could add the functionality into LocalizationFilter but that 
seems to be almost like if you don't want URL locales then you need to 
implement it all yourself which is anti-tapestry ethos I would have thought.

> Optimizations for custom persistent locale implementations
> --
>
> Key: TAP5-658
> URL: https://issues.apache.org/jira/browse/TAP5-658
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.4
>Reporter: Andy Blower
>Priority: Minor
>
> I was wondering if having a method in LocalizationSetter that allows a Locale 
> to be passed would be a good idea. This would remove the conversion to String 
> and back again which occurs for every request if you are actually storing a 
> locale with a custom persistent locale implementation.
> The other slight annoyance I have with this area of T5 is that 
> PersistentLocale.set() being constantly called by the LocalizationSetter for 
> each request, this doesn't fit in with the old way that the PersistentLocale 
> service was used. I think that only executing persistentLocale.set(locale); 
> (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little 
> improvement/optimization.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (TAP5-658) Optimizations for custom persistent locale implementations

2009-04-21 Thread Andy Blower (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701141#action_12701141
 ] 

Andy Blower edited comment on TAP5-658 at 4/21/09 5:06 AM:
---

You're correct about the calls to PersistentLocale.set() - I have no idea why I 
thought it was being called for every request, it's not. I do think that the 
symbol could be used to stop the checks for supported locale being the first 
part of a URL. It's never going to be if ENCODE_LOCALE_INTO_PATH is false.

Regarding LocalizationSetter, I have not rewritten CELE to handle locales, and 
I actually decided against doing it for our URL manipulation too - I advised 
the service instead which worked very nicely. (shame I couldn't just have 
decorated a service for 5.0 but that did it in the dispatcher...) 

It seems you're still conflating these two *separate* aspects of my Tapestry 
work: 

* URL manipulation, where I did mess with internals in 5.0 with full knowledge 
of the implications. (took less than a day to move this code to advice in T5.1, 
no problem at all once I figured out the best approach)

* Overriding locale persistence, where I did not touch the internals and there 
is still a backwards compatibility issue that seems to bother no one so it's 
pretty irrelevant.

So, what I've actually done to handle locales my own way in T5.1 is to follow 
the three steps from TAP5-577.

1) Set the ENCODE_LOCALE_INTO_PATH symbol to false.
2) Created an implementation of PersistentLocale and contribute it to the IOC. 
(same as 5.0 version we had)
3) Created a custom filter written and created to do the same job as the 5.0 
LocalizationFilter and contribute it to the IOC RequestHandler. This filter 
calls the LocalizationSetter setLocaleFromLocaleName() method instead of the 
old setThreadLocale() method.

I attached the relevant changes to our module for step 3 to TAP5-577, I don't 
know if you've seen that. If you take a look you can see that Locale is 
converted to a string just so it can be passed. I could add the functionality 
from LocalizationSetter to the LocalizationFilter I had to create, but that 
seems wrong if I've not rewritten CELE for locale functionality or anything 
else. I certainly could add the functionality into LocalizationFilter but that 
seems to be almost like if you don't want URL locales then you need to 
implement it all yourself which is anti-tapestry ethos I would have thought.

  was (Author: andyb):
You're correct about the calls to PersistentLocale.set() - I have no idea 
why I thought it was being called for every request, it's not. I do think that 
the symbol could be used to stop the checks for supported locale being the 
first part of a URL. It's never going to be if ENCODE_LOCALE_INTO_PATH is false.

Regarding LocalizationSetter, I have not rewritten CELE to handle locales, and 
I actually decided against doing it for our URL manipulation too - I advised 
the service instead which worked very nicely. (shame I couldn't just have 
decorated a service for 5.0 but that did it in the dispatcher...) 

It seems you're still conflating these two *separate* aspects of my Tapestry 
work: 

* URL manipulation, where I did mess with internals in 5.0 with full knowledge 
of the implications. (took less than a day to move this code to advice in T5.1, 
no problem at all once I figured out the best approach)

* Overriding locale persistence, where I did not touch the internals and there 
is still a backwards compatibility issue that seems to bother no one so it's 
pretty irrelevant.

So, what I've actually done to handle locales my own way in T5.1 is to follow 
the three steps from TAP5-577.

1) Set the ENCODE_LOCALE_INTO_PATH symbol to false.
2) Created an implementation of PersistentLocale and contribute it to the IOC. 
(same as 5.0 version we had)
3) Create a custom filter written and created to do the same job as the 5.0 
LocalizationFilter and contribute it to the IOC RequestHandler. This filter 
will need to call the LocalizationSetter setLocaleFromLocaleName() method 
instead of the old setThreadLocale() method.

I attached the relevant changes to our module for step 3 to TAP5-577, I don't 
know if you've seen that. If you take a look you can see that Locale is 
converted to a string just so it can be passed. I could add the functionality 
from LocalizationSetter to the LocalizationFilter I had to create, but that 
seems wrong if I've not rewritten CELE for locale functionality or anything 
else. I certainly could add the functionality into LocalizationFilter but that 
seems to be almost like if you don't want URL locales then you need to 
implement it all yourself which is anti-tapestry ethos I would have thought.
  
> Optimizations for custom persistent locale implementations
> --
>
> Key: TAP5-658
>

[jira] Updated: (TAP5-657) The FieldFocusPriority enum should include an additional value, OVERRIDE, to indicate a manually focused field (with highest priority)

2009-04-21 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-657:
--

Summary: The FieldFocusPriority enum should include an additional value, 
OVERRIDE, to indicate a manually focused field (with highest priority)  (was: 
The FieldFocusPriority enum should include an additional value, MANUAL, to 
indicate a manually focused field (with highest priority))

> The FieldFocusPriority enum should include an additional value, OVERRIDE, to 
> indicate a manually focused field (with highest priority)
> --
>
> Key: TAP5-657
> URL: https://issues.apache.org/jira/browse/TAP5-657
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.1.0.4
>
>
> For applications that wish to force a field to be the focus field, a 
> FFP.MANUAL would do the trick.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (TAP5-646) When Tapestry is combining JavaScript files, it should check for a JS file that ends with an unterminated comment, and add the comment terminator

2009-04-21 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-646:
-

Assignee: Howard M. Lewis Ship

> When Tapestry is combining JavaScript files, it should check for a JS file 
> that ends with an unterminated comment, and add the comment terminator
> -
>
> Key: TAP5-646
> URL: https://issues.apache.org/jira/browse/TAP5-646
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>
> From the mailing list:
> I'm found were is the problem...
> It's appear only when tapestry.production-mode=true.
> As I'm understand in this mode all JavaScripts gather in one virtual .js.
> But one of my script have comment at the last line!
> The next script added to the end of previous one without CL, so the meaning
> line of the second script became commented...
> I'm solve the problem, but IMHO it's need to change virtual file gathering
> in order to prevent such a situation.
> To be honest, this one goes to user error, but the unterminated comment 
> doesn't cause problems with many individual 

svn commit: r767288 - in /tapestry/tapestry5/trunk/tapestry-core/src: main/java/org/apache/tapestry5/internal/services/ main/java/org/apache/tapestry5/services/ test/java/org/apache/tapestry5/internal

2009-04-21 Thread hlship
Author: hlship
Date: Tue Apr 21 20:50:56 2009
New Revision: 767288

URL: http://svn.apache.org/viewvc?rev=767288&view=rev
Log:
TAP5-646: When Tapestry is combining JavaScript files, it should check for a JS 
file that ends with an unterminated comment, and add the comment terminator
TAP5-659: In some servlet containers, access to virtual assets can result in a 
GZIP-related exception

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataEncoderImpl.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataSinkImpl.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DocumentLinkerImpl.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/VirtualAssetStreamerImpl.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/ClientDataEncoder.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/ClientDataSink.java

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/DocumentLinkerImplTest.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataEncoderImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataEncoderImpl.java?rev=767288&r1=767287&r2=767288&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataEncoderImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataEncoderImpl.java
 Tue Apr 21 20:50:56 2009
@@ -17,6 +17,7 @@
 import org.apache.tapestry5.internal.util.Base64InputStream;
 import org.apache.tapestry5.services.ClientDataEncoder;
 import org.apache.tapestry5.services.ClientDataSink;
+import org.apache.tapestry5.services.URLEncoder;
 
 import java.io.BufferedInputStream;
 import java.io.IOException;
@@ -25,11 +26,18 @@
 
 public class ClientDataEncoderImpl implements ClientDataEncoder
 {
+private final URLEncoder urlEncoder;
+
+public ClientDataEncoderImpl(URLEncoder urlEncoder)
+{
+this.urlEncoder = urlEncoder;
+}
+
 public ClientDataSink createSink()
 {
 try
 {
-return new ClientDataSinkImpl();
+return new ClientDataSinkImpl(urlEncoder);
 }
 catch (IOException ex)
 {
@@ -54,4 +62,9 @@
 throw new RuntimeException(ex);
 }
 }
+
+public ObjectInputStream decodeEncodedClientData(String clientData) throws 
IOException
+{
+return decodeClientData(urlEncoder.decode(clientData));
+}
 }

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataSinkImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataSinkImpl.java?rev=767288&r1=767287&r2=767288&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataSinkImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientDataSinkImpl.java
 Tue Apr 21 20:50:56 2009
@@ -16,6 +16,7 @@
 
 import org.apache.tapestry5.internal.util.Base64OutputStream;
 import org.apache.tapestry5.services.ClientDataSink;
+import org.apache.tapestry5.services.URLEncoder;
 
 import java.io.BufferedOutputStream;
 import java.io.IOException;
@@ -29,10 +30,13 @@
 
 private final ObjectOutputStream objectOutputStream;
 
+private final URLEncoder urlEncoder;
+
 private boolean closed;
 
-public ClientDataSinkImpl() throws IOException
+public ClientDataSinkImpl(URLEncoder urlEncoder) throws IOException
 {
+this.urlEncoder = urlEncoder;
 base64OutputStream = new Base64OutputStream();
 
 final BufferedOutputStream pipeline = new BufferedOutputStream(new 
GZIPOutputStream(base64OutputStream));
@@ -97,4 +101,9 @@
 
 return base64OutputStream.toBase64();
 }
+
+public String getEncodedClientData()
+{
+return urlEncoder.encode(getClientData());
+}
 }

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DocumentLinkerImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DocumentLinkerImpl.java?rev=767288&r1=767287&r2=767288&view=diff
==
--- 
tape

[jira] Closed: (TAP5-646) When Tapestry is combining JavaScript files, it should check for a JS file that ends with an unterminated comment, and add the comment terminator

2009-04-21 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-646.
-

   Resolution: Fixed
Fix Version/s: 5.1.0.4

> When Tapestry is combining JavaScript files, it should check for a JS file 
> that ends with an unterminated comment, and add the comment terminator
> -
>
> Key: TAP5-646
> URL: https://issues.apache.org/jira/browse/TAP5-646
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.1.0.4
>
>
> From the mailing list:
> I'm found were is the problem...
> It's appear only when tapestry.production-mode=true.
> As I'm understand in this mode all JavaScripts gather in one virtual .js.
> But one of my script have comment at the last line!
> The next script added to the end of previous one without CL, so the meaning
> line of the second script became commented...
> I'm solve the problem, but IMHO it's need to change virtual file gathering
> in order to prevent such a situation.
> To be honest, this one goes to user error, but the unterminated comment 
> doesn't cause problems with many individual 

[jira] Closed: (TAP5-659) In some servlet containers, access to virtual assets can result in a GZIP-related exception

2009-04-21 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-659.
-

   Resolution: Fixed
Fix Version/s: 5.1.0.4

> In some servlet containers, access to virtual assets can result in a 
> GZIP-related exception
> ---
>
> Key: TAP5-659
> URL: https://issues.apache.org/jira/browse/TAP5-659
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Blocker
> Fix For: 5.1.0.4
>
>
> It looks like certain characters (I believe slashes) in the path name for the 
> virtual asset are being decoded by the servlet container (this is for 
> Websphere, I've seen a similar problem for Tomcat).
> 2009-04-20 11:29:21,006 [WebContainer : 1] DEBUG 
> org.apache.tapestry5.services.TapestryModule.ClientDataEncoder:73 - [ENTER] 
> decodeClientData("H4sIAKXQwUoDMRAG4CD04nOIFKHJbktFD 
> JFDz0JWuhRssnsGs3uhMwsbX0mX813cLOwC15aaG/Dny9/wvz8ism3EBcPQohLcaM0ETApMtEF1qb12JJaylxmcqFCREbeB5CfJORh
>  y9NfnrYQ1mC4V5eDZJ1AOK4H9EQJHU9qMJr81W4aEc2JsnNjrbNaiDSFfSPvwzc 
> G4Imj9Umdk8X97d3meLfF4Uc2WwVhEqsGkK2EDT 
> a2zVbr3mg6ed8Gj7fe0Ordw924w9lWPp1bV0LSpYHPuX966TTls1q4GbPnJaY9VV/wHK4JGUkYCAAA=")
> 2009-04-20 11:29:21,022 [WebContainer : 1] DEBUG 
> org.apache.tapestry5.services.TapestryModule.ClientDataEncoder:164 - [ FAIL] 
> decodeClientData -- java.lang.RuntimeException
> java.lang.RuntimeException: java.util.zip.ZipException: invalid bit length 
> repeat
>   at 
> org.apache.tapestry5.internal.services.ClientDataEncoderImpl.decodeClientData(ClientDataEncoderImpl.java:54)
>   at 
> Invocation$ClientDataEncoder$decodeClientData$120c4253f59.invokeDelegateMethod(Invocation$ClientDataEncoder$decodeClientData$120c4253f59.java)
>   at 
> org.apache.tapestry5.ioc.internal.services.AbstractInvocation.proceed(AbstractInvocation.java:117)
>   at 
> org.apache.tapestry5.ioc.internal.services.LoggingAdvice.advise(LoggingAdvice.java:45)
>   at 
> org.apache.tapestry5.ioc.internal.services.AbstractInvocation.proceed(AbstractInvocation.java:121)
>   at 
> $ClientDataEncoder_120c42536f2.decodeClientData($ClientDataEncoder_120c42536f2.java)
>   at 
> $ClientDataEncoder_120c4253666.decodeClientData($ClientDataEncoder_120c4253666.java)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl.constructVirtualAssetStream(VirtualAssetStreamerImpl.java:161)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl.getVirtualStream(VirtualAssetStreamerImpl.java:148)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl.getCompressedVirtualStream(VirtualAssetStreamerImpl.java:112)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl.getVirtualStream(VirtualAssetStreamerImpl.java:103)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl.streamVirtualAsset(VirtualAssetStreamerImpl.java:74)
>   at 
> $VirtualAssetStreamer_120c425362c.streamVirtualAsset($VirtualAssetStreamer_120c425362c.java)
>   at 
> org.apache.tapestry5.internal.services.VirtualAssetDispatcher.dispatch(VirtualAssetDispatcher.java:49)
>   at $Dispatcher_120c4253633.dispatch($Dispatcher_120c4253633.java)
>   at $Dispatcher_120c4253626.dispatch($Dispatcher_120c4253626.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:250)
>   at 
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
>   at $RequestHandler_120c4253627.service($RequestHandler_120c4253627.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:782)
>   at $RequestHandler_120c4253627.service($RequestHandler_120c4253627.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:771)
>   at $RequestHandler_120c4253627.service($RequestHandler_120c4253627.java)
>   at 
> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
>   at $RequestHandler_120c4253627.service($RequestHandler_120c4253627.java)
>   at 
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
>   at 
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
>   at 
> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
>   at 
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
>   at $RequestHandler_120c4253627.service($Req

svn commit: r767301 - /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java

2009-04-21 Thread hlship
Author: hlship
Date: Tue Apr 21 21:25:16 2009
New Revision: 767301

URL: http://svn.apache.org/viewvc?rev=767301&view=rev
Log:
TAP5-660: Type coercion from String to DateFormat will always coerce using the 
server's default locale, rather than the current per-thread locale

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java?rev=767301&r1=767300&r2=767301&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
 Tue Apr 21 21:25:16 2009
@@ -861,6 +861,9 @@
  @Builtin
  TypeCoercer coercer,
 
+ @Builtin
+ final ThreadLocale threadLocale,
+
  @Core
  final AssetSource assetSource)
 {
@@ -964,7 +967,7 @@
 {
 public DateFormat coerce(String input)
 {
-return new SimpleDateFormat(input);
+return new SimpleDateFormat(input, threadLocale.getLocale());
 }
 });
 




[jira] Closed: (TAP5-660) Type coercion from String to DateFormat will always coerce using the server's default locale, rather than the current per-thread locale

2009-04-21 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-660.
-

   Resolution: Fixed
Fix Version/s: 5.1.0.4

> Type coercion from String to DateFormat will always coerce using the server's 
> default locale, rather than the current per-thread locale
> ---
>
> Key: TAP5-660
> URL: https://issues.apache.org/jira/browse/TAP5-660
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.4, 5.0.18
>Reporter: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.1.0.4
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (TAP5-661) Documentation typos

2009-04-21 Thread Martin Strand (JIRA)
Documentation typos
---

 Key: TAP5-661
 URL: https://issues.apache.org/jira/browse/TAP5-661
 Project: Tapestry 5
  Issue Type: Improvement
  Components: documentation
Affects Versions: 5.1.0.4
Reporter: Martin Strand
Priority: Trivial
 Attachments: docs.patch

Patch for a few typos and broken links in the documentation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (TAP5-661) Documentation typos

2009-04-21 Thread Martin Strand (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Strand updated TAP5-661:
---

Attachment: docs.patch

> Documentation typos
> ---
>
> Key: TAP5-661
> URL: https://issues.apache.org/jira/browse/TAP5-661
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 5.1.0.4
>Reporter: Martin Strand
>Priority: Trivial
> Attachments: docs.patch
>
>
> Patch for a few typos and broken links in the documentation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.