commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi <kohsuke.kawagu...@sun.com>
Subject Re: [javaflow] a problem in ResourceTransformer abstraction
Date Tue, 27 Dec 2005 19:27:09 GMT
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.


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.

-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@sun.com

Mime
View raw message