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