I've been developing a Wicket app on GlassFish v2 and everything works
fine. But when I deploy the application to our production server
which runs Sun Java App Server 7, setResponsePage() isn't working
properly. What's particularly infuriating is that I can see in the
database that the request is
turn the logging to debug level and look at the logs for any clues.
-igor
On Mon, Aug 10, 2009 at 7:22 AM, Jeff Longland wrote:
> I've been developing a Wicket app on GlassFish v2 and everything works
> fine. But when I deploy the application to our production server
> which runs Sun Java App Se
Not much in the way of clues... The ResultPage is being instantiated,
but instead of being rendered the HomePage is reloaded. Everything is
fine on GlassFish v2.. but Sun Java App Server 7 = no dice. I'm at a
loss for what to do next.
On Mon, Aug 10, 2009 at 10:29 AM, Igor Vaynberg wrote:
> tu
no clue either. wicket is just a filter, if it works in one container
it should work in them all. try a couple of other containers, maybe it
will help you to narrow the problem.
-igor
On Mon, Aug 10, 2009 at 12:31 PM, Jeff Longland wrote:
> Not much in the way of clues... The ResultPage is being
Hi,
Just a thought, could it be, that your session times out - so that the
request get's a new sessionID and therefore is sendt to the homepage (which
I assume is your normal start page for your wicket app).
--
View this message in context:
http://www.nabble.com/setResponsePage%28%29-Not-Workin
That's the thing that I can't seem to figure out. The app works on
GlassFish v2 and Tomcat, but I'm having this problem on Sun Java App
Server 7.
As suggested in ##wicket, I switched from the wicket filter to the
wicket servlet - but I'm still having the problem where there are two
"?wicket" in t
Don't know if I am making a fool of myself here but isn't the first
"?wicket" part of the jessionid?
The jsessionid is generated by the container, right? Try changing the
settings for that and see if something becomes different.
/Per
On Tue, Aug 11, 2009 at 3:28 AM, Jeff Longland wrote:
> That'
It doesn't seem to be a session problem. If I take off the first
?wicket: in the URL, it will correctly load the ResultPage - so the
session is still valid. I'm continuing to scratch my head as to why
there are two ?wicket params in the URL... Very frustrating.
On Mon, Aug 10, 2009 at 4:32 PM,
In my quest to solve this problem, I'm mounting all my pages using
HybridUrlCodingStrategy to see if that will negate the extra ?wicket
param in the URL. Worked fine on GlassFish, but as soon as I moved it
over to Sun App Server 7 I got:
Exception in rendering component: [MarkupContainer [Compone
So it looks like it has a problem rendering your stylesheet in the header of
the page. The exception is really due to:
Caused by: java.lang.IllegalArgumentException:
../../../../../../resources/ca.uwo.owl.gradeexport.PublicPage/style.css
at
com.iplanet.ias.web.connector.nsapi.NSAPIRespon
You shouldn't need to mount anything. Did you try to reconfigure the app
server? Typically, "use cookies" instead of "url rewrite"+
On Tue, Aug 11, 2009 at 6:23 PM, Jeff Longland wrote:
> In my quest to solve this problem, I'm mounting all my pages using
> HybridUrlCodingStrategy to see if that w
On Tue, Aug 11, 2009 at 12:23 PM, Jeff Longland wrote:
> In my quest to solve this problem, I'm mounting all my pages using
> HybridUrlCodingStrategy to see if that will negate the extra ?wicket
> param in the URL. Worked fine on GlassFish, but as soon as I moved it
> over to Sun App Server 7 I g
12 matches
Mail list logo