> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Thursday, November 14, 2002 1:04 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MetaDataRepository Proposal > > > Matt Munz wrote: > >> and the worst part is we have no control over it at runtime. It is > >> way simpler. You'll see. > > > > > > It sounds like you have a vision. Please continue to make the effort > > to get the rest of us into the loop. I want to "see" also, but I'd > > prefer to do so sooner rather than later (not after it's done and > > finished). > > We can just throw away any code I add later. It won't take very long.. > What I am suggesting is a fairly small change. You guys are just > getting way to excited about repository implementation details. I just
I'm not focusing on implementation details, just throwing in ideas... Requirements: - Layered config. i.e. Cluster-wide vs. App-Server vs. Component - Notifications - search capability. - integration with JMX (or leveraging/extending it.) Whatever is decided. > need a place to get information. I really don't care where it comes > from. Until you guys decide on how to load the repository and keep it > in sync with a physical store, I'll just write a very simple one that > uses our current metadata code. I made the interface super simple so it > can be replace later. Also the total size of the code will be a 3-4 > small classes, so we can just toss the entire idea if needed later. > > >> The easiest case for me the read ahead configuration in entity > >> beans. There is no reason for this to be static. In fact it should > >> be manageable at runtime, and if I'm luck I'll be able to pull it > >> off for 4.0. Scott tells me there is a similar need to manage > >> security at > > > > > > Great, now we're getting somewhere. Can you pick one of these > > (perhaps the read ahead), and provide some details? What does the > > server admin have to do that is particularly time consuming? It may > > be obvious to you, but I'd love to hear the details on this one. > > I'm saying that it is currently not possible to changes this type of > information, and if we could the metadata is scattered across the > interceptor and plugins. There is no regular usage, storage, or > management of the current data. I am only proposing a clean separation > between the data and the users (Interceptors) and nothing more. > > >> runtime. There really is no need to shut down an application in > >> production just to change some configuration data. > > > > > > This is *exactly* what MBean Persistence is supposed to do, IMO. > > Feel free to reread that last sentence for added emphasis. Why not > > channel this energy into making MBean Persistence even better? > > Shouldn't any and all server configuration be done through JMX > > anyway? Isn't that the point of JMX in the first place? > > I only want a clean separation. I really don't care what the backing > store is or how we actually managing it. I fully expect my lame > repository to be tossed and replaced with several implementations (until > we figure out the best way). > > >> Even if there is no real need the code is simpler. > > > > > > Simple is the key word. I'm new and all, so feel free to ignore me, > > but this whole thing just sets off my KISS alarm system -- it > > actually sounds rather complicated. > > Go take a look at the TxInterceptors, SecurityInterceptors and the > Containers. 90% of the code is getting data out of the metadata objects > and caching it in an internal hashtable. I am just proposing we > centralize that code into a single interceptor with a repository for > caching. Simpler. > > -dain > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
