[
https://issues.apache.org/jira/browse/FELIX-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255015#comment-13255015
]
Göktürk Gezer commented on FELIX-3461:
--------------------------------------
Method was not implemented before, i overrided it. Reason is to prevent
parameter annotations(only @Property and @Requires) of original constructor to
go into generated one. And i also changed
ClassChecker.AnnotationCollector.visitParameterAnnotation() method to keep
those parameter annotations in original constructor. By keeping injection
annotations in original constructor, they are interpreted correctly at
re-manipulation time without doing any harm to runtime semantics. Otherwise
parameter indexes are interpreted in the context of generated cosntructor with
additional InstanceManager reference, thus causing injection parameters to be
assigned wrong type identifier at re-manipulation. (Injecting services and
parameters still works in runtime with those changes).
While writing this, I also noticed that this fix can be implemented another way:
in ConstructorCodeAdapter.visitParameterAnnotation():
if(desc.equals("Lorg/apache/felix/ipojo/annotations/Property;")
||
desc.equals("Lorg/apache/felix/ipojo/annotations/Requires;")){
return null;
}
else{
return super.visitParameterAnnotation(parameter+1, desc,
visible);
}
returning super.visitParameterAnnotation with parameter index incremented by 1,
because InstanceManager is added to the first position in argument list. Then
we can remove the code i added to the
ClassChecker.AnnotationCollector.visitParameterAnnotation() safely.
> Re-manipulation with annotated component produces corrupted MANIFEST
> --------------------------------------------------------------------
>
> Key: FELIX-3461
> URL: https://issues.apache.org/jira/browse/FELIX-3461
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
> Reporter: Göktürk Gezer
> Labels: ipojo-manipulator
> Attachments: org.apache.felix.ipojo.manipulator.patch
>
>
> As the manipulation process alters the annotations of original classes on
> generated ones. It leaves it in inconsistent state for re-manipulation. While
> re-manipulation process does not touch classes, re-manipulated bundle is
> unable to function because of a corrupted MANIFEST.
> Broken MANIFEST is missing some handler declarations because of the filters
> and have entries in manipulation section those should have been hided.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
