Re: [Springframework-developer] Dependency checking

[Colin S. <col...@ex...>]

Sounds sort of useful, although unless I am misunderstanding how this 
would work, it would not be useful for a lot of beans since you can use 
a lot of beans without setting all properties, relying on defaults, etc.

What I think would be useful for Spring is a tool for verifying that all 
classes and interfaces which have been specified in a context definition 
are actually available on the classpath. I have been hit by typos a few 
times, and having a tool in the build which would verify the context in 
this respect would be useful...


rod...@in... wrote:

>All,
>
>As I can see it the only arguable advantage that 
>PicoContainer has over Spring is that it can satisfy all 
>dependencies before allowing an object to be invoked, so that 
>an object can never be used when incompletely configured. I 
>don't like their constructor way of doing this, and I think 
>that it often makes sense to have optional properties, with 
>sensible default. So I've never been worried by this in 
>Spring.
>
>However, it's pretty easy to add optional dependency 
>checking. I've successfully prototyped the following, which 
>required very minor changes:
>- add a new DTD attribute for the "bean" element called 
>dependencyCheck
>- if this is set to true, XmlBeanFactory checks that all 
>properties on that bean have been set. If not it throws an 
>UnsatisfiedDependencyException. We can't do the PicoContainer-
>style automatic wiring up as we can support multiple objects 
>of any type. They can only accomplish this because they 
>support only a single object of each type, which doesn't 
>satisfy the kind of real-world requirements I've used Spring 
>in.
>
>At present my prototype checks only Object properties 
>(presumably other beans in the factory). It might be good to 
>have three values for dependencyCheck: "no" 
>(default), "object" (collaborators) and "all" (primitives and 
>collaborators).
>
>As this is backward compatible and easy to do I'm inclined to 
>add it, if only for marketing value. There may be real value 
>in that it means that an init method wouldn't need to check 
>that a certain property was non-null.
>
>What do you think? Is this worthwhile?
>
>Regards,
>Rod
>  
>