search/query is exactly the benefit I see from a centralized XML-based config repository.
I see your point though. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Scott > M Stark > Sent: Wednesday, November 13, 2002 3:17 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Metadata Service > > > 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 ------------------------------------------------------- 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
