Abstract bean definitions

[Martin Ellis]

Hi,

I'm wondering what the best way to handle abstract bean definitions,
that is, bean definitions with the 'abstract' attribute set to true.
For example:

<bean id="person-base" class="me.springframework.di.spring.Person"
abstract="true"/>
<bean id="person" parent="person-base"/>

Currently, this causes a NullPointerException in the QDoxAugmentation,
because it assumes that the bean class name is known.

As far as I can tell, finding the type of the 'person' bean requires
looking up the definition of the parent bean in the
BeanDefinitionRegistry. For more complex examples, this would need to
be done repeatedly until a concrete type is found.

I wonder what the best way to implement this is? Here are my thoughts so far:

* It seems simplest to keep Instance/MutableInstance for non-abstract beans.
* The augmentation classes don't have access to the
BeanDefinitionRegistry, so can't access parent bean definitions.
* The load methods in SpringConfigurationLoader don't have access to
the BeanDefinitionRegistry either.
* Bean types are inherited from the nearest parent bean definition
that defines the type.
* Bean properties can be inherited from any number of parent bean definitions.
* Other attributes will be inherited in similar ways.

One option I'm considering is to write a wrapper around BeanDefinition
(and BeanDefinitionRegistry) to resolve these properties from parent
beans if necessary. Another option is to change the load() methods in
SpringConfigurationLoader to also take the BeanDefinitionRegistry as a
parameter. The third option I've considered, is to provide the
BeanDefinitionRegistry to the Augmentation instances.

Any suggestions on the best way to approach this?

Martin

[Martin Ellis]

Shortly after sending my email, a simpler answer becomes apparent. :)
Typical. I'll try to prepare a patch.

Martin

[Wilfred Springer]

Thanks Martin. 

I will see what I can do. Meanwhile, I did however move the repository over to GitHub. 

Feel free to start cloning. ;-)

Wilfred

2011/3/14 Martin Ellis <mar...@contemplateltd.com>

--
You received this message because you are subscribed to the Google Groups "Spring ME" group.
To post to this group, send email to spri...@googlegroups.com.
To unsubscribe from this group, send email to spring-me+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spring-me?hl=en.

[Paul]

Hi Martin.

I had to do the same for a project I was working on. I'll try and dig
out the details, but think I checked if abstract and then performed a
merge.

[Martin Ellis]

Hi Paul,

No need to worry. My patch for this has already been merged on github.

(In retrospect, there's a simpler way to do it, but I plan to submit a
patch that will simplify that code anyway).

Thanks,
Martin

[Paul]

Hi Martin,

Cool, I'll take a look.

I found my hack, and FYI it looked like this.

private static Map<String, MutableInstance>
load(DefaultListableBeanFactory registry) {
Map<String, MutableInstance> instances = new HashMap<String,
MutableInstance>();
for (String name : registry.getBeanDefinitionNames()) {
// ***NEW*** Ignore abstract definitions and use merged
definition for non-abstract beans
BeanDefinition definition =
registry.getBeanDefinition(name);
if (!definition.isAbstract()) {
BeanDefinition mergedDefinition =
registry.getMergedBeanDefinition(name);
MutableInstance instance = new MutableInstance(name);
load(instance, mergedDefinition);
instances.put(name, instance);
}
}
return instances;

}


On Mar 16, 10:34 pm, Martin Ellis <mar...@contemplateltd.com> wrote:
> Hi Paul,
>
> No need to worry. My patch for this has already been merged on github.
>
> (In retrospect, there's a simpler way to do it, but I plan to submit a
> patch that will simplify that code anyway).
>
> Thanks,