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 <[email protected]> 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", > ar...@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", ar...@arg(value="1") NewAccount account; .... } @Bean(id="myBean2") public BeanClass beanClass1(){ @Inject @Bean(id="accountOne", ar...@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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >
