Ok. now I understood the story. I will go XML for my components. I can understand the pain Kelven suffered, CloudStack has some many components that are hard to convert to XML files at one time, given the tight schedule we faced on javelin. So using @Component to make Spring onboard is understandable.
However, I agree with Darren that we should not use @Component and should use JSR annotations instead of Spring specific like @Autowired. @Component is easy, but not feasible and unreadable. By not feasible I mean you could not use amazing spring constructor/setter injection, you may argue that you don't need it but if someday you are, then you have to go XML way which breaks your code convention as you have had @Component mess everywhere. By unreadable I mean you are not able to tell what's skeleton of project if you are new to CloudStack. The skeleton are usually made up of Spring beans, listing these beans in XML file gives people a chance to grab a global picture quickly, for they don't have to loss in huge java files for @Component. And Spring has some other plus on XML file, it has an extensible framework that you can add your namespace in bean definition, a beast tool! >> Option 3, Using @Configuration) Please don't approach to this. @Configuration is not for this. Its main purpose is using byte-weaver(Aspectj) to do dependency injection on domain object. A domain object is produced by your code but not Spring IOC, which means the object generated by java *new* keyword. So @Configuration is largely for prototype bean, not singleton, this is usually not you want. However, I don't think using Spring specific utilities is a big deal. I agree that POJO is good, and Spring also encourages people not to lock in Spring as much as possible. But to a large enterprise project, it would unlikely switch to another container if current container is stable and flexible(I mean Spring here you know). Pursuing pure POJO will introduce boilerplate glue code and make things over-abstract/over-wrapping sometime. Five years ago I was writing a C framework in Linux, to be pure, I added a layer of wrapper for some glib component. I told my architect that I don't want to lock in to glib, he asked back that why you want to switch to another library as glib has been proved itself for a long time? so, I agree we should be POJO, but just avoid being purist if the gain is small. > -----Original Message----- > From: Kelven Yang > Sent: Monday, February 11, 2013 10:48 AM > To: Darren Shepherd > Cc: Frank Zhang; cloudstack-dev@incubator.apache.org > Subject: Re: what's rule for using @Component and xml bean file > > > > On 2/9/13 6:54 AM, "Darren Shepherd" <dar...@godaddy.com> wrote: > > >Sorry, technical error in sending the last email... > > > > > >Please, please, please do note use spring packages. Spring should be a > >runtime and not compile time dependency. If you leave spring as a > >compile time dependency you'll see overtime that developers start > >leveraging handy spring utilities and components. Architecturally it > >does make sense to have dependencies on such a large component as > >spring for utility style functionality, that is what apache commons is for. > > > >So my two cents. > > > >Option 1, Using coding convention to reduce the auto-scan scope,) > > > > > >Not feasible in a realistic time frame > > > >Option 2, Using build-time XML auto-generation) > > > >Too much of a one off solution. This is just another thing people have > >to understand that is different from how the majority of people use > >spring. And its uses a spring specific annotation. > > > >Option 3, Using @Configuration) > > > >Yeah people don't like XML. But the eclipse support and specifically > >the Spring IDE support for the XML configuration is awesome. The new p > >namespace also makes the XML less verbose. So, oh well, write some XML > >it won't kill you. If you use autowiring you'll find that mostly you > >are just registering the bean and the XML is quite small. Again, for > >simplest learning curve to developing and understanding CloudStack just > >stick with the XML. > > > > > >So again, I'm going to strongly assert that CloudStack should > > > >1) Use JSR250, JSR330 annotations (@Inject, @PostConstruct, > >@PreDestroy) > >2) Register all beans in XML > >3) Use autowiring > > > We have hundreds of Bean components in CloudStack, it is quite annoying to > register all of them in XML and to maintain it when code-refactoring is still > going on. So we are taking some compromises here, for your points, we are > definitely using auto wiring, but for 1) and 2), we used one more Spring > defined annotation (@Component), which may not sound elegant that it has > Spring dependency, but the dependency is only at meta(annotation) level, > we have very limited places that require a direct reference to Spring at code > level. > > Having some meta level annotations and combining with the flexibility of > XML is pretty much the census I've got from local CloudStack developers > around me, this may not the final approach either, let's give it some time to > evolve based on broader feedbacks from the community > > -kelven > > > > > > >Darren > > > >On Feb 9, 2013, at 12:05 AM, Kelven Yang <kelven.y...@citrix.com> wrote: > > > >> > >> Apologize for such a long email first, if you are interested, please > >>read on... > >> > >> > >> Auto-scan globally is never a good idea and we are currently doing it > >>just for the reason of getting existing code quickly converted. I'm > >>currently profiling some details on how much time Spring has spent > >>for scanning the component and how much time it spends to resolve > >>dependency and performs auto-wiring. > >> > >> There are both "pros and cons" for in doing in annotation way or in > >>XML way. Historically in CloudStack we are doing code-refactoring > >>quite often, this makes using annotation attractive to CloudStack > >>developers. > >>However, > >> we also need flexibility provided by XML for people to customize > >>CloudStack after deployment, so historically, CloudStack prefers to > >>take advantages of both annotation way and XML way. For built-in or > >>other basic components like DAOs, using annotations can save > >>developers a lot of typing work. For pluggable components like > >>Adapters, Network Elements, having them in XML makes more sense. > >> > >> As a general guideline, we should keep component as independent of > >>others as possible, as loosely coupled with other as possible. The > >>motivation of adopting Spring is for that purpose, to enforce a > >>consistent way of developing pluggable, unit-testable components. > >> > >> However, there is never a perfect solution that can satisfy > >>everyone's needs, I would prefer to just using auto-wiring and > >>leaving component definitions all in XML, in this way, component and > >>a particular container are not tightly coupled (does not necessarily > >>to be Spring), however, in reality, using @Component with caution can > >>give developers decent freedom to write component independently > (they > >>don't need to remember to edit Java and XML at multiple places and > >>not everyone likes XML soup). > >> > >> A possible solution to combine both the advantages of using > >>@Component and XML <bean> definitions could be > >> > >> Option 1, Using coding convention to reduce the auto-scan scope, for > >> example, > >> > >> All components (Spring component specifically) have to share with the > >>same java package namespace, for example, > >>org.apache.cloudstack.component. > >> overall module/java package structure would look like, Cloud-engine > >>(module) org.apache.cloudstack.component.XyzMgr > >> org.apache.cloudstack.component.AbcAdapter > >> > >> Cloud-cool-plugin (module) > >> org.apache.cloudstack.component.CoolMgr > >> org.apache.cloudstack.component.CoolAdapter > >> > >> > >> > >> And we only scan org.apache.cloudstack.component. > >> > >> We didn't use this approach for the reason that this involves with a > >> lot of directory refactoring work, and this is too bad for branch merges. > >> > >> Option 2, Using build-time XML auto-generation > >> > >> With this option, developers can continue to use @Component for > >> meta-programming, we can add a step in build-process that we can > >> automatically generate the Spring XML file for components that have > >> been annotated by @Component. > >> > >> However, our maven build is already slow now, what we saved in > >>bootstrapping will have to be paid at build time, so for developers, > >>this option may still looks slow > >> > >> Option 3, Using @Configuration (one more Spring annotation!) > >> Cloud-server and pluggable module, each can have a per-module Spring > >> component configuration class (annotated by @Configuration) and we > >> only scan configuration components at bootstrap. > >> > >> Option 3 does not need us to refactor existing directory structure, > >> and have the flexibility for developers to do module development > >> independently, as I mentioned early, I'm profiling the Spring > >> bootstrap process, if it is confirmed that majority of time is spent > >> in scanning instead of auto-wiring, I'm actually leaning towards this > >> option. > >> > >> As of whether or not to strictly limit the usage of Spring specific > >>stuff, > >> **never** or **ever** to use @Component, I'm not a perfect-ist but a > >>more practical one, so using @Component only for meta programming > >>looks fine to me. And In this option, @Component is actually not > >>necessarily to be defined by Spring, we just happen to borrow it and > >>that's it. I'm kind of buying the point that with such a powerful > >>editor like Eclipse, it seems to be much easier for code-refactoring > >>if things are written in "java" > >> instead of XML. > >> > >> Kelven > >> > >> > >> > >> On 2/8/13 9:38 PM, "Darren Shepherd" <dar...@godaddy.com> wrote: > >> > >>> Frank, > >>> > >>> This is probably not the answer you looking for, but I have to just > >>>throw in my two cents. When should you use @Component? Never. The > >>>cleanest way to use the Spring container is to *never* "import > >>>org.springframework". Only bootstrap and obviously spring specific > >>>code should import spring packages. JSR250 and JSR330 provide > >>>standards compliant annotations that can be used in place of the > >>>Spring one's that give most of all the functionality. Refer to > >>> > >>>http://static.springsource.org/spring/docs/3.2.x/spring-framework-ref > >>>ere > >>>nc > >>> e/html/beans.html#beans-standard-annotations. > >>> The standard compliant annotation of @Component would be @Named > from > >>> JSR250 (which is included in the JDK at this point). > >>> > >>> Regarding when to use @Named and when to register the bean in XML. > >>>You should never use @Named. I'm sure many will disagree with me but > >>>past experiences have over and over again shown to me that > component > >>>scanning on large scale projects is a bad idea. Ignoring bad > >>>initialization performance, component scanning ends up introducing > >>>weird difficult to debug issues when some does something dumb. It is > >>>better to have a clear and definitive source regarding what is > >>>registered in your context. > >>> > >>> Additionally if you get into context hierarchies (which I hope you > >>> do, but that is a different topic altogether), component scanning blows > up. > >>> > >>> Darren > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: what's rule for using @Component and xml bean file > >>> From: Frank Zhang <frank.zh...@citrix.com> > >>> Date: Fri, February 08, 2013 6:39 pm > >>> To: "cloudstack-dev@incubator.apache.org" > >>> <cloudstack-dev@incubator.apache.org> > >>> > >>> > >>> I see client/tomcatconf/componentContext.xml.in defining lots of > >>> beans while I also see many beans use @Component Is there any > >>> guideline here? > >>
