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 ate
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-referenc >> 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? >
