Spring bean description validation

[timothygordon32]

Hi

When the instatiation of Spring beans is lazy then it's possible to do a getBean() on the bean factory and get a BeansException thrown due to, say, a property being specified on a bean that does not exist.

Even when the instantiation is lazy, if the class="com.company.app.Something" and the Something class doesn't actually have a property setter of myProperty, yet you've specified <property name="myProperty>, then it's surely easy to programmatically verify that this is going to be a problem before deployment/runtime?

Has someone written something to do this already? It need to be programmatic, really - just coloring a name red in an IDE isn't really an aggressive enough validation check when deploying an app that may have lots of Spring config files and inexperienced users have changed implementation classes without checking that their changes are consistent with the Spring config files.

Tim

[Costin Leau]

You can use ref local as much as possible to do XML validation. Otherwise I think you should take a look at BeanDoc which creates drawings of the application. Probably you can use their API if the drawings are not good enough.

[davison]

BeanDoc works in isolation of the class libraries - it only needs the XML files to operate. So in the OP's case it wouldn't help.

Still worth checking out though

[yangju]

My case is on the opposite. I use ContextSingletonLocator. The beanRefContext.xml contains several bean xmls which are located at different jars under ear. At deployment time, when one jar is loaded, spring validation complains that some beans are not found. Ofcouse they are not found becase the rest of jars have not loaded yet. This causes big problem for us. Is there a way to turn off the bean validation at deployment time. After the deployment is done (with all jar and wars are loaded, spring should be able to find all bean classes.

Also, when we use non-singleton bean, it cannot be declared "lazy-init=true", why?

Thanks.

[Injecteer]

Also, when we use non-singleton bean, it cannot be declared "lazy-init=true", why?

it's because of the prototype's nature: they are fully configured, wired-up and instantiated upon EACH call, and never before.

[Costin Leau]

Prototypes are not managed by Spring - they are initialized and given to the client (other dependencies) but since they are created only when they are needed there is no point in lazy initialization.

[yangju]

We use jboss and ContextSingletonBeanFactoryLocator in Spring.
The problem is: when the jboss server is started, not all classes that are referred in the bean definition file are loaded. They will be loaded eventually. But it seems to us that spring loads the bean definition xml file and tries to verify each of the classpath of the beans. Because not all classes are loaded yet, spring gives us bunch of exceptions saying class not found. This happens even we define lazy-init="true".

Is there anyway we can defer the verfication of bean classpath?

Thanks.

[Costin Leau]

I'm not sure how your classpath is constructed by the classes definitions have to exist since they are required for validating the configuration. What you can do is load the application context only after the classpath has been defined (or divide the app context into several pieces and load them step by step after the classpath has been constructed).