Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to fix 'Injection of autowired dependencies failed' issue?


We are looking at developing/enhancing a Bamboo plugin. We've come across a problem with the Atlassian IOC mechanism. The problem is a failure to resolve an auto-wired (via Autowire annotation) bean called "linkedDeploymentProjectCacheService" in the Atlassian SDK class com.atlassian.bamboo.ww2.BambooActionSupport. Our plugin class indirectly inherits from BambooActionSupport.

The Bamboo server throws the following exception when it attempts to install the plugin:

2016-04-07 09:48:23,953 ERROR [localhost-startStop-1] [BambooPluginUtils] A problem has occurred when instantiating action class [], skipping action [viewChainChangeResults]
org.springframework.beans.factory.BeanCreationException: Error creating bean with name '': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.atlassian.bamboo.deployments.cache.LinkedDeploymentProjectCacheService com.atlassian.bamboo.ww2.BambooActionSupport.linkedDeploymentProjectCacheService; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.atlassian.bamboo.deployments.cache.LinkedDeploymentProjectCacheService] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(
    at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at com.atlassian.plugin.osgi.spring.DefaultSpringContainerAccessor.createBean(
    at com.atlassian.bamboo.plugin.xwork.PluginAwareObjectFactory.autowireIfContainerManagerPlugin(

Our project skeleton (pom.xml, atlassian-plugin.xml etc.) has been generated by the latest version of the Atlassian SDK 6.2.4 tool atlas-create-bamboo-plugin against Bamboo 5.10.3.

Any clues?



1 answer

2 votes

As a workaround, try adding a component import statement in your plugin xml for linkedDeploymentProjectCacheService (com.atlassian.bamboo.deployments.cache.LinkedDeploymentProjectCacheService).

We will fix it in one of the forthcoming Bamboo releases.

Hi Przemek.

Thanks for a prompt reply and a helpful suggestion.

Our action class inherits from com.atlassian.bamboo.ww2.actions.chains.ViewChainResult, and this forced me to add a few more imports. This allowed me to install my test plugin without the server throwing an exception. The plugin itself seems to be functional. Still, the UPM reports an error after the installation without anything specific present in the server logs.

Also, including a component-import tag in the SDK-generated atlassian-plugin.xml forces me to comment out the <Atlassian-Plugin-Key> tag. Apparently, the effect of that is that I no longer have a 'transformer-less plugin' (you wouldn't happen to know if this is actually documented anywhere?). Is that likely to be an issue?


Krzysztof Novak


By the way, you wouldn't happen to know when the next Bamboo release is going to be available?

Unfortunately, after further testing, the plugin, despite installing more or less successfully, failed at run time. The reason for the failure was another IOC problem, this time in the direct parent of our action class: com.atlassian.bamboo.ww2.actions.chains.ViewChainResult. More specifically, it has two fields: deploymentProjectService and commentService, both annotated with Autowired.

The <component-import> trick fails to fix this particular problem. I assume that those issues stem from the switch from Spring DM to Gemini Blueprint. The whole mechanism seems to be quite fragile and rather poorly documented at the moment. Hopefully, the upcoming release will fix that.

If you have a transformerless plugin, you can use the \@Import annotation on a reference to a com.atlassian.bamboo.deployments.cache.LinkedDeploymentProjectCacheService (and other beans) on a scanned bean somewhere in your plugin. This will pull the reference into your plugin context.

The next release should be released next week. The fix to your issue won't be available till 5.11.1, we only fixed the problem on Thursday and the change is too big to ship right away.

It won't fix the ViewChainResult problem though. BambooActionSupport is a general purpose class and the inclusion of these dependencies there was a mistake. ViewChainResult needs these references wired to operate. You will need to find a way to have it wired properly. I am a bit surprised that component-import didn't fix it. Maybe adding \@Import annotations will? Are you able to wire these beans in your own components? They are both plugin-available, so you should be able to do this. If you can't or you can but they are still unavailable to your action, it's definitely worth looking into.

Thanks for all the suggestions. Good to hear that the problem is going to be fixed.

For now, I have managed to find a workaround by changing our action class to inherit from ChainResultsAction rather than ViewChainResults. Luckily, ChainResultsAction (and its ancestors) doesn't use @Autowire annotation which appears to be the source of our problem.

As for wiring the references myself, I have tried a lot of different things. I even rammed them into the parent class using Java Reflections, but it was such an ugly hack that I kept looking for something more appealing.

IMHO, the relatively new mechanism with annotations and the Spring scanner plugin needs far more comprehensive documentation. The most useful would be a detailed tutorial and a collection of various working examples with different types of modules.

In my case (Bamboo 5.11.0), this workaround works, but I had to remove "Atlassian-Plugin-Key" from pom.xml (as created by atlas-create-bamboo-plugin), too.

I have no clue, how this removing "Atlassian-Plugin-Key" affects the build, but I hope, the reason for this issue will be resolved until I am ready for releasing my plugin.

diff --git a/pom.xml b/pom.xml
-  &lt;Atlassian-Plugin-Key&gt;${atlassian.plugin.key}&lt;/Atlassian-Plugin-Key&gt;
+  &lt;!-- &lt;Atlassian-Plugin-Key&gt;${atlassian.plugin.key}&lt;/Atlassian-Plugin-Key&gt; --&gt;

"Atlassian-Plugin-Key" marks a plugin as 'transformerless' i.e. its JAR is not processed by the Atlassian installer and it's assumed to have a complete and functional IOC configuration inside its JAR (META-INF/spring folder). I also had to comment it out for my plugin. See for some, but not a lot of, details :smile:.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Bamboo

Bamboo 7.1 is here and is packed with value!

I'm happy to announce that Bamboo 7.1 has been released and it’s overflowing with awesome new features. Top-voted issues First and foremost, a bunch of JAC top voted issues has been delivered - y...

926 views 4 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you