Hi, have any one of you looked at XmlBlaster? (www.xmlBlaster.org). I guess it could really work as a central XmlRepository. XmlBlaster is an XML based MOM. You publish your XML to it and it will save it in an Xml DOM tree, even persist it a RDMB or Xincice.
You can then subscribe to event with an XPath expression (or do a synchronous get (with an XPath). Ok. You can not just subsribe to one element, thats true, but you can subscribe on a "domain" or "config", say MyMessageDrivenBean and get any update notifications for that XML config. Or you could do a get(//x/y/port) (pseudocode!) and get all configs wich contains that element. There are a lot more to XmlBlaster (I have done the JBoss integration thats currently is available in XmlBlaster ;.)) Well, just a thought. //Peter On 13 Nov, Bill Burke wrote: > 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 > > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt >> Munz >> Sent: Wednesday, November 13, 2002 1:26 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] Metadata Service >> >> >> Dain, >> >> > Meta data for an invocation. >> >> I assume you refer here to EJB/servlet invocations. >> >> Just out of curiosity, how is that metadata currently stored? >> >> - Matt >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain >> Sundstrom >> Sent: Wednesday, November 13, 2002 1:13 PM >> To: [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Metadata Service >> >> >> Meta data for an invocation. What are the tx attributes? What is the >> security manager? What are the required roles? What is the readahead >> configuration? That kind of data. >> >> -dain >> >> Matt Munz wrote: >> > Dain/Bill/Scott, >> > >> > Could you clarify this? Metadata for what data? Are you referring to >> > MBeanInfo, or something else? >> > >> > - Matt >> > >> > -----Original Message----- >> > From: [EMAIL PROTECTED] >> > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain >> > Sundstrom >> > Sent: Wednesday, November 13, 2002 12:52 PM >> > To: [EMAIL PROTECTED] >> > Subject: Re: [JBoss-dev] Metadata Service >> > >> > >> > Bill Burke wrote: >> > >> >>Dain and I were IMing. He said Scott was thinking about a MetaData >> >>service... >> >> >> >>My idea for a MetaData/Configuration service would be the ability to >> >>register for callbacks based on XPATHS. So, all config of >> jboss would be >> >>stored in one big XML Document. Components insert their config >> there, and >> >>register for callbacks on this config via XPATHS. So, this >> config can be >> >>managed centrally, yet, components can easily be notified with >> changes via >> > >> > a >> > >> >>simple mechanism. >> > >> > >> > I didn't know you could do that. What spec/library is this in? I want >> > to read it. >> > >> > Scott and I were really only talking about use. We need something like >> > this for component, application, and domain data, but we didn't get into >> > the actually implementation. We just decided to have an metadata loader >> > interceptor and a metadata loader interface for the interceptor to call. >> > The goal is to create a place to put a good metadata service, but >> > those details are for another day (one step at a time). >> > >> > -dain >> > >> > >> > >> > ------------------------------------------------------- >> > 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 >> >> >> -- >> xxxxxxxxxxxxxxxxxxxxxxxx >> Dain Sundstrom >> Chief Architect JBossCMP >> JBoss Group, LLC >> xxxxxxxxxxxxxxxxxxxxxxxx >> >> >> >> ------------------------------------------------------- >> 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 > > > > ------------------------------------------------------- > 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 -- ------------------------------------------------------------ Peter Antman Chief Technology Officer, Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11 ------------------------------------------------------------ ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
