[Springide-eclip-developer] Brainstorming about validator improvements

[Torsten J. <tor...@on...>]

I would like to start a discussion about the internals of the 
BeansConfigValidator and it's shortcomings. Maybe we can get some ideas 
for improvements.

Ok, here it goes with  the internals:

BeansConfigValidator is responsible for validating a single Spring bean 
config file only. It does not read the Spring bean config XML files 
itself. This is done in BeansModel's implementation of IBeanConfig.

BeansConfigValidator is called by the BeansModel's internal 
ResourceChangeListener for a modified bean class' config files or by 
the core's IncrementalProjectBuilder for every modfied Spring bean 
config file.

BeansConfigValidator performs the following actions during validation 
of a single config file:

1. Delete all BeansConfigValidator-related problem markers from the 
given config file.

2. Reset the corresponding BeanConfig in the BeanModel to force 
re-reading the config file and updating the model.
     If an exception occurs during reading the config file then a 
corresponding problem marker is created.

3. Validate all beans (inner beans too) of the config file:

  	a) If a bean class is specified then check if the corresponding Java 
type is available in the projects build path.
	     The project build of any referenced external project is searched 
too.
	     If no Java type is found then create a problem marker for the 
corresponding bean.

	b) If no bean class is specified for a child bean then look for a Java 
type in it's parent bean chain.

	c) If a Java type was found via a) or b) then validate the bean's 
constructor arguments
	    (check if the Java type has a constructor with the same number of 
arguments) and properties
	    (check if the Java type has a set method for the property)

4. Validate all config set the config file belongs to:
      For every bean defined in the validated config file check if a 
bean with the same bean name is defined in one
      of the other config files of the config set. If yes then create a 
problem marker for the corresponding bean.
      This check is applied only to config sets where the option "Enable 
bean overide" is diasbled.


Now for the shortcomings of the current implementation of 
BeansConfigValidator:

1. If no Java type for a child bean is found, e.g. the parent bean is 
defined ia a different config file,  then no validation of the bean is 
performed.

Config sets could be used to resolve this issue. But how to decide 
which config set is the correct one.
Maybe in one of the config sets a bean with the parent bean' name is 
defined but it's not the intended one (only a name clash). Or we have 
multiple config sets which have a bean with the parent's name. Which 
one should we use? If we would use all then we would create multipe 
problem marker's for the same bean.

We could use the import tags. But these are only recognized by the 
EventBeanDefinitionParser which is used by BeansConfig during reading a 
config file. And EventBeanDefinitionParser is (like 
BeansConfigValidator) responsible for a single config file. So it only 
checks the existance of the specified resource.

Hhm, perhaps we should extend BeansConfig to expose the imported 
BeansConfigs and use these for parent bean name resolution during 
validation.

2. Bean references are not validated at all. We could check if the 
referenced bean is defined but if it's defined outside of the current 
config file then we have the same issues as with a child bean's parent 
Java type (refer to 1.).

What do you think? Any suggestions?

Cheers,
Torsten