Probably because the domain component of the cookie issued by the
servlet container is the actual hostname, not .my-host.com
(http://wp.netscape.com/newsref/std/cookie_spec.html).
Anyhow, if you ever need to share the session, you'll know where to look :)
Ted Steen wrote:
hah, and now, after further investigation I see that all this is
unnecessary... I get a new session automatically for each new host i
try to access my page from.
I just assumed that the same session would be used.
anyway, it was interesting to see how a persistance stategy was contributed.
2007/9/24, Ted Steen <[EMAIL PROTECTED]>:
the contribution should be to the PersistentFieldManager of course
2007/9/24, Ted Steen <[EMAIL PROTECTED]>:
Ok!
After digging a little deeper I now see that extending the
AbstractSessionPersistentFieldStrategy and letting the prefix contain
the host name should be a solution!
I then contribute this to the ApplicationStatePersistenceStrategySource.
Any objections? :)
2007/9/24, Ted Steen <[EMAIL PROTECTED]>:
A page in our application can be in different states (depending on the
sub domain). When a field is persisted, the state of the page should
be taken in to account.
For example if the page is accessed via the host name a.my-host.com
the page should have its fields persisted for the context A and if the
page is accessed via the host name b.my-host.com the fields should be
persisted for the context B.
its important that if the user browses the page via a.my-host.com and
then changes to b.my-host.com the persistent fields should not cross
over!
I am currently looking for a contribution to some sort of persist
stategy service but I'm not really sure where to look, and also, I'm
not really sure this is the right way.
--
/ted
--
/ted
--
/ted
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
