> -----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? Easily....Its 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
