Are you running another server/service on the same machine that would
overwrite the 'jsessionid' cookie?
I was running into this when my CI server (java-based) and auto-built dev
server were on the same machine/IP address. When I would switch from my dev
build to my CI server interface it
Something I just saw... make sure Account implements java.io.Serializable
If it doesn't the session won't be persisted, so it would try to re-create
it each request.
--
View this message in context:
http://www.nabble.com/Session-creation-tp19123581p19125999.html
Sent from the Wicket - User
It depends on the situation and your logging setup. Do this to verify:
- First put a logging statement in WebApplication.newSession(), not
MySession.get()
- Open a new browser window and go to your 'verify' bookmarkable page. You
should see a new session created on each refresh
- Now put
There are a few things going on here... try this and see if it does what you
want it to do. If so reply back and I'll explain what the underlying issue
was:
TextField propertiesName = new TextField(name,new
PropertyModel(pluginProperties, name));
TextField propertiesValue = new
Calling setResponsePage(Page a) increases your session size by the size of a
serialized version of 'a'. If 'a' has a List of data that 'a' is going to
display, that size may be non-trivial. As long as you're okay with that,
it's fine... but I wouldn't recommend doing that unless there's a good
Jonathan Locke wrote:
- (only signed) jars could be automatically picked up by some naming
pattern from maven repos and deployed as live demos
Once a signed jar is identified, what about something like OSGi to deploy
it?
- metadata would define an application name
- load the
If I'm understanding you correctly the input it still sitting on the client
(since the form hasn't been submitted) and the server doesn't have any
knowledge of it when it renders the modal.
You should be able to use AjaxFormComponentUpdatingBehavor(onblur) on the
date field. That will send an
I have only read up on Seam a few times, so help me out where I'm
incorrect...
As far as I can tell Seam uses the conversation scope as a step between
request scope and session scope to persist values across a couple of
requests, for instance a user creation wizard, etc.
I don't know what
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse
This directive lets Apache adjust the URL in the Location, Content-Location
and URI headers on HTTP redirect responses
ProxyPassReverse is the culprit here, not anything to do with Wicket.
Jeremy Levy-3 wrote:
I have
...and after reading your post a little closer, I flipped the directive
parameters in my head. I don't think there's anything wrong with your
ProxyPass directives. Sorry about that...
--
View this message in context:
slf4j is a logging facade with different implementations (though most people
use it plugged into log4j).
The library slf4j-jcl (if you look 80% down the page here:
http://www.slf4j.org/manual.html)
is a way to delegate slf4j calls to jakarta commons logging. You probably
don't want to do that.
+1 for 'Option B': 1.4=generics, drop java 1.4 support
This is coming from a large DoD application (notoriously behind the
technology power curve), the only thing not generified is our UI (Wicket)
stuff.
I think maintaining 'one behind' JVM compatibility is sufficient. I mean,
come on... Java
+1
(Sorry, didn't see this thread before posting in the other)
--
View this message in context:
http://www.nabble.com/-vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-tp16090054p16112208.html
Sent from the Wicket - User mailing list archive at Nabble.com.
13 matches
Mail list logo
