Overriding system Spring beans

[daviderickson]

I want to replace the built-in captchaManager bean with one from my plugin such that it is the one autowired to xwork actions rather than the default. Is this possible? I tried:

<component key="captchaManager" class="me.daviderickson.confluence.ReCaptchaManager"
public="true">
<description>Provides Captcha services.</description>
<interface>com.atlassian.confluence.security.CaptchaManager</interface>
</component>

But the SignupAction was always initialized with the DefaultCaptchaManager rather than my own.

Even worse, when I rename my bean to say key="reCaptchaManager" I get errors in my xwork actions stating the following:

[INFO] [talledLocalContainer] Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.atlassian.confluence.security.CaptchaManager] is defined: expected single matching bean but found 2: [reCaptchaManager, captchaManager]
[INFO] [talledLocalContainer] at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:621)
[INFO] [talledLocalContainer] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireByType(AbstractAutowireCapableBeanFactory.java:1076)
[INFO] [talledLocalContainer] ... 72 more

[CharlesA · Accepted solution]

In short, no.

Confluence does not allow you to replace components like this. While it would be a really powerful tool for plugin developers to be able to replace core application components, it would lead to some very real problems in compatibility (plugins would be tightly coupled with the intimate details of the component they were replacing), plugin isolation (plugins that tried to override the same component would kill each other) and supportability (there would be no known baseline of Confluence code that we could assume was present when diagnosing problems).

One of our medium-term goals for the product is to move more features that are currently in the core code out into plugins where they could conceivably be replaced by third-party implementations. The CAPTCHA implementation would be a good candidate for such a move.

[daviderickson]

Thanks for the reply, the sooner you can get the Captcha moved out the better, we woke up this morning to a slew of new user signups and spam being posted, this is with the existing captcha system in place. To make matters worse I couldn't find a decent plugin to help deal with mass removal of users/spam after the fact either, even the systems that list users had no way to sort by creation date.. these are tools that are critical (and absent!!) for anyone managing a public instance.

[Colin Goudie]

If you package up your classes into a jar and add to WEB-INF/lib and then add a copy of the spring configuration file that contains the bean/s you want to override (with the necessary replaced beans in it) and add to WEB-INF/classes Confluence will bootup and use yours instead.

(At least does with the attachment system)

However, everything Charles mentions above is very very true. It's an ugly and unsafe hack to do what I suggested but if required, can work.

It's a pain, because every release of Confluence you need to compare your spring config versus the shipped version and make the updates etc..

[daviderickson]

Ya I agree, I could also edit the source and just compile myself and deploy, but at least in this case I was (am?) hoping to release a plugin others could consume, and neither of these options make that realistic :|