Well it least that <configuration-mode> config element would actually be used for something then. It is completely ignored at the moment :-)
Did you find an instance where the underlying implementation changed in some jdk release and our instrumentation was no longer correct? I think you concern is completely valid, just wondering if we actually got bit by it. It'd be nice if we could cover ourselves 100% here and anything we can do to approach that ideal makes the world a better place. I think we have fairly comprehensive tests for jdk classes, and the minute sun releases new updates we absorb them into the monkeys. For TIMs I think we might be doing some rudimentary version checking to at least emit a warning if the library version isn't the one that the TIM was designed for. The thing about class byte[] checksums is that can be really touchy, even some different ordering in the constant pool will trip that up. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Geert Bevin > Sent: Tuesday, 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
