You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Joel Schuster <jo...@Navsys.com> on 2010/09/09 00:39:03 UTC
ipojo and inheritance
It seems that iPojo doesn't know how to go up the inheritance tree to look for annotations. So if I wish to have an abstract class that has the @Provides or @Component or even the @Validate/@Invalidate method because a bunch of them implement things in the same way I cannot.
Am I correct?
- Joel Schuster
Re: ipojo and inheritance
Posted by Peter Donald <pe...@realityforge.org>.
>> * Why not inject BundleContext via @Require?
>
> I was thinking providing a @Context annotation to inject the BundleContext. @Requires is right now limited to Service Dependencies.
> Do you think @Requires is better ? The Context injection will be soonish available.
I think @Context is a much better idea
> Most of your complains can be fixed in the next minor release. Please open jira tickets, then we can discuss those improvements.
I have opened jira tickets for all the points raised above. Thanks!
--
Cheers,
Peter Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and inheritance
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 21.09.2010, at 14:48, Peter Donald wrote:
> Hi,
>
>> First sorry for this late reply, the mail strangely went out of my radar.
>> I cannot give you an exact date for iPOJO 2.0. My goal is to release iPOJO 2.0 in 2011 (June is my first target).
>>
>> Right now, I'm collecting requirements, and ideas and starting to write that down. For sure, inheritance will be part of the new release as well as new handlers such as a kind of JPA handler... I also want to reduce the complexity of some mechanisms as the 'component type type' definition.
>
> Well then maybe I should supply some of the things we came up with
> when we were starting to get to grips with ipojo. Note that these
> should not be considered criticisms as such - just things that didn't
> behave as expected :)
>
> * There is lots of name collisions between annotations which make the
> use of them painful at best. For example @Property could either be
> associated with jmx handler or it could be a config property. Why not
> just have annotations named @ConfigProperty and @JmxProperty instead?
> Much easier for end user as don't need to fully qualify everything.
> There is also namespace collisions between annotations and classes
> (i.e. @Publisher vs Publisher) which means more ugly fully qualified
> names (why not rename the annotation to something like @Publishes or
> similar.
I agree with those conflicts. It's an historical issue, please open Jira issue because this can be fixed mostly immediately.
>
> * Non-java ish names seem to be scattered through the annotations. Why
> have data_key rather than the more javaish dataKey. ie.
> - @Subscriber.data_key
> - @Subscriber.data_type
> - @Publisher.data_key
> - @Publisher.data_type
> - @Component.factory_method
Same here, it's mostly historical ... This can also be fixed before iPOJO 2.0
>
> * Annotations on parent classes ignored!
This is the main issue and the main improvement of iPOJO 2.0 : the inheritance support.
>
> * Why can't you set static service properties via annotations that are
> not mirrored in fields? (Not sure if you can do this via xml). I could
> easily imagine extending the @Provides annotation such as
>
> @Provides{ specifications = {Foo.class},
> properties = {@ServiceProperty{name="x",
> value="1"},@ServiceProperty{name="y", value="2"}}} )
Well, let's say I never think about that :-)
Please open an issue, this also can be fixed.
>
> * Why not inject BundleContext via @Require?
I was thinking providing a @Context annotation to inject the BundleContext. @Requires is right now limited to Service Dependencies.
Do you think @Requires is better ? The Context injection will be soonish available.
>
> * Why does not validation of annotations occur until runtime? If you
> use annotation and refer to a method that does not exist it should
> fail at build time! Likewise if you annotate a method that does not
> have expected parameter types
Because annotations are completely generic, and the manipulator does not check anything. This is something planned for iPOJO 2.0. The way annotations are managed will be changed.
>
> * @Update annotated methods should not require a Dictionary parameter
> - especially if all expected fields configured by @Property before
> hand.
That's a good improvements, please fill a Jira ticket
>
> * @Provides have to be parent classes or interfaces not the class
> itself ... seems like an arbitrary decision???
You can set @Provides to expose the class itself. However, this is not recommended, as OSGi services 'should' be interchangeable.
>
> Anyhoo - thats all that is on this list. Other than the above iPojo
> has worked a charm. We were planning on having a custom set of
> annotations that fit more with our expectations and generated the
> appropriate xml .
Most of your complains can be fixed in the next minor release. Please open jira tickets, then we can discuss those improvements.
Regards,
Clement
>
> --
> Cheers,
>
> Peter Donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and inheritance
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
> First sorry for this late reply, the mail strangely went out of my radar.
> I cannot give you an exact date for iPOJO 2.0. My goal is to release iPOJO 2.0 in 2011 (June is my first target).
>
> Right now, I'm collecting requirements, and ideas and starting to write that down. For sure, inheritance will be part of the new release as well as new handlers such as a kind of JPA handler... I also want to reduce the complexity of some mechanisms as the 'component type type' definition.
Well then maybe I should supply some of the things we came up with
when we were starting to get to grips with ipojo. Note that these
should not be considered criticisms as such - just things that didn't
behave as expected :)
* There is lots of name collisions between annotations which make the
use of them painful at best. For example @Property could either be
associated with jmx handler or it could be a config property. Why not
just have annotations named @ConfigProperty and @JmxProperty instead?
Much easier for end user as don't need to fully qualify everything.
There is also namespace collisions between annotations and classes
(i.e. @Publisher vs Publisher) which means more ugly fully qualified
names (why not rename the annotation to something like @Publishes or
similar.
* Non-java ish names seem to be scattered through the annotations. Why
have data_key rather than the more javaish dataKey. ie.
- @Subscriber.data_key
- @Subscriber.data_type
- @Publisher.data_key
- @Publisher.data_type
- @Component.factory_method
* Annotations on parent classes ignored!
* Why can't you set static service properties via annotations that are
not mirrored in fields? (Not sure if you can do this via xml). I could
easily imagine extending the @Provides annotation such as
@Provides{ specifications = {Foo.class},
properties = {@ServiceProperty{name="x",
value="1"},@ServiceProperty{name="y", value="2"}}} )
* Why not inject BundleContext via @Require?
* Why does not validation of annotations occur until runtime? If you
use annotation and refer to a method that does not exist it should
fail at build time! Likewise if you annotate a method that does not
have expected parameter types
* @Update annotated methods should not require a Dictionary parameter
- especially if all expected fields configured by @Property before
hand.
* @Provides have to be parent classes or interfaces not the class
itself ... seems like an arbitrary decision???
Anyhoo - thats all that is on this list. Other than the above iPojo
has worked a charm. We were planning on having a custom set of
annotations that fit more with our expectations and generated the
appropriate xml .
--
Cheers,
Peter Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and inheritance
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks Clement,
It'll be a long wait but it's probably worth waiting for...
/Bengt
2010/9/21 Clement Escoffier <cl...@gmail.com>
> Hi,
>
> On 09.09.2010, at 21:09, Bengt Rodehav wrote:
>
> > Clement,
> >
> > I'm glad you're considering it - it would be really useful. Do you have
> any
> > idea of when iPOJO 2.0 would be released? Is it 6 months? A year?
>
> First sorry for this late reply, the mail strangely went out of my radar.
> I cannot give you an exact date for iPOJO 2.0. My goal is to release iPOJO
> 2.0 in 2011 (June is my first target).
>
> Right now, I'm collecting requirements, and ideas and starting to write
> that down. For sure, inheritance will be part of the new release as well as
> new handlers such as a kind of JPA handler... I also want to reduce the
> complexity of some mechanisms as the 'component type type' definition.
>
> Regards,
>
> Clement
>
> >
> > /Bengt
> >
> > 2010/9/9 Clement Escoffier <cl...@gmail.com>
> >
> >> Hi,
> >>
> >> You it is a really good feature. I'm thinking to that one since 1 year
> now.
> >> Despite I've an idea how to implement this support, it is an important
> >> change probably postponed until iPOJO 2.0.
> >> Supporting method callbacks is easy but supporting field injection on
> >> parent classes is really more tricky.
> >>
> >> Regards,
> >>
> >> Clement
> >>
> >>
> >> On 09.09.2010, at 09:26, Bengt Rodehav wrote:
> >>
> >>> I have the exact same problem. I have generic classes (in a framework)
> >> that
> >>> do most boilerplate stuff and the intention is to make it simple to add
> >> sub
> >>> classes with specific needs (most often adding service properties and
> >> logic)
> >>> - but I can't. I have to copy/paste all the boilerplate code to every
> >>> subclass.
> >>>
> >>> I would really like inheritance support for the annotations too.
> >>>
> >>> /Bengt
> >>>
> >>> 2010/9/9 Joel Schuster <jo...@navsys.com>
> >>>
> >>>>
> >>>> It seems that iPojo doesn't know how to go up the inheritance tree to
> >> look
> >>>> for annotations. So if I wish to have an abstract class that has the
> >>>> @Provides or @Component or even the @Validate/@Invalidate method
> because
> >> a
> >>>> bunch of them implement things in the same way I cannot.
> >>>>
> >>>> Am I correct?
> >>>>
> >>>> - Joel Schuster
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and inheritance
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 09.09.2010, at 21:09, Bengt Rodehav wrote:
> Clement,
>
> I'm glad you're considering it - it would be really useful. Do you have any
> idea of when iPOJO 2.0 would be released? Is it 6 months? A year?
First sorry for this late reply, the mail strangely went out of my radar.
I cannot give you an exact date for iPOJO 2.0. My goal is to release iPOJO 2.0 in 2011 (June is my first target).
Right now, I'm collecting requirements, and ideas and starting to write that down. For sure, inheritance will be part of the new release as well as new handlers such as a kind of JPA handler... I also want to reduce the complexity of some mechanisms as the 'component type type' definition.
Regards,
Clement
>
> /Bengt
>
> 2010/9/9 Clement Escoffier <cl...@gmail.com>
>
>> Hi,
>>
>> You it is a really good feature. I'm thinking to that one since 1 year now.
>> Despite I've an idea how to implement this support, it is an important
>> change probably postponed until iPOJO 2.0.
>> Supporting method callbacks is easy but supporting field injection on
>> parent classes is really more tricky.
>>
>> Regards,
>>
>> Clement
>>
>>
>> On 09.09.2010, at 09:26, Bengt Rodehav wrote:
>>
>>> I have the exact same problem. I have generic classes (in a framework)
>> that
>>> do most boilerplate stuff and the intention is to make it simple to add
>> sub
>>> classes with specific needs (most often adding service properties and
>> logic)
>>> - but I can't. I have to copy/paste all the boilerplate code to every
>>> subclass.
>>>
>>> I would really like inheritance support for the annotations too.
>>>
>>> /Bengt
>>>
>>> 2010/9/9 Joel Schuster <jo...@navsys.com>
>>>
>>>>
>>>> It seems that iPojo doesn't know how to go up the inheritance tree to
>> look
>>>> for annotations. So if I wish to have an abstract class that has the
>>>> @Provides or @Component or even the @Validate/@Invalidate method because
>> a
>>>> bunch of them implement things in the same way I cannot.
>>>>
>>>> Am I correct?
>>>>
>>>> - Joel Schuster
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and inheritance
Posted by Bengt Rodehav <be...@rodehav.com>.
Clement,
I'm glad you're considering it - it would be really useful. Do you have any
idea of when iPOJO 2.0 would be released? Is it 6 months? A year?
/Bengt
2010/9/9 Clement Escoffier <cl...@gmail.com>
> Hi,
>
> You it is a really good feature. I'm thinking to that one since 1 year now.
> Despite I've an idea how to implement this support, it is an important
> change probably postponed until iPOJO 2.0.
> Supporting method callbacks is easy but supporting field injection on
> parent classes is really more tricky.
>
> Regards,
>
> Clement
>
>
> On 09.09.2010, at 09:26, Bengt Rodehav wrote:
>
> > I have the exact same problem. I have generic classes (in a framework)
> that
> > do most boilerplate stuff and the intention is to make it simple to add
> sub
> > classes with specific needs (most often adding service properties and
> logic)
> > - but I can't. I have to copy/paste all the boilerplate code to every
> > subclass.
> >
> > I would really like inheritance support for the annotations too.
> >
> > /Bengt
> >
> > 2010/9/9 Joel Schuster <jo...@navsys.com>
> >
> >>
> >> It seems that iPojo doesn't know how to go up the inheritance tree to
> look
> >> for annotations. So if I wish to have an abstract class that has the
> >> @Provides or @Component or even the @Validate/@Invalidate method because
> a
> >> bunch of them implement things in the same way I cannot.
> >>
> >> Am I correct?
> >>
> >> - Joel Schuster
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and inheritance
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
You it is a really good feature. I'm thinking to that one since 1 year now. Despite I've an idea how to implement this support, it is an important change probably postponed until iPOJO 2.0.
Supporting method callbacks is easy but supporting field injection on parent classes is really more tricky.
Regards,
Clement
On 09.09.2010, at 09:26, Bengt Rodehav wrote:
> I have the exact same problem. I have generic classes (in a framework) that
> do most boilerplate stuff and the intention is to make it simple to add sub
> classes with specific needs (most often adding service properties and logic)
> - but I can't. I have to copy/paste all the boilerplate code to every
> subclass.
>
> I would really like inheritance support for the annotations too.
>
> /Bengt
>
> 2010/9/9 Joel Schuster <jo...@navsys.com>
>
>>
>> It seems that iPojo doesn't know how to go up the inheritance tree to look
>> for annotations. So if I wish to have an abstract class that has the
>> @Provides or @Component or even the @Validate/@Invalidate method because a
>> bunch of them implement things in the same way I cannot.
>>
>> Am I correct?
>>
>> - Joel Schuster
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and inheritance
Posted by Bengt Rodehav <be...@rodehav.com>.
I have the exact same problem. I have generic classes (in a framework) that
do most boilerplate stuff and the intention is to make it simple to add sub
classes with specific needs (most often adding service properties and logic)
- but I can't. I have to copy/paste all the boilerplate code to every
subclass.
I would really like inheritance support for the annotations too.
/Bengt
2010/9/9 Joel Schuster <jo...@navsys.com>
>
> It seems that iPojo doesn't know how to go up the inheritance tree to look
> for annotations. So if I wish to have an abstract class that has the
> @Provides or @Component or even the @Validate/@Invalidate method because a
> bunch of them implement things in the same way I cannot.
>
> Am I correct?
>
> - Joel Schuster
>