[
https://issues.apache.org/jira/browse/FELIX-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255562#comment-13255562
]
Göktürk Gezer commented on FELIX-3461:
--------------------------------------
We already are at the root !
ClassChecker is intended to to that, right. But then the metadata that
ClassChecker has been collected is being used to generate MANIFEST, and that's
the problem. Not also manifest by the way. ClassChecker visits the methods and
while visiting, it collects the annotations and parameter annotations of the
methods(including constructors) and that information is used in MethodCreator
to modify constructors again. So ClassChecker's collected informations are
important here, they're not just for checking whether manipulation is occured,
they're used after checking process. That's why i modified ClassChecker and
added exception for injection annotations. Otherwise modified constructor will
not contain injection annotations. And also modified ConstructorCodeGenerator
to prevent them from going into generated constructor.
Process is two step:
First we must make sure first manipulation does not leave constructor
annotations in inconsistent state for second manipulation,
Secondly we fix all the manifest data in rendering step so they reflect initial
component state in any manipulation attempt.
No your assumption is not the case. It results in a single component{} with
corrupted values, not multiple component{} decleration.
> 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: FELIX-3461-GSA.patch,
> 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
