Bill, > Components register their XML with this service. MBean, EJB, whatever...
For MBeans, you're talking about *-service.xml, right? Would this apply also to XMBean XML? > JMX console needs an additional XML editor for MBean attributes that are XML elements. I think it would be great to expand the JMX console to handle all sorts of common types, for input and output. Collection obects and arrays in particular would be a powerful addition. I believe that the PropertyEditor mechanism may be useful for this. I always thought that w3c DOM Elements were transient objects -- a stepping stone between XML text and full-fledged objects. I'm curious -- why do they need to be stored as MBean attributes? 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? Is there something specific to this metadata problem that makes a "central" XML file a more attractive solution? - 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
