commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: [weaver] SPI decisions
Date Sat, 05 Jan 2013 14:01:41 GMT

----- Original Message -----
> From: Matt Benson <>
> Weaver#weave():
>   Currently there are separate methods for weaving a class vs. a method.  I
> think it would be sufficient and cleaner to have a class weaving method
> only; having provided its "interests," the Weaver can presumably 
> figure out
> what to do with a class that has been determined to match. 

Yes that might be an option. I added it because sometimes you are interested in just a few
methods as opposed to having to scan this all yourself (which is redundant because xbean-finder
does it much more efficiently).

 > Next, it feels
> a little odd to use a loaded Class instance to represent a class intended
> for modification.  Should we just use classname here?

Not sure, I need to look at the xbean-finder code. You need to parse the bytecode of the class
for many things anyway and I don't think it will cause a file system lock. 

> Weaver#getInterest():
>   Rather than providing List<Class<? extends Annotation>>, I wonder 
> whether
> it would be more future-proof for this method (pluralized?) to return
> Map<Class<? extends Annotation>, ElementType> to say not only which
> Annotation types it is interested in, but where they are expected to be
> found.  This could work comfortably with the type of search registration
> APIs we've discussed for [classscan] in the future.

Yes we could go for it. There was just no need for it yet.

> Weaver#configure():
>   This method supplies a target directory where classes are to be found.
> Perhaps too optimistically, I envision a future that could include a
> [weaver] ClassLoader to apply our advice at run, rather than build, time.
> Does anyone have any relevant experience that would guide us in providing
> the most flexible API to permit weaving of classfiles whether on the
> filesystem or otherwise?  Is it going too far to pull in [vfs] v2-core as a
> dependency?

I fear that might be a good bit of additional work to pull off. I'd rather go for a version
with is working for now. We can still improve it later.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message