Hi Alasdair Thanks much for the valuable feedback. See comments in line -
On Wed, May 19, 2010 at 4:40 AM, Alasdair Nottingham <[email protected]> wrote: > Hi, > > I'm coming to all this a little late, I'm just back from vacation and > I'm not sure I know exactly where the discussion is right now, I'm > basing my feedback mostly on the wiki page. In my view we need to fit > the following principals for creating annotations: > > 1. Everything that can be done in XML does not need to be expressible > using annotations. > 2. Annotation based programming should be there to make development > trivial for the most common scenarios. > 3. You should be able to mix annotations and XML, and if both exist > XML trumps annotations. This allows changes to be made without > recompiling code. > 4. The annotations should be configuration by exception, so we should > choose good defaults. Totally agree with these. Annotation should be overridden by XML if similar configuration exists. This is the area I haven't really worked on since I am focusing on defining annotation syntax. > A key benefit in my experience of using annotations is that the > metadata is applied directly to the class to which it relates. If you > put the annotations in a different class it seems that we are > essentially creating a different serialisation of the xml, one that > goes to .java files, which isn't something I think makes sense. > > So based on the wiki page here are my thoughts: > > 1. I like the bean annotation and I think it makes sense to apply it to a > class. I agree. The purpose of @Bean annotation helps the annotation scanner to determine which class should be scanned, plus not all classes are beans in a blueprint managed bundle. > 2. I think the "id" should be optional if not specified we should > default, perhaps default to the class name of the bean. Yes, Guillaume pointed that out too and I agree. > 3. I don't think the args property of the Bean makes sense. First of > all it applies to the constructor, so I would annotate the > constructor, but in the second instance I'm not sure it makes sense to > initialise values in annotations, you can already express that in Java > code, so I think @Bean annotated classes should have a zero args > constructor. This is one of the biggest feedback I got from Guillaume. In order to make the classes portable, it makes sense not to specify argument values (or initialization values) in the java files via annotation. While you can specify it in blueprint definition XML in addition to annotation, but I think it may be simpler to specify in a global blueprint configuration java file, as doing so you leverages java to do basic checking for you to see if you are using the right class name, right parameter types, etc. So it seems to make sense to offer such an alternative. I remember seeing people making basic simple syntax mistakes with blueprint definition XML, for example: <bean id="bar" class="org.apache.aries.blueprint.sample.Bar"> <property name="value"> <value>Hello FooBar</value> </property> </bean> People can make simple mistakes in writing the class name wrong, or specify the property name incorrectly. With the these configuration in a java file, we essentially able to avoid these simple mistakes. Something like: @Blueprint public class MyConfig { @Bean public Bar bar() { Bar bar = new Bar(); bar.setValue("Hello FooBar"); return bar; } } > 4. I don't think factory methods etc make sense for an @Bean > annotation. I think you should annotate the factory component in that > case. > 5. Not 100% sure I see the point of annotating factories, but I don't > feel too strongly. I think it is possible that we don't need to specify/annotate factory methods at all, as they could be specified in the blueprint configuration java file when creating the bean. > 6. Why is @Inject and @Reference used together? This seems a common way to inject things when I read jsr 330. > 7. I do not think there is any point in the @Inject(value="Hello > FooBar") example, why wouldn't I just do private String value = "Hello > FooBar"; it is more efficient and simpler code. Yes, this is similar as your comments 3 above. It makes sense to put these values in a global blueprint configuration java file or blueprint XML so that the java file can be portable whenever the value changes. > 8. I think we should drop the @Blueprint annotation. This is for > overriding the defaults in the spec which should be good enough in > most scenarios. If someone wants to set these they can do this in a > blueprint.xml that only specifies the defaults. I was planning on using the @Blueprint annotation on the blueprint configuration java file, as this file is a global configuration for the bundle and using @Blueprint will identify this file easily, in addition to allow users to set these default values such as timeout, availability, etc. Thanks again. Lin
