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?
