Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 Wicket 1.4 is 1.3 + generics, drop support for 1.3 On Mon, Mar 17, 2008 at 7:08 AM, James Carman [EMAIL PROTECTED] wrote: +1 On 3/17/08, Jay Hogan [EMAIL PROTECTED] wrote: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Explanation of Wicket session management
I am having a tough time understanding how sessions are
created/managed specifically related to the calls
public RequestCycle newRequestCycle(Request request, Response response)
and
public Session newSession(Request request, Response response)
I am creating a new session by overriding the method newSession and
doing something like
public Session newSession(Request request, Response response) {
..
Session session = new Session(request);
return session;
}
This works fine. On subsequent calls, newSession isn't called as a
session is already in place. This is working as expected.
What isn't working is the call
to Session.exists(), this is always returning false when its invoked
in the method newRequestCycle which I override.
public RequestCycle newRequestCycle(Request request, Response response) {
if(Session.exists() certain condiition is met) { - The
method Session.exists() is always returning false
Session mySession = Session.get();
mySession.invalidateNow();
}
}
}
Can someone explain why Session.exists() always returns false, and if
the session truly doesn't exist why newSession isn't called after the
first invocation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explanation of Wicket session management
Yes I did. I was assuming that once newSession is called, on
subsequent calls, the session will be set on a thread local variable.
If that is not the case, what would be the right way to check if a
session has been created.
On Tue, Mar 11, 2008 at 10:32 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Did you read the javadoc for Session#exists() ?
http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
Checks if the Session threadlocal is set in this thread
So not if the session was created or not.
Martijn
On 3/11/08, Rajiv Jivan [EMAIL PROTECTED] wrote:
I am having a tough time understanding how sessions are
created/managed specifically related to the calls
public RequestCycle newRequestCycle(Request request, Response response)
and
public Session newSession(Request request, Response response)
I am creating a new session by overriding the method newSession and
doing something like
public Session newSession(Request request, Response response) {
..
Session session = new Session(request);
return session;
}
This works fine. On subsequent calls, newSession isn't called as a
session is already in place. This is working as expected.
What isn't working is the call
to Session.exists(), this is always returning false when its invoked
in the method newRequestCycle which I override.
public RequestCycle newRequestCycle(Request request, Response response) {
if(Session.exists() certain condiition is met) { - The
method Session.exists() is always returning false
Session mySession = Session.get();
mySession.invalidateNow();
}
}
}
Can someone explain why Session.exists() always returns false, and if
the session truly doesn't exist why newSession isn't called after the
first invocation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem when MIgrating from 1.2 to 1.3 - Parameters removed from HomePage URL
This doesnt work. The QueryStringUrlCodingStrategy class isn't hit.
When going to URL
http://localhost/helloworld?name=John
the code first calls the method
WicketServlet.doGet(..)
which delegates the call to WicketFilter.doGet(..)
As pointed in my first post, WicketFilter.doGet checks if the URL is
the home page and if so, redirects without appending the parameters.
On Fri, Mar 7, 2008 at 8:32 PM, David Leangen [EMAIL PROTECTED] wrote:
I dunno.
I thought you were talking about mounted urls, whose urls displays are
rendered by a UrlCodingStrategy. If you're using the
QueryStringUrlCodingStrategy, then my guess is that it's relevant.
If you want to know for sure, try applying the patch to your local wicket,
or maybe try adding a break and debugging at the lines changed by the patch.
If that doesn't work, then I guess you'd better post your question again.
Cheers,
Dave
-Original Message-
From: Rajiv Jivan [mailto:[EMAIL PROTECTED]
Sent: 8 March 2008 00:28
To: users@wicket.apache.org
Subject: Re: Problem when MIgrating from 1.2 to 1.3 - Parameters
removed from HomePage URL
Are we talking about the same thing? Your patch removes the trailing /
while in my case without the trailing / the parameters aren't
recognized.
On Thu, Mar 6, 2008 at 6:11 PM, David Leangen [EMAIL PROTECTED] wrote:
I've already filed an issue and submitted a patch for this:
https://issues.apache.org/jira/browse/WICKET-1385
Cheers,
Dave
-Original Message-
From: Rajiv Jivan [mailto:[EMAIL PROTECTED]
Sent: 7 March 2008 05:47
To: users@wicket.apache.org
Subject: Problem when MIgrating from 1.2 to 1.3 - Parameters
removed from HomePage URL
We have a site developed using Wicket 1.2. One of the use cases we
have is to pass in a parameter on the home page, and based on that we
perform some actions. e.g
http://localhost/helloworld?name=John
This functionality seem to be broken in 1.3. When passing in
parameters on the home page URL they are stripped. Going through the
Wicket I have narrowed down to an issue in WicketFilter
// Special-case for home page - we redirect to add a
trailing slash.
if (relativePath.length() == 0
!Strings.stripJSessionId(servletRequest.getRequestURI()).endsWith(/))
{
final String redirectUrl =
servletRequest.getRequestURI() + /;
servletResponse.sendRedirect(servletResponse.encodeRedirectURL(red
irectUrl));
return;
}
The only workaround I have is to change the URL to
http://localhost/helloworld/?name=John
Notice the traling / after helloworld
Am I missing something or is this a bug ?
Thanks,
Rajiv
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem when MIgrating from 1.2 to 1.3 - Parameters removed from HomePage URL
Are we talking about the same thing? Your patch removes the trailing /
while in my case without the trailing / the parameters aren't
recognized.
On Thu, Mar 6, 2008 at 6:11 PM, David Leangen [EMAIL PROTECTED] wrote:
I've already filed an issue and submitted a patch for this:
https://issues.apache.org/jira/browse/WICKET-1385
Cheers,
Dave
-Original Message-
From: Rajiv Jivan [mailto:[EMAIL PROTECTED]
Sent: 7 March 2008 05:47
To: users@wicket.apache.org
Subject: Problem when MIgrating from 1.2 to 1.3 - Parameters
removed from HomePage URL
We have a site developed using Wicket 1.2. One of the use cases we
have is to pass in a parameter on the home page, and based on that we
perform some actions. e.g
http://localhost/helloworld?name=John
This functionality seem to be broken in 1.3. When passing in
parameters on the home page URL they are stripped. Going through the
Wicket I have narrowed down to an issue in WicketFilter
// Special-case for home page - we redirect to add a
trailing slash.
if (relativePath.length() == 0
!Strings.stripJSessionId(servletRequest.getRequestURI()).endsWith(/))
{
final String redirectUrl =
servletRequest.getRequestURI() + /;
servletResponse.sendRedirect(servletResponse.encodeRedirectURL(red
irectUrl));
return;
}
The only workaround I have is to change the URL to
http://localhost/helloworld/?name=John
Notice the traling / after helloworld
Am I missing something or is this a bug ?
Thanks,
Rajiv
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem when MIgrating from 1.2 to 1.3 - Parameters removed from HomePage URL
We have a site developed using Wicket 1.2. One of the use cases we
have is to pass in a parameter on the home page, and based on that we
perform some actions. e.g
http://localhost/helloworld?name=John
This functionality seem to be broken in 1.3. When passing in
parameters on the home page URL they are stripped. Going through the
Wicket I have narrowed down to an issue in WicketFilter
// Special-case for home page - we redirect to add a trailing slash.
if (relativePath.length() == 0
!Strings.stripJSessionId(servletRequest.getRequestURI()).endsWith(/))
{
final String redirectUrl = servletRequest.getRequestURI() + /;
servletResponse.sendRedirect(servletResponse.encodeRedirectURL(redirectUrl));
return;
}
The only workaround I have is to change the URL to
http://localhost/helloworld/?name=John
Notice the traling / after helloworld
Am I missing something or is this a bug ?
Thanks,
Rajiv
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
