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
- [JBoss-dev] MetaDataRepository Proposal Dain Sundstrom
- Re: [JBoss-dev] MetaDataRepository Proposal David Jencks
- Re: [JBoss-dev] MetaDataRepository Proposal Dain Sundstrom
- RE: [JBoss-dev] MetaDataRepository Proposal Hiram Chirino
- Re: [JBoss-dev] MetaDataRepository Propos... Dain Sundstrom
- RE: [JBoss-dev] MetaDataRepository P... Bill Burke
- Re: [JBoss-dev] MetaDataReposito... Dain Sundstrom
- RE: [JBoss-dev] MetaDataRepository Proposal Matt Munz
- RE: [JBoss-dev] MetaDataRepository Propos... Dain Sundstrom
- RE: [JBoss-dev] MetaDataRepository P... Bill Burke
- Re: [JBoss-dev] MetaDataReposito... Dain Sundstrom
- Re: [JBoss-dev] MetaDataRepository Proposal Peter Fagerlund
- Re: [JBoss-dev] MetaDataRepository Proposal Dain Sundstrom