[jira] [Comment Edited] (TAP5-2067) Error loading classes with Tomcat 7 parallel deployment
[
https://issues.apache.org/jira/browse/TAP5-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605618#comment-13605618
]
Kalle Korhonen edited comment on TAP5-2067 at 3/22/13 3:58 AM:
---
Finally stumbled upon the the cause of different behaviors we are seeing.
Anybody requiring parallel development can just use Maven war plugin's
archiveClasses feature or similar (see
http://maven.apache.org/plugins/maven-war-plugin/faq.html) as a workaround. If
you *don't* archive classes in a jar, you'll see this failure in a parallel
deployment environment. The issue is already addressed by TAP5-1995, to be
included in T5.3.7.
was (Author: kaosko):
Finally stumbled upon the the cause of different behaviors we are seeing.
Anybody requiring parallel development can just use Maven war plugin's
archiveClasses feature or similar (see
http://maven.apache.org/plugins/maven-war-plugin/faq.html) as a workaround. If
you *don't* archive classes in a jar, you'll see this failure in a parallel
deployment environment. I'll assign the issue to myself.
> Error loading classes with Tomcat 7 parallel deployment
> ---
>
> Key: TAP5-2067
> URL: https://issues.apache.org/jira/browse/TAP5-2067
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6
>Reporter: Pavel
>Assignee: Kalle Korhonen
> Fix For: 5.3.7
>
>
> When trying to deploy tapestry app using tomcat 7 parallel deployment (which
> demands to name app dir like myapp##version) there is an
> FileNotFoundException when loading AppModule file. The reason is, that path
> to app dir gets urlencoded whith those ## looking like %23%23.
> In PlasticInternalUtils there is already code dealing with urlencoded spaces
> private static InputStream getStreamForPath(
> if (url.getProtocol().equals("file"))
> {
> String urlPath = url.getPath();
> String decoded = urlPath.replaceAll("%20", " ");
> return new FileInputStream(new File(decoded));
> }
> could it be extended (or better generalised) to handle all urlencoded
> problems? I think it is really easy to fix and is very annoying not being
> able to use parallel deployment. I could even provide a patch if you think
> this issue is worth fixing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TAP5-2067) Error loading classes with Tomcat 7 parallel deployment
[
https://issues.apache.org/jira/browse/TAP5-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2067.
--
Resolution: Fixed
Fix Version/s: 5.3.7
> Error loading classes with Tomcat 7 parallel deployment
> ---
>
> Key: TAP5-2067
> URL: https://issues.apache.org/jira/browse/TAP5-2067
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6
>Reporter: Pavel
>Assignee: Kalle Korhonen
> Fix For: 5.3.7
>
>
> When trying to deploy tapestry app using tomcat 7 parallel deployment (which
> demands to name app dir like myapp##version) there is an
> FileNotFoundException when loading AppModule file. The reason is, that path
> to app dir gets urlencoded whith those ## looking like %23%23.
> In PlasticInternalUtils there is already code dealing with urlencoded spaces
> private static InputStream getStreamForPath(
> if (url.getProtocol().equals("file"))
> {
> String urlPath = url.getPath();
> String decoded = urlPath.replaceAll("%20", " ");
> return new FileInputStream(new File(decoded));
> }
> could it be extended (or better generalised) to handle all urlencoded
> problems? I think it is really easy to fix and is very annoying not being
> able to use parallel deployment. I could even provide a patch if you think
> this issue is worth fixing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TAP5-2098) JSONObject should keep its properties in the order in which they were added
[ https://issues.apache.org/jira/browse/TAP5-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship resolved TAP5-2098. Resolution: Invalid I'm not sure what it has to do with pretty printing, but we're not going to add new functionality on top of JSON's rather precise specification. Doing so will cause more harm, as people in the Tapestry world will expect that functionality even when receiving JSON from other sources. > JSONObject should keep its properties in the order in which they were added > --- > > Key: TAP5-2098 > URL: https://issues.apache.org/jira/browse/TAP5-2098 > Project: Tapestry 5 > Issue Type: Wish > Components: tapestry-json >Affects Versions: 5.3, 5.4 >Reporter: Jochen Kemnade >Priority: Minor > Labels: json, patch > > While JSON objects are unordered according to the specification, it would be > nice if Tapestry's implementation kept its properties in the order of their > insertion. That way, it could be used for pretty-printing more easily. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2098) JSONObject should keep its properties in the order in which they were added
Jochen Kemnade created TAP5-2098: Summary: JSONObject should keep its properties in the order in which they were added Key: TAP5-2098 URL: https://issues.apache.org/jira/browse/TAP5-2098 Project: Tapestry 5 Issue Type: Wish Components: tapestry-json Affects Versions: 5.3, 5.4 Reporter: Jochen Kemnade Priority: Minor While JSON objects are unordered according to the specification, it would be nice if Tapestry's implementation kept its properties in the order of their insertion. That way, it could be used for pretty-printing more easily. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
