I'll take a look, but my QA says it's also happening with Tomcat 6.
All in all, it's Wicket that actually has the problem. There is
something wicket is doing with the URL/ session that is not what
should be happening.
- Brill Pappin
Sent from my mobile.
On 17-Dec-08, at 3:25 PM, "Matthe
Right, I guess it's not correct to say it's a just a Jetty thing. there's a
way to suppress jsessionid in tomcat as well, but I don't know how.
On Wed, Dec 17, 2008 at 2:42 PM, Adriano dos Santos Fernandes <
adrian...@uol.com.br> wrote:
> Matthew Hanlon wrote:
>
>> This is a Jetty thing...
>>
>>
Matthew Hanlon wrote:
This is a Jetty thing...
One way to fix it is to suppress the jsessionid in the url. Jetty allows
you to suppress the jsessionid in the url as a context parameters in the
web.xml or webdefault.xml. Note, if the user does not have cookies enabled
this will cause problems.
This is a Jetty thing...
One way to fix it is to suppress the jsessionid in the url. Jetty allows
you to suppress the jsessionid in the url as a context parameters in the
web.xml or webdefault.xml. Note, if the user does not have cookies enabled
this will cause problems.
In your web.xml:
For us its consistent and predictable... it always happens when the
session has expired.
- Brill Pappin
On 17-Dec-08, at 12:26 PM, Adriano dos Santos Fernandes wrote:
I'm having similar errors (not 404, but internal error, sorry but do
not have stack trace right now, and is not always r
I'm having similar errors (not 404, but internal error, sorry but do not
have stack trace right now, and is not always reproducible). I use
Wicket 1.4-rc1 and auth-roles with Tomcat6.
It seems that when there is no session, just after the login the error
happens. It was a NoMethodFound from IF
We are getting a consistent 404 error during our first login.
it seems to be appending the jsessionid= param and wicket doesn't seem
to like it.
This usually happens on the first login of the day:
the app redirects to the login page with the session id appended:
Goto: h
