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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
