You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Lin Sun <li...@gmail.com> on 2010/05/07 19:00:21 UTC
blueprint annotation prototype
Hi
I have been doing some prototype work for blueprint annotation in my
own sandbox[1]. Currently the code builds in these orders:
blueprint-annotation-api, blueprint-annotation-impl and
blueprint-sample-annotation, blueprint-annotation-itest. However the
itest only run successfully on my local machine, since I also have
some uncommitted code on my local machine that modifies the blueprint
core a bit to scan blueprint annotation for bundles that have the
Bundle-Blueprint-Annotation header to true. I intend to move the
sandbox code to trunk if there is no objection, so that I can commit
my change to blueprint core without breaking the aries build. I have
coded to do runtime annotation scanning only but supporting build time
generation of blueprint definition XML from annotation should be
possible.
The blueprint-annotation-api contains some of the basic annotations I
am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
@Inject, etc.
The blueprint-annotation-impl contains a bunch of generated and
slightly modified jaxb files along with some code to scan annotations
and write the generated blueprint definition to a URL location, using
xbean-finder.
The blueprint-sample-annotation contains an example of how these
annotations can be used in the sample.
Comments welcome!
Thanks
Lin
[1] https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Hi Valentin and Johan
Thanks much again for the feedback. I have attempted to address all
Valentin's feedback via recent commits this week except the moving the
@Blueprint annotation property to the bundle's manifest header, which
can be easily done but I am not 100% convinced on that :)
I have written a wiki page on the blueprint annotation work -
https://cwiki.apache.org/confluence/display/ARIES/BlueprintAnnotation.
It is created as a child of the existing blueprint page.
If anyone has any comments/questions, feel free to let me know :)
Thanks
Lin
On Fri, May 7, 2010 at 1:00 PM, Lin Sun <li...@gmail.com> wrote:
> Hi
>
> I have been doing some prototype work for blueprint annotation in my
> own sandbox[1]. Currently the code builds in these orders:
> blueprint-annotation-api, blueprint-annotation-impl and
> blueprint-sample-annotation, blueprint-annotation-itest. However the
> itest only run successfully on my local machine, since I also have
> some uncommitted code on my local machine that modifies the blueprint
> core a bit to scan blueprint annotation for bundles that have the
> Bundle-Blueprint-Annotation header to true. I intend to move the
> sandbox code to trunk if there is no objection, so that I can commit
> my change to blueprint core without breaking the aries build. I have
> coded to do runtime annotation scanning only but supporting build time
> generation of blueprint definition XML from annotation should be
> possible.
>
> The blueprint-annotation-api contains some of the basic annotations I
> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
> @Inject, etc.
>
> The blueprint-annotation-impl contains a bunch of generated and
> slightly modified jaxb files along with some code to scan annotations
> and write the generated blueprint definition to a URL location, using
> xbean-finder.
>
> The blueprint-sample-annotation contains an example of how these
> annotations can be used in the sample.
>
> Comments welcome!
>
> Thanks
>
> Lin
>
> [1] https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
>
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
I started to prototype the idea of using blueprint config to
initialize beans and attempted to convert our blueprint samples. Not
entirely done yet but I am not sure I like what i have -
public class BaseBlueprintConfig {
@Inject(ref="blueprintBundleContext")
BundleContext blueprintBundleContext;
@Inject(ref="blueprintContainer")
BlueprintContainer blueprintContainer;
@Inject(ref="blueprintBundle")
Bundle blueprintBundle;
@Inject(ref="converter")
Converter converter;
}
@Blueprint(defaultActivation="eager", defaultTimeout=300,
defaultAvailability="optional")
public class BlueprintConfig extends BaseBlueprintConfig {
Bar bar;
@Bean(id="bar")
public Bar bar() {
if (bar == null) {
bar = new Bar();
bar.setValue("Hello FooBar");
bar.setContext(blueprintBundleContext);
List l = new ArrayList();
l.add("a list element");
l.add(5);
bar.setList(l);
}
return bar;
}
@Bean
public Foo foo() {
Foo foo = new Foo();
foo.setA(5);
//foo.setB(${key.b});
foo.setBar(bar());
// not sure how to do this one...
foo.setCurrency(new Currency(null, 0));
foo.setDate(new Date("2009.04.17"));
return foo;
}
@Bean
public Account accountOne() {
Account account = new Account(1);
return account;
}
@Bean
public Account accountTwo() {
Account account = StaticAccountFactory.createAccount(2);
return account;
}
@Bean
public NewAccount accountThree() {
NewAccount account = getAccountFactory().createAccount(3);
return account;
}
@Bean
public AccountFactory getAccountFactory() {
AccountFactory af = new AccountFactory("account factory");
return af;
}
}
I have to admit that there are a few things I didn't like about the
blueprint configuration file:
1. I didn't like the fact that it detach many of the initialization
from the original java files. Some was very easy to annotate in the
original bean class but now I don't even know what to do, for example
the inject of the blueprintBundleContext I still have to fell back to
the original way of doing things and I don't even know how to do
foo.setCurrency which was obvious to me before.
2. I am concerned about converting these blueprint configuration to
the corresponding blueprint XML. I think this is necessary to have
the ability of blueprint XML override the annotation.
3. I remember one of Guillaume's concern was code reusability. Given
blueprint XML has higher priority than annotation, people can only
specify values that are stable in annotation and the rest in blueprint
definition XML, or modify what is being annotated or create blueprint
XML definition to override annotation without changing the java files.
4. For complicated scenario, may just be better to support only the
blueprint XML definition without annotation, for example initialize a
list.
Lin
On Tue, May 18, 2010 at 3:32 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> That would be better imho.
> I still think that adding annotations containing values (or reference to
> names of other beans) on a class is a bad idea. The reason is that it makes
> this class not reusable at all, which imho is one of the main feature of
> blueprint.
> Doing that would led our users down this path and when further down,
> they'll see that they can't really reuse their beans without modifying
> them...
>
> Annotations on the classes are fine when they just say something about the
> bean: if they need to be injected with a value, if a method is the
> initialization / destroy method, etc ...
>
> Another point is that we should try to minimize the amount of information in
> order to make things easier to refactory, not harder. Currently, all the
> ids of beans for example are centrlized in the xml. Spreading them around
> will just make things harder to refactor. The @Bean annotation should be
> mostly optional, as it does not bring anything. The use of @PreDestroy and
> @PostConstruct on the method will also make it easier to change the method
> name, without having the change the init-method attribute on the bean
> annotation.
>
> I don't think the goal should be to stay too close to the xml
> configuration. While dealing with Java, we could also thing about some kind
> of DSL to build the configuration.
>
> In addition, we need to remain blueprint compliant and make sure we have
> something in the blueprint xml to indicate we want some extension parser.
>
> On Fri, May 14, 2010 at 19:48, Lin Sun <li...@gmail.com> wrote:
>
>>
>> I wonder if we could use what we have now for simple, common cases,
>> while use a hybrid approach like below:
>>
>> 1) we allow users to annotate the class to define its behavior like
>> @Bean, @Service, @ReferenceListener like what we have right now.
>> 2) Optionally, we allow users to create a common configuration java
>> file to describe how they want to create instances with the values.
>>
>> For example:
>>
>> @Bean
>> public class BeanClass {
>> ...
>> }
>>
>
> Such annotations should not be mandatory I think. A bean is just an
> instance of a class. There's no load time weaving or anything going on at
> this point, so annotating it with a default annotation should be optional
> (if needed at all)
>
>
>>
>> @Bean(factoryRef="accountFactory",
>> factoryMethod="createAccount")
>> public class NewAccount {
>> ...
>> }
>>
>
> I really don't like this one either. If needed, this annotation should be
> on the createAccount method of the factory.
>
>
>>
>> // this class also gets to specify the blueprint global configuration
>> like defaultActivation, defaultTimeout, etc
>> @Blueprint(defaultActivation="eager", defaultTimeout=300,
>> defaultAvailability="optional")
>> public class BlueprintConfig {
>>
>> @Bean(id="myBean1")
>> public BeanClass beanClass1(){
>> @Inject @Bean(id="accountOne", args=@Arg(value="1")
>> NewAccount account;
>> ....
>> }
>>
>> @Bean(id="myBean2")
>> public BeanClass beanClass1(){
>> @Inject @Bean(id="accountOne", args=@Arg(value="2")
>> NewAccount account;
>> ....
>> }
>> }
>>
>> WDYT?
>>
>>
> The id of the bean could be inferred from the method name.
> What about the following configuration:
>
> @Blueprint
> public class MyConfig {
>
> @Bean public BeanClass myBean1() {
> return new BeanClass(accountFactory.createAccount(1));
> }
>
> @Bean public BeanClass myBean2() {
> return new BeanClass(accountFactory().createAccount(2));
> }
>
> @Bean public AccountFactory accountFactory() {
> return new AccountFactory();
> }
> }
>
> I suppose in order to respect scopes, we'd have to modify this class to
> intercept calls, so that the accountFactory() method would cache the value
> of the create account factory.
>
> I also think, that in order to support "custom namespace", we'd have to
> define annotations to put on other annotations, so that we can ask the
> namespace handler to help building the metadata. We also need to be able
> to inject values from outside to support config admin and property
> placeholders.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Hi Alasdair
Thanks much for the valuable feedback. See comments in line -
On Wed, May 19, 2010 at 4:40 AM, Alasdair Nottingham <no...@apache.org> 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
Re: blueprint annotation prototype
Posted by Alasdair Nottingham <no...@apache.org>.
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.
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.
2. I think the "id" should be optional if not specified we should
default, perhaps default to the class name of the bean.
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.
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.
6. Why is @Inject and @Reference used together?
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.
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.
Thanks
Alasdair
On 19 May 2010 02:44, Lin Sun <li...@gmail.com> wrote:
> Hi Guillaume,
>
> Thanks for the nice input. I think you have some excellent points
> here on code reusability and easy for re-factor. I'll try modify the
> annotation designs based on the discussions here and let you know when
> I have an update.
>
> Lin
>
> On Tue, May 18, 2010 at 3:32 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> That would be better imho.
>> I still think that adding annotations containing values (or reference to
>> names of other beans) on a class is a bad idea. The reason is that it makes
>> this class not reusable at all, which imho is one of the main feature of
>> blueprint.
>> Doing that would led our users down this path and when further down,
>> they'll see that they can't really reuse their beans without modifying
>> them...
>>
>> Annotations on the classes are fine when they just say something about the
>> bean: if they need to be injected with a value, if a method is the
>> initialization / destroy method, etc ...
>>
>> Another point is that we should try to minimize the amount of information in
>> order to make things easier to refactory, not harder. Currently, all the
>> ids of beans for example are centrlized in the xml. Spreading them around
>> will just make things harder to refactor. The @Bean annotation should be
>> mostly optional, as it does not bring anything. The use of @PreDestroy and
>> @PostConstruct on the method will also make it easier to change the method
>> name, without having the change the init-method attribute on the bean
>> annotation.
>>
>> I don't think the goal should be to stay too close to the xml
>> configuration. While dealing with Java, we could also thing about some kind
>> of DSL to build the configuration.
>>
>> In addition, we need to remain blueprint compliant and make sure we have
>> something in the blueprint xml to indicate we want some extension parser.
>>
>> On Fri, May 14, 2010 at 19:48, Lin Sun <li...@gmail.com> wrote:
>>
>>>
>>> I wonder if we could use what we have now for simple, common cases,
>>> while use a hybrid approach like below:
>>>
>>> 1) we allow users to annotate the class to define its behavior like
>>> @Bean, @Service, @ReferenceListener like what we have right now.
>>> 2) Optionally, we allow users to create a common configuration java
>>> file to describe how they want to create instances with the values.
>>>
>>> For example:
>>>
>>> @Bean
>>> public class BeanClass {
>>> ...
>>> }
>>>
>>
>> Such annotations should not be mandatory I think. A bean is just an
>> instance of a class. There's no load time weaving or anything going on at
>> this point, so annotating it with a default annotation should be optional
>> (if needed at all)
>>
>>
>>>
>>> @Bean(factoryRef="accountFactory",
>>> factoryMethod="createAccount")
>>> public class NewAccount {
>>> ...
>>> }
>>>
>>
>> I really don't like this one either. If needed, this annotation should be
>> on the createAccount method of the factory.
>>
>>
>>>
>>> // this class also gets to specify the blueprint global configuration
>>> like defaultActivation, defaultTimeout, etc
>>> @Blueprint(defaultActivation="eager", defaultTimeout=300,
>>> defaultAvailability="optional")
>>> public class BlueprintConfig {
>>>
>>> @Bean(id="myBean1")
>>> public BeanClass beanClass1(){
>>> @Inject @Bean(id="accountOne", args=@Arg(value="1")
>>> NewAccount account;
>>> ....
>>> }
>>>
>>> @Bean(id="myBean2")
>>> public BeanClass beanClass1(){
>>> @Inject @Bean(id="accountOne", args=@Arg(value="2")
>>> NewAccount account;
>>> ....
>>> }
>>> }
>>>
>>> WDYT?
>>>
>>>
>> The id of the bean could be inferred from the method name.
>> What about the following configuration:
>>
>> @Blueprint
>> public class MyConfig {
>>
>> @Bean public BeanClass myBean1() {
>> return new BeanClass(accountFactory.createAccount(1));
>> }
>>
>> @Bean public BeanClass myBean2() {
>> return new BeanClass(accountFactory().createAccount(2));
>> }
>>
>> @Bean public AccountFactory accountFactory() {
>> return new AccountFactory();
>> }
>> }
>>
>> I suppose in order to respect scopes, we'd have to modify this class to
>> intercept calls, so that the accountFactory() method would cache the value
>> of the create account factory.
>>
>> I also think, that in order to support "custom namespace", we'd have to
>> define annotations to put on other annotations, so that we can ask the
>> namespace handler to help building the metadata. We also need to be able
>> to inject values from outside to support config admin and property
>> placeholders.
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Alasdair Nottingham
not@apache.org
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Hi Guillaume,
Thanks for the nice input. I think you have some excellent points
here on code reusability and easy for re-factor. I'll try modify the
annotation designs based on the discussions here and let you know when
I have an update.
Lin
On Tue, May 18, 2010 at 3:32 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> That would be better imho.
> I still think that adding annotations containing values (or reference to
> names of other beans) on a class is a bad idea. The reason is that it makes
> this class not reusable at all, which imho is one of the main feature of
> blueprint.
> Doing that would led our users down this path and when further down,
> they'll see that they can't really reuse their beans without modifying
> them...
>
> Annotations on the classes are fine when they just say something about the
> bean: if they need to be injected with a value, if a method is the
> initialization / destroy method, etc ...
>
> Another point is that we should try to minimize the amount of information in
> order to make things easier to refactory, not harder. Currently, all the
> ids of beans for example are centrlized in the xml. Spreading them around
> will just make things harder to refactor. The @Bean annotation should be
> mostly optional, as it does not bring anything. The use of @PreDestroy and
> @PostConstruct on the method will also make it easier to change the method
> name, without having the change the init-method attribute on the bean
> annotation.
>
> I don't think the goal should be to stay too close to the xml
> configuration. While dealing with Java, we could also thing about some kind
> of DSL to build the configuration.
>
> In addition, we need to remain blueprint compliant and make sure we have
> something in the blueprint xml to indicate we want some extension parser.
>
> On Fri, May 14, 2010 at 19:48, Lin Sun <li...@gmail.com> wrote:
>
>>
>> I wonder if we could use what we have now for simple, common cases,
>> while use a hybrid approach like below:
>>
>> 1) we allow users to annotate the class to define its behavior like
>> @Bean, @Service, @ReferenceListener like what we have right now.
>> 2) Optionally, we allow users to create a common configuration java
>> file to describe how they want to create instances with the values.
>>
>> For example:
>>
>> @Bean
>> public class BeanClass {
>> ...
>> }
>>
>
> Such annotations should not be mandatory I think. A bean is just an
> instance of a class. There's no load time weaving or anything going on at
> this point, so annotating it with a default annotation should be optional
> (if needed at all)
>
>
>>
>> @Bean(factoryRef="accountFactory",
>> factoryMethod="createAccount")
>> public class NewAccount {
>> ...
>> }
>>
>
> I really don't like this one either. If needed, this annotation should be
> on the createAccount method of the factory.
>
>
>>
>> // this class also gets to specify the blueprint global configuration
>> like defaultActivation, defaultTimeout, etc
>> @Blueprint(defaultActivation="eager", defaultTimeout=300,
>> defaultAvailability="optional")
>> public class BlueprintConfig {
>>
>> @Bean(id="myBean1")
>> public BeanClass beanClass1(){
>> @Inject @Bean(id="accountOne", args=@Arg(value="1")
>> NewAccount account;
>> ....
>> }
>>
>> @Bean(id="myBean2")
>> public BeanClass beanClass1(){
>> @Inject @Bean(id="accountOne", args=@Arg(value="2")
>> NewAccount account;
>> ....
>> }
>> }
>>
>> WDYT?
>>
>>
> The id of the bean could be inferred from the method name.
> What about the following configuration:
>
> @Blueprint
> public class MyConfig {
>
> @Bean public BeanClass myBean1() {
> return new BeanClass(accountFactory.createAccount(1));
> }
>
> @Bean public BeanClass myBean2() {
> return new BeanClass(accountFactory().createAccount(2));
> }
>
> @Bean public AccountFactory accountFactory() {
> return new AccountFactory();
> }
> }
>
> I suppose in order to respect scopes, we'd have to modify this class to
> intercept calls, so that the accountFactory() method would cache the value
> of the create account factory.
>
> I also think, that in order to support "custom namespace", we'd have to
> define annotations to put on other annotations, so that we can ask the
> namespace handler to help building the metadata. We also need to be able
> to inject values from outside to support config admin and property
> placeholders.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: blueprint annotation prototype
Posted by Guillaume Nodet <gn...@gmail.com>.
That would be better imho.
I still think that adding annotations containing values (or reference to
names of other beans) on a class is a bad idea. The reason is that it makes
this class not reusable at all, which imho is one of the main feature of
blueprint.
Doing that would led our users down this path and when further down,
they'll see that they can't really reuse their beans without modifying
them...
Annotations on the classes are fine when they just say something about the
bean: if they need to be injected with a value, if a method is the
initialization / destroy method, etc ...
Another point is that we should try to minimize the amount of information in
order to make things easier to refactory, not harder. Currently, all the
ids of beans for example are centrlized in the xml. Spreading them around
will just make things harder to refactor. The @Bean annotation should be
mostly optional, as it does not bring anything. The use of @PreDestroy and
@PostConstruct on the method will also make it easier to change the method
name, without having the change the init-method attribute on the bean
annotation.
I don't think the goal should be to stay too close to the xml
configuration. While dealing with Java, we could also thing about some kind
of DSL to build the configuration.
In addition, we need to remain blueprint compliant and make sure we have
something in the blueprint xml to indicate we want some extension parser.
On Fri, May 14, 2010 at 19:48, Lin Sun <li...@gmail.com> wrote:
>
> I wonder if we could use what we have now for simple, common cases,
> while use a hybrid approach like below:
>
> 1) we allow users to annotate the class to define its behavior like
> @Bean, @Service, @ReferenceListener like what we have right now.
> 2) Optionally, we allow users to create a common configuration java
> file to describe how they want to create instances with the values.
>
> For example:
>
> @Bean
> public class BeanClass {
> ...
> }
>
Such annotations should not be mandatory I think. A bean is just an
instance of a class. There's no load time weaving or anything going on at
this point, so annotating it with a default annotation should be optional
(if needed at all)
>
> @Bean(factoryRef="accountFactory",
> factoryMethod="createAccount")
> public class NewAccount {
> ...
> }
>
I really don't like this one either. If needed, this annotation should be
on the createAccount method of the factory.
>
> // this class also gets to specify the blueprint global configuration
> like defaultActivation, defaultTimeout, etc
> @Blueprint(defaultActivation="eager", defaultTimeout=300,
> defaultAvailability="optional")
> public class BlueprintConfig {
>
> @Bean(id="myBean1")
> public BeanClass beanClass1(){
> @Inject @Bean(id="accountOne", args=@Arg(value="1")
> NewAccount account;
> ....
> }
>
> @Bean(id="myBean2")
> public BeanClass beanClass1(){
> @Inject @Bean(id="accountOne", args=@Arg(value="2")
> NewAccount account;
> ....
> }
> }
>
> WDYT?
>
>
The id of the bean could be inferred from the method name.
What about the following configuration:
@Blueprint
public class MyConfig {
@Bean public BeanClass myBean1() {
return new BeanClass(accountFactory.createAccount(1));
}
@Bean public BeanClass myBean2() {
return new BeanClass(accountFactory().createAccount(2));
}
@Bean public AccountFactory accountFactory() {
return new AccountFactory();
}
}
I suppose in order to respect scopes, we'd have to modify this class to
intercept calls, so that the accountFactory() method would cache the value
of the create account factory.
I also think, that in order to support "custom namespace", we'd have to
define annotations to put on other annotations, so that we can ask the
namespace handler to help building the metadata. We also need to be able
to inject values from outside to support config admin and property
placeholders.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Hi Guillaume
Thanks much for the valuable feedback! I will look at jsr 330 a bit
more closely to see if there is any we could leverage.
See comments in line
Lin
On Fri, May 14, 2010 at 12:26 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> On another topic, I do agree that what you have defined closely maps to the
> blueprint xml, but at the same time, it just looks very weird in some cases.
>
> For example, in the sample, you have:
>
> @Bean(id="accountThree",
> factoryRef="accountFactory",
> factoryMethod="createAccount",
> args=@Arg(value="3"))
> public class NewAccount {
> ...
> }
>
>
> The problem is that if you want several instances of the same class with
> different values, you'd have to add several @Bean annotations.
Yes you are correct on that with the current solution, even tho this
is still possible.
> So something like
>
> <bean id="myBean1" class="BeanClass">
> <property name="account">
> <bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
> factoryMethod="createAccount">
> <argument value="2"/>
> </bean>
> </property>
> </bean>
> <bean id="myBean2" class="BeanClass">
> <property name="account">
> <bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
> factoryMethod="createAccount">
> <argument value="3"/>
> </bean>
> </property>
> </bean>
>
> could not even be translated using annotations.
>
> It looks to me that annotating the class to create instances with values
> just does not work.
Yes this was not really a requirement when I first prototyped the
code, as I didn't know if it is common scenario for people to do so.
If this is a common scenario that we should support, I agree with you
that annotating the class to create instances with values won't work
for this case.
I wonder if we could use what we have now for simple, common cases,
while use a hybrid approach like below:
1) we allow users to annotate the class to define its behavior like
@Bean, @Service, @ReferenceListener like what we have right now.
2) Optionally, we allow users to create a common configuration java
file to describe how they want to create instances with the values.
For example:
@Bean
public class BeanClass {
...
}
@Bean(factoryRef="accountFactory",
factoryMethod="createAccount")
public class NewAccount {
...
}
// this class also gets to specify the blueprint global configuration
like defaultActivation, defaultTimeout, etc
@Blueprint(defaultActivation="eager", defaultTimeout=300,
defaultAvailability="optional")
public class BlueprintConfig {
@Bean(id="myBean1")
public BeanClass beanClass1(){
@Inject @Bean(id="accountOne", args=@Arg(value="1")
NewAccount account;
....
}
@Bean(id="myBean2")
public BeanClass beanClass1(){
@Inject @Bean(id="accountOne", args=@Arg(value="2")
NewAccount account;
....
}
}
WDYT?
> I don't have a good answer yet, but I think the values used to create the
> instances have to be specified outside the class itself. The annotations on
> the class can/should only be common to all instances created from a given
> class.
>
>
> So while annotating the bean to define its behavior is fine, annotating
>
> On Fri, May 14, 2010 at 18:11, Lin Sun <li...@gmail.com> wrote:
>
>> Good question. I tried to look jsr 330(Dependency Injection) before I
>> came up these annotation. It essentially provides 6 annotations
>> @Inject, @Named, @Provider, @Qualifier, @Scope, @Singleton. I don't
>> think it can be mapped to many functions we need such as Service,
>> Reference, ReferenceListener, RegistrationListener, annotate bind,
>> unbind, register, unregister, init, and so on methods.
>>
>> I like the @Inject provided by jsr 330 annotation but it doesn't
>> provide exactly what we want, as often times, when we inject
>> something, we either provide a value or a ref.
>>
>> @Singleton and @Scope could be possibly used, even tho it is currently
>> specified as property to @Bean annotation where you specify the scope
>> of the bean.
>>
>> From a user's point of view, I think it would be easy to use familiar
>> blueprint concepts such as bean, service, reference, referencelist,
>> registrationlistener, referencelistener, etc to annotate the classes.
>> From this sense, this is similar like Peter Kriens proposed the
>> annotation for components [1]
>>
>> HTH
>>
>> Lin
>>
>> [1] http://www.aqute.biz/Blog/20091020
>>
>> One thing that is not obvious to me is that how these jsr 330
>> annotations can be possibly mapped to what we want in blueprint.
>>
>> On Fri, May 14, 2010 at 11:48 AM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>> > I haven't really had any time to look at what you've done yet, but my
>> first
>> > reaction was / is, why not leverage jsr330 instead of redefining a whole
>> new
>> > set of annotations ?
>> >
>> > On Fri, May 7, 2010 at 19:00, Lin Sun <li...@gmail.com> wrote:
>> >
>> >> Hi
>> >>
>> >> I have been doing some prototype work for blueprint annotation in my
>> >> own sandbox[1]. Currently the code builds in these orders:
>> >> blueprint-annotation-api, blueprint-annotation-impl and
>> >> blueprint-sample-annotation, blueprint-annotation-itest. However the
>> >> itest only run successfully on my local machine, since I also have
>> >> some uncommitted code on my local machine that modifies the blueprint
>> >> core a bit to scan blueprint annotation for bundles that have the
>> >> Bundle-Blueprint-Annotation header to true. I intend to move the
>> >> sandbox code to trunk if there is no objection, so that I can commit
>> >> my change to blueprint core without breaking the aries build. I have
>> >> coded to do runtime annotation scanning only but supporting build time
>> >> generation of blueprint definition XML from annotation should be
>> >> possible.
>> >>
>> >> The blueprint-annotation-api contains some of the basic annotations I
>> >> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
>> >> @Inject, etc.
>> >>
>> >> The blueprint-annotation-impl contains a bunch of generated and
>> >> slightly modified jaxb files along with some code to scan annotations
>> >> and write the generated blueprint definition to a URL location, using
>> >> xbean-finder.
>> >>
>> >> The blueprint-sample-annotation contains an example of how these
>> >> annotations can be used in the sample.
>> >>
>> >> Comments welcome!
>> >>
>> >> Thanks
>> >>
>> >> Lin
>> >>
>> >> [1]
>> >>
>> https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: blueprint annotation prototype
Posted by Guillaume Nodet <gn...@gmail.com>.
Actually, I just spotted another example which seems plain wrong to me:
@Bean(id="accountTwo",
factoryMethod="createAccount",
args = @Arg(value="2"))
public class StaticAccountFactory {
public static Account createAccount(long number) {
return new Account(number);
}
}
Once again, this just isn't usable. Things like that just make dependency
injection useless, as you can't reuse any class at all (because you need to
annotate them with specific values, so you can't import them from another
bundle).
So the overall current solution looks to me as very restricting and I fear
users would try to use it and very soon hit the limitation.
I've just had a look at what the spring guys came up with to solve the
problem, and it looks much better to me:
@Configurationpublic class AppConfig {
@Bean
public ClientService clientService1() {
ClientServiceImpl clientService = new ClientServiceImpl();
clientService.setClientDao(clientDao());
return clientService;
}
@Bean
public ClientService clientService2() {
ClientServiceImpl clientService = new ClientServiceImpl();
clientService.setClientDao(clientDao());
return clientService;
}
@Bean
public ClientDao clientDao() {
return new ClientDaoImpl();
}
}
On Fri, May 14, 2010 at 18:26, Guillaume Nodet <gn...@gmail.com> wrote:
> Well, if you look well enough, some of those are annotations for
> annotations.
> So their role is to be used to define your own api using annotations but
> annotating them with @Qualifier, @Scope.
> For example, @Named is annotated with @Qualifier.
> So there may be a way to still reuse those, even at least @PreDestroy and
> @PostConstruct which are already in the JRE.
>
> On another topic, I do agree that what you have defined closely maps to the
> blueprint xml, but at the same time, it just looks very weird in some cases.
>
> For example, in the sample, you have:
>
> @Bean(id="accountThree",
> factoryRef="accountFactory",
> factoryMethod="createAccount",
> args=@Arg(value="3"))
> public class NewAccount {
> ...
> }
>
>
> The problem is that if you want several instances of the same class with
> different values, you'd have to add several @Bean annotations.
> So something like
>
> <bean id="myBean1" class="BeanClass">
> <property name="account">
> <bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
> factoryMethod="createAccount">
> <argument value="2"/>
> </bean>
> </property>
> </bean>
> <bean id="myBean2" class="BeanClass">
> <property name="account">
> <bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
> factoryMethod="createAccount">
> <argument value="3"/>
> </bean>
> </property>
> </bean>
>
> could not even be translated using annotations.
>
> It looks to me that annotating the class to create instances with values
> just does not work.
>
> I don't have a good answer yet, but I think the values used to create the
> instances have to be specified outside the class itself. The annotations on
> the class can/should only be common to all instances created from a given
> class.
>
>
> So while annotating the bean to define its behavior is fine, annotating
>
> On Fri, May 14, 2010 at 18:11, Lin Sun <li...@gmail.com> wrote:
>
>> Good question. I tried to look jsr 330(Dependency Injection) before I
>> came up these annotation. It essentially provides 6 annotations
>> @Inject, @Named, @Provider, @Qualifier, @Scope, @Singleton. I don't
>> think it can be mapped to many functions we need such as Service,
>> Reference, ReferenceListener, RegistrationListener, annotate bind,
>> unbind, register, unregister, init, and so on methods.
>>
>> I like the @Inject provided by jsr 330 annotation but it doesn't
>> provide exactly what we want, as often times, when we inject
>> something, we either provide a value or a ref.
>>
>> @Singleton and @Scope could be possibly used, even tho it is currently
>> specified as property to @Bean annotation where you specify the scope
>> of the bean.
>>
>> From a user's point of view, I think it would be easy to use familiar
>> blueprint concepts such as bean, service, reference, referencelist,
>> registrationlistener, referencelistener, etc to annotate the classes.
>> From this sense, this is similar like Peter Kriens proposed the
>> annotation for components [1]
>>
>> HTH
>>
>> Lin
>>
>> [1] http://www.aqute.biz/Blog/20091020
>>
>> One thing that is not obvious to me is that how these jsr 330
>> annotations can be possibly mapped to what we want in blueprint.
>>
>> On Fri, May 14, 2010 at 11:48 AM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>> > I haven't really had any time to look at what you've done yet, but my
>> first
>> > reaction was / is, why not leverage jsr330 instead of redefining a whole
>> new
>> > set of annotations ?
>> >
>> > On Fri, May 7, 2010 at 19:00, Lin Sun <li...@gmail.com> wrote:
>> >
>> >> Hi
>> >>
>> >> I have been doing some prototype work for blueprint annotation in my
>> >> own sandbox[1]. Currently the code builds in these orders:
>> >> blueprint-annotation-api, blueprint-annotation-impl and
>> >> blueprint-sample-annotation, blueprint-annotation-itest. However the
>> >> itest only run successfully on my local machine, since I also have
>> >> some uncommitted code on my local machine that modifies the blueprint
>> >> core a bit to scan blueprint annotation for bundles that have the
>> >> Bundle-Blueprint-Annotation header to true. I intend to move the
>> >> sandbox code to trunk if there is no objection, so that I can commit
>> >> my change to blueprint core without breaking the aries build. I have
>> >> coded to do runtime annotation scanning only but supporting build time
>> >> generation of blueprint definition XML from annotation should be
>> >> possible.
>> >>
>> >> The blueprint-annotation-api contains some of the basic annotations I
>> >> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
>> >> @Inject, etc.
>> >>
>> >> The blueprint-annotation-impl contains a bunch of generated and
>> >> slightly modified jaxb files along with some code to scan annotations
>> >> and write the generated blueprint definition to a URL location, using
>> >> xbean-finder.
>> >>
>> >> The blueprint-sample-annotation contains an example of how these
>> >> annotations can be used in the sample.
>> >>
>> >> Comments welcome!
>> >>
>> >> Thanks
>> >>
>> >> Lin
>> >>
>> >> [1]
>> >>
>> https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: blueprint annotation prototype
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, if you look well enough, some of those are annotations for
annotations.
So their role is to be used to define your own api using annotations but
annotating them with @Qualifier, @Scope.
For example, @Named is annotated with @Qualifier.
So there may be a way to still reuse those, even at least @PreDestroy and
@PostConstruct which are already in the JRE.
On another topic, I do agree that what you have defined closely maps to the
blueprint xml, but at the same time, it just looks very weird in some cases.
For example, in the sample, you have:
@Bean(id="accountThree",
factoryRef="accountFactory",
factoryMethod="createAccount",
args=@Arg(value="3"))
public class NewAccount {
...
}
The problem is that if you want several instances of the same class with
different values, you'd have to add several @Bean annotations.
So something like
<bean id="myBean1" class="BeanClass">
<property name="account">
<bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
factoryMethod="createAccount">
<argument value="2"/>
</bean>
</property>
</bean>
<bean id="myBean2" class="BeanClass">
<property name="account">
<bean id="accountTwo" class="NewAccount" factory-ref="accountFactory"
factoryMethod="createAccount">
<argument value="3"/>
</bean>
</property>
</bean>
could not even be translated using annotations.
It looks to me that annotating the class to create instances with values
just does not work.
I don't have a good answer yet, but I think the values used to create the
instances have to be specified outside the class itself. The annotations on
the class can/should only be common to all instances created from a given
class.
So while annotating the bean to define its behavior is fine, annotating
On Fri, May 14, 2010 at 18:11, Lin Sun <li...@gmail.com> wrote:
> Good question. I tried to look jsr 330(Dependency Injection) before I
> came up these annotation. It essentially provides 6 annotations
> @Inject, @Named, @Provider, @Qualifier, @Scope, @Singleton. I don't
> think it can be mapped to many functions we need such as Service,
> Reference, ReferenceListener, RegistrationListener, annotate bind,
> unbind, register, unregister, init, and so on methods.
>
> I like the @Inject provided by jsr 330 annotation but it doesn't
> provide exactly what we want, as often times, when we inject
> something, we either provide a value or a ref.
>
> @Singleton and @Scope could be possibly used, even tho it is currently
> specified as property to @Bean annotation where you specify the scope
> of the bean.
>
> From a user's point of view, I think it would be easy to use familiar
> blueprint concepts such as bean, service, reference, referencelist,
> registrationlistener, referencelistener, etc to annotate the classes.
> From this sense, this is similar like Peter Kriens proposed the
> annotation for components [1]
>
> HTH
>
> Lin
>
> [1] http://www.aqute.biz/Blog/20091020
>
> One thing that is not obvious to me is that how these jsr 330
> annotations can be possibly mapped to what we want in blueprint.
>
> On Fri, May 14, 2010 at 11:48 AM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> > I haven't really had any time to look at what you've done yet, but my
> first
> > reaction was / is, why not leverage jsr330 instead of redefining a whole
> new
> > set of annotations ?
> >
> > On Fri, May 7, 2010 at 19:00, Lin Sun <li...@gmail.com> wrote:
> >
> >> Hi
> >>
> >> I have been doing some prototype work for blueprint annotation in my
> >> own sandbox[1]. Currently the code builds in these orders:
> >> blueprint-annotation-api, blueprint-annotation-impl and
> >> blueprint-sample-annotation, blueprint-annotation-itest. However the
> >> itest only run successfully on my local machine, since I also have
> >> some uncommitted code on my local machine that modifies the blueprint
> >> core a bit to scan blueprint annotation for bundles that have the
> >> Bundle-Blueprint-Annotation header to true. I intend to move the
> >> sandbox code to trunk if there is no objection, so that I can commit
> >> my change to blueprint core without breaking the aries build. I have
> >> coded to do runtime annotation scanning only but supporting build time
> >> generation of blueprint definition XML from annotation should be
> >> possible.
> >>
> >> The blueprint-annotation-api contains some of the basic annotations I
> >> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
> >> @Inject, etc.
> >>
> >> The blueprint-annotation-impl contains a bunch of generated and
> >> slightly modified jaxb files along with some code to scan annotations
> >> and write the generated blueprint definition to a URL location, using
> >> xbean-finder.
> >>
> >> The blueprint-sample-annotation contains an example of how these
> >> annotations can be used in the sample.
> >>
> >> Comments welcome!
> >>
> >> Thanks
> >>
> >> Lin
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Good question. I tried to look jsr 330(Dependency Injection) before I
came up these annotation. It essentially provides 6 annotations
@Inject, @Named, @Provider, @Qualifier, @Scope, @Singleton. I don't
think it can be mapped to many functions we need such as Service,
Reference, ReferenceListener, RegistrationListener, annotate bind,
unbind, register, unregister, init, and so on methods.
I like the @Inject provided by jsr 330 annotation but it doesn't
provide exactly what we want, as often times, when we inject
something, we either provide a value or a ref.
@Singleton and @Scope could be possibly used, even tho it is currently
specified as property to @Bean annotation where you specify the scope
of the bean.
>From a user's point of view, I think it would be easy to use familiar
blueprint concepts such as bean, service, reference, referencelist,
registrationlistener, referencelistener, etc to annotate the classes.
>From this sense, this is similar like Peter Kriens proposed the
annotation for components [1]
HTH
Lin
[1] http://www.aqute.biz/Blog/20091020
One thing that is not obvious to me is that how these jsr 330
annotations can be possibly mapped to what we want in blueprint.
On Fri, May 14, 2010 at 11:48 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> I haven't really had any time to look at what you've done yet, but my first
> reaction was / is, why not leverage jsr330 instead of redefining a whole new
> set of annotations ?
>
> On Fri, May 7, 2010 at 19:00, Lin Sun <li...@gmail.com> wrote:
>
>> Hi
>>
>> I have been doing some prototype work for blueprint annotation in my
>> own sandbox[1]. Currently the code builds in these orders:
>> blueprint-annotation-api, blueprint-annotation-impl and
>> blueprint-sample-annotation, blueprint-annotation-itest. However the
>> itest only run successfully on my local machine, since I also have
>> some uncommitted code on my local machine that modifies the blueprint
>> core a bit to scan blueprint annotation for bundles that have the
>> Bundle-Blueprint-Annotation header to true. I intend to move the
>> sandbox code to trunk if there is no objection, so that I can commit
>> my change to blueprint core without breaking the aries build. I have
>> coded to do runtime annotation scanning only but supporting build time
>> generation of blueprint definition XML from annotation should be
>> possible.
>>
>> The blueprint-annotation-api contains some of the basic annotations I
>> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
>> @Inject, etc.
>>
>> The blueprint-annotation-impl contains a bunch of generated and
>> slightly modified jaxb files along with some code to scan annotations
>> and write the generated blueprint definition to a URL location, using
>> xbean-finder.
>>
>> The blueprint-sample-annotation contains an example of how these
>> annotations can be used in the sample.
>>
>> Comments welcome!
>>
>> Thanks
>>
>> Lin
>>
>> [1]
>> https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: blueprint annotation prototype
Posted by Guillaume Nodet <gn...@gmail.com>.
I haven't really had any time to look at what you've done yet, but my first
reaction was / is, why not leverage jsr330 instead of redefining a whole new
set of annotations ?
On Fri, May 7, 2010 at 19:00, Lin Sun <li...@gmail.com> wrote:
> Hi
>
> I have been doing some prototype work for blueprint annotation in my
> own sandbox[1]. Currently the code builds in these orders:
> blueprint-annotation-api, blueprint-annotation-impl and
> blueprint-sample-annotation, blueprint-annotation-itest. However the
> itest only run successfully on my local machine, since I also have
> some uncommitted code on my local machine that modifies the blueprint
> core a bit to scan blueprint annotation for bundles that have the
> Bundle-Blueprint-Annotation header to true. I intend to move the
> sandbox code to trunk if there is no objection, so that I can commit
> my change to blueprint core without breaking the aries build. I have
> coded to do runtime annotation scanning only but supporting build time
> generation of blueprint definition XML from annotation should be
> possible.
>
> The blueprint-annotation-api contains some of the basic annotations I
> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
> @Inject, etc.
>
> The blueprint-annotation-impl contains a bunch of generated and
> slightly modified jaxb files along with some code to scan annotations
> and write the generated blueprint definition to a URL location, using
> xbean-finder.
>
> The blueprint-sample-annotation contains an example of how these
> annotations can be used in the sample.
>
> Comments welcome!
>
> Thanks
>
> Lin
>
> [1]
> https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: blueprint annotation prototype
Posted by Johan Edstrom <jo...@opennms.org>.
I really like this,
Thank you.
On May 8, 2010, at 9:17 PM, Lin Sun wrote:
> Hi Valentin
>
> Thanks much for the valuable feedback. See replies in line below
>
> Lin
>
> On Sat, May 8, 2010 at 11:54 AM, Valentin Mahrwald
> <vm...@googlemail.com> wrote:
>> Hi Lin,
>>
>> the annotation code looks cool, will be well cool when blueprint xml is no longer needed.
>
> Not sure if we 'll have the equivalent of annotation for all blueprint
> definition xmls, but hopefully for majority of them soon :)
>
>>
>> Some comments I have (in particular order):
>>
>> - how does field injection work in the current code, I couldn't see that you set the extension attribute anywhere?
>
> Field injection is currently processed when processing the class that
> has @Bean annotation, the code checks if any of the declared fields
> have @Inject annotation. @Inject can be used on Field, Constructor
> and Method.
>>
>> - what is the intention behind giving the scanner service service.ranking=0, I thought 0 was the default?
>
> No particular intention... since it is the only scanner service avail
> so it doesn't really mean anything right now :-)
>
>> - might it be better to allow the blueprint level settings (defaultActivation, defaultTimeout, defaultAvailability) in the bundle manifest as opposed to an annotation on a random class?
>
> Yes, that is certainly feasible, and may make more sense since the
> manifest is at the bundle level :)
>
>> - as far as I understand the FactoryMethod annotation, this annotation is going to be used on the factory class, right? Does this mean that this only works for factory classes using annotations (and in the same bundle), also how does this work with multiple factory methods like java.util.concurrent.Executors?
>
> Good question. I didn't think I work out issues with FactoryMethod
> annotation in implementation and that is why I commented out the
> annotation in AccountFactory.java. Seems to me it make more sense to
> allow users to specify the factoryMethod attribute and its arguments
> in @Bean annotation. I didn't go this route in the first place, as I
> thought it was pretty hard to specify such an annotation from a user's
> point of view.
>
>> - the Reference and ReferenceList annotations look a bit strange with an annotation target of type because to me that suggests you can only use them if your bundle contains the interfaces for any services you want to inject via annotations.
>>
>> What about supporting annotation like
>>
>> class ServiceUser {
>>
>> @InjectReference(
>> ...
>> )
>> private Service service;
>> }
>
> I like that, I think this is more reasonable. I'll see if we can use
> the existing @Inject annotation since it has an attribute ref, or
> create a new @InjectReference annotation.
>
>> - also the bind and unbind methods look awkward being marked as Strings in the ReferenceListener annotation as opposed to having separate annotations like Init and Destroy? (Same for registration listeners :)
>>
>>
>> Maybe (although that works only for annotation based reference listeners), and similarly for RegistrationListeners:
>>
>> class ServiceUser {
>>
>> @InjectReference(
>> listener=Listener.class
>> )
>> private Service service;
>> }
>>
>> @ReferenceListener
>> class Listener {
>> @Bind
>> public void bind() { ... }
>>
>> @Unbind
>> public void unbind() { ... }
>> }
>
> I think I didn't use @Bind or @Unbind annotation as I was not sure if
> there can be multiple bind methods in a class like the factory method.
> (The BindingListener.java seems to indicate that there can be
> multiple.) The init or destory I assume would be unique in the class.
>
>> Apologies for the amount of questions ;)
>
> No prob at all. :) Glad you reviewed it and appreciated the feedback!
>
> Lin
Johan Edstrom
joed@opennms.org
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: blueprint annotation prototype
Posted by Lin Sun <li...@gmail.com>.
Hi Valentin
Thanks much for the valuable feedback. See replies in line below
Lin
On Sat, May 8, 2010 at 11:54 AM, Valentin Mahrwald
<vm...@googlemail.com> wrote:
> Hi Lin,
>
> the annotation code looks cool, will be well cool when blueprint xml is no longer needed.
Not sure if we 'll have the equivalent of annotation for all blueprint
definition xmls, but hopefully for majority of them soon :)
>
> Some comments I have (in particular order):
>
> - how does field injection work in the current code, I couldn't see that you set the extension attribute anywhere?
Field injection is currently processed when processing the class that
has @Bean annotation, the code checks if any of the declared fields
have @Inject annotation. @Inject can be used on Field, Constructor
and Method.
>
> - what is the intention behind giving the scanner service service.ranking=0, I thought 0 was the default?
No particular intention... since it is the only scanner service avail
so it doesn't really mean anything right now :-)
> - might it be better to allow the blueprint level settings (defaultActivation, defaultTimeout, defaultAvailability) in the bundle manifest as opposed to an annotation on a random class?
Yes, that is certainly feasible, and may make more sense since the
manifest is at the bundle level :)
> - as far as I understand the FactoryMethod annotation, this annotation is going to be used on the factory class, right? Does this mean that this only works for factory classes using annotations (and in the same bundle), also how does this work with multiple factory methods like java.util.concurrent.Executors?
Good question. I didn't think I work out issues with FactoryMethod
annotation in implementation and that is why I commented out the
annotation in AccountFactory.java. Seems to me it make more sense to
allow users to specify the factoryMethod attribute and its arguments
in @Bean annotation. I didn't go this route in the first place, as I
thought it was pretty hard to specify such an annotation from a user's
point of view.
> - the Reference and ReferenceList annotations look a bit strange with an annotation target of type because to me that suggests you can only use them if your bundle contains the interfaces for any services you want to inject via annotations.
>
> What about supporting annotation like
>
> class ServiceUser {
>
> @InjectReference(
> ...
> )
> private Service service;
> }
I like that, I think this is more reasonable. I'll see if we can use
the existing @Inject annotation since it has an attribute ref, or
create a new @InjectReference annotation.
> - also the bind and unbind methods look awkward being marked as Strings in the ReferenceListener annotation as opposed to having separate annotations like Init and Destroy? (Same for registration listeners :)
>
>
> Maybe (although that works only for annotation based reference listeners), and similarly for RegistrationListeners:
>
> class ServiceUser {
>
> @InjectReference(
> listener=Listener.class
> )
> private Service service;
> }
>
> @ReferenceListener
> class Listener {
> @Bind
> public void bind() { ... }
>
> @Unbind
> public void unbind() { ... }
> }
I think I didn't use @Bind or @Unbind annotation as I was not sure if
there can be multiple bind methods in a class like the factory method.
(The BindingListener.java seems to indicate that there can be
multiple.) The init or destory I assume would be unique in the class.
> Apologies for the amount of questions ;)
No prob at all. :) Glad you reviewed it and appreciated the feedback!
Lin
Re: blueprint annotation prototype
Posted by Valentin Mahrwald <vm...@googlemail.com>.
Hi Lin,
the annotation code looks cool, will be well cool when blueprint xml is no longer needed.
Some comments I have (in particular order):
- how does field injection work in the current code, I couldn't see that you set the extension attribute anywhere?
- what is the intention behind giving the scanner service service.ranking=0, I thought 0 was the default?
- might it be better to allow the blueprint level settings (defaultActivation, defaultTimeout, defaultAvailability) in the bundle manifest as opposed to an annotation on a random class?
- as far as I understand the FactoryMethod annotation, this annotation is going to be used on the factory class, right? Does this mean that this only works for factory classes using annotations (and in the same bundle), also how does this work with multiple factory methods like java.util.concurrent.Executors?
- the Reference and ReferenceList annotations look a bit strange with an annotation target of type because to me that suggests you can only use them if your bundle contains the interfaces for any services you want to inject via annotations.
What about supporting annotation like
class ServiceUser {
@InjectReference(
...
)
private Service service;
}
- also the bind and unbind methods look awkward being marked as Strings in the ReferenceListener annotation as opposed to having separate annotations like Init and Destroy? (Same for registration listeners :)
Maybe (although that works only for annotation based reference listeners), and similarly for RegistrationListeners:
class ServiceUser {
@InjectReference(
listener=Listener.class
)
private Service service;
}
@ReferenceListener
class Listener {
@Bind
public void bind() { ... }
@Unbind
public void unbind() { ... }
}
Apologies for the amount of questions ;)
Regards,
Valentin
On 7 May 2010, at 18:00, Lin Sun wrote:
> Hi
>
> I have been doing some prototype work for blueprint annotation in my
> own sandbox[1]. Currently the code builds in these orders:
> blueprint-annotation-api, blueprint-annotation-impl and
> blueprint-sample-annotation, blueprint-annotation-itest. However the
> itest only run successfully on my local machine, since I also have
> some uncommitted code on my local machine that modifies the blueprint
> core a bit to scan blueprint annotation for bundles that have the
> Bundle-Blueprint-Annotation header to true. I intend to move the
> sandbox code to trunk if there is no objection, so that I can commit
> my change to blueprint core without breaking the aries build. I have
> coded to do runtime annotation scanning only but supporting build time
> generation of blueprint definition XML from annotation should be
> possible.
>
> The blueprint-annotation-api contains some of the basic annotations I
> am proposing, such as @Bean, @Service, @Reference, @ReferenceList,
> @Inject, etc.
>
> The blueprint-annotation-impl contains a bunch of generated and
> slightly modified jaxb files along with some code to scan annotations
> and write the generated blueprint definition to a URL location, using
> xbean-finder.
>
> The blueprint-sample-annotation contains an example of how these
> annotations can be used in the sample.
>
> Comments welcome!
>
> Thanks
>
> Lin
>
> [1] https://svn.apache.org/repos/asf/incubator/aries/sandbox/linsun/blueprint/