incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Shepherd" <dar...@godaddy.com>
Subject Re: what's rule for using @Component and xml bean file
Date Sat, 09 Feb 2013 14:54:29 GMT
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

Darren

On Feb 9, 2013, at 12:05 AM, Kelven Yang <kelven.yang@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" <darren@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.Zhang@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?
>

Mime
View raw message