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 <[email protected]> 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",
> 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.
> 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 <[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
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
