Hi, That's very good. But just one question, what if a user wants to have different settings for different webapps. For example, maybe he/she wants to view the Japanese version for the local department while keeping the setting for "Far West". How do you account for that?
Thanks! -Yan -----Original Message----- From: Justin Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 1:05 PM To: 'Tomcat Users List' Subject: RE: Please Comment: plan for co-ordinating sessions across mutliple contexts [follow-up: success] I implemented UserDataBeanEvent system I mentioned below, and it appears to be working: A change in the state of a bean in one session is immediately updated in the state of the same bean in a different session for the same user. I created a UserDataBeanEvent object with properties for the property that was changed, the new value, and the user. The UserDataBean signals a singleton, a UserDataBeanEventDispatcher, with the event; the dispatcher then forwards the event to all UserDataBeans for the same user (all UserDataBeans register as listeners with the dispatcher on attaching to a session, and keep a reference to it). The dispatcher is necessary to avoid coupling UserDataBeans directly to each other, with all the discovery problems that would entail. I'll have to do a little more testing to make sure it functioning as I expect, but using the language change link changes the preference for language across all contexts immediately. Yoav mentioned using the SingleSignOn valve, but I require NTLM authentication that's being provided through jCIFS, and I couldn't find any guidance on using that as a realm, which is required for the valve. Anyway, this is one way to unify the user's experience across multiple contexts, and if I'm not mistaken, it's fairly lightweight. Justin -----Original Message----- From: Justin Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:58 AM To: 'Tomcat Users List' Subject: Please Comment: plan for co-ordinating sessions across mutliple c ontexts I have an internal website with several web applications, and thus several contexts. The user's identity is automatically provided via jCIFs (NTLM authentication). At the start of a session, a UserDataBean is created that loads user preferences from a database, including the language preference for the user (the site is English/Japanese bilingual). I've implemented a site-wide filter that checks for changes to preferences sent as a querystring by clicking a link (e.g., clicking on the 'nihon-go' link in the main menu sends the URL [current path]?Language=JA). The filter catches the change, calls the change method in the session's UserDataBean, which changes the preference and updates the database. The experienced among you have already spotted the problem: with multiple contexts there are multiple sessions for the user, and multiple UserDataBeans; changing a preference in one bean doesn't change the preference in another bean, which has already populated its fields from the database. Switch to Japanese in one context, and the change isn't reflected in another. What I think will work is the create a UserDataBeanEvent that is broadcast on changing a preference; all the other beans listen for that event, and on receiving one, check if that event was sent by a bean for the same user as the receiving UserDataBean; if it was, it can update its own fields to the same value (without bothering to update the database since the broadcasting bean did so), and so all the UserDataBeans are co-ordinated across multiple contexts. Does this seem workable? Am I forgetting something, or am I missing something about performance? Is there a lighter-weight way to accomplish the same thing? Thanks, Justin --------------------------------------------------------------------- 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]