Community
Participate
Working Groups
(originally from http://trac.objectteams.org/ot/ticket/163) (continued from http://trac.objectteams.org/ot/ticket/161): I could identify the following root cause: * class org.eclipse.jdt.internal.compiler.problem.AbortCompilation is loaded twice o the second loading is triggered from org.apache.jasper.compiler.JDTCompiler.generateClass(String[]) * during the second transformation (we do have a bound role in the compiler adaptor), org.objectteams.transformer.util.TeamIdDispenser.clinitAdded(String) tells that we have already added the <clinit> method. o in fact this version of the class has no <clinit> method, thus the mentioned assumption in StaticSliceBaseTransformation does not hold. This raises several questions: 1.) Why is jasper loading another version of AbortCompilation? * Answer: the jasper plugin (org.apache.jasper_5.5.17.v200806031609.jar) contains a copy of the eclipse java compiler! 2.) Why is the TeamIdDispenser keeping information after a class has finished loading? * ? In fact this is the first instance where the OTRE must cope with multiple versions of the same (adapted) class. Action items: * OTRE must cleanup state at given points in time (when? which state?) * OT/Equinox should detect that the class is loaded from a different plugin and thus avoid weaving (no aspect binding is declared for jasper!), roughly fixed as of http://trac.objectteams.org/ot/changeset/19192. * OT/Equinox must be able to distinguish classes not only by FQN but also by their defining bundle. ---- today's comment: Much of this is actually covered by OTDyn, so this issue should be re-checked once OTDyn is mature.
