This has merit, but mbeans today do not know about XML in general, they know about attributes. Changes made to the XML config need to propagate as attribute setter invocations. Editing mbean attributes via JMX would have to update the repository. I'm not sure using XML as the manifest memory storage mechanism is a good programming API. Maybe that is just the search/query index representation.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 13, 2002 11:01 AM Subject: RE: [JBoss-dev] Metadata Service > 1. I'm not talking about a central config file...Components register their > XML with this service. MBean, EJB, whatever... > > 2. You know what XPATHs are right? If not, look them up. They are really > cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. > What's not supported, which we would have to write, would be the ability to > register for change notifications via an XPATH. > > Other ideas: > - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. > Services/components registered as listening for changes, recieve > notification. > > - JMX console needs an additional XML editor for MBean attributes that are > XML elements. > > - This sort of centralized service allows you to query, via XPATHS, for all > components that have a "port" attribute for instance. Allows you to do > global things on configuration when you don't know the actual components > that have that type of attribute > > Another thing about configuration I wanted to have is the concept of > Configuration Domains. A component would get configuration by searching a > set of chained configuration domains. > > invocation domain->instance domain->component domain->app server > domain->cluster domain etc... > > So, when a component needs config information, it looks it up via the chain. > Any domain in the chain can override a config value. As the chain is > traversed, if the config info is not there, it searches farther up the > chain. > > This would allow us to have a layered way of obtaining default config > information, or overriding existing configuration at different levels at > different times. > > Bill ------------------------------------------------------- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
