Hi Clement, On Apr 16, 2012 7:10 PM, "Clement Escoffier" <[email protected]> wrote: > > Hi, > > We started looking at it. Guillaume did some work on it. So, first the second evaluation of the annotations is definitely a bug. We're now trying to be sure we're not breaking something somewhere (like the component filter). > Yeah, me too not sure if it broke something internally. > So you can be sure we will fix the issue. The patch or a slightly different version will be applied this week. I'm focussing on an ipojo core and composite release, and then back to the manipulator.
All right, thanks. Let me know if I can help at any point. > Regards, Göktürk > Regards, > > Clement > > Sent from my iPhone > > On 16.04.2012, at 17:42, Göktürk Gezer <[email protected]> wrote: > > > 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? > > > > Thanks, > > Gokturk > > > > On Sun, Apr 15, 2012 at 1:11 AM, Göktürk Gezer <[email protected]> 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-3461with 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 > >>
