https://issues.apache.org/jira/browse/TAPESTRY-2765
Andreas Andreou wrote:
I tried this example (and some non-ajax permutations) and i indeed see
different behavior with cookies enabled vs. disabled.
If that's not expected, then a new issue should be raised in jira.
On Fri, May 28, 2010 at 09:
I tried this example (and some non-ajax permutations) and i indeed see
different behavior with cookies enabled vs. disabled.
If that's not expected, then a new issue should be raised in jira.
On Fri, May 28, 2010 at 09:51, Paul Stanton wrote:
> well, its worth discussing - the question being sho
well, its worth discussing - the question being should tapestry work
with cookies disabled.
i did notice that the jsessionid param was being appended to the form's
action however submitting said form had unexpected results.
its no longer holding me up, but i have worked on apps where cookies
On Fri, 28 May 2010 00:31:18 -0300, Paul Stanton
wrote:
Surely this is a bug in t5 ...
I disagree. HTTP is purely stateless. Session keeping is the container's
(server) responsibility, not Tapestry's. With cookies disabled, the only
way to find out what is the session is appending the ;
Sorry guys, I found the problem.
I had disabled cookies on the webapp.
Surely this is a bug in t5 ...
in that with cookies disabled, an ajax form submit acquires a new
session every time?
Regards, p.
Paul Stanton wrote:
Here is a concrete example which I've constructed separate to the rest
Here is a concrete example which I've constructed separate to the rest
of my app to exclude any quirks intruduced by it's complexity:
public class Start
{
private final static Logger LOG = Logger.getLogger(Start.class);
@Inject
private ComponentResources reso
Actually, the 2nd request (which clears the session) is not a manually
created Ajax.Request. Sorry for the confusion.
It's actually a async form submit, and to simplify the issue somewhat
every submit of this form prints a different sessionId:
@Inject
private Ht
Thiago,
I tried with @SessionState(create=false) and the same occurs (testing
the field for null).
I also tried (as a sanity check) to inject HttpRequest and manage the
session attribute manually. Interestingly, the session Id is changing!
This must be the cause - somehow my manual Ajax.Req
I'm with Thiago, what you are describing doesn't make sense. It
doesn't matter how you make the request the session stored attributes
should still be there. Since it doesn't make sense I'll ask all the
dumb question:
Are you setting the value somewhere? If you have a setter for it try
set
On Thu, 27 May 2010 23:26:13 -0300, Paul Stanton
wrote:
I've also tried with @SessionState with no luck.
Please post your code. Without it, it will be very hard to understand
what's happening.
I'm imagining it's because one request goes to componentA (where the
persistent field is) th
On Thu, 27 May 2010 23:32:38 -0300, Paul Stanton
wrote:
Hi Thiago,
Hi!
please bare with me... I'm not imagining it. I'm guessing it's something
to do with my manually created ajax request...
Tapestry's session handling works the same regardless how the request was
made.
I'm not ins
Hi Thiago,
please bare with me... I'm not imagining it. I'm guessing it's something
to do with my manually created ajax request...
I'm not inspecting via debugger, I'm testing the value of the field in
code, ie:
via @Persist("session")
if (persistentField == null) LOG.debug("state reset");
I've also tried with @SessionState with no luck.
I'm imagining it's because one request goes to componentA (where the
persistent field is) the other goes to componentB. The subsequent
request to componentA reveals that the persistent field is reset. ie:
1. Ajax.Request to componentA via actio
On Thu, 27 May 2010 23:08:37 -0300, Paul Stanton
wrote:
Hi all,
Hi!
I've noticed that the value for the apparently persistent field is reset
to null when the second type of ajax requests are made ... this may be
because the actions point to different components as listeners.
How you
14 matches
Mail list logo
