Bill, > My thinking is that a "well-crafted object graph or relational db" needs to > be crafted and the code maintained. Most components in JBoss are configured
Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... > via XML files. Why not store this XML in memory with Xerces? XML Objects > provide us with a common, simple, easy way to store config data in memory > and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service > BTW -- I aggree that XPath is cool. What makes a "central" XML file work > better as a metadata database than a well-crafted object graph or > relational > database, in your opinion? My thinking is that a "well-crafted object graph or relational db" needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). >Is there something specific to this metadata > problem that makes a "central" XML file a more attractive solution? > I saying Document as in the Java Object. Not in a XML file stored on disk. > - Matt > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Bill > Burke > Sent: Wednesday, November 13, 2002 2:02 PM > To: [EMAIL PROTECTED] > 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 > > > > > -----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 > > > > ------------------------------------------------------- > 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
