I'm doing some interesting work with changes to ComponentClassTransformer right now; part of what I'm doing is to set the stage for moving away from Javassist in the future.
Increasingly, I'm building up new APIs that allow the transformations on the component class to be expressed in terms of interfaces and callbacks, and I'm decreasing the amount of "Javassist-psuedocode" that gets written. I'll have some checkins to 5.2 in a few more days. One idea that's occured to me is that, in addition to instrumenting injected fields and parameter fields, we could use the same trick for ordinary fields, holding transient per-request data. Effectively, the page would contain no mutable state, all mutable state for the page would be shunted off into a per-request HashMap. There'd be some overhead to that (reading or updating a field would turn into several method calls), but if done properly, it means we would only need ONE instance of a page (per locale). I wonder if this is worth pursuing; it's a lot of work. Done a reduction in memory overhead and some of the other aspects (such as page pool maintenance) justify the overhead for field access? Plus there are some areas I'm not sure how to handle. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
