In then end having the clustered sso valve try to find a shared TreeCache but then create its own if it could not find the shared one led to a lot of complexity. Having the valve manage the lifecycle of a created cache is not clean at all. IMO it seems much cleaner to simply externalize the TreeCache and have Tomcat5 pass in the object name of the tree cache service.
I've changed the ClusteredSingleSignOn to work this way (although the code to create the TreeCache is just disabled, and can be reenabled fairly easily if someone disagrees with this approach). I've added a "cacheName" attribute to Tomcat5, and use the value of this attribute to configure any ClusteredSingleSignOn valve. The default value of the attribute is "jboss.cache:service=TreeCache". My next question is where do we want to configure the jboss.cache:service=TreeCache service? For testing I did this in the Tomcat 5 sar's jboss-service.xml, but I'm not sure that's where you want the config to go. The webserver config file seems a non-intuitive place to put a service with such a generic name. But if we do it elsewhere, we need to have a note in the Tomcat sar config file saying where. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3836917#3836917 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3836917 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
