I like having an 'operational state machine' like that, where transitioning from dev/test to production implies some clear changes in behavior:-)
It might be though that you can turn such things on and off in dev mode, to give you granular control over specific features as you transition through various stages of testing. But if they're left on on prod mode they're ignored and a message is written to the logs saying such and such is on but ignored in prod mode. Perhaps too complex. Cheers, J 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: Geert Bevin <[EMAIL PROTECTED]> Sent: Tue, May 20, 2008 8:41 AM To: [email protected] Subject: Re: [tc-dev] Thoughts about byte-code instrumentation 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
