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 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

Reply via email to