Referencing beans that may not exist.

[Kallin]

I am trying to write a simple plugin system for the core of our application so that client modules can supply their own implementations.

I've created a delegate bean that is configured through spring xml to always a reference to the default core implementation. I would also like to have it reference a client bean that may or may not exist. Whether or not a client wants to provide extra xml bean definitions is up to them.

Basically, I'd like to have something like:

<bean id="myBeanDelegate" class="MyBeanDelegate">
<property name="coreBean" ref="coreBean"/>
<property name="clientBean" ref="clientBean"/>
</bean>

<bean id="coreBean" class="MyCoreBean"/>

And then optionally in a seperate xml file.

<bean id="clientBean" class="MyClientBean"/>

This way the delegate can use the core methods unless a client provides an alternate implementation. The problem with this is that when the client doesn't supply that 'clientBean' the container throws up.

The way I've worked around this for now is to not define the clientBean reference in the core xml file. Instead, I give the clientBean a reference to the delegate via setter injection. Once I have the reference to the delegate in the client's setter, I can then provide the delegate with a reference to the client. This works, but it seems far from elegant.

Can anyone suggest a cleaner alternative?
Please let me know if I'm being unclear.

[Andreas Senft]

Maybe OSGi (especially Spring OSGi) might be helpful in your scenario?

[Marten Deinum]

If you let your clients register a bean with the name 'coreBean' and provide one yourself. The one from your clients will be used, the definition will be overriden. So instead of injecting 2 beans, inject one and let your clients override that definition.

[Andreas Senft]

Hmm. Yes, Marten, you are right. If a default implementation always exists that would indeed be the more elegant solution

[Kallin]

Thanks guys,

The only problems I have with the approach of overriding the bean definitions are:

a) which bean ultimately gets injected depends on the order in which the config files are read.

b) I lose the fine-grained control available with a delegate class. I was hoping to provide the delegate with some criteria as to which methods should be called on the core component, and which can be sent to the client component.

[Marten Deinum]

a) which bean ultimately gets injected depends on the order in which the config files are read.

That is correct. However you can influence that.

b) I lose the fine-grained control available with a delegate class. I was hoping to provide the delegate with some criteria as to which methods should be called on the core component, and which can be sent to the client component.

If that is the case I would split your bean in 2. One core component which contains the methods which cannot be changed/overriden. The other bean can be changed/overriden. That way you have all the control you need.

[Kallin]

Thanks for the advice.

I've written some tests to prove to myself that it is the last bean registered with a given ID that is ultimately used by the container.

I will just have to ensure that client contexts are read after core contexts.

Perhaps if I need more fine-grained control I should investigate Spring OSGi as Andreas recommended (as soon as there is more documentation anyways :P ).

[Jörg Heinicke]

I will just have to ensure that client contexts are read after core contexts.

Best to ensure this is probably to create a context hierarchy. Your context has to be the parent of the client's one.

Jörg