Message-ID: <105961193.5837.1369530702983.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5836_1104349802.1369530702983" ------=_Part_5836_1104349802.1369530702983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
backport175 has been designed to work in highly dynamic= environment (such as load-time and runtime weaving for AOP). In environmen= ts like this the bytecode on disk is not the "current" one being = executed. Since the bytecode has been transformed during the execution of t= he application. What this means is that annotations can have been added or = removed.
We therefore need two things:
All these operation should be fully thread-safe, if not, then we have a = bug.
This is done by implementing the
ytecode.spi.BytecodeProvider interface. This interface is a strategy=
with one single method you need to implement:
The bytecode provider implementation class is registered in the
g.codehaus.backport175.reader.bytecode.AnnotationReader class by inv=
If no bytecode provider is registered then a default one that uses
getResourceAsStream(), e.g. reads in the bytecode from disk, is use=
It is also possible to set a bytecode provider on a per class basis, whi=
ch can be usefull in some circumstances.
Refer to the API documentation for more details.
When a change to the bytecode has been made it is needed to refresh the =
annotation reader, so that it can pull the new bytecode from the
codeProvider, parse it and update the reader with the new informatio=
n about the annotations.
This is done by invoking one of the
refresh(..) methods in =