Re: The active page name has not been specified
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up top
and I think I'm using defer true, so I'm not sure if that has something to
do with it. I also have some logic in my onActivate method, but I figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be
sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015
x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
Re: The active page name has not been specified
On Wed, Apr 1, 2015 at 9:22 AM, George Christman gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works with
one and not the other is that the authorization is enforced at a different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the active
page, whereas url-based authorization happens before. There's nothing wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form
is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up top
and I think I'm using defer true, so I'm not sure if that has something
to
do with it. I also have some logic in my onActivate method, but I figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping
Re: The active page name has not been specified
Should I file a bug with tynamo jira?
On Apr 1, 2015 3:40 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
On Wed, Apr 1, 2015 at 9:22 AM, George Christman gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works with
one and not the other is that the authorization is enforced at a different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the active
page, whereas url-based authorization happens before. There's nothing wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor
urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman
gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form
is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up
top
and I think I'm using defer true, so I'm not sure if that has something
to
do with it. I also have some logic in my onActivate method, but I
figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone
id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn
btn-default
data-dismiss=modal${message:close-label}/button
Re: The active page name has not been specified
Github https://github.com/tynamo/tapestry-security, might just as well.
Kalle
On Wed, Apr 1, 2015 at 1:29 PM, George Christman gchrist...@cardaddy.com
wrote:
Should I file a bug with tynamo jira?
On Apr 1, 2015 3:40 PM, Kalle Korhonen kalle.o.korho...@gmail.com
wrote:
On Wed, Apr 1, 2015 at 9:22 AM, George Christman
gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works
with
one and not the other is that the authorization is enforced at a
different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the
active
page, whereas url-based authorization happens before. There's nothing
wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor
urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman
gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My
form
is
very complicating, so I'll try breaking it down into something
simpler
tomorrow and hopefully pin point the issue. My submit buttons are up
top
and I think I'm using defer true, so I'm not sure if that has
something
to
do with it. I also have some logic in my onActivate method, but I
figured
the redirection should have been happening before that method was
ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find
the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone
id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup
Re: The active page name has not been specified
Hey Kalle, just checking in with you to see if you happened to have anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the issue is
caused by tapestry-security operating as part of the httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may be
pushing around some shard edge there. It's also possible that some change
in the core tapestry has caused the issue to surface. It may be that the
issue happens exactly when the security library is trying to deal with the
expired session. In your stack trace, you'll see that the exception
happens
way before the active page is being set. Just a note that you cannot
simply
return a full page response to an ajax request (as you try to do in your
example). What's your exact version of T5 you are using? I'll see if we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax form and
I'm using tapestry-security. When my session times out and an form
action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap 5.4
and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException: The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41)
at $ComponentRequestFilter_18c715615aaeb.handleComponentEvent(Unknown
Source) at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source)
at $ComponentRequestHandler_18c715615aac8.handleComponentEvent(Unknown
Source) at
Re: The active page name has not been specified
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to have anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the issue
is
caused by tapestry-security operating as part of the httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may be
pushing around some shard edge there. It's also possible that some
change
in the core tapestry has caused the issue to surface. It may be that the
issue happens exactly when the security library is trying to deal with
the
expired session. In your stack trace, you'll see that the exception
happens
way before the active page is being set. Just a note that you cannot
simply
return a full page response to an ajax request (as you try to do in your
example). What's your exact version of T5 you are using? I'll see if we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax form
and
I'm using tapestry-security. When my session times out and an form
action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap
5.4
and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException: The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41)
at
Re: The active page name has not been specified
I think I've seen the error during debugging here and there in beta-22...
We're not using tapestry security, I can't remember if it happens when I'm
too slow in the javascript debugger or it is during serverside debugging -
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar to the one
in tynamo conversations, so requests may arrive while things are locked up
in either debugger - but I cannot remember if this has happened on pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception. What
version of tapestry-security are you using? I'm using 0.6.2? Are you
submitting with an ajax form? I can reproduce this very easily by forcing
my session to expire locally by advancing my computers time and then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets fixed, I
can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
dimitris.zen...@gmail.com wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman
gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the
issue
is
caused by tapestry-security operating as part of the
httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may
be
pushing around some shard edge there. It's also possible that some
change
in the core tapestry has caused the issue to surface. It may be
that
the
issue happens exactly when the security library is trying to deal
with
the
expired session. In your stack trace, you'll see that the exception
happens
way before the active page is being set. Just a note that you
cannot
simply
return a full page response to an ajax request (as you try to do in
your
example). What's your exact version of T5 you are using? I'll see
if
we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax
form
and
I'm using tapestry-security. When my session times out and an
form
action
is clicked, I get the The active page name has not been
specified
exception. I found the code throwing the exception, I'm just not
sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page
when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using
Tap
5.4
and
I've been seeing this quite often, but can't seem to reproduce
it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException:
The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
Re: The active page name has not been specified
Dimitris, I just tested in 5.4-beta-28 with the same exception. What
version of tapestry-security are you using? I'm using 0.6.2? Are you
submitting with an ajax form? I can reproduce this very easily by forcing
my session to expire locally by advancing my computers time and then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets fixed, I can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
dimitris.zen...@gmail.com wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman
gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the
issue
is
caused by tapestry-security operating as part of the
httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may
be
pushing around some shard edge there. It's also possible that some
change
in the core tapestry has caused the issue to surface. It may be that
the
issue happens exactly when the security library is trying to deal
with
the
expired session. In your stack trace, you'll see that the exception
happens
way before the active page is being set. Just a note that you cannot
simply
return a full page response to an ajax request (as you try to do in
your
example). What's your exact version of T5 you are using? I'll see if
we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax
form
and
I'm using tapestry-security. When my session times out and an form
action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not
sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page
when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap
5.4
and
I've been seeing this quite often, but can't seem to reproduce
it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException:
The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
Re: The active page name has not been specified
I'll test it in beta-28, but until that validation bug gets fixed, I can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the
issue
is
caused by tapestry-security operating as part of the
httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may be
pushing around some shard edge there. It's also possible that some
change
in the core tapestry has caused the issue to surface. It may be that
the
issue happens exactly when the security library is trying to deal with
the
expired session. In your stack trace, you'll see that the exception
happens
way before the active page is being set. Just a note that you cannot
simply
return a full page response to an ajax request (as you try to do in
your
example). What's your exact version of T5 you are using? I'll see if
we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax form
and
I'm using tapestry-security. When my session times out and an form
action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not
sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page
when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap
5.4
and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException:
The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
Re: The active page name has not been specified
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^ t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman gchrist...@cardaddy.com
wrote:
And your wrapping your form in a zone too? Sorry, I just want to be sure we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I also
tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute (Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted the
user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in
beta-22...
We're not using tapestry security, I can't remember if it happens when
I'm
too slow in the javascript debugger or it is during serverside
debugging
-
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar to the
one
in tynamo conversations, so requests may arrive while things are locked
up
in either debugger - but I cannot remember if this has happened on
pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman
gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception. What
version of tapestry-security are you using? I'm using 0.6.2? Are you
submitting with an ajax form? I can reproduce this very easily by
forcing
my session to expire locally by advancing my computers time and then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman
gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets fixed,
I
can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
dimitris.zen...@gmail.com wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman
gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to
have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally,
the
issue
is
caused by tapestry-security operating as part of the
httpservletrequest
pipeline, before the active page is
Re: The active page name has not been specified
When you include a tynamo dependency do you exclude the tapestry-core and
tapestry-ioc like I did? If you don't then you end up having tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^ t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=department.name
t:mixins=formGroup/
t:select t:id=parent t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder
t:mixins=formGroup t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup t:blankoption=ALWAYS
t:validate=required/
t:textarea t:id=notes t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I also
tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute (Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted the
user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in
beta-22...
We're not using tapestry security, I can't remember if it happens when
I'm
too slow in the javascript debugger or it is during serverside
debugging
-
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar to
the
one
in tynamo conversations, so requests may arrive while things are
locked
up
in either debugger - but I cannot remember if this has happened on
pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman
gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception. What
version of tapestry-security are you using? I'm using 0.6.2? Are you
submitting with an ajax form? I can reproduce this very easily by
forcing
my session to expire locally by advancing my computers time and then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman
gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets
fixed, I
can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
dimitris.zen...@gmail.com wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman
gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to
have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George
Re: The active page name has not been specified
And your wrapping your form in a zone too? Sorry, I just want to be sure we are doing everything the same. On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios dimitris.zen...@gmail.com wrote: Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Java 1.8.0_40 Google chrome Version 41.0.2272.101 (64-bit) jetty-distribution-9.2.5.v20141112 Tapestry 5.4-beta28 dependency groupIdorg.tynamo/groupId artifactIdtapestry-security/artifactId version0.6.2/version exclusions exclusion groupIdorg.apache.tapestry/groupId artifactIdtapestry-core/artifactId /exclusion exclusion groupIdorg.apache.tapestry/groupId artifactIdtapestry-ioc/artifactId /exclusion /exclusions /dependency I am doing the same test as you do (Moving the clock forward). I also tried 1.Removing the cookie 2.Normal session time out by setting the time out to 1 minute (Web.xml) 3.Doing session invalidate. All of those tests had the same result.Once the form is submitted the user is redirected back to login page. On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen mailingl...@nesluop.dk wrote: I think I've seen the error during debugging here and there in beta-22... We're not using tapestry security, I can't remember if it happens when I'm too slow in the javascript debugger or it is during serverside debugging - I'll keep an eye out for it. We have a conversation moderator in play on some pages - similar to the one in tynamo conversations, so requests may arrive while things are locked up in either debugger - but I cannot remember if this has happened on pages supporting conversations. -- Chris On Tue, Mar 31, 2015 at 7:52 PM, George Christman gchrist...@cardaddy.com wrote: Dimitris, I just tested in 5.4-beta-28 with the same exception. What version of tapestry-security are you using? I'm using 0.6.2? Are you submitting with an ajax form? I can reproduce this very easily by forcing my session to expire locally by advancing my computers time and then submitting an ajax form. It happens every single time. On Tue, Mar 31, 2015 at 1:36 PM, George Christman gchrist...@cardaddy.com wrote: I'll test it in beta-28, but until that validation bug gets fixed, I can't upgrade to it. On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios dimitris.zen...@gmail.com wrote: FYI just tested with 5.4-beta28 and I don't have such problem On Tue, Mar 31, 2015 at 5:38 PM, George Christman gchrist...@cardaddy.com wrote: Hey Kalle, just checking in with you to see if you happened to have anymore info on this issue. On Wed, Mar 25, 2015 at 4:05 PM, George Christman gchrist...@cardaddy.com wrote: Thanks Kalle, were using 5.4-beta24 On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Sorry, I forgot to reply to your earlier post. Fundamentally, the issue is caused by tapestry-security operating as part of the httpservletrequest pipeline, before the active page is already set up. The library is internally setting up request globals etc. where needed but you may be pushing around some shard edge there. It's also possible that some change in the core tapestry has caused the issue to surface. It may be that the issue happens exactly when the security library is trying to deal with the expired session. In your stack trace, you'll see that the exception happens way before the active page is being set. Just a note that you cannot simply return a full page response to an ajax request (as you try to do in your example). What's your exact version of T5 you are using? I'll see if we have a test for this case and try to reproduce. Kalle On Wed, Mar 25, 2015 at 6:07 AM, George Christman gchrist...@cardaddy.com wrote: So I've been able to finally reproduce this bug. I have an ajax form and I'm using tapestry-security. When my session times out and an form action is clicked, I get the The active page name has not been specified exception. I found the code throwing the exception, I'm just not sure why this is happening to begin with. https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java line 86. Shouldn't the page automatically be redirected to the login page when the user session has timed out and an action has been performed. I even tried this without
Re: The active page name has not been specified
Thanks Dimitris, I'm guessing there is a bug in my code. I went to another
page in my app where I have an ajaxformloop and it appeared to redirect
without issue. I'm going to have to dig deeper tomorrow to find the cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the tapestry-core and
tapestry-ioc like I did? If you don't then you end up having tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=department.name
t:mixins=formGroup/
t:select t:id=parent t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015
x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I also
tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute
(Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted the
user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen
mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in
beta-22...
We're not using tapestry security, I can't remember if it happens
when
I'm
too slow in the javascript debugger or it is during serverside
debugging
-
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar to
the
one
in tynamo conversations, so requests may arrive while things are
locked
up
in either debugger - but I cannot remember if this has happened on
pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman
gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception.
What
version of tapestry-security are you using? I'm using 0.6.2? Are
you
submitting with an ajax form? I can reproduce this very easily by
forcing
my session to expire locally by advancing my computers time and
then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman
gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets
fixed, I
can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
Re: The active page name has not been specified
Yes, still having the same issue, but only on the my Ajax form. My form is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up top
and I think I'm using defer true, so I'm not sure if that has something to
do with it. I also have some logic in my onActivate method, but I figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to redirect
without issue. I'm going to have to dig deeper tomorrow to find the cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which might
be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be
sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015
x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I
also
tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute
(Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted
the
user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen
mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in
beta-22...
We're not using tapestry security, I can't remember if it
happens
when
I'm
too slow in the javascript debugger or it is during serverside
debugging
-
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar
to
the
one
in tynamo conversations, so requests may arrive
Re: The active page name has not been specified
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I also tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute (Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted the user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in beta-22...
We're not using tapestry security, I can't remember if it happens when I'm
too slow in the javascript debugger or it is during serverside debugging -
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar to the one
in tynamo conversations, so requests may arrive while things are locked up
in either debugger - but I cannot remember if this has happened on pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception. What
version of tapestry-security are you using? I'm using 0.6.2? Are you
submitting with an ajax form? I can reproduce this very easily by forcing
my session to expire locally by advancing my computers time and then
submitting an ajax form. It happens every single time.
On Tue, Mar 31, 2015 at 1:36 PM, George Christman
gchrist...@cardaddy.com
wrote:
I'll test it in beta-28, but until that validation bug gets fixed, I
can't
upgrade to it.
On Tue, Mar 31, 2015 at 12:46 PM, Dimitris Zenios
dimitris.zen...@gmail.com wrote:
FYI just tested with 5.4-beta28 and I don't have such problem
On Tue, Mar 31, 2015 at 5:38 PM, George Christman
gchrist...@cardaddy.com
wrote:
Hey Kalle, just checking in with you to see if you happened to have
anymore
info on this issue.
On Wed, Mar 25, 2015 at 4:05 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen
kalle.o.korho...@gmail.com wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the
issue
is
caused by tapestry-security operating as part of the
httpservletrequest
pipeline, before the active page is already set up. The library
is
internally setting up request globals etc. where needed but you
may
be
pushing around some shard edge there. It's also possible that
some
change
in the core tapestry has caused the issue to surface. It may be
that
the
issue happens exactly when the security library is trying to deal
with
the
expired session. In your stack trace, you'll see that the
exception
happens
way before the active page is being set. Just a note that you
cannot
simply
return a full page response to an ajax request (as you try to do
in
your
example). What's your exact version of T5 you are using? I'll see
if
we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman
gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax
form
and
I'm using tapestry-security. When my session times out and an
form
action
is clicked, I get the The active page name has not been
specified
exception. I found the code throwing the exception, I'm just
not
sure
why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login
page
when
the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
Re: The active page name has not been specified
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to another
page in my app where I have an ajaxformloop and it appeared to redirect
without issue. I'm going to have to dig deeper tomorrow to find the cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the tapestry-core and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=department.name
t:mixins=formGroup/
t:select t:id=parent t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be
sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015
x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
/exclusion
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-ioc/artifactId
/exclusion
/exclusions
/dependency
I am doing the same test as you do (Moving the clock forward). I
also
tried
1.Removing the cookie
2.Normal session time out by setting the time out to 1 minute
(Web.xml)
3.Doing session invalidate.
All of those tests had the same result.Once the form is submitted
the
user
is redirected back to login page.
On Tue, Mar 31, 2015 at 9:35 PM, Chris Poulsen
mailingl...@nesluop.dk
wrote:
I think I've seen the error during debugging here and there in
beta-22...
We're not using tapestry security, I can't remember if it happens
when
I'm
too slow in the javascript debugger or it is during serverside
debugging
-
I'll keep an eye out for it.
We have a conversation moderator in play on some pages - similar
to
the
one
in tynamo conversations, so requests may arrive while things are
locked
up
in either debugger - but I cannot remember if this has happened on
pages
supporting conversations.
--
Chris
On Tue, Mar 31, 2015 at 7:52 PM, George Christman
gchrist...@cardaddy.com
wrote:
Dimitris, I just tested in 5.4-beta-28 with the same exception.
What
version of tapestry-security are you using? I'm using 0.6.2? Are
you
submitting with an ajax form? I can reproduce this very easily
by
forcing
my session to expire locally by advancing my computers time and
then
submitting an ajax form. It happens every single time.
Re: The active page name has not been specified
So I've been able to finally reproduce this bug. I have an ajax form and
I'm using tapestry-security. When my session times out and an form action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not sure why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page when the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap 5.4 and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException: The active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41)
at $ComponentRequestFilter_18c715615aaeb.handleComponentEvent(Unknown
Source) at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown Source)
at $ComponentRequestHandler_18c715615aac8.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:48)
at $Dispatcher_18c715615aac9.dispatch(Unknown Source) at
$Dispatcher_18c715615aac2.dispatch(Unknown Source) at
org.apache.tapestry5.modules.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:305)
at org.healthresearch.etss.services.AppModule$1.service(AppModule.java:302)
at $RequestFilter_18c715615aac1.service(Unknown Source) at
$RequestHandler_18c715615aac3.service(Unknown Source) at
org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
at $RequestHandler_18c715615aac3.service(Unknown Source) at
org.apache.tapestry5.modules.TapestryModule$3.service(TapestryModule.java:844)
at $RequestHandler_18c715615aac3.service(Unknown Source) at
org.apache.tapestry5.modules.TapestryModule$2.service(TapestryModule.java:834)
at $RequestHandler_18c715615aac3.service(Unknown Source) at
org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:89)
at $RequestHandler_18c715615aac3.service(Unknown Source) at
$RequestHandler_18c715615aa81.service(Unknown Source) at
org.apache.tapestry5.modules.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:256)
at
org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:56)
at
org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:54)
at
Re: The active page name has not been specified
Sorry, I forgot to reply to your earlier post. Fundamentally, the issue is
caused by tapestry-security operating as part of the httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may be
pushing around some shard edge there. It's also possible that some change
in the core tapestry has caused the issue to surface. It may be that the
issue happens exactly when the security library is trying to deal with the
expired session. In your stack trace, you'll see that the exception happens
way before the active page is being set. Just a note that you cannot simply
return a full page response to an ajax request (as you try to do in your
example). What's your exact version of T5 you are using? I'll see if we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax form and
I'm using tapestry-security. When my session times out and an form action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not sure why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page when the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap 5.4 and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException: The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41)
at $ComponentRequestFilter_18c715615aaeb.handleComponentEvent(Unknown
Source) at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source)
at $ComponentRequestHandler_18c715615aac8.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:48)
at $Dispatcher_18c715615aac9.dispatch(Unknown Source) at
$Dispatcher_18c715615aac2.dispatch(Unknown Source) at
org.apache.tapestry5.modules.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:305)
at
org.healthresearch.etss.services.AppModule$1.service(AppModule.java:302)
at $RequestFilter_18c715615aac1.service(Unknown Source) at
$RequestHandler_18c715615aac3.service(Unknown
Re: The active page name has not been specified
Thanks Kalle, were using 5.4-beta24
On Wed, Mar 25, 2015 at 1:09 PM, Kalle Korhonen kalle.o.korho...@gmail.com
wrote:
Sorry, I forgot to reply to your earlier post. Fundamentally, the issue is
caused by tapestry-security operating as part of the httpservletrequest
pipeline, before the active page is already set up. The library is
internally setting up request globals etc. where needed but you may be
pushing around some shard edge there. It's also possible that some change
in the core tapestry has caused the issue to surface. It may be that the
issue happens exactly when the security library is trying to deal with the
expired session. In your stack trace, you'll see that the exception happens
way before the active page is being set. Just a note that you cannot simply
return a full page response to an ajax request (as you try to do in your
example). What's your exact version of T5 you are using? I'll see if we
have a test for this case and try to reproduce.
Kalle
On Wed, Mar 25, 2015 at 6:07 AM, George Christman gchrist...@cardaddy.com
wrote:
So I've been able to finally reproduce this bug. I have an ajax form and
I'm using tapestry-security. When my session times out and an form action
is clicked, I get the The active page name has not been specified
exception. I found the code throwing the exception, I'm just not sure why
this is happening to begin with.
https://github.com/apache/tapestry-5/blob/5.4-beta-26/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AjaxPartialResponseRendererImpl.java
line 86.
Shouldn't the page automatically be redirected to the login page when the
user session has timed out and an action has been performed.
I even tried this without any success.
Object onActivate() throws Exception {
if (request.isRequestedSessionIdValid()) {
//some code
}
return Login.class;
}
Any thoughts on how to repair this issue?
On Thu, Mar 19, 2015 at 12:54 PM, George Christman
gchrist...@cardaddy.com
wrote:
Could someone help me to understand this exception? I'm using Tap 5.4
and
I've been seeing this quite often, but can't seem to reproduce it.
The active page name has not been
specified.org.apache.tapestry5.ioc.internal.OperationException: The
active
page name has not been specified. at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:184)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:118)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.invokeQueuedRenderer(DeferredResponseRenderer.java:73)
at
org.apache.tapestry5.internal.services.DeferredResponseRenderer.handleComponentEvent(DeferredResponseRenderer.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ProductionModeUnknownComponentFilter.handleComponentEvent(ProductionModeUnknownComponentFilter.java:50)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55)
at
org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:110)
at
org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:84)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1264)
at
org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47)
at $ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source) at
org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41)
at $ComponentRequestFilter_18c715615aaeb.handleComponentEvent(Unknown
Source) at
$ComponentRequestHandler_18c715615aaee.handleComponentEvent(Unknown
Source)
at $ComponentRequestHandler_18c715615aac8.handleComponentEvent(Unknown
Source) at
org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:48)
at $Dispatcher_18c715615aac9.dispatch(Unknown Source) at
$Dispatcher_18c715615aac2.dispatch(Unknown Source) at
