felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: Re-manipulation generates corrupted MANIFEST on annotated components.
Date Mon, 16 Apr 2012 15:42:06 GMT
Hi Devs,

Sorry for pressuring but this is blocker for us in ApacheDS. Could some one
please evaluate the issue and the patch? We really need to know whether
it'll be fixed or not?


On Sun, Apr 15, 2012 at 1:11 AM, Göktürk Gezer <gokturk@apache.org> wrote:

> Hi Everyone,
> As i was trying to integrate IPojo manipulation into eclipse environment,
> i noticed re-manipulation without cleaning corrupts the MANIFEST file even
> though it does not brake manipulated class files. Re-manipulated MANIFEST
> is lacking some handler declarations and "manipulation" section contains
> entries for fields and methods those are IPojo generated ones, which brakes
> down everything.
> I created a jira: https://issues.apache.org/jira/browse/FELIX-3461 with a
> patch to fix.
> I will document the fix here briefly, so that you guys can tell me if
> anything brakes some part of code that i don't know.
> * First problem is ManipulatedMetadataFilter class which is simply
> ignoring elements if some of their attributes contain manipulation headers.
> This behavior ends up in ignoring elements whose values are dependent on
> methods like transition callbacks(Validate-Invalidate), since the
> re-manipulation process will read methods with their mangled names. And
> filter was also missing some manipulation headers too, causing manipulation
> section to contain extra entries. I removed the filter logic from code and
> injected a ManipulationMetadataFixer which is called before any
> manipulation medata <Element> is rendered. It fixes the mangled method
> names and performs a structered clean-up on manipulation elements.
> * After using Fixer there were two main problems left:
> -> Bind/Unbind/Modified metadatas were being lost and @Property on methods
> were lacking property names after re-manipulation :: Solved by adding
> necessary checks into BindAnnotationsParser and PropertyAnnotationParser
> classes's visitEnd() methods.
> -> Constructor injection parameters were being assigned wrong class types
> after re-manipulation :: While generating new constructor based on existing
> one argument annotations were being transferred to new one without changing
> their index. While this is valid action, it falsify the fetched type of
> injection annotations at re-manipulation. At ClassChecker i added an
> exception for @Property and @Requires annotation types to remain attached
> to original constructor, also overrided visitParameterAnnotation() method
> in ConstructorCodeAdaptor class to forbid those two annotation to go into
> generated constructor.
> Tested those changes against an IPojo component containing all current
> ipojo annotations + custom annotations to produce same MANIFEST after
> multiple manipulation attempts.
> Regards,
> Gokturk

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message