Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 74.125.83.53 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
Date: Wed, 2 Jan 2013 18:49:22 -0600
Message-ID: 
 <CAE9L6G2iHNXW769ureY4To-VK-Ybuya=Kab2B+rL1xMAhDMi4w@mail.gmail.com>
Subject: [weaver] SPI decisions
From: Matt Benson <gudnabrsam@gmail.com>
To: dev@commons.apache.org
Content-Type: multipart/alternative; boundary=047d7b3436ace635e804d257bb74

--047d7b3436ace635e804d257bb74
Content-Type: text/plain; charset=ISO-8859-1

Hi all, and especially Mark S.--in case I've not done it publicly enough
yet, many thanks to Mark for picking up where I had left off with the
privilizer/weaver code.  I think the two of us (others? :D) would like to
reach a point at which the library is usable, so I submit the following
talking points:


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.  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?

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.

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?

Thanks,
Matt

--047d7b3436ace635e804d257bb74--