Very good idea, we could actually use the development / production modes in tc-config.xml for this.
On 20 May 2008, at 17:36, Jeff Hartley wrote: > This would presumably be something you could turn off in a stable > production environment? When you decide the risk of inconsistency > should be low enough to forego the checksum overhead... > > Jeff Hartley - Terracotta > M) 415 350 2592 > This email incorporates the Terracotta confidentiality policy: > http://www.terracottatech.com/emailconfidentiality.html > > [Message delivered by NotifyLink] > > ----------Original Message---------- > > From: Orion Letizi <[EMAIL PROTECTED]> > Sent: Tue, May 20, 2008 7:55 AM > To: [email protected] > Subject: Re: [tc-dev] Thoughts about byte-code instrumentation > > > sounds like a good idea to me. > > --Orion > > On May 20, 2008, at 5:55 AM, Geert Bevin wrote: >> Hi everyone, >> >> I'm a bit concerned about how we're approaching the byte-code >> instrumentation of JDK classes or framework classes. >> >> There are basically two ways: >> * we either replace existing methods/classes by new implementations; >> or >> * we modify existing methods/classes by looking for patterns in the >> byte code >> >> Both of these approaches are very much tied to the actual version of >> the instrumented class. When incompatible versions of those classes >> appear in later versions of the JDK or the frameworks, we basically >> have to rely on tests to fail (which doesn't really happen, since we >> don't test with all possible framework versions) or on users to >> report >> that something doesn't work as expected. >> >> I'm wondering if we should be more strict about which classes we >> actually support for each instrumentation. >> >> An initial idea I have is to make checksums of the byte code arrays >> for each class that is supported and to map those to the adaptors. >> This would also allow us to have clearly isolated adaptors for >> classes >> that have the same name, but have different implementations. When new >> versions of the JDK or frameworks appear and the implementation of an >> instrumented class has changed, we can fail-fast since the checksum >> will not be part of the ones we support. I personally think that this >> is much better than just hoping that it will work and wait until >> something bad happens at runtime. One downside is that creating the >> checksums for each class with custom instrumentation could be quite >> expensive at runtime. >> >> Any thoughts? >> >> Geert >> >> -- >> Geert Bevin >> Terracotta - http://www.terracotta.org >> Uwyn "Use what you need" - http://uwyn.com >> RIFE Java application framework - http://rifers.org >> Music and words - http://gbevin.com >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
