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

2013-01-04 Thread Guillaume Sauthier (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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).

WDYT ?

 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


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

2013-01-04 Thread JIRA

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

Jérémy Cazaux commented on FELIX-3837:
--

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


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

2013-01-03 Thread Guillaume Sauthier (JIRA)

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

Guillaume Sauthier commented on FELIX-3837:
---

I had something similar in mind, but at runtime.
Something that looks like the auto-handlers behavior, but based on service.
You could modify the component definition before a Factory is created from it.

Could that feature be useful for you ?

 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


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

2013-01-03 Thread Guillaume Sauthier (JIRA)

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

Guillaume Sauthier commented on FELIX-3837:
---

See here for an implementation proposal:
https://github.com/sauthieg/felix/commit/33070082a209da9b3baa9b5cd1f2cc3aec8288a8

 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


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

2013-01-03 Thread JIRA

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

Jérémy Cazaux commented on FELIX-3837:
--

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

However, just from my personal point of view, I always prefer to make a feature 
at compile time rather than at runtime (it's always cheaper) if the feature is 
really similar (like this one). I think it could be a good thing to 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.

 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


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

2013-01-03 Thread Guillaume Sauthier (JIRA)

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

Guillaume Sauthier commented on FELIX-3837:
---

I understand your POV, I was just wondering how much we want to have 2 ways to 
do the same thing ?

BTW, the compile time way is still harder to use (you'll have to both extends 
the PojoizationPlugin and write your MetadataManipulator). I'm not sure how we 
could do something easier for the user.
For the runtime way, you just have to write a transformer (equivalent to your 
MetadataManipulator).

 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


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

2013-01-03 Thread JIRA

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

Jérémy Cazaux commented on FELIX-3837:
--

2 ways to do globally the same thing in two different phases (compile  
runtime).

With the runtime way, a new service will be registered in the OSGi registry 
just to manipulate metadata before factories creation (more expensive at 
runtime). The main advantage of the runtime way is that if our own iPOJO 
handler and a transformer which automate definition of this handler are not 
included in a profil of an OSGi server then all others factories can still be 
valid and can instantiate new instances easily (the handler will not be added 
in the component definition). However the runtime way imply that metadata 
modifications will be applied to all factories (and not just a group of 
factories).  
 
So that remains to be seen if we want two ways to manipulate metadata elements.

 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