In UserDataBean, there are two versions of each setter method for each property: a simple, public setter method per the JavaBean convention, and a private setter that takes a boolean flag indicating whether or not the setting should be local to the bean or propogate to the system by saving the change in the database and notifying the other beans. The public setter calls the private setter with a true flag, so that used from the outside, setting a bean property is system-wide and persistant. Internally, the private method is called with a false flag, for example when the bean is constructed and retrieves its settings from the database, so that changes are local. When the bean receives an event, the event method calls the private setter with a false flag, indicating a strictly local change and not updating the database (which was updated by the bean that originated the change).
So, if you didn't want to have per app language preferences stored in the database (which you'd need for persistance), then you'd split the flag on the private setter into two so that updating the database isn't tied to spreading the change to other beans. I suppose you could then store the app unique language setting somewhere else, but the result would be a change to a bean that doesn't propogate to the user's other session beans. It's really a question of how the bean handles changes--whether or not it chooses to propogate a change. All the BeanEvent object and Dispatcher do is allow for event-based communication based on arbitrary criteria (username, in my case). -----Original Message----- From: Yansheng Lin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 2:40 PM To: 'Tomcat Users List' Subject: RE: Please Comment: plan for co-ordinating sessions across mutliple contexts [follow-up: success] 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
