felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Sauthier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3837) PojoizationPlugin should be more extensible
Date Fri, 04 Jan 2013 14:18:12 GMT

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

Guillaume Sauthier commented on FELIX-3837:

At compile time, you have the metadata.xml to describe additional handlers.
At runtime, you could add any handler to any component, it's much more powerful (IMHO).
In fact, you want a way to automate the writing of your metadata.xml

Oh, an additional thing, introducing a MetadataManipulator API in the bnd-ipojo-plugin would
make that feature only available for bnd users. What about the ipojo URLHandler that manipulates
bundles on-the-fly ?

What bother me is to have 2 ways of doing the same thing: add handlers not known/defined at
development time.
But I also agree that the current PojoizationPlugin is not well written enough to allow you
to subclass it easily to add your own logic.

So I can propose you the following solution:
I refactor the plugin to let you override some methods in order to modify on your side the
metadata, but I do not include the MetadataManipulator interface that do the exact same job
of a runtime ElementTransformer.
In all case, you have to write your own plugin subclass, so 1 or 2 classes more is not much
of a burden for you (I hope).

> 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

View raw message