Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 3 Jan 2013 13:06:12 +0000 (UTC)
From: =?utf-8?Q?J=C3=A9r=C3=A9my_Cazaux_=28JIRA=29?= <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12625628.1357075679508.73914.1357218372316@arcas>
In-Reply-To: <JIRA.12625628.1357075679508@arcas>
References: <JIRA.12625628.1357075679508@arcas>
Subject: [jira] [Commented] (FELIX-3837) PojoizationPlugin should be more
 extensible
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/FELIX-3837?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1354=
2903#comment-13542903 ]=20

J=C3=A9r=C3=A9my Cazaux commented on FELIX-3837:
--------------------------------------

Yes, as you have added the possibility to modify the component definition b=
efore the component(=3Dfactory) creation at runtime, this feature is great =
and will be really useful for a lots of peoples. =20

However, just from my personal point of view, I always prefer to make a fea=
ture at compile time rather than at runtime (it's always cheaper) if the fe=
ature is really similar (like this one). I think it could be a good thing t=
o add the possibility  to modify elments metadata either at compile time or=
 at runtime. After what, it'll be to the user to determine if he prefers to=
 modify elements metadata at compile time or at runtime.
               =20
> 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=C3=A9r=C3=A9my Cazaux
>         Attachments: 0001-PojoizationPlugin-should-be-more-extensible.pat=
ch
>
>
> I would like to extend Pojoization plugin without duplication of code in =
order to manipulate metadata elements from the CacheableMetadataProvider ob=
ject just before the pojoization operation (for example to automate the def=
inition of my own handlers in the manifest).
> So all fields and methods should be protected instead of private and a ne=
w mechanism should be add in order to allow to manipulate cacheable metadat=
a easily.
> I have attached a patch to fix this issue if the extensibility of the plu=
gin is acceptable.

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