[jira] [Comment Edited] (FELIX-3837) PojoizationPlugin should be more extensible

["Jérémy Cazaux (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544218#comment-13544218 ] 

Jérémy Cazaux edited comment on FELIX-3837 at 1/4/13 8:22 PM:
--------------------------------------------------------------

Ok for the iPOJO URLHandler. I did not know about this feature. This looks pretty interesting !

You're right that with the compile way this feature will be only available for bnd users. However maybe some users according to their use case (if advantages of the runtime way are useless for their use case) could prefer to automate handlers definition via the compile way just because of the (really small I can concede) adding cost at runtime. From my personal POV, I do not care if I will write one more class at compile time just to reduce a little bit the runtime cost. 

Anyway, just for my personal use case,  I recognize that the runtime way is better (like I said before handlers won't be automatically added in component description if an handler and its associated transoformer are missing in the runtime environment) and I'll use it instead of the bnd way.

Ok for the plugin refactorization and ok to not support metadata manipulation in the ipojo-bnd-plugin seeing that supporting this two ways is not acceptable (I can understand that).
                
      was (Author: cazauxj):
    Ok for the iPOJO URLHandler. I did not know about this feature. This looks pretty interesting !

You're right that with the compile way this feature will be only available for bnd users. However maybe some users according to their use case (if the runtime way has no advantage for their use case) could prefer to automate handlers definition via the compile way just because of the (really small I can concede) adding cost at runtime. From my personal POV, I do not care if I will write one more class at compile time just to reduce a little bit the runtime cost. 

Anyway, just for my personal use case,  I recognize that the runtime way is better (like I said before handlers won't be automatically added in component description if an handler and its associated transoformer are missing in the runtime environment) and I'll use it instead of the bnd way.

Ok for the plugin refactorization and ok to not support metadata manipulation in the ipojo-bnd-plugin seeing that supporting this two ways is not acceptable (I can understand that).
                  
> PojoizationPlugin should be more extensible
> -------------------------------------------
>
>                 Key: FELIX-3837
>                 URL: https://issues.apache.org/jira/browse/FELIX-3837
>             Project: Felix
>          Issue Type: Improvement
>          Components: iPOJO
>            Reporter: Jérémy Cazaux
>         Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch
>
>
> I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest).
> So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily.
> I have attached a patch to fix this issue if the extensibility of the plugin is acceptable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira