[jira] Created: (TAP5-1374) Quickstart layout component uses deprecated IncludeStyleSheet annotation
Quickstart layout component uses deprecated IncludeStyleSheet annotation Key: TAP5-1374 URL: https://issues.apache.org/jira/browse/TAP5-1374 Project: Tapestry 5 Issue Type: Bug Components: quickstart Affects Versions: 5.2.4 Reporter: Javier Molina Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971836#action_12971836
]
Josh Canfield edited comment on TAP5-1373 at 12/15/10 4:12 PM:
---
> I guess I was not clear enough. I'm talking about aborting the event in the
> generated method
Yes, I understand. I still don't think what you are proposing to do is an
improvement to how it works now.
You are going to take away the ability of using the no-arg onActivate method as
general activation setup when you use the @PageActivationContext. Users such as
Alexander are going to have broken apps when their code that depends on the
existing behavior stops getting called.
I don't think adding a parameter to the annotation is right either... if you
want to use both the annotation and the no-arg onActivate then check for the
parameter to be initialized in the no-arg onActivate.
was (Author: joshcanfield):
> I guess I was not clear enough. I'm talking about aborting the event in
the generated method
Yes, I understand. I still don't think what you are proposing to do is an
improvement to how it works now.
You are going to take away the ability of using the no-arg onActivate method as
general activation setup when you use the @PageActivationContext. Users such as
Alexander are going to have broken apps when they're code that depends on the
existing behavior stops getting called.
I don't think adding a parameter to the annotation is right either... if you
want to use both the annotation and the no-arg onActivate then check for the
parameter to be initialized in the no-arg onActivate.
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971836#action_12971836
]
Josh Canfield commented on TAP5-1373:
-
> I guess I was not clear enough. I'm talking about aborting the event in the
> generated method
Yes, I understand. I still don't think what you are proposing to do is an
improvement to how it works now.
You are going to take away the ability of using the no-arg onActivate method as
general activation setup when you use the @PageActivationContext. Users such as
Alexander are going to have broken apps when they're code that depends on the
existing behavior stops getting called.
I don't think adding a parameter to the annotation is right either... if you
want to use both the annotation and the no-arg onActivate then check for the
parameter to be initialized in the no-arg onActivate.
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971823#action_12971823
]
Alexander Gavrilov commented on TAP5-1373:
--
Proposed changes will break our application, because these changes lead to a
different default system behavior.
If this change important for you we can add parameter "stopPropagation" to
PageActivationContext with default value false. Or, in more generic way, we
can add Enum Propagation (stop, let, def) and put configuration of default
system behaviour into application setting. And we can add parameter
"propagation" in PageActivationContext with default value Propagation.def
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971778#action_12971778
]
Igor Drobiazko commented on TAP5-1373:
--
I guess I was not clear enough. I'm talking about aborting the event in the
generated method. As of now the code in the page above is equivalent to:
public class Foo {
private String bar;
void onActivate() {
bar = "baz";
}
void onActivate(String bar) {
this. bar = bar;
}
}
This way both methods are called. The method with a string argument should
abort the event by returning true. So the generated bytecode should be
equilvalent to:
public class Foo {
private String bar;
void onActivate() {
bar = "baz";
}
boolean onActivate(String bar) {
this. bar = bar;
return true;
}
}
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971772#action_12971772
]
Josh Canfield commented on TAP5-1373:
-
This sounds like a feature, not a bug. If you want to do other initialization
in onActivate then you should be able to do this.
Your example code should be:
void onActivate() {
if ( bar == null )
bar = "baz";
// Handle other activation stuff
}
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
@PageActivationContext should case the activate event to be aborted
---
Key: TAP5-1373
URL: https://issues.apache.org/jira/browse/TAP5-1373
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Igor Drobiazko
Currently it is not possible to have both: a field annotated with
@PageActivationContext and a no-args onActivate() method. The generated method
doesn't abort the event, so that the no-args activation method is called
afterwards. This behaviour overrides the activation context retrieved from the
URL.
public class Foo {
@PageActivationContext
private String bar;
void onActivate() {
bar = "baz";
}
}
The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1373) @PageActivationContext should case the activate event to be aborted
[
https://issues.apache.org/jira/browse/TAP5-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Drobiazko reassigned TAP5-1373:
Assignee: Igor Drobiazko
> @PageActivationContext should case the activate event to be aborted
> ---
>
> Key: TAP5-1373
> URL: https://issues.apache.org/jira/browse/TAP5-1373
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Igor Drobiazko
>Assignee: Igor Drobiazko
>
> Currently it is not possible to have both: a field annotated with
> @PageActivationContext and a no-args onActivate() method. The generated
> method doesn't abort the event, so that the no-args activation method is
> called afterwards. This behaviour overrides the activation context retrieved
> from the URL.
> public class Foo {
>@PageActivationContext
>private String bar;
>void onActivate() {
>bar = "baz";
>}
> }
> The generated method should store a "true" result in order to abort the event.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1372) BaseURLSource uses getLocalPort() rather than getServerPort()
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1372: -- Priority: Critical (was: Major) Description: Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received." getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the Host header, if any, or the server port where the client connection was accepted on." I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered & load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it! Unless anyone has a convincing argument why it should be this way, of course... was: Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received." getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the Host header, if any, or the server port where the client connection was accepted on." I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that will only rarely cause a problem, but it's just affected our site so it would be great if it could be fixed for 5.2.5 final release. Unless anyone has a convincing argument why it should be this way, of course... > BaseURLSource uses getLocalPort() rather than getServerPort() > - > > Key: TAP5-1372 > URL: https://issues.apache.org/jira/browse/TAP5-1372 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Andy Blower >Priority: Critical > > Line 31 of BaseURLSourceImpl: > int port = request.getLocalPort(); > Which calls same method in the underlying ServletRequest. > getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the > interface on which the request was received." > getServerPort javadoc: "Returns the port number to which the request was > sent. It is the value of the part after ":" in the Host header, > if any, or the server port where the client connection was accepted on." > I think that the second is the one that should be used and since this port > number is paired with the host returned from getServerName() rather than > getLocalName(), this seems like a bug to me. Admittedly one that only causes > problems in clustered & load balanced environments, but it's just affected > our site so it would be great if it could be fixed for 5.2 final release. A > final release of Tapestry should not have a bug like this in it! > Unless anyone has a convincing argument why it should be this way, of > course... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1372) BaseURLSource uses getLocalPort() rather than getServerPort()
BaseURLSource uses getLocalPort() rather than getServerPort() - Key: TAP5-1372 URL: https://issues.apache.org/jira/browse/TAP5-1372 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Andy Blower Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received." getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the Host header, if any, or the server port where the client connection was accepted on." I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that will only rarely cause a problem, but it's just affected our site so it would be great if it could be fixed for 5.2.5 final release. Unless anyone has a convincing argument why it should be this way, of course... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
