Opened an issue about this: https://jira.terracotta.org/jira/browse/DEV-1644
On 20 May 2008, at 23:43, Tim Eck wrote: > 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 -- 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
