> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt > Munz > Sent: Wednesday, November 13, 2002 3:30 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Metadata Service > > > 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
I don't like DTDs and XML schemas for the very reason that they force you to update the DTD every time a new type of configuration comes along. The Components themselves should do the validation of their particular part of the large XML file/document. Consider an ISV who wants to add their new component to JBoss with new complex configuration. They have to modify our DTD? No, they shouldn't have to and we shouldn't allow them. (Don't know much about XML Schemas....maybe they address these issues?) > 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? > What I was trying to suggest is that complex xml config data is modified via a file or through some Management Console at runtime. Components can register via XPATHS to listen to this changed data. They are notified and update their local config, construct new objects, whatever... Hmmm...I'm starting to see what you're saying. MBeans already have notifications and ways to query, right? > 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? > XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. > - 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 ------------------------------------------------------- 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
