----- Original Message -----
> From: Matt Benson <gudnabr...@gmail.com>
>
> 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.
LieGrue,
strub
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
