Re: [JBoss-dev] MetaDataRepository Proposal
Bill Burke wrote: 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. Understood. Do you see my point of view? From my point of view they are implementation details. The consumer of the data in a repository doesn't really need to know that it is layers, that is has notification, that complex searches can happen under the covers, etc. All the consumer wants to know is "what is the tx attribute for this invocation?" -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
RE: [JBoss-dev] MetaDataRepository Proposal
> -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
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 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
Re: [JBoss-dev] MetaDataRepository Proposal
Peter Fagerlund wrote:
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
maybe add
void setJDBCBackend(url, u, p);
void serConf(path);
Implementation detail.
The final problem is how do we keep this repository in sync with the
physical store. For this I would guess we need some sort of listener
or notification system. This isn't one of my current problems so I
haven't thought about it too much.
hmmm ... me thinks hsqldb is way underused as a admin tool in jboss
today ... hehe ... i am biased ... yes ...
hsqldb has a pluggable listener called Trigger.class with one method
public void fire(String trigName, String tabName, Object row[]);
so when an jboss instance starts ... it would ofcource need some core
configuration either as a xml-file or class.ser ? then one could start a
"jdbc:hsqldb:hsql:." instance and go get configuration - also when db
changes it will notify other db's throughout *hsqldbr and there is our
"distributed metadata repository" ... all sql, all libs in there already
... cool ...
Sure, but to me this is just an implementation detail of whatever
repository the admin decides to use.
-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
Re: [JBoss-dev] MetaDataRepository Proposal
Bill Burke wrote: In all honesty Dain, I don't think this is a simplification. And Hiram's right. Attaching interfaces with the aspect framework should give you the functionality you want here of adding read-ahead apis. How would it get into the invocation? EasilyIts just another invocation on the invocation stack. A client interceptor intercepts the setReadAhead method, and stuff 500 into some variable. With regular calls, that same interceptor attaches the read-ahead value into the invocation object. CMP picks up the value from the invocation if it is there. Sure but where does the client put the info while it is waiting for an invocation? What about the server side? Where does the server store the defaults (assuming they did not come from the client) while waiting for the invocations? -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
RE: [JBoss-dev] MetaDataRepository Proposal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Thursday, November 14, 2002 12:55 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MetaDataRepository Proposal > > > Hiram Chirino wrote: > >>David, > >> > >>Actually it simplifies the code. If you take a look at our interceptor > >>stack most have a ton of code just to load and maintain the metadata, > > > > > > Yes there is alot of Metadata now. 1/2 the ton of code that we > have there > > is just taking XML and creating a metadata objects. I think > that something > > like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) > should be able > > eliminate that code. A tool that will take XML config and generate the > > Metadata objects that our interceptors can use directly. > > Sure. It is just a detail. I want to put in an interface between the > interceptor and the metadata repository. > > >>and the worst part is we have no control over it at runtime. It is way > >>simpler. You'll see. > >> > > > > > > I agree there. But wouldn't it be simpler if we just exposed > an API to the > > client that would allow him to modify the metadata (thus > turning something > > that is static now, into something dynamic)? > > > > For example. Say you have a CMP bean x, and the configuration API is > > exposed via an aspect, then on the client side you would do: > > > > CMPConfiguration c = (CMPConfiguration)x; > > c.setReadAhead( 500 ); > > > > And the would in turn create a Invocation with > method=setReadAhead that the > > CMP interceptor would handle by updating the metadata > configuration for the > > bean. > > > > Does this make sense? Are you trying to achieve something > similar but in a > > more automated way? > > This could easily happen but is not my motivation. I really just want > simplify the containers and interceptors. Anyway, where would this data > live? How would it get into the invocation? My guess is that the same > repository code could be used on the client side for client specific > configuration, but maybe it won't work for that. > In all honesty Dain, I don't think this is a simplification. And Hiram's right. Attaching interfaces with the aspect framework should give you the functionality you want here of adding read-ahead apis. How would it get into the invocation? EasilyIts just another invocation on the invocation stack. A client interceptor intercepts the setReadAhead method, and stuff 500 into some variable. With regular calls, that same interceptor attaches the read-ahead value into the invocation object. CMP picks up the value from the invocation if it is there. > -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
RE: [JBoss-dev] MetaDataRepository Proposal
Dain, > 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). > 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. > 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? > 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. - Matt --- 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
Re: [JBoss-dev] MetaDataRepository Proposal
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
maybe add
void setJDBCBackend(url, u, p);
void serConf(path);
Basically this is a plain old map with a possible parent. Exactly how
this is implemented, I really don't care; it is a detail. I'm going
to write one backed by a HashMap, and we can throw it away later.
For attribute keys, I'm thinking of things like MethodTxAttribute that
has a method object inside of it. Alternatively, we could lookup by
method and get another map back. I don't like that one because it
would be too hard to manage with any user interface. There are a
million ways to skin this cat. Does anyone have any ideas on how to
organize the keys?
The final problem is how do we keep this repository in sync with the
physical store. For this I would guess we need some sort of listener
or notification system. This isn't one of my current problems so I
haven't thought about it too much.
hmmm ... me thinks hsqldb is way underused as a admin tool in jboss
today ... hehe ... i am biased ... yes ...
hsqldb has a pluggable listener called Trigger.class with one method
public void fire(String trigName, String tabName, Object row[]);
so when an jboss instance starts ... it would ofcource need some core
configuration either as a xml-file or class.ser ? then one could start
a "jdbc:hsqldb:hsql:." instance and go get configuration - also when db
changes it will notify other db's throughout *hsqldbr and there is our
"distributed metadata repository" ... all sql, all libs in there
already ... cool ...
/peter_f
*hsqldbr(eplicated)
http://www.javagroups.com/javagroupsnew/docs/hsqldbr/design.htm
***
/**
* Sample code for use of triggers in hsqldb.
*
* SQL to invoke is:
* CREATE TRIGGER triggerSample BEFORE|AFTER INSERT|UPDATE|DELETE
* ON myTable [FOR EACH ROW] [QUEUE n] [NOWAIT] CALL
"myPackage.trigClass"
*
* This will create a thread that will wait for its firing event to
occur;
* when this happens, the trigger's thread runs the 'trigClass.fire'
* Note that this is still in the same Java Virtual Machine as the
* database, so make sure the fired method does not hang.
*
* There is a queue of events waiting to be run by each trigger thread.
* This is particularly useful for 'FOR EACH ROW' triggers, when a large
* number of trigger events occur in rapid succession, without the
trigger
* thread getting a chance to run. If the queue becomes full, subsequent
* additions to it cause the database engine to suspend awaiting space
* in the queue. Take great care to avoid this situation if the trigger
* action involves accessing the database, as deadlock will occur.
* This can be avoided either by ensuring the QUEUE parameter makes a
large
* enough queue, or by using the NOWAIT parameter, which causes a new
* trigger event to overwrite the most recent event in the queue.
* The default queue size is 1024.
*
* Ensure that "myPackage.trigClass" is present in the classpath which
* you use to start hsql.
*
* If the method wants to access the database, it must establish
* a JDBC connection.
*
* When the 'fire' method is called, it is passed the following
arguments:
* fire (String trigName, String tabName, Object row[])
*
* where 'row' represents the row acted on, with each column being
* a member of the array. The mapping of row classes to database
* types is specified in /doc/hsqlSyntax.html#Datatypes
*
*
* For implementation at a later date:
* 1. jdbc:default:connection: URL for JDBC trigger method
connections to
* the database.
* 2. arguments to the trigger method.
* 3. Because they run in different threads, it is possible for an
* 'after' trigger to run before its corresponding 'before' trigger;
* the acceptability of this needs to be investigated.
*
* @author Peter Hudson
* @version 1.7.0
*/
public class TriggerSample implements org.hsqldb.Trigger {
/**
* fire method declaration
* This is a sample implementation that simply prints
information
* about the trigger firing.
*
* @param trigName
* @param tabName
* @param row
*/
public void fire(String trigName, String tabName, Object row[]) {
System.out.println(trigName + " trigger fired on " + tabName);
System.out.print("col 0 value <");
System.out.print(row[0]);
System.out.println(">");
// you can cast row[i] given your knowledge of what the table
// format is.
}
}
/**
*
*
* test SQL
* CREATE CACHED TABLE trig_test (int_field integer)
* CREATE TRIGGER ins_before BEFORE INSERT ON trig_test CALL
"org.hsqldb.sample.TriggerSample"
* CREATE TRIGGER ins_after AFTER INSERT ON trig_test CALL
"org.hsqldb.sample.TriggerSample"
* CREATE TRIGGER upd_before
Re: [JBoss-dev] MetaDataRepository Proposal
Hiram Chirino wrote: David, Actually it simplifies the code. If you take a look at our interceptor stack most have a ton of code just to load and maintain the metadata, Yes there is alot of Metadata now. 1/2 the ton of code that we have there is just taking XML and creating a metadata objects. I think that something like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) should be able eliminate that code. A tool that will take XML config and generate the Metadata objects that our interceptors can use directly. Sure. It is just a detail. I want to put in an interface between the interceptor and the metadata repository. and the worst part is we have no control over it at runtime. It is way simpler. You'll see. I agree there. But wouldn't it be simpler if we just exposed an API to the client that would allow him to modify the metadata (thus turning something that is static now, into something dynamic)? For example. Say you have a CMP bean x, and the configuration API is exposed via an aspect, then on the client side you would do: CMPConfiguration c = (CMPConfiguration)x; c.setReadAhead( 500 ); And the would in turn create a Invocation with method=setReadAhead that the CMP interceptor would handle by updating the metadata configuration for the bean. Does this make sense? Are you trying to achieve something similar but in a more automated way? This could easily happen but is not my motivation. I really just want simplify the containers and interceptors. Anyway, where would this data live? How would it get into the invocation? My guess is that the same repository code could be used on the client side for client specific configuration, but maybe it won't work for that. -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
RE: [JBoss-dev] MetaDataRepository Proposal
> > David, > > Actually it simplifies the code. If you take a look at our interceptor > stack most have a ton of code just to load and maintain the metadata, Yes there is alot of Metadata now. 1/2 the ton of code that we have there is just taking XML and creating a metadata objects. I think that something like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) should be able eliminate that code. A tool that will take XML config and generate the Metadata objects that our interceptors can use directly. > and the worst part is we have no control over it at runtime. It is way > simpler. You'll see. > I agree there. But wouldn't it be simpler if we just exposed an API to the client that would allow him to modify the metadata (thus turning something that is static now, into something dynamic)? For example. Say you have a CMP bean x, and the configuration API is exposed via an aspect, then on the client side you would do: CMPConfiguration c = (CMPConfiguration)x; c.setReadAhead( 500 ); And the would in turn create a Invocation with method=setReadAhead that the CMP interceptor would handle by updating the metadata configuration for the bean. Does this make sense? Are you trying to achieve something similar but in a more automated way? Regards, Hiram > 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 > runtime. There really is no need to shut down an application in > production just to change some configuration data. > > Even if there is no real need the code is simpler. > > -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
Re: [JBoss-dev] MetaDataRepository Proposal
David,
Actually it simplifies the code. If you take a look at our interceptor
stack most have a ton of code just to load and maintain the metadata,
and the worst part is we have no control over it at runtime. It is way
simpler. You'll see.
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
runtime. There really is no need to shut down an application in
production just to change some configuration data.
Even if there is no real need the code is simpler.
-dain
David Jencks wrote:
Can you please give a fairly detailed use case for this idea and indicate
why it is needed rather than a static division of metadata between that
which is tied to an interceptor stack (the same for every invocation going
through the stack) and that which is specific to a particular invocation
(and thus supplied by the client).
So far this idea strikes me as needless complexity that doesn't solve any
problems, so please enlighten me as to the point. I will understand much
better if you have a specific example that won't work with the division of
responsibility outlined above.
thanks
david jencks
On 2002.11.13 17:56:17 -0500 Dain Sundstrom wrote:
This is based on some emails I have been trading with Scott. I'm going
to start at the invoker and work my way out, because it is the way I
know best.
I'm going to add a new MetaDataLoaderInvoker. All this invoker does is
populate the invocation object with meta data from the repository. Here
is the code for the invoke method:
public Object invoke(Invocation invocation) throw Exception
{
invocationMetaDataLoader.load(invocation, metaDataRepository);
return getNext().invoke();
}
The invocation meta data loader is responsible for getting only the data
needed for the interceptor stack from the repository and merging the
data into the invocation object. The loader should not blindly
overwrite data already in the invocation, so clients can have control
over the invocation and the loader should fill in reasonable default if
non is available in the repository.
This design is a trade off between blindly stuffing all possible data
for an invocation in to the hash table, which could take a very long
time, and alternatively having an intelligent loader that "knows" what
is needed for the invocation. It is just a trade off of speed for a
more static (puggable and runtime replaceable) loader.
Assuming I haven't already confused you, now where does the repository
come from? I propose that it is just another service that the container
depends on like caching and pooling (when these become real MBeans). I
am thinking of an interface like this:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
Basically this is a plain old map with a possible parent. Exactly how
this is implemented, I really don't care; it is a detail. I'm going to
write one backed by a HashMap, and we can throw it away later. For
attribute keys, I'm thinking of things like MethodTxAttribute that has a
method object inside of it. Alternatively, we could lookup by method
and get another map back. I don't like that one because it would be too
hard to manage with any user interface. There are a million ways to skin
this cat. Does anyone have any ideas on how to organize the keys?
If you agree to this point, the next problem is how do we get data into
the repository and how do we get updates out. I see two possibilities
here: we could go the JCache route where you have a loader associated
with the repository that is called when data is not in the cache or we
could have an outboard loader that stuffs the cache on container
startup. Either way is cool with me.
The final problem is how do we keep this repository in sync with the
physical store. For this I would guess we need some sort of listener or
notification system. This isn't one of my current problems so I haven't
thought about it too much.
-dain
--
Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC
---
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
Re: [JBoss-dev] MetaDataRepository Proposal
Can you please give a fairly detailed use case for this idea and indicate
why it is needed rather than a static division of metadata between that
which is tied to an interceptor stack (the same for every invocation going
through the stack) and that which is specific to a particular invocation
(and thus supplied by the client).
So far this idea strikes me as needless complexity that doesn't solve any
problems, so please enlighten me as to the point. I will understand much
better if you have a specific example that won't work with the division of
responsibility outlined above.
thanks
david jencks
On 2002.11.13 17:56:17 -0500 Dain Sundstrom wrote:
> This is based on some emails I have been trading with Scott. I'm going
> to start at the invoker and work my way out, because it is the way I
> know best.
>
> I'm going to add a new MetaDataLoaderInvoker. All this invoker does is
> populate the invocation object with meta data from the repository. Here
> is the code for the invoke method:
>
> public Object invoke(Invocation invocation) throw Exception
> {
> invocationMetaDataLoader.load(invocation, metaDataRepository);
> return getNext().invoke();
> }
>
> The invocation meta data loader is responsible for getting only the data
> needed for the interceptor stack from the repository and merging the
> data into the invocation object. The loader should not blindly
> overwrite data already in the invocation, so clients can have control
> over the invocation and the loader should fill in reasonable default if
> non is available in the repository.
>
> This design is a trade off between blindly stuffing all possible data
> for an invocation in to the hash table, which could take a very long
> time, and alternatively having an intelligent loader that "knows" what
> is needed for the invocation. It is just a trade off of speed for a
> more static (puggable and runtime replaceable) loader.
>
> Assuming I haven't already confused you, now where does the repository
> come from? I propose that it is just another service that the container
> depends on like caching and pooling (when these become real MBeans). I
> am thinking of an interface like this:
>
> public interface MetaDataRepository {
> MetaDataRepository getParent();
> void setParent(MetaDataRepository parent);
> Object get(Object attributeKey);
> void set(Object attributeKey, Object value);
> }
>
> Basically this is a plain old map with a possible parent. Exactly how
> this is implemented, I really don't care; it is a detail. I'm going to
> write one backed by a HashMap, and we can throw it away later. For
> attribute keys, I'm thinking of things like MethodTxAttribute that has a
> method object inside of it. Alternatively, we could lookup by method
> and get another map back. I don't like that one because it would be too
> hard to manage with any user interface. There are a million ways to skin
> this cat. Does anyone have any ideas on how to organize the keys?
>
> If you agree to this point, the next problem is how do we get data into
> the repository and how do we get updates out. I see two possibilities
> here: we could go the JCache route where you have a loader associated
> with the repository that is called when data is not in the cache or we
> could have an outboard loader that stuffs the cache on container
> startup. Either way is cool with me.
>
> The final problem is how do we keep this repository in sync with the
> physical store. For this I would guess we need some sort of listener or
> notification system. This isn't one of my current problems so I haven't
> thought about it too much.
>
> -dain
>
> --
>
> Dain Sundstrom
> Chief Architect JBossCMP
> JBoss Group, LLC
>
>
>
>
> ---
> 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
