[jira] [Commented] (TAP5-1803) URL encoding in ActivationRequestParameter is very strict
[ https://issues.apache.org/jira/browse/TAP5-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381042#comment-15381042 ] Kalle Korhonen commented on TAP5-1803: -- I agree with Jochen on both counts: I think we should remove the safe character check and change the request parameter handling to use URLEncoder. > URL encoding in ActivationRequestParameter is very strict > - > > Key: TAP5-1803 > URL: https://issues.apache.org/jira/browse/TAP5-1803 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.1, 5.4 >Reporter: David Canteros > Labels: @ActivationRequestParameter, InvalidaArgumenteException, > URLEncoder,, desired_for_5.5 > > The URLEncoder that perform the URL encoding process does not include the > following "unreserved characters" : > ! ~ * ' ( ) > (see rfc2396 Uniform Resource Identifiers (URI): Generic Syntax, item 2.3) > > Because the fix of TAP5-1768, from v5.3.1 the @ActivationRequestParameter > requires this enconding, which becomes incompatible with the standard. > Thus, any URL which contains those symbols will throw an > InvalidaArgumenteException. Tapestry should consider that the > ActivationRequestParameter is a standar way of parameter sending, and the > parameters sent in this way probably not have the "strict" coding process of > the URLEncoder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2556) Upgrade Hibernate to 5.1 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2556. -- Resolution: Fixed > Upgrade Hibernate to 5.1 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > Hibernate 5.1 is Java 8 only. There are issues upgrading to 5.2. Basically I > gave up and upgraded to 5.1 because that worked without additional changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2556) Upgrade Hibernate to 5.1 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2556: - Description: Hibernate 5.1 is Java 8 only. There are issues upgrading to 5.2. Basically I gave up and upgraded to 5.1 because that worked without additional changes. (was: Hibernate 5.2 is Java 8 only.) > Upgrade Hibernate to 5.1 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > Hibernate 5.1 is Java 8 only. There are issues upgrading to 5.2. Basically I > gave up and upgraded to 5.1 because that worked without additional changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2556) Upgrade Hibernate to 5.1 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2556: - Summary: Upgrade Hibernate to 5.1 for T5.5 (was: Upgrade Hibernate to 5.2 for T5.5) > Upgrade Hibernate to 5.1 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > Hibernate 5.2 is Java 8 only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2556) Upgrade Hibernate to 5.2 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376020#comment-15376020 ] Kalle Korhonen commented on TAP5-2556: -- Yeah totally, sorry. Somehow totally botched this up while I was working on multiple things in parallel. I already wrote the fix for the upgrade but committed it to tynamo instead... will fix. > Upgrade Hibernate to 5.2 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > Hibernate 5.2 is Java 8 only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2556) Upgrade Hibernate to 5.2 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2556. -- Resolution: Fixed Fix Version/s: 5.5.0 > Upgrade Hibernate to 5.2 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > Hibernate 5.2 is Java 8 only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2554) Using Confirm mixin in conjunction with an EventLink or ActionLink having "async" set to true causes double invocation of event handler
[ https://issues.apache.org/jira/browse/TAP5-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2554. -- Resolution: Fixed Fix Version/s: 5.5.0 Applied without changes, thanks! > Using Confirm mixin in conjunction with an EventLink or ActionLink having > "async" set to true causes double invocation of event handler > --- > > Key: TAP5-2554 > URL: https://issues.apache.org/jira/browse/TAP5-2554 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: I D >Assignee: Kalle Korhonen > Fix For: 5.5.0 > > > The first invocation is via ajax and the second one is synchronous (i.e. the > page is fully reloaded). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2556) Upgrade Hibernate to 5.2 for T5.5
Kalle Korhonen created TAP5-2556: Summary: Upgrade Hibernate to 5.2 for T5.5 Key: TAP5-2556 URL: https://issues.apache.org/jira/browse/TAP5-2556 Project: Tapestry 5 Issue Type: Dependency upgrade Components: tapestry-hibernate Reporter: Kalle Korhonen Hibernate 5.2 is Java 8 only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2556) Upgrade Hibernate to 5.2 for T5.5
[ https://issues.apache.org/jira/browse/TAP5-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2556: Assignee: Kalle Korhonen > Upgrade Hibernate to 5.2 for T5.5 > - > > Key: TAP5-2556 > URL: https://issues.apache.org/jira/browse/TAP5-2556 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-hibernate >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > > Hibernate 5.2 is Java 8 only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2115) Document how the hibernate session is implemented
[
https://issues.apache.org/jira/browse/TAP5-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-2115:
Assignee: Kalle Korhonen
> Document how the hibernate session is implemented
> -
>
> Key: TAP5-2115
> URL: https://issues.apache.org/jira/browse/TAP5-2115
> Project: Tapestry 5
> Issue Type: Documentation
> Components: documentation, tapestry-hibernate
>Reporter: Lance
>Assignee: Kalle Korhonen
>Priority: Minor
> Labels: documentation, hibernate
>
> There have been many questions on the user's list about how the hibernate
> session is implemented in tapestry-hibernate and also how to use
> tapestry-hibernate outside of a tapestry managed request / response.
> I think that the documentation should mention the following:
> 1. The hibernate session service provided by tapestry-hibernate is a singleton
> 2. The singleton is a proxy that points to a per-thread, lazy loaded
> hibernate session instance
> 3. The per-thread session instance is cleaned up by Registry.cleanupThread() /
> PerThreadManager.cleanup()
> 4. Tapestry automatically cleans up the thread local inside the normal
> request / response flow
> 5. Outside of a tapestry managed request / response, you must explicitly
> cleanup the thread
> 6. Transaction management outside of a request/response flow
>a. @CommitAfter and @Match("*DAO") with HibernateTransactionAdvisor
>b. HibernateSessionManager.commit() and abort()
>c. session.getTransaction().commit()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TAP5-2554) Using Confirm mixin in conjunction with an EventLink or ActionLink having "async" set to true causes double invocation of event handler
[ https://issues.apache.org/jira/browse/TAP5-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2554: Assignee: Kalle Korhonen > Using Confirm mixin in conjunction with an EventLink or ActionLink having > "async" set to true causes double invocation of event handler > --- > > Key: TAP5-2554 > URL: https://issues.apache.org/jira/browse/TAP5-2554 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: I D >Assignee: Kalle Korhonen > > The first invocation is via ajax and the second one is synchronous (i.e. the > page is fully reloaded). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2555) Add an okClass parameter to Confirm mixin
[ https://issues.apache.org/jira/browse/TAP5-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2555. -- Resolution: Fixed Assignee: Kalle Korhonen Fix Version/s: 5.5.0 Applied without changes, thanks! > Add an okClass parameter to Confirm mixin > - > > Key: TAP5-2555 > URL: https://issues.apache.org/jira/browse/TAP5-2555 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: I D >Assignee: Kalle Korhonen >Priority: Minor > Fix For: 5.5.0 > > > The confirm-click script module references an option named "okClass" and > renders it as the class of the ok button in the dialog. This can be very > useful, in case we want to later attach a js listener to the click of this > button (without this there is no way to create a css selector that uniquely > identifies the ok button of a specific "Confirm" dialog). > However, it seems as though on the server side code, someone forgot to take > this value as a parameter, and then pass it along to the client-side > runDialog function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2553) Support pseudo nested JPA transactions, injectable entity listeners and pre/post commit hooks
[ https://issues.apache.org/jira/browse/TAP5-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2553: - Summary: Support pseudo nested JPA transactions, injectable entity listeners and pre/post commit hooks (was: Support pseudo nested JPA transactions and pre/post commit hooks) > Support pseudo nested JPA transactions, injectable entity listeners and > pre/post commit hooks > - > > Key: TAP5-2553 > URL: https://issues.apache.org/jira/browse/TAP5-2553 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Labels: jpa > Fix For: 5.5.0 > > > Plain JPA does not support nested transaction but by keeping track of > @CommitAfter stack, we can support "pseudo nested" transactions. The concept > was first demonstrated in > https://github.com/satago/tapestry-jpa-transactions. @kaosko started an > effort to merge the codebase to T5 > (https://github.com/satago/tapestry-jpa-transactions/pull/5) but because of > fundamental limitations in the original design (no support for multiple > persistence units, pre/post commit hooks were only available for the last > transaction), @kaosko refactored the implementation for more general use > (https://github.com/kaosko/tapestry-jpa-transactions). The original code was > under Apache license with support from the original authors to merge the > codebase to T5 and the refactored implementation was solely made by @kaosko. > This issue is about merging the refactored implementation to T5.5 and > replacing the existing JPA classes (mainly class workers, advisors) by the > those provided by the new implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2553) Support pseudo nested JPA transactions and pre/post commit hooks
[ https://issues.apache.org/jira/browse/TAP5-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2553: - Fix Version/s: 5.5.0 > Support pseudo nested JPA transactions and pre/post commit hooks > > > Key: TAP5-2553 > URL: https://issues.apache.org/jira/browse/TAP5-2553 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Labels: jpa > Fix For: 5.5.0 > > > Plain JPA does not support nested transaction but by keeping track of > @CommitAfter stack, we can support "pseudo nested" transactions. The concept > was first demonstrated in > https://github.com/satago/tapestry-jpa-transactions. @kaosko started an > effort to merge the codebase to T5 > (https://github.com/satago/tapestry-jpa-transactions/pull/5) but because of > fundamental limitations in the original design (no support for multiple > persistence units, pre/post commit hooks were only available for the last > transaction), @kaosko refactored the implementation for more general use > (https://github.com/kaosko/tapestry-jpa-transactions). The original code was > under Apache license with support from the original authors to merge the > codebase to T5 and the refactored implementation was solely made by @kaosko. > This issue is about merging the refactored implementation to T5.5 and > replacing the existing JPA classes (mainly class workers, advisors) by the > those provided by the new implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2553) Support pseudo nested JPA transactions and pre/post commit hooks
[ https://issues.apache.org/jira/browse/TAP5-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2553: Assignee: Kalle Korhonen > Support pseudo nested JPA transactions and pre/post commit hooks > > > Key: TAP5-2553 > URL: https://issues.apache.org/jira/browse/TAP5-2553 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Labels: jpa > > Plain JPA does not support nested transaction but by keeping track of > @CommitAfter stack, we can support "pseudo nested" transactions. The concept > was first demonstrated in > https://github.com/satago/tapestry-jpa-transactions. @kaosko started an > effort to merge the codebase to T5 > (https://github.com/satago/tapestry-jpa-transactions/pull/5) but because of > fundamental limitations in the original design (no support for multiple > persistence units, pre/post commit hooks were only available for the last > transaction), @kaosko refactored the implementation for more general use > (https://github.com/kaosko/tapestry-jpa-transactions). The original code was > under Apache license with support from the original authors to merge the > codebase to T5 and the refactored implementation was solely made by @kaosko. > This issue is about merging the refactored implementation to T5.5 and > replacing the existing JPA classes (mainly class workers, advisors) by the > those provided by the new implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2553) Support pseudo nested JPA transactions and pre/post commit hooks
Kalle Korhonen created TAP5-2553: Summary: Support pseudo nested JPA transactions and pre/post commit hooks Key: TAP5-2553 URL: https://issues.apache.org/jira/browse/TAP5-2553 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-jpa Affects Versions: 5.4.1 Reporter: Kalle Korhonen Plain JPA does not support nested transaction but by keeping track of @CommitAfter stack, we can support "pseudo nested" transactions. The concept was first demonstrated in https://github.com/satago/tapestry-jpa-transactions. @kaosko started an effort to merge the codebase to T5 (https://github.com/satago/tapestry-jpa-transactions/pull/5) but because of fundamental limitations in the original design (no support for multiple persistence units, pre/post commit hooks were only available for the last transaction), @kaosko refactored the implementation for more general use (https://github.com/kaosko/tapestry-jpa-transactions). The original code was under Apache license with support from the original authors to merge the codebase to T5 and the refactored implementation was solely made by @kaosko. This issue is about merging the refactored implementation to T5.5 and replacing the existing JPA classes (mainly class workers, advisors) by the those provided by the new implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2544) Using JPA EntityManager without explicit @PersistenceContext fails
[ https://issues.apache.org/jira/browse/TAP5-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2544. -- Resolution: Fixed Fix Version/s: 5.4.2 5.5.0 > Using JPA EntityManager without explicit @PersistenceContext fails > -- > > Key: TAP5-2544 > URL: https://issues.apache.org/jira/browse/TAP5-2544 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > Fix For: 5.5.0, 5.4.2 > > > The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and > unreleased 5.5.x). As a workaround use 5.4.0 tapestry-jpa when you only have > a single EntityManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2544) Using JPA EntityManager without explicit @PersistenceContext fails
[ https://issues.apache.org/jira/browse/TAP5-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2544: - Summary: Using JPA EntityManager without explicit @PersistenceContext fails (was: Using JPA EntityManager without explicit @PersistentContext fails) > Using JPA EntityManager without explicit @PersistenceContext fails > -- > > Key: TAP5-2544 > URL: https://issues.apache.org/jira/browse/TAP5-2544 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > > The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and > unreleased 5.5.x). As a workaround use 5.4.0 tapestry-jpa when you only have > a single EntityManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2544) Using JPA EntityManager without explicit @PersistentContext fails
[ https://issues.apache.org/jira/browse/TAP5-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2544: - Description: The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and unreleased 5.5.x). As a workaround use 5.4.0 tapestry-jpa when you only have a single EntityManager. (was: The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and unreleased 5.5.x).) > Using JPA EntityManager without explicit @PersistentContext fails > - > > Key: TAP5-2544 > URL: https://issues.apache.org/jira/browse/TAP5-2544 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > > The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and > unreleased 5.5.x). As a workaround use 5.4.0 tapestry-jpa when you only have > a single EntityManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2544) Using JPA EntityManager without explicit @PersistentContext fails
[ https://issues.apache.org/jira/browse/TAP5-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2544: Assignee: Kalle Korhonen > Using JPA EntityManager without explicit @PersistentContext fails > - > > Key: TAP5-2544 > URL: https://issues.apache.org/jira/browse/TAP5-2544 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.4.1 >Reporter: Kalle Korhonen >Assignee: Kalle Korhonen > > The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and > unreleased 5.5.x). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2544) Using JPA EntityManager without explicit @PersistentContext fails
Kalle Korhonen created TAP5-2544: Summary: Using JPA EntityManager without explicit @PersistentContext fails Key: TAP5-2544 URL: https://issues.apache.org/jira/browse/TAP5-2544 Project: Tapestry 5 Issue Type: Bug Components: tapestry-jpa Affects Versions: 5.4.1 Reporter: Kalle Korhonen The issue was caused by a fix to TAP5-2027 and only affects 5.4.1 (and unreleased 5.5.x). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-1918) RenderInformals mixin doesn't always work as expected
[
https://issues.apache.org/jira/browse/TAP5-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194908#comment-15194908
]
Kalle Korhonen commented on TAP5-1918:
--
I unassigned myself but Lance's suggestion still seems reasonable to me. We can
just throw an exception if there are no children.
> RenderInformals mixin doesn't always work as expected
> -
>
> Key: TAP5-1918
> URL: https://issues.apache.org/jira/browse/TAP5-1918
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.1, 5.3.2, 5.3.3, 5.4
>Reporter: Lance
>Priority: Minor
>
> The following code:
> {code}
>
>data-foo="bar" />
>
> {code}
> Results in the following HTML:
> {code}
>
>
>
> {code}
> As you can see, the informal parameter was added to the div instead of the
> form.
> The current implementation of RenderInformals assumes that a component has
> populated the MarkupWriter with an element in beginRender() which is not
> always the case. I think it should be changed to use an afterRender() method
> and add informals to the current element's last child.
> eg:
> {code}
> @MixinAfter
> @SupportsInformalParameters
> public class RenderInformals
> {
>@Inject
>private ComponentResources resources;
>
>void afterRender(MarkupWriter writer)
>{
> List children = writer.getElement().getChildren();
> if (!children.isEmpty()) {
> Element lastChild = (Element) children.get(children.size() - 1);
> for (String name : resources.getInformalParameterNames()) {
> lastChild.attribute(name, resources.getInformalParameter(name,
> String.class));
> }
> }
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TAP5-1918) RenderInformals mixin doesn't always work as expected
[
https://issues.apache.org/jira/browse/TAP5-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-1918:
Assignee: (was: Kalle Korhonen)
> RenderInformals mixin doesn't always work as expected
> -
>
> Key: TAP5-1918
> URL: https://issues.apache.org/jira/browse/TAP5-1918
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.1, 5.3.2, 5.3.3, 5.4
>Reporter: Lance
>Priority: Minor
>
> The following code:
> {code}
>
>data-foo="bar" />
>
> {code}
> Results in the following HTML:
> {code}
>
>
>
> {code}
> As you can see, the informal parameter was added to the div instead of the
> form.
> The current implementation of RenderInformals assumes that a component has
> populated the MarkupWriter with an element in beginRender() which is not
> always the case. I think it should be changed to use an afterRender() method
> and add informals to the current element's last child.
> eg:
> {code}
> @MixinAfter
> @SupportsInformalParameters
> public class RenderInformals
> {
>@Inject
>private ComponentResources resources;
>
>void afterRender(MarkupWriter writer)
>{
> List children = writer.getElement().getChildren();
> if (!children.isEmpty()) {
> Element lastChild = (Element) children.get(children.size() - 1);
> for (String name : resources.getInformalParameterNames()) {
> lastChild.attribute(name, resources.getInformalParameter(name,
> String.class));
> }
> }
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2027. -- Resolution: Fixed The fix should address the issue. Let the committers know if this is still desired for T5.3. As ugly as the original implementation was, I'd still see this as a marginal case and therefore not critical for T5.3. > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6, 5.4 >Reporter: John Coleman >Assignee: Kalle Korhonen > Fix For: 5.4.1 > > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2027: - Fix Version/s: 5.4.1 > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6, 5.4 >Reporter: John Coleman >Assignee: Kalle Korhonen > Fix For: 5.4.1 > > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2027: - Affects Version/s: 5.4 > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6, 5.4 >Reporter: John Coleman >Assignee: Kalle Korhonen > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194294#comment-15194294 ] Kalle Korhonen commented on TAP5-2027: -- Issue affects 5.4 as well. We can still use a cached proxy member but it should be a map keyed by the entityName instead of a single EntityManager instance. > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6, 5.4 >Reporter: John Coleman >Assignee: Kalle Korhonen > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2027: - Labels: (was: bulk-close-candidate) > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6, 5.4 >Reporter: John Coleman >Assignee: Kalle Korhonen > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2499) Race condition in EntityManagerSource#getEntityManagerFactory
[
https://issues.apache.org/jira/browse/TAP5-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2499.
--
Resolution: Fixed
Fix Version/s: 5.4.1
> Race condition in EntityManagerSource#getEntityManagerFactory
> -
>
> Key: TAP5-2499
> URL: https://issues.apache.org/jira/browse/TAP5-2499
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.4, 5.3.8
>Reporter: Dmitry Gusev
>Assignee: Kalle Korhonen
> Fix For: 5.4.1
>
>
> On application start if more than one thread needs an entity manager more
> than one instance of EntityManagerFactory may be created.
> This is undesirable, because EMF may use a connection pool and creating more
> than one instance will lead to too many open database connections.
> EntityManagerSourceImpl.java:
> {code}
> public EntityManagerFactory getEntityManagerFactory(final String
> persistenceUnitName)
> {
> EntityManagerFactory emf =
> entityManagerFactories.get(persistenceUnitName);
> if (emf == null)
> {
> emf = createEntityManagerFactory(persistenceUnitName);
> entityManagerFactories.put(persistenceUnitName, emf);
> }
> return emf;
> }
> {code}
> Above code needs some synchronization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TAP5-2525) Tapestry-Hibernate integration incompatible with Hibernate 5.x
[
https://issues.apache.org/jira/browse/TAP5-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2525.
--
Resolution: Fixed
Fix Version/s: 5.4.1
> Tapestry-Hibernate integration incompatible with Hibernate 5.x
> --
>
> Key: TAP5-2525
> URL: https://issues.apache.org/jira/browse/TAP5-2525
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-hibernate
>Affects Versions: 5.4
>Reporter: I D
>Assignee: Kalle Korhonen
> Fix For: 5.4.1
>
>
> The following exception is thrown when attempting to start up tapestry with
> the latest stable version of Hibernate (5.0.6.Final):
> {code:java}
> java.lang.NoSuchMethodError:
> org.hibernate.cfg.Configuration.getClassMappings()Ljava/util/Iterator;
> at
> org.apache.tapestry5.hibernate.modules.HibernateModule.contributeValueEncoderSource(HibernateModule.java:95)
> ~[tapestry-hibernate-5.4.0.jar:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> ~[na:1.8.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> ~[na:1.8.0_60]
> at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.8.0_60]
> at
> org.apache.tapestry5.ioc.internal.ContributionDefImpl.invokeMethod(ContributionDefImpl.java:125)
> ~[tapestry-ioc-5.4.0.jar:na]
> {code}
> That is due to the fact that getClassMappings() was removed from
> org.hibernate.cfg.Configuration in Hibernate 5.
> Luckily, it isn't really needed, and there is a backwards compatible way to
> do without it. I.e., tapestry can easily become compatible with Hibernate 5
> without breaking compatibility with Hibernate 3 and 4.
> I'll create a pull request on GitHub and link to it here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-1803) URL encoding in ActivationRequestParameter is very strict
[ https://issues.apache.org/jira/browse/TAP5-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194095#comment-15194095 ] Kalle Korhonen commented on TAP5-1803: -- Replacing the URLEncoderImpl with a custom implementation has been one of the first tasks in most real world projects I've been involved in - the built-in one really doesn't give a reasonable default behavior IMHO. I agree with Jochen, just skipping the safe set check when decoding seem like a good, common sense improvement. > URL encoding in ActivationRequestParameter is very strict > - > > Key: TAP5-1803 > URL: https://issues.apache.org/jira/browse/TAP5-1803 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.1, 5.4 >Reporter: David Canteros > Labels: @ActivationRequestParameter, InvalidaArgumenteException, > URLEncoder, > > The URLEncoder that perform the URL encoding process does not include the > following "unreserved characters" : > ! ~ * ' ( ) > (see rfc2396 Uniform Resource Identifiers (URI): Generic Syntax, item 2.3) > > Because the fix of TAP5-1768, from v5.3.1 the @ActivationRequestParameter > requires this enconding, which becomes incompatible with the standard. > Thus, any URL which contains those symbols will throw an > InvalidaArgumenteException. Tapestry should consider that the > ActivationRequestParameter is a standar way of parameter sending, and the > parameters sent in this way probably not have the "strict" coding process of > the URLEncoder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2525) Tapestry-Hibernate integration incompatible with Hibernate 5.x
[
https://issues.apache.org/jira/browse/TAP5-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-2525:
Assignee: Kalle Korhonen
> Tapestry-Hibernate integration incompatible with Hibernate 5.x
> --
>
> Key: TAP5-2525
> URL: https://issues.apache.org/jira/browse/TAP5-2525
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-hibernate
>Affects Versions: 5.4
>Reporter: I D
>Assignee: Kalle Korhonen
>
> The following exception is thrown when attempting to start up tapestry with
> the latest stable version of Hibernate (5.0.6.Final):
> {code:java}
> java.lang.NoSuchMethodError:
> org.hibernate.cfg.Configuration.getClassMappings()Ljava/util/Iterator;
> at
> org.apache.tapestry5.hibernate.modules.HibernateModule.contributeValueEncoderSource(HibernateModule.java:95)
> ~[tapestry-hibernate-5.4.0.jar:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> ~[na:1.8.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> ~[na:1.8.0_60]
> at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.8.0_60]
> at
> org.apache.tapestry5.ioc.internal.ContributionDefImpl.invokeMethod(ContributionDefImpl.java:125)
> ~[tapestry-ioc-5.4.0.jar:na]
> {code}
> That is due to the fact that getClassMappings() was removed from
> org.hibernate.cfg.Configuration in Hibernate 5.
> Luckily, it isn't really needed, and there is a backwards compatible way to
> do without it. I.e., tapestry can easily become compatible with Hibernate 5
> without breaking compatibility with Hibernate 3 and 4.
> I'll create a pull request on GitHub and link to it here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TAP5-2499) Race condition in EntityManagerSource#getEntityManagerFactory
[
https://issues.apache.org/jira/browse/TAP5-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-2499:
Assignee: Kalle Korhonen
> Race condition in EntityManagerSource#getEntityManagerFactory
> -
>
> Key: TAP5-2499
> URL: https://issues.apache.org/jira/browse/TAP5-2499
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.4, 5.3.8
>Reporter: Dmitry Gusev
>Assignee: Kalle Korhonen
>
> On application start if more than one thread needs an entity manager more
> than one instance of EntityManagerFactory may be created.
> This is undesirable, because EMF may use a connection pool and creating more
> than one instance will lead to too many open database connections.
> EntityManagerSourceImpl.java:
> {code}
> public EntityManagerFactory getEntityManagerFactory(final String
> persistenceUnitName)
> {
> EntityManagerFactory emf =
> entityManagerFactories.get(persistenceUnitName);
> if (emf == null)
> {
> emf = createEntityManagerFactory(persistenceUnitName);
> entityManagerFactories.put(persistenceUnitName, emf);
> }
> return emf;
> }
> {code}
> Above code needs some synchronization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[ https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2027: Assignee: Kalle Korhonen > EntityManagerObjectProvider always provides the initial EntityManger proxy > created > -- > > Key: TAP5-2027 > URL: https://issues.apache.org/jira/browse/TAP5-2027 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-jpa >Affects Versions: 5.3.5, 5.3.6 >Reporter: John Coleman >Assignee: Kalle Korhonen > Labels: patch > Attachments: TapestryJPATest.zip > > > When persistence.xml defines multiple persistence units, classes injecting > EntityManager with @PersistenceContext(unitName=value crash because the > entities associated with the PU in configuration are not recognised at > runtime. > By placing trace in the code I established that the first EntityManager > injected gets injected to all my other service classes even though I use > different unitName= annotations. > The EntityManagerObjectProvider class contains a class variable proxy and > works like a singleton always injecting the first EntityManager proxy class > created for any later EntityManager injections. > The following code fixes the issue and is provided as-is, free and without > copyright or warranty. This is more like a refactor because I have also > replaced some depricated code. As a patch it also works just to remove the > proxy class member variable and the if (proxy == null) condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[ https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988415#comment-14988415 ] Kalle Korhonen commented on TAP5-2509: -- I run into this as well while updating Tynamo's tapestry-model for T5.4. We are rendering dynamic form control blocks and while I can work around this issue, a "for" parameter is not required for (HTML) label. I'm not sure why TAP5-2500 forced this change? > Regression with radiogroup label in 5.4-beta-37 > --- > > Key: TAP5-2509 > URL: https://issues.apache.org/jira/browse/TAP5-2509 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-radiogrouplabel.zip > > > Having a label for a radio group fails in 5.4 beta 37, while it works up > until beta-36. > The error is: > Render queue error in AfterRender[Index:form]: The field has returned a null > client-side ID > See the attached project for an example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2482) BeanEditForm field name regression introduced with 5.4-beta-31
[
https://issues.apache.org/jira/browse/TAP5-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14717971#comment-14717971
]
Kalle Korhonen commented on TAP5-2482:
--
Unless Howard provides more reasoning as to why this change is needed, I'd vote
for rolling it back. Howard had added the following comments in the release
notes as part of the issue:
As before, the id is made unique with an optional numeric suffix; however with
this change it is possible, in some complex Ajax-related cases (involving
FormFragment or FormInjector components) for there to be name collisions that
were not possible before.
Implying this change may cause issues later on.
BeanEditForm field name regression introduced with 5.4-beta-31
--
Key: TAP5-2482
URL: https://issues.apache.org/jira/browse/TAP5-2482
Project: Tapestry 5
Issue Type: Bug
Affects Versions: 5.4
Reporter: Balázs Palcsó
Labels: 54_release_prerequisite
Issue started with: 5.4-beta-31
Last working release: 5.4-beta-30
I have the below BeanEditForm
{code}
t:beaneditor t:object=user
include=username,lastName,firstName,email,phone,password,confirmPassword
p:username
div class=form-group
t:label for=username /
t:textfield t:id=username value=user.username
t:mixins=OverrideFieldFocus /
/div
/p:username
p:password
div class=form-group
t:label for=password /
t:passwordfield t:id=password value=user.password
/
/div
/p:password
p:confirmPassword
div class=form-group
t:label for=confirmPassword /
t:passwordfield t:id=confirmPassword
value=user.confirmPassword /
/div
/p:confirmPassword
/t:beaneditor
{code}
The {{name}} attribute of the input generated for each included fields were
matching the field name until 5.4-beta-31.
With 5.4-beta-31 the above form generates the following name attribute for
{{input /}} for
{{name=textField}} instead of {{name=lastName}}
{{name=textField_0}} instead of {{name=firstName}}
{{name=textField_1}} instead of {{name=phone}}
For username, email, password, confirmPassword correct name attributes are
generated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2462) Parent component should be able to reset a Grid regardless of its internal state
[ https://issues.apache.org/jira/browse/TAP5-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350591#comment-14350591 ] Kalle Korhonen commented on TAP5-2462: -- TAP5-2437 is the generic case, this was a fix just for the reset(). In any case though, now paginationModel can be both instantiated internally and passed as a parameter which is likely going to cause issues down the road. Parent component should be able to reset a Grid regardless of its internal state Key: TAP5-2462 URL: https://issues.apache.org/jira/browse/TAP5-2462 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Fix For: 5.4 Calling Grid.reset() from the parent component may result in NullPointerException: Caused by: java.lang.NullPointerException at org.apache.tapestry5.corelib.components.Grid.setCurrentPage(Grid.java:600) at org.apache.tapestry5.corelib.components.Grid.reset(Grid.java:636) at org.tynamo.examples.simple.pages.List.resetGrid(List.java:83) at org.tynamo.examples.simple.pages.List.setupRender(List.java) The issue is that setCurrentPage(1) on Grid.reset() is really unnecessary or at least should be after sortModel.clear(); (lines 636-637) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TAP5-2462) Parent component should be able to reset a Grid regardless of its internal state
[ https://issues.apache.org/jira/browse/TAP5-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2462: Assignee: Kalle Korhonen Parent component should be able to reset a Grid regardless of its internal state Key: TAP5-2462 URL: https://issues.apache.org/jira/browse/TAP5-2462 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Calling Grid.reset() from the parent component may result in NullPointerException: Caused by: java.lang.NullPointerException at org.apache.tapestry5.corelib.components.Grid.setCurrentPage(Grid.java:600) at org.apache.tapestry5.corelib.components.Grid.reset(Grid.java:636) at org.tynamo.examples.simple.pages.List.resetGrid(List.java:83) at org.tynamo.examples.simple.pages.List.setupRender(List.java) The issue is that setCurrentPage(1) on Grid.reset() is really unnecessary or at least should be after sortModel.clear(); (lines 636-637) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2462) Parent component should be able to reset a Grid regardless of its internal state
Kalle Korhonen created TAP5-2462: Summary: Parent component should be able to reset a Grid regardless of its internal state Key: TAP5-2462 URL: https://issues.apache.org/jira/browse/TAP5-2462 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Kalle Korhonen Calling Grid.reset() from the parent component may result in NullPointerException: Caused by: java.lang.NullPointerException at org.apache.tapestry5.corelib.components.Grid.setCurrentPage(Grid.java:600) at org.apache.tapestry5.corelib.components.Grid.reset(Grid.java:636) at org.tynamo.examples.simple.pages.List.resetGrid(List.java:83) at org.tynamo.examples.simple.pages.List.setupRender(List.java) The issue is that setCurrentPage(1) on Grid.reset() is really unnecessary or at least should be after sortModel.clear(); (lines 636-637) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2462) Parent component should be able to reset a Grid regardless of its internal state
[ https://issues.apache.org/jira/browse/TAP5-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2462. -- Resolution: Fixed Fix Version/s: 5.4 Parent component should be able to reset a Grid regardless of its internal state Key: TAP5-2462 URL: https://issues.apache.org/jira/browse/TAP5-2462 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Fix For: 5.4 Calling Grid.reset() from the parent component may result in NullPointerException: Caused by: java.lang.NullPointerException at org.apache.tapestry5.corelib.components.Grid.setCurrentPage(Grid.java:600) at org.apache.tapestry5.corelib.components.Grid.reset(Grid.java:636) at org.tynamo.examples.simple.pages.List.resetGrid(List.java:83) at org.tynamo.examples.simple.pages.List.setupRender(List.java) The issue is that setCurrentPage(1) on Grid.reset() is really unnecessary or at least should be after sortModel.clear(); (lines 636-637) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-2321: - Fix Version/s: 5.3.8 Tapestry 5.3.7 does not run with Java 8 --- Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Assignee: Kalle Korhonen Priority: Critical Fix For: 5.3.8 Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reopened TAP5-2321: -- Tapestry 5.3.7 does not run with Java 8 --- Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Assignee: Kalle Korhonen Priority: Critical Fix For: 5.3.8 Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2321. -- Resolution: Fixed Tapestry 5.3.7 does not run with Java 8 --- Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Assignee: Kalle Korhonen Priority: Critical Fix For: 5.3.8 Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TAP5-2396) DefaultExceptionHandler doesn't currently recognize TapestryException
[
https://issues.apache.org/jira/browse/TAP5-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2396.
--
Resolution: Fixed
Fix Version/s: 5.4
DefaultExceptionHandler doesn't currently recognize TapestryException
-
Key: TAP5-2396
URL: https://issues.apache.org/jira/browse/TAP5-2396
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Chris Mylonas
Assignee: Kalle Korhonen
Fix For: 5.4
TapestryException wraps around a custom exception when it happens at the
service layer (or maybe other places too, but it's affecting me at service
layer).
When I contributeRequestExceptionHandler with my FooterException I never
receive it. It is always TapestryException.
Link to nabble mailling list with sample:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/TapestryException-in-Inject-service-method-does-it-behave-like-component-action-exception-td5728680.html
Stacktrace from mailing list:
{noformat}
13:17:16.185 [277461231@qtp-209021619-0] ERROR
t.render.org.opencsta.pages.Index - Render queue error in
SetupRender[Index:layout.footercomponent]:
org.apache.tapestry5.ioc.internal.util.TapestryException
org.apache.tapestry5.ioc.internal.util.TapestryException: null
at
org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.invoke(ComponentPageElementImpl.java:155)
~[tapestry-core-5.4-beta-22.jar:na]
at
org.apache.tapestry5.internal.structure.ComponentPageElementImpl$SetupRenderPhase.render(ComponentPageElementImpl.java:183)
~[tapestry-core-5.4-beta-22.jar:na]
at
org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:79)
~[tapestry-core-5.4-beta-22.jar:na]
at
org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:114)
[tapestry-core-5.4-beta-22.jar:na]
at $PageRenderQueue_139b0aa8c6745330.render(Unknown Source) [na:na]
at $PageRenderQueue_139b0aa8c674532f.render(Unknown Source) [na:na]
at
org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
[tapestry-core-5.4-beta-22.jar:na]
at
org.apache.tapestry5.internal.services.PageNameMetaInjector.renderMarkup(PageNameMetaInjector.java:41)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.TapestryModule$29.renderMarkup(TapestryModule.java:1810)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.TapestryModule$28.renderMarkup(TapestryModule.java:1800)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.TapestryModule$27.renderMarkup(TapestryModule.java:1784)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.TapestryModule$26.renderMarkup(TapestryModule.java:1768)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.JavaScriptModule$1.renderMarkup(JavaScriptModule.java:259)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.modules.TapestryModule$25.renderMarkup(TapestryModule.java:1751)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.internal.services.javascript.AddBrowserCompatibilityStyles.renderMarkup(AddBrowserCompatibilityStyles.java:45)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.internal.services.javascript.ConfigureHTMLElementFilter.renderMarkup(ConfigureHTMLElementFilter.java:45)
[tapestry-core-5.4-beta-22.jar:na]
at $MarkupRenderer_139b0aa8c6745333.renderMarkup(Unknown Source) [na:na]
at $MarkupRenderer_139b0aa8c674532e.renderMarkup(Unknown Source) [na:na]
at
org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:47)
[tapestry-core-5.4-beta-22.jar:na]
at $PageMarkupRenderer_139b0aa8c674532c.renderPageMarkup(Unknown
Source) [na:na]
at
org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:64)
[jira] [Commented] (TAP5-2365) PlasticUtilsTests.Do not urlencode file paths fails when using openjdk7
[
https://issues.apache.org/jira/browse/TAP5-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14113511#comment-14113511
]
Kalle Korhonen commented on TAP5-2365:
--
Ah yes, tempFile is better or even just {code}new
File(webapp##01.test);{code}, I think that should create it in the
classloader root.
PlasticUtilsTests.Do not urlencode file paths fails when using openjdk7
-
Key: TAP5-2365
URL: https://issues.apache.org/jira/browse/TAP5-2365
Project: Tapestry 5
Issue Type: Bug
Components: plastic
Affects Versions: 5.4
Reporter: Felix Scheffer
Priority: Minor
PlasticUtilsTests.Do not urlencode file paths fails on Ubuntu 14.04 (using
openjdk7):
{code}
java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.init(File.java:418)
at org.apache.tapestry5.internal.plastic.PlasticUtilsTests.Do not
urlencode file paths(PlasticUtilsTests.groovy:28)
{code}
getClass().getClassLoader().getResource(.) returns
jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/
which is obvisiouly not the expected result.
I am not sure but I think pulse-java.jar was not part of openjdk6 in ealier
versions of Ubuntu. Removing pulse-java.jar solves the problem but I dont
think that's a good solution.
I think there are two issues here:
a) There's something wrong with pulse-java.jar even though I have absolutely
no clue what it is.
b) Calling getResource(.) looks like a hack to me. . is not a real
resource.
For more information on this issue:
-
http://stackoverflow.com/questions/16317789/thread-currentthread-getcontextclassloader-getresource-has-different-re
-
http://stackoverflow.com/questions/13901540/how-to-get-location-of-runnable-jar-file-when-run-from-gnome
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2346) use servletRequest.getLocales() rather than getLocale() to support second choice language options
[ https://issues.apache.org/jira/browse/TAP5-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14112481#comment-14112481 ] Kalle Korhonen commented on TAP5-2346: -- Yes, I'd assume we'd need to take the first locale from HttpServletRequest.getLocales() (which returns values from the accept-language header) that exactly matches with one of the supported locales, or fall back to the default supported if no exact match was found. use servletRequest.getLocales() rather than getLocale() to support second choice language options --- Key: TAP5-2346 URL: https://issues.apache.org/jira/browse/TAP5-2346 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Reporter: Robert Hailey Priority: Minor Labels: localization At the moment, Tapestry only considers a request's first locale choice, falling back to the default. It would be better, methinks, to iterate over the available choices (selecting the first supported) before falling back to the default. Note that it is still appropriate for Tapestry's Request object to have only getLocale(), as it will be the best fit from the request.getLocales(). http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-3-Localization-is-only-partially-implemented-td5726903.html http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getLocales%28%29 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2321. -- Resolution: Duplicate Assignee: Kalle Korhonen TAP5-2214 Was merged to 5.3 branch: commit a0ac605dbd89f543b0396d747f5909e1ba38205b Author: kaosko kao...@apache.org Date: Tue Mar 25 11:29:43 2014 -0700 FIXED - TAP5-2214: Make tapestry5 java8 compatible - update ASM source to 5.0.1, should be jdk 1.5 compatible, see ASM bug 317132 ASM 5.0 do not supported JDK 1.5? Tapestry 5.3.7 does not run with Java 8 --- Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Assignee: Kalle Korhonen Priority: Critical Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen closed TAP5-2321. Tapestry 5.3.7 does not run with Java 8 --- Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Assignee: Kalle Korhonen Priority: Critical Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2300. -- Resolution: Fixed Fix Version/s: 5.4 JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Fix For: 5.4 Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2300: Assignee: Kalle Korhonen JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946790#comment-13946790 ] Kalle Korhonen commented on TAP5-2214: -- That's caused by a change in Plastic rather than directly related to ASM version. createProxyTransformation is added to T5.3.x as well in 4a818e35585ac0860aaffa23bc0d1799514480da by Thiago as he backported TAP5-2029 to T5.3 but that's unreleased. Anyhow, perhaps easiest just to cherry pick the ASM 5 change to 5.3 as well. Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reopened TAP5-2214: -- Gah - as soon as I did this, of course ASM releases 5.0.1. I'll update to that version and merge to 5.3 Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2214. -- Resolution: Fixed Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947286#comment-13947286 ] Kalle Korhonen commented on TAP5-2300: -- Eh no, the problem is that the Initialization.with() still wraps the functionName and the parameters in a JSONArray. I haven't looked into backwards compatibility yet, but if it really is a regression, then I think it should be addressed on the server side rather than with Javascript. JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947313#comment-13947313 ] Kalle Korhonen commented on TAP5-2300: -- Ok, still ugly but better :) Perhaps this could be pushed down to the Initialization interface but I'll have to see what other changes it would cause. JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13942021#comment-13942021 ] Kalle Korhonen commented on TAP5-2214: -- Seems like this is just matter of applying the patch upgrade to ASM 5. Howard, this is currently assigned to you - do you want to take this on, or I can do it if you are busy. Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Howard M. Lewis Ship Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13942171#comment-13942171 ] Kalle Korhonen commented on TAP5-2214: -- The patch did not apply cleanly, and besides there's ASM 5.0 final release so I just used the official source from asm.ow2.org. No changes to the rest of Plastic source were required so I believe T5.3 uses could just use T5.4 plastic library once this is released (or build from source). Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2214. -- Resolution: Fixed Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13942171#comment-13942171 ] Kalle Korhonen edited comment on TAP5-2214 at 3/20/14 7:27 PM: --- The patch did not apply cleanly, and besides there's ASM 5.0 final release so I just used the official source from asm.ow2.org. No changes to the rest of Plastic source were required so I believe T5.3 uses could just use T5.4 plastic library once this is released (or build from source). Perhaps we should create a new version number (5.4.0?) to indicate difference between beta release and the final, or whatever we are targeting next. was (Author: kaosko): The patch did not apply cleanly, and besides there's ASM 5.0 final release so I just used the official source from asm.ow2.org. No changes to the rest of Plastic source were required so I believe T5.3 uses could just use T5.4 plastic library once this is released (or build from source). Make tapestry5 java8 compatible --- Key: TAP5-2214 URL: https://issues.apache.org/jira/browse/TAP5-2214 Project: Tapestry 5 Issue Type: Improvement Components: plastic Affects Versions: 5.4 Reporter: Joachim Van der Auwera Assignee: Kalle Korhonen Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch, plastic-5.3.7-mint-asm5-java8.jar As it stands Tapestry does not work on java8. This seems to be caused by ASM. Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TAP5-2267) Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken
[ https://issues.apache.org/jira/browse/TAP5-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2267: Assignee: Kalle Korhonen Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken - Key: TAP5-2267 URL: https://issues.apache.org/jira/browse/TAP5-2267 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Priority: Minor Attachments: TAP5-2267.patch DefaultRequestExceptionHandler fails with ClassCastException when an instance of ExceptionHandlerAssistant is contributed to RequestExceptionHandler. This had been broken accidentally in commit cb3d4c853f47cccf9193c33cfd085d6ca27c8706 when implementing contributions of assistant classes that are autobuilt. Although DefaultRequestExceptionHandlerTest covers contributions of ExceptionHandlerAssistant instances, it didn't fail because of an oversight in the test. The patch resolves the bug (trivially) and improves existing tests in DefaultRequestExceptionHandlerTest which now fail without patching DefaultRequestExceptionHandler. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (TAP5-1973) :443 added to URLs when using the Link.toAbsoluteURI(true)
[
https://issues.apache.org/jira/browse/TAP5-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reopened TAP5-1973:
--
Assignee: Kalle Korhonen (was: Howard M. Lewis Ship)
:443 added to URLs when using the Link.toAbsoluteURI(true)
--
Key: TAP5-1973
URL: https://issues.apache.org/jira/browse/TAP5-1973
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3.4, 5.4
Reporter: Howard M. Lewis Ship
Assignee: Kalle Korhonen
Labels: fixed-in-5.4-js-rewrite
Fix For: 5.3.5, 5.4
An error in the code means that when secure is true and the port is set to
443, then :443 is appended:
int port = secure ? secureHostPort : hostPort;
String portSuffix = ;
if (port = 0) {
port = request.getServerPort();
int schemeDefaultPort = request.isSecure() ? 443 : 80;
portSuffix = port == schemeDefaultPort ? : : + port;
}
else if (secure port != 443) portSuffix = : + port;
else if (port != 80) portSuffix = : + port;
String hostname = .equals(this.hostname) ? request.getServerName()
: this.hostname.startsWith($) ? System.getenv(this.hostname.substring(1)) :
this.hostname;
return String.format(%s://%s%s, secure ? https : http,
hostname, portSuffix);
secure == true port != 443 is false, so
port != 80 is evaluated, it true, so
:443 is appended.
--
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] [Assigned] (TAP5-1918) RenderInformals mixin doesn't always work as expected
[
https://issues.apache.org/jira/browse/TAP5-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-1918:
Assignee: Kalle Korhonen
RenderInformals mixin doesn't always work as expected
-
Key: TAP5-1918
URL: https://issues.apache.org/jira/browse/TAP5-1918
Project: Tapestry 5
Issue Type: Bug
Affects Versions: 5.3.1, 5.3.2, 5.3.3
Reporter: Lance
Assignee: Kalle Korhonen
Priority: Minor
The following code:
div
t:beaneditform t:id=entity ... t:mixins=RenderInformals
class=form-horizontal /
/div
Results in the following HTML:
div class=form-horizontal
form ...
/form
/div
As you can see, the informal parameter was added to the div instead of the
form.
The current implementation of RenderInformals assumes that a component has
populated the MarkupWriter with an element in beginRender() which is not
always the case. I think it should be changed to use an afterRender() method
and add informals to the current element's last child.
eg:
@MixinAfter
@SupportsInformalParameters
public class RenderInformals
{
@Inject
private ComponentResources resources;
void afterRender(MarkupWriter writer)
{
ListNode children = writer.getElement().getChildren();
if (!children.isEmpty()) {
Element lastChild = (Element) children.get(children.size() - 1);
for (String name : resources.getInformalParameterNames()) {
lastChild.attribute(name, resources.getInformalParameter(name,
String.class));
}
}
}
}
--
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-2101) BeanEditor should always provide a new BeanValidationContext (JSR-303)
[
https://issues.apache.org/jira/browse/TAP5-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2101.
--
Resolution: Fixed
Applied Alejandro's patch and cherry-picked to 5.3, thanks!
BeanEditor should always provide a new BeanValidationContext (JSR-303)
--
Key: TAP5-2101
URL: https://issues.apache.org/jira/browse/TAP5-2101
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-beanvalidator
Reporter: Luca Menegus
Assignee: Kalle Korhonen
Fix For: 5.3.7, 5.4
Attachments: beaneditor-jsr303.patch, TAP5-2101-2.patch
We found that the current BeanEditor implementation:
* fails to beanvalidate (JSR-303) complex beans (beans that contain other
beans)
* fails to validate more than one bean in the same page (when more than one
BeanEditor is present in teh page)
The problem is that BeanEditor doesn't provide the correct
BeanValidationContext to the validation framework.
Given the following beans:
public class ComplexBean {
private SomeSimpleBean someSimpleBean;
@NotNull private String simpleNotNullProperty;
...
}
public class SimpleBean {
@Min(6) private int minValue;
..
}
One would expect that the following page would validate all the constraint
from both ComplexBean and SimpleBean:
t:form validate=complexBean
t:BeanEditor object=complexBean /
t:BeanEditor object=complexBean.someSimpleBean /
...
Instead only ComplexBean.simpleNotNullProperty constraint is validated.
Moreover not even:
t:form validate=this
t:BeanEditor object=beanA /
t:BeanEditor object= beanB /
t:form/
Is (bean)validating properly
BeanEditor should provide the validation framework with a new
BeanValidationContext bound to the object being validated all the times.
--
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] [Reopened] (TAP5-2101) BeanEditor should always provide a new BeanValidationContext (JSR-303)
[
https://issues.apache.org/jira/browse/TAP5-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reopened TAP5-2101:
--
Reopening based on Alejandro's comments. Alejandro, if you have time, please
create a patch, otherwise I'll take a look at it (tomorrow at the earliest).
BeanEditor should always provide a new BeanValidationContext (JSR-303)
--
Key: TAP5-2101
URL: https://issues.apache.org/jira/browse/TAP5-2101
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-beanvalidator
Reporter: Luca Menegus
Assignee: Kalle Korhonen
Fix For: 5.3.7, 5.4
Attachments: beaneditor-jsr303.patch
We found that the current BeanEditor implementation:
* fails to beanvalidate (JSR-303) complex beans (beans that contain other
beans)
* fails to validate more than one bean in the same page (when more than one
BeanEditor is present in teh page)
The problem is that BeanEditor doesn't provide the correct
BeanValidationContext to the validation framework.
Given the following beans:
public class ComplexBean {
private SomeSimpleBean someSimpleBean;
@NotNull private String simpleNotNullProperty;
...
}
public class SimpleBean {
@Min(6) private int minValue;
..
}
One would expect that the following page would validate all the constraint
from both ComplexBean and SimpleBean:
t:form validate=complexBean
t:BeanEditor object=complexBean /
t:BeanEditor object=complexBean.someSimpleBean /
...
Instead only ComplexBean.simpleNotNullProperty constraint is validated.
Moreover not even:
t:form validate=this
t:BeanEditor object=beanA /
t:BeanEditor object= beanB /
t:form/
Is (bean)validating properly
BeanEditor should provide the validation framework with a new
BeanValidationContext bound to the object being validated all the times.
--
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] [Updated] (TAP5-1890) PlaceholderBlock should implement RenderCommand
[ https://issues.apache.org/jira/browse/TAP5-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated TAP5-1890: - Fix Version/s: 5.3.7 PlaceholderBlock should implement RenderCommand --- Key: TAP5-1890 URL: https://issues.apache.org/jira/browse/TAP5-1890 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.2, 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Priority: Trivial Labels: block, zone Fix For: 5.3.7, 5.4 Attachments: TAP-1890.patch If we have an empty zone like this: t:zone t:id=myZone / zone.getBody() fails to update the zone in an event handler with the following exception: org.apache.tapestry5.ioc.util.UnknownValueException A component event handler method returned the value PlaceholderBlock. Return type org.apache.tapestry5.internal.structure.ComponentPageElementImpl$PlaceholderBlock can not be handled. This is because ComponentPageElementImpl.PlaceholderBlock does not implement RenderCommand. A patch is provided with a test that fails. I would highly appreciate it if a commiter applies it to the 5.4. branch and to the 5.3. branch. Cheers, Dragan Sahpaski -- 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-2025) Duplicate generated ids
[ https://issues.apache.org/jira/browse/TAP5-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2025. -- Resolution: Fixed Fix Version/s: 5.4 5.3.7 Changed to use nanoTime() instead of millis. This doesn't prevent id conflicts from happening, but should greatly reduce the chances. Duplicate generated ids --- Key: TAP5-2025 URL: https://issues.apache.org/jira/browse/TAP5-2025 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.5, 5.3.6 Reporter: Dimitris Zenios Assignee: Kalle Korhonen Labels: duplicate, id Fix For: 5.3.7, 5.4 IdGenerator of javascriptSupport PartialMarkupRendererFilter is using Long.toHexString(System.currentTimeMillis()) as a suffix for ids.If two ajax requests arrive at the same time they will both have the same suffix.If both request will render a component named Sort (From grid) then many sort links will have same ids.Found it out because i had 10 progressive displays in my page each drawing an inPlace grid.Some of the sort links will also sort another grid when clicked since they have the same id. -- 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-2084) Form should decode its link parameters
[ https://issues.apache.org/jira/browse/TAP5-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2084. -- Resolution: Fixed Fix Version/s: 5.4 5.3.7 Applied cleanly, thanks Denis! Form should decode its link parameters -- Key: TAP5-2084 URL: https://issues.apache.org/jira/browse/TAP5-2084 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.3 Reporter: Denis Stepanov Assignee: Kalle Korhonen Fix For: 5.3.7, 5.4 Attachments: 0001-TAP5-2084-Form-should-decode-its-link-parameters.patch The Form component will add all its action event link parameters as hidden inputs, but link parameter's value is encoded and hidden input field value is not, because of that parameter's value will be encoded on arrival. simple request: //add parameter to the link link.addParameter (abc, URLDecoder.encode(abcValue, UTF-8)) on event: request.getParameter(abc) is equals to abcValue form request: // add parameter to the form action link using the LinkCreationHub link.addParameter (abc, URLDecoder.encode(value, UTF-8)) on event: request.getParameter(abc) is not equals to abcValue, parameter's value is encoded It could be fixed by decoding parameter's value at line: writer.element(input, type, hidden, name, parameterName, value, value); -- 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-2063) Add support for multivalued parameters in Link
[ https://issues.apache.org/jira/browse/TAP5-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2063. -- Resolution: Fixed Fix Version/s: 5.4 5.3.7 Thanks Alejandro! Add support for multivalued parameters in Link -- Key: TAP5-2063 URL: https://issues.apache.org/jira/browse/TAP5-2063 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Alejandro Scandroli Assignee: Kalle Korhonen Fix For: 5.3.7, 5.4 Attachments: TAP5-2063_1.patch Request.java has support for multivalued parameters but there is no way to add more than one parameter with the same name to the Link. Instead of throwing an IllegalArgumentException when the link already has a parameter with the same name Link.addParameter should add it to the URL as a multivalued parameter. -- 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] [Commented] (TAP5-2084) Form should decode its link parameters
[ https://issues.apache.org/jira/browse/TAP5-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631335#comment-13631335 ] Kalle Korhonen commented on TAP5-2084: -- See Fix Versions field. Form should decode its link parameters -- Key: TAP5-2084 URL: https://issues.apache.org/jira/browse/TAP5-2084 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.3 Reporter: Denis Stepanov Assignee: Kalle Korhonen Fix For: 5.3.7, 5.4 Attachments: 0001-TAP5-2084-Form-should-decode-its-link-parameters.patch The Form component will add all its action event link parameters as hidden inputs, but link parameter's value is encoded and hidden input field value is not, because of that parameter's value will be encoded on arrival. simple request: //add parameter to the link link.addParameter (abc, URLDecoder.encode(abcValue, UTF-8)) on event: request.getParameter(abc) is equals to abcValue form request: // add parameter to the form action link using the LinkCreationHub link.addParameter (abc, URLDecoder.encode(value, UTF-8)) on event: request.getParameter(abc) is not equals to abcValue, parameter's value is encoded It could be fixed by decoding parameter's value at line: writer.element(input, type, hidden, name, parameterName, value, value); -- 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] [Assigned] (TAP5-2063) Add support for multivalued parameters in Link
[ https://issues.apache.org/jira/browse/TAP5-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2063: Assignee: Kalle Korhonen Add support for multivalued parameters in Link -- Key: TAP5-2063 URL: https://issues.apache.org/jira/browse/TAP5-2063 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Alejandro Scandroli Assignee: Kalle Korhonen Attachments: TAP5-2063_1.patch Request.java has support for multivalued parameters but there is no way to add more than one parameter with the same name to the Link. Instead of throwing an IllegalArgumentException when the link already has a parameter with the same name Link.addParameter should add it to the URL as a multivalued parameter. -- 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-1987) ProgressiveDisplay update parameter as a symbol
[
https://issues.apache.org/jira/browse/TAP5-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-1987.
--
Resolution: Won't Fix
Fix Version/s: 5.4
Assignee: Kalle Korhonen
From 5.4 ComponentParameterConstants:
* @deprecated Deprecated in 5.4 with no replacement.
*/
public static final String ZONE_SHOW_METHOD =
tapestry.components.zone_show_method;
/**
* The default name of a JS function attached to Tapestry.ElementEffect
object to point out an
* update on a {@link org.apache.tapestry5.corelib.components.Zone}.
* Defaults to highlight
*
* @deprecated Deprecated in 5.4 with no replacement.
*/
public static final String ZONE_UPDATE_METHOD =
tapestry.components.zone_update_method;
i.e. the comparable component specific effect symbols are deprecated in 5.4
without replacements so putting this in would go against the grain. I'm not
sure what Howard's thinking with deprecation was but to me, a symbol in
principle seems like too heavyweight a mechanism to configure component
defaults. Argue hard on the dev list if you want this reopened and committed.
ProgressiveDisplay update parameter as a symbol
---
Key: TAP5-1987
URL: https://issues.apache.org/jira/browse/TAP5-1987
Project: Tapestry 5
Issue Type: Improvement
Affects Versions: 5.3.4
Reporter: Dusko Jovanovski
Assignee: Kalle Korhonen
Priority: Minor
Fix For: 5.4
Attachments:
Added-Symbol-for-default-ProgressiveDisplay-zone-upd.patch
ProgressiveDisplay update parameter as a symbol
Could be a new symbol, or the same one used for the Zone component.
--
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] [Assigned] (TAP5-2101) BeanEditor should always provide a new BeanValidationContext (JSR-303)
[
https://issues.apache.org/jira/browse/TAP5-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-2101:
Assignee: Kalle Korhonen
BeanEditor should always provide a new BeanValidationContext (JSR-303)
--
Key: TAP5-2101
URL: https://issues.apache.org/jira/browse/TAP5-2101
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-beanvalidator
Reporter: Luca Menegus
Assignee: Kalle Korhonen
Attachments: beaneditor-jsr303.patch
We found that the current BeanEditor implementation:
* fails to beanvalidate (JSR-303) complex beans (beans that contain other
beans)
* fails to validate more than one bean in the same page (when more than one
BeanEditor is present in teh page)
The problem is that BeanEditor doesn't provide the correct
BeanValidationContext to the validation framework.
Given the following beans:
public class ComplexBean {
private SomeSimpleBean someSimpleBean;
@NotNull private String simpleNotNullProperty;
...
}
public class SimpleBean {
@Min(6) private int minValue;
..
}
One would expect that the following page would validate all the constraint
from both ComplexBean and SimpleBean:
t:form validate=complexBean
t:BeanEditor object=complexBean /
t:BeanEditor object=complexBean.someSimpleBean /
...
Instead only ComplexBean.simpleNotNullProperty constraint is validated.
Moreover not even:
t:form validate=this
t:BeanEditor object=beanA /
t:BeanEditor object= beanB /
t:form/
Is (bean)validating properly
BeanEditor should provide the validation framework with a new
BeanValidationContext bound to the object being validated all the times.
--
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-2102) Allow supplying EntityManager properties via TapestryPersistenceUnitInfo
[ https://issues.apache.org/jira/browse/TAP5-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2102. -- Resolution: Fixed Fix Version/s: 5.4 5.3.7 Not convinced about using TapestryPersistenceUnitInfo to carry the properties map but we could improve the solution later. Allow supplying EntityManager properties via TapestryPersistenceUnitInfo Key: TAP5-2102 URL: https://issues.apache.org/jira/browse/TAP5-2102 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-jpa Affects Versions: 5.3.6 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Fix For: 5.3.7, 5.4 Currently EntityManagerSourceImpl.createEntityManagerFactory create an internal map on the fly. We should users to supply their own properties map to the EntityManagerFactory as the default properties for EntityManager. -- 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] [Assigned] (TAP5-2025) Duplicate generated ids
[ https://issues.apache.org/jira/browse/TAP5-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2025: Assignee: Kalle Korhonen Duplicate generated ids --- Key: TAP5-2025 URL: https://issues.apache.org/jira/browse/TAP5-2025 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.5, 5.3.6 Reporter: Dimitris Zenios Assignee: Kalle Korhonen Labels: duplicate, id IdGenerator of javascriptSupport PartialMarkupRendererFilter is using Long.toHexString(System.currentTimeMillis()) as a suffix for ids.If two ajax requests arrive at the same time they will both have the same suffix.If both request will render a component named Sort (From grid) then many sort links will have same ids.Found it out because i had 10 progressive displays in my page each drawing an inPlace grid.Some of the sort links will also sort another grid when clicked since they have the same id. -- 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-2101) BeanEditor should always provide a new BeanValidationContext (JSR-303)
[
https://issues.apache.org/jira/browse/TAP5-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-2101.
--
Resolution: Fixed
Fix Version/s: 5.4
5.3.7
BeanEditor should always provide a new BeanValidationContext (JSR-303)
--
Key: TAP5-2101
URL: https://issues.apache.org/jira/browse/TAP5-2101
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-beanvalidator
Reporter: Luca Menegus
Assignee: Kalle Korhonen
Fix For: 5.3.7, 5.4
Attachments: beaneditor-jsr303.patch
We found that the current BeanEditor implementation:
* fails to beanvalidate (JSR-303) complex beans (beans that contain other
beans)
* fails to validate more than one bean in the same page (when more than one
BeanEditor is present in teh page)
The problem is that BeanEditor doesn't provide the correct
BeanValidationContext to the validation framework.
Given the following beans:
public class ComplexBean {
private SomeSimpleBean someSimpleBean;
@NotNull private String simpleNotNullProperty;
...
}
public class SimpleBean {
@Min(6) private int minValue;
..
}
One would expect that the following page would validate all the constraint
from both ComplexBean and SimpleBean:
t:form validate=complexBean
t:BeanEditor object=complexBean /
t:BeanEditor object=complexBean.someSimpleBean /
...
Instead only ComplexBean.simpleNotNullProperty constraint is validated.
Moreover not even:
t:form validate=this
t:BeanEditor object=beanA /
t:BeanEditor object= beanB /
t:form/
Is (bean)validating properly
BeanEditor should provide the validation framework with a new
BeanValidationContext bound to the object being validated all the times.
--
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] [Commented] (TAP5-2101) BeanEditor should always provide a new BeanValidationContext (JSR-303)
[
https://issues.apache.org/jira/browse/TAP5-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631275#comment-13631275
]
Kalle Korhonen commented on TAP5-2101:
--
Applied, thanks Luca!
BeanEditor should always provide a new BeanValidationContext (JSR-303)
--
Key: TAP5-2101
URL: https://issues.apache.org/jira/browse/TAP5-2101
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-beanvalidator
Reporter: Luca Menegus
Assignee: Kalle Korhonen
Fix For: 5.3.7, 5.4
Attachments: beaneditor-jsr303.patch
We found that the current BeanEditor implementation:
* fails to beanvalidate (JSR-303) complex beans (beans that contain other
beans)
* fails to validate more than one bean in the same page (when more than one
BeanEditor is present in teh page)
The problem is that BeanEditor doesn't provide the correct
BeanValidationContext to the validation framework.
Given the following beans:
public class ComplexBean {
private SomeSimpleBean someSimpleBean;
@NotNull private String simpleNotNullProperty;
...
}
public class SimpleBean {
@Min(6) private int minValue;
..
}
One would expect that the following page would validate all the constraint
from both ComplexBean and SimpleBean:
t:form validate=complexBean
t:BeanEditor object=complexBean /
t:BeanEditor object=complexBean.someSimpleBean /
...
Instead only ComplexBean.simpleNotNullProperty constraint is validated.
Moreover not even:
t:form validate=this
t:BeanEditor object=beanA /
t:BeanEditor object= beanB /
t:form/
Is (bean)validating properly
BeanEditor should provide the validation framework with a new
BeanValidationContext bound to the object being validated all the times.
--
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-2102) Allow supplying EntityManager properties via TapestryPersistenceUnitInfo
Kalle Korhonen created TAP5-2102: Summary: Allow supplying EntityManager properties via TapestryPersistenceUnitInfo Key: TAP5-2102 URL: https://issues.apache.org/jira/browse/TAP5-2102 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-jpa Affects Versions: 5.3.6 Reporter: Kalle Korhonen Currently EntityManagerSourceImpl.createEntityManagerFactory create an internal map on the fly. We should users to supply their own properties map to the EntityManagerFactory as the default properties for EntityManager. -- 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] [Assigned] (TAP5-2102) Allow supplying EntityManager properties via TapestryPersistenceUnitInfo
[ https://issues.apache.org/jira/browse/TAP5-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2102: Assignee: Kalle Korhonen Allow supplying EntityManager properties via TapestryPersistenceUnitInfo Key: TAP5-2102 URL: https://issues.apache.org/jira/browse/TAP5-2102 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-jpa Affects Versions: 5.3.6 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Currently EntityManagerSourceImpl.createEntityManagerFactory create an internal map on the fly. We should users to supply their own properties map to the EntityManagerFactory as the default properties for EntityManager. -- 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] [Assigned] (TAP5-2097) Use a JavaScriptStack to import the tapestry-beanvalidator.js file.
[ https://issues.apache.org/jira/browse/TAP5-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2097: Assignee: Kalle Korhonen Use a JavaScriptStack to import the tapestry-beanvalidator.js file. --- Key: TAP5-2097 URL: https://issues.apache.org/jira/browse/TAP5-2097 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-beanvalidator Affects Versions: 5.3.6 Reporter: Alejandro Scandroli Assignee: Kalle Korhonen Attachments: TAP5-2097.patch tapestry-beanvalidator is using MarkupRendererFilter to include the tapestry-beanvalidator.js in every page. Which means that if you have the tapestry-beanvalidator dependency in your project you end up importing many tapestry javascript files that you may not need. Even for an empty page, if you have tapestry-beanvalidator as a dependency it will include a dozen javascript files. A better approach would be to have a JavaScriptStack for tapestry-beanvalidator.js and then use a worker to import the stack ONLY when there is a form present. The tapestry-jquery project has a nice example of this, FormResourcesInclusionWorker https://github.com/got5/tapestry5-jquery/blob/master/src/main/java/org/got5/tapestry5/jquery/services/FormResourcesInclusionWorker.java -- 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] [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-tabpanelfocusedCommentId=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] [Assigned] (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 reassigned TAP5-2067:
Assignee: Kalle Korhonen
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
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] [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-tabpanelfocusedCommentId=13605618#comment-13605618
]
Kalle Korhonen edited comment on TAP5-2067 at 3/18/13 8:54 PM:
---
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.
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). 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
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] [Commented] (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-tabpanelfocusedCommentId=13575245#comment-13575245
]
Kalle Korhonen commented on TAP5-2067:
--
The reason I haven't attempted fixing it is that I don't see the issue in my
Tomcat 7 parallel deployment environment. I'm running Tapestry 5.3.6 with
Tomcat 7.0.27 on CentOS release 5.8 (Final) x86_64. I'd be interested in
knowing why it works on some environment and doesn't in others. What are the
details of your environment?
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
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] [Assigned] (TAP5-2035) Make it easier to choose another slf4j backend
[ https://issues.apache.org/jira/browse/TAP5-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2035: Assignee: Kalle Korhonen Make it easier to choose another slf4j backend -- Key: TAP5-2035 URL: https://issues.apache.org/jira/browse/TAP5-2035 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3, 5.4 Reporter: Jochen Kemnade Assignee: Kalle Korhonen Labels: logging, patch Attachments: 0001-Have-tapestry-ioc-depend-on-slf4j-api-instead-of-slf.patch Tapestry-IOC includes slf4j-log4j12 and log4j as compile dependencies. This is not necessary and makes it hard for users to choose another logging backend for slf4j. Tapestry-IOC should depend on slf4j-api only and the backend should be exchangeable without having to exclude transitive dependencies. However, it seems sensible to provide log4j as the default binding for quickstart projects, so the dependency on slf4j-log4l12 should be added to the final project. -- 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-2035) Make it easier to choose another slf4j backend
[ https://issues.apache.org/jira/browse/TAP5-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2035. -- Resolution: Fixed Fix Version/s: 5.4 Agreed. Patch applied, thanks! Not deemed critical enough for 5.3.x, use excludes. Make it easier to choose another slf4j backend -- Key: TAP5-2035 URL: https://issues.apache.org/jira/browse/TAP5-2035 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3, 5.4 Reporter: Jochen Kemnade Assignee: Kalle Korhonen Labels: logging, patch Fix For: 5.4 Attachments: 0001-Have-tapestry-ioc-depend-on-slf4j-api-instead-of-slf.patch Tapestry-IOC includes slf4j-log4j12 and log4j as compile dependencies. This is not necessary and makes it hard for users to choose another logging backend for slf4j. Tapestry-IOC should depend on slf4j-api only and the backend should be exchangeable without having to exclude transitive dependencies. However, it seems sensible to provide log4j as the default binding for quickstart projects, so the dependency on slf4j-log4l12 should be added to the final project. -- 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-1833) Merge functionality of Tynamo.org's tapestry-exceptionpage module with the built-in ExceptionHandler
[ https://issues.apache.org/jira/browse/TAP5-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-1833. -- Resolution: Fixed Fix Version/s: 5.4 Merge functionality of Tynamo.org's tapestry-exceptionpage module with the built-in ExceptionHandler Key: TAP5-1833 URL: https://issues.apache.org/jira/browse/TAP5-1833 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.3 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Fix For: 5.4 As discussed on the dev list: http://markmail.org/search/?q=Bringing+Tynamo%27s+tapestry-exceptionpage+into+the+core#query:Bringing%20Tynamo%27s%20tapestry-exceptionpage%20into%20the%20core+page:1+mid:wocbkhyqqe7a2tm7+state:results -- 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] [Assigned] (TAP5-1993) Support returning an URL for an ajax request
[ https://issues.apache.org/jira/browse/TAP5-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-1993: Assignee: Kalle Korhonen Support returning an URL for an ajax request Key: TAP5-1993 URL: https://issues.apache.org/jira/browse/TAP5-1993 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.5 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Priority: Minor Howard Lewis Ship hls...@gmail.com via tapestry.apache.org to Tapestry On Tue, Aug 21, 2012 at 1:42 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Currently you get Return type java.net.URL can not be handled if you return an URL from an ajax event handler. Is this just an oversight or is there some limitation I cannot see why you couldn't return an URL but can return a Link? The JSON response should be the same. Seems like an oversight; this is supported for traditional requests, it should be supported for Ajax requests as well. -- 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-1993) Support returning an URL for an ajax request
[ https://issues.apache.org/jira/browse/TAP5-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-1993. -- Resolution: Fixed Fix Version/s: 5.4 Added AjaxURLComponentEventResultProcessor Support returning an URL for an ajax request Key: TAP5-1993 URL: https://issues.apache.org/jira/browse/TAP5-1993 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.5 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Priority: Minor Fix For: 5.4 Howard Lewis Ship hls...@gmail.com via tapestry.apache.org to Tapestry On Tue, Aug 21, 2012 at 1:42 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Currently you get Return type java.net.URL can not be handled if you return an URL from an ajax event handler. Is this just an oversight or is there some limitation I cannot see why you couldn't return an URL but can return a Link? The JSON response should be the same. Seems like an oversight; this is supported for traditional requests, it should be supported for Ajax requests as well. -- 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] [Assigned] (TAP5-2022) Add PropertyAccess.getAnnotation
[ https://issues.apache.org/jira/browse/TAP5-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-2022: Assignee: Kalle Korhonen Add PropertyAccess.getAnnotation Key: TAP5-2022 URL: https://issues.apache.org/jira/browse/TAP5-2022 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.6 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Priority: Minor On Sun, Oct 28, 2012 at 5:41 AM, Howard Lewis Ship hls...@gmail.com wrote: I can't think of why that's not already present. On Sat, Oct 27, 2012 at 7:56 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: We don't seem to have anything for fetching annotations... wouldn't it be nice if you could do PropertyAccess.get(Object instance, String propertyName, Class? extends Annotation annotationClass) without having to care whether the annotation is on the getter or on the field? Anybody object to adding it? Kalle -- 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-2022) Add PropertyAccess.getAnnotation
[ https://issues.apache.org/jira/browse/TAP5-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2022. -- Resolution: Fixed Fix Version/s: 5.4 Convenience only, no burning reason to merge to 5.3.x Add PropertyAccess.getAnnotation Key: TAP5-2022 URL: https://issues.apache.org/jira/browse/TAP5-2022 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.6 Reporter: Kalle Korhonen Assignee: Kalle Korhonen Priority: Minor Fix For: 5.4 On Sun, Oct 28, 2012 at 5:41 AM, Howard Lewis Ship hls...@gmail.com wrote: I can't think of why that's not already present. On Sat, Oct 27, 2012 at 7:56 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: We don't seem to have anything for fetching annotations... wouldn't it be nice if you could do PropertyAccess.get(Object instance, String propertyName, Class? extends Annotation annotationClass) without having to care whether the annotation is on the getter or on the field? Anybody object to adding it? Kalle -- 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-2022) Add PropertyAccess.getAnnotation
Kalle Korhonen created TAP5-2022: Summary: Add PropertyAccess.getAnnotation Key: TAP5-2022 URL: https://issues.apache.org/jira/browse/TAP5-2022 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.6 Reporter: Kalle Korhonen Priority: Minor On Sun, Oct 28, 2012 at 5:41 AM, Howard Lewis Ship hls...@gmail.com wrote: I can't think of why that's not already present. On Sat, Oct 27, 2012 at 7:56 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: We don't seem to have anything for fetching annotations... wouldn't it be nice if you could do PropertyAccess.get(Object instance, String propertyName, Class? extends Annotation annotationClass) without having to care whether the annotation is on the getter or on the field? Anybody object to adding it? Kalle -- 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-2015) Tomcat .war path is not decoded properly
[ https://issues.apache.org/jira/browse/TAP5-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-2015. -- Resolution: Duplicate Fix Version/s: 5.4 5.3.7 Assignee: Kalle Korhonen https://issues.apache.org/jira/browse/TAP5-1995 Tomcat .war path is not decoded properly Key: TAP5-2015 URL: https://issues.apache.org/jira/browse/TAP5-2015 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.6 Reporter: Kapep Assignee: Kalle Korhonen Labels: tomcat Fix For: 5.3.7, 5.4 If an tapestry application is deployed to tomcat and the path to a webapp contains hash signs (#), org.apache.tapestry5.internal.plastic.PlasticInternalUtils.getStreamForPath tries to read files from a wrong directory: instead a hash sign, the path it tries to read contains the sequence %23. This results in a FileNotFoundException and causes the app to fail starting. getStreamForPath already replaces url encoded %20 space characters for tomcat, it should also replace hash signs - and maybe even more valid file name characters. Background: Tomcat 6 uses hash signs in war file names as replacement for slashes, so that the file name can be used to construct the webapp's url. The war is unpacked to a directory which name is the war's file name without the .war extension and therefore can contain hash signs. Tomcat 7 uses two hash signs for the same purpose. -- 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] [Assigned] (TAP5-1995) Tapestry5 Application can not be deployed as Tomcat7 HotDeploy Package
[
https://issues.apache.org/jira/browse/TAP5-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen reassigned TAP5-1995:
Assignee: Kalle Korhonen
Tapestry5 Application can not be deployed as Tomcat7 HotDeploy Package
--
Key: TAP5-1995
URL: https://issues.apache.org/jira/browse/TAP5-1995
Project: Tapestry 5
Issue Type: Bug
Components: plastic
Affects Versions: 5.3.3
Reporter: Thomas Hackel
Assignee: Kalle Korhonen
Attachments: TAP5-1995.patch
1. WAR file is named like
{noformat}
yourapp##1.2.3.war
{noformat}
2. Results in path
{noformat}
webapps/yourapp##1.2.3
{noformat}
3. Tapestry throws error:
{noformat}
Caused by: java.lang.RuntimeException: Failure reading bytecode for class
com.biso.casingdb.web.services.AppModule:
/home/apache-tomcat-7.0.26/webapps/yourapp%23%231.2.3/WEB-INF/classes/AppModule.class
(No such file or directory)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.readBytecodeForClass(PlasticInternalUtils.java:384)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.readClassNode(PlasticProxyFactoryImpl.java:107)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.getMemberLocation(PlasticProxyFactoryImpl.java:141)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.getMethodLocation(PlasticProxyFactoryImpl.java:114)
at
org.apache.tapestry5.ioc.internal.util.InternalUtils.asString(InternalUtils.java:85)
at
org.apache.tapestry5.ioc.internal.ContributionDefImpl.toString(ContributionDefImpl.java:59)
at java.lang.String.valueOf(String.java:2902)
at java.lang.StringBuilder.append(StringBuilder.java:128)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.addToMappedConfiguration(RegistryImpl.java:557)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.getMappedConfiguration(RegistryImpl.java:515)
at
org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:126)
at
org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:123)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
... 224 more
Caused by: java.io.FileNotFoundException:
/home/apache-tomcat-7.0.26/webapps/yourapp%23%231.2.3/WEB-INF/classes/AppModule.class
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:138)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.getStreamForPath(PlasticInternalUtils.java:408)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.readBytecodeForClass(PlasticInternalUtils.java:370)
... 236 more
{noformat}
--
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-1995) Tapestry5 Application can not be deployed as Tomcat7 HotDeploy Package
[
https://issues.apache.org/jira/browse/TAP5-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalle Korhonen resolved TAP5-1995.
--
Resolution: Fixed
Fix Version/s: 5.4
5.3.7
Applied, added test
Tapestry5 Application can not be deployed as Tomcat7 HotDeploy Package
--
Key: TAP5-1995
URL: https://issues.apache.org/jira/browse/TAP5-1995
Project: Tapestry 5
Issue Type: Bug
Components: plastic
Affects Versions: 5.3.3
Reporter: Thomas Hackel
Assignee: Kalle Korhonen
Fix For: 5.3.7, 5.4
Attachments: TAP5-1995.patch
1. WAR file is named like
{noformat}
yourapp##1.2.3.war
{noformat}
2. Results in path
{noformat}
webapps/yourapp##1.2.3
{noformat}
3. Tapestry throws error:
{noformat}
Caused by: java.lang.RuntimeException: Failure reading bytecode for class
com.biso.casingdb.web.services.AppModule:
/home/apache-tomcat-7.0.26/webapps/yourapp%23%231.2.3/WEB-INF/classes/AppModule.class
(No such file or directory)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.readBytecodeForClass(PlasticInternalUtils.java:384)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.readClassNode(PlasticProxyFactoryImpl.java:107)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.getMemberLocation(PlasticProxyFactoryImpl.java:141)
at
org.apache.tapestry5.ioc.internal.services.PlasticProxyFactoryImpl.getMethodLocation(PlasticProxyFactoryImpl.java:114)
at
org.apache.tapestry5.ioc.internal.util.InternalUtils.asString(InternalUtils.java:85)
at
org.apache.tapestry5.ioc.internal.ContributionDefImpl.toString(ContributionDefImpl.java:59)
at java.lang.String.valueOf(String.java:2902)
at java.lang.StringBuilder.append(StringBuilder.java:128)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.addToMappedConfiguration(RegistryImpl.java:557)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.getMappedConfiguration(RegistryImpl.java:515)
at
org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:126)
at
org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:123)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
... 224 more
Caused by: java.io.FileNotFoundException:
/home/apache-tomcat-7.0.26/webapps/yourapp%23%231.2.3/WEB-INF/classes/AppModule.class
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:138)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.getStreamForPath(PlasticInternalUtils.java:408)
at
org.apache.tapestry5.internal.plastic.PlasticInternalUtils.readBytecodeForClass(PlasticInternalUtils.java:370)
... 236 more
{noformat}
--
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] [Assigned] (TAP5-986) sendError in onActivate / Tapestry error dispatching
[ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reassigned TAP5-986: --- Assignee: Kalle Korhonen sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Assignee: Kalle Korhonen Attachments: TAP5-986.txt With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- 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-986) sendError in onActivate / Tapestry error dispatching
[ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-986. - Resolution: Fixed Fix Version/s: 5.4 5.3.6 Fixed as suggested. sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Assignee: Kalle Korhonen Fix For: 5.3.6, 5.4 Attachments: TAP5-986.txt With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- 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] [Commented] (TAP5-986) sendError in onActivate / Tapestry error dispatching
[
https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466369#comment-13466369
]
Kalle Korhonen commented on TAP5-986:
-
This happens at least on Jetty and all versions, including 5.4 snapshots. The
issue is related to servlet standard error pages and how (at least) Jetty
handles error dispatches. You'll get the exception whenever a
response.sendError is invoked, because the container's error dispatcher
immediately starts processing the error request in the same thread. We probably
don't see this in Tomcat because it likely issues a new thread for processing
the error request. Anyway, Tapestry successfully cleans up the thread and ends
processing the request, after which the original request finishes up, invoking
EndOfRequestEventHub.fire() but the thread is already cleaned up. That also
explains why everything still works even though you see the exception. A
corrected, but naive implementation of EndOfRequestEventHub would check if the
request still exists, for example (note the added if
(requestGlobals.getRequest() == null) return; in fire() ):
@ServiceId(GuardedEndOfRequestEventHub)
public EndOfRequestEventHub buildEndOfRequestEventHub(final
RequestGlobals requestGlobals) {
return new EndOfRequestEventHub() {
private final ListEndOfRequestListener listeners =
CollectionFactory.newThreadSafeList();
public void
addEndOfRequestListener(EndOfRequestListener listener) {
listeners.add(listener);
}
public void
removeEndOfRequestListener(EndOfRequestListener listener) {
listeners.remove(listener);
}
public void fire() {
if (requestGlobals.getRequest() == null) return;
for (EndOfRequestListener l : listeners) {
l.requestDidComplete();
}
}
};
}
It's easy to override the original EndOfRequestEventHub since it has no
dependencies. That's just stopgap measure, I'll bring the topic of multiple
container dispatches on the dev list as it may imply a larger issue with the
expectations T5 makes about the isolation level of container threads.
sendError in onActivate / Tapestry error dispatching
Key: TAP5-986
URL: https://issues.apache.org/jira/browse/TAP5-986
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Christophe Cordenier
Attachments: TAP5-986.txt
With this kind of configuration in web.xml :
filter-mapping
filter-nametapestryFilter/filter-name
url-pattern/*/url-pattern
dispatcherERROR/dispatcher
dispatcherREQUEST/dispatcher
/filter-mapping
error-page
error-code403/error-code
location/error/AccessDenied/location
/error-page
error-page
error-code404/error-code
location/error/NotFound/location
/error-page
RestoreDirtySessionObjects is generating a NullPointerException with this
line :
Session session = request.getSession(false);
It seems that the dispatching is done in one single thread, then the initial
class to RestoreDirtySessionObjects is delay, and request object is lost.
--
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] [Reopened] (TAP5-1996) Add Severity.SUCCESS enum for alerts
[ https://issues.apache.org/jira/browse/TAP5-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen reopened TAP5-1996: -- Add Severity.SUCCESS enum for alerts Key: TAP5-1996 URL: https://issues.apache.org/jira/browse/TAP5-1996 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.5 Reporter: Dmitry Gusev Assignee: Kalle Korhonen Labels: features, patch Fix For: 5.3.6, 5.4 Attachments: new-alerts-look-and-feel.jpg, TAP5-1996.patch I'm currently implementing twitter-bootstrap integration for alerts and found that tapestry5 lacks this value. http://twitter.github.com/bootstrap/components.html#alerts -- 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-1996) Add Severity.SUCCESS enum for alerts
[ https://issues.apache.org/jira/browse/TAP5-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen resolved TAP5-1996. -- Resolution: Fixed Add Severity.SUCCESS enum for alerts Key: TAP5-1996 URL: https://issues.apache.org/jira/browse/TAP5-1996 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.5 Reporter: Dmitry Gusev Assignee: Kalle Korhonen Labels: features, patch Fix For: 5.3.6, 5.4 Attachments: new-alerts-look-and-feel.jpg, TAP5-1996.patch I'm currently implementing twitter-bootstrap integration for alerts and found that tapestry5 lacks this value. http://twitter.github.com/bootstrap/components.html#alerts -- 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
