[
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
