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