commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [javaflow] a problem in ResourceTransformer abstraction
Date Thu, 29 Dec 2005 17:33:17 GMT

On 27.12.2005, at 20:27, Kohsuke Kawaguchi wrote:

> Kohsuke Kawaguchi wrote:
>> So I suggest we introduce a mechanism to resolve symbols to their  
>> class files:
>>    interface ClassImageLoader {
>>      byte[] load(String className);
>>    }
>> .. and change ResourceTransformer as follows:
>>    interface ResourceTransformer {
>>      byte[] transform(String className, ClassImageLoader loader);
>>    }
> While taking a bath I realized that perhaps a better way to do it  
> is to pass ClassImageLoader (or an equivalent) to the constructor  
> of ResourceTransformer.
> In that way we don't even have to define 'ClassImageLoader' if we  
> don't want to --- it could be specific to the implementation of  
> ResourceTransformer. For BCEL, it could be just  
> org.apache.bcel.util.Repository.
> A ResourceTransformer instance is often used to process multiple  
> class files from the same ClassImageLoader, so passing it to the  
> constructor allows a ResourceTransformer implementation to cache  
> states internally.
> The downside is that the ResourceTransformer instance becomes  
> stateful, but I think that's OK given how it's used.

Think so, too

> Another possible tweak would be to pass in "byte[] classImage"  
> instead of "String className", which would possibly allow  
> composition of multiple transformations into one  
> ResourceTransformer. I saw that you wanted to do it in  
> RewritingUtils class, although I'm not quite sure if it would ever  
> happen in the context of javaflow.

That's true not necessarily in the javaflow context ...but that  
interface is meant to be a bit more generic.

So basically that would leave us with the interface at is currently  
is ...or am I mistaken? ;)


View raw message