> How much of what you are thinking of would be handled by: > > jmx
Most if not all of it - the JMX timer would be responsible for the async work of taking down and upgrading the module and its dependencies. In addition, the rich client platform would benefit from JMX itself. The only problem is transports between rich clients, but that is out of scope for long enough that the JMX spec should catch up anyway. Besides, JXTA could handle that if I really needed peer-to-peer rather than a more client-server approach. Or, I could just use your built-in clustering using JavaGroups as another option. > > jboss service lifecycle All of it, as I would see a "module" as the equiv of an EJB on the client side from the standpoint of componentized development and the need for component lifecycles. I actually built a similar application that was Swing-based, used JXTA, and resembled something like Groove.. We called it our "Groove Killer" but never got enough $$ after 9-11 to launch it full scale. I'd like to rewrite the framework I built our product on using Jboss and open source it. Something like Eclipse but not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for the "modules" and provided a "Module context" for accessing known platform services, plus a service locator for a more dynamic lookup (including web services on the desktop over JXTA - that was fun!). > > jboss mbean dependencies enhanced by including the version as > a key in the ObjectName and using queries or filter > conditions rather than equality for resolution of dependencies. Jboss dependencies would be a must. I hadn't thought about versioning in the name.. In the past I've shyed away from things like that in a "name", but since its unique to the JMX container, that should be fine.. Like encoding the version number in a OID I guess. > > BTW in jboss 4 clients using the trunk invoker already have jmx client > side: others will follow when I get to work on tx > propagation for the other transports. True, but I would want the JMX container initialized first thing.. Consider the typical startup as something like splash, init Jboss Kernel, Load core platform services, load user services, launch user application. > > david jencks > James ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
