Re: [javaflow] a problem in ResourceTransformer abstraction

[Torsten Curdt]

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.

cheers
--
Torsten

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? ;)

PGP.sig
Description: This is a digitally signed message part