Why component-import doesn't work?

[kravemir]

I've successfully referenced the UserManager using:

private UserManager userManager;
private com.atlassian.jira.user.util.UserManager jiraUserManager;
 
public ExampleServlet() {
	this.userManager = ComponentAccessor.getOSGiComponentInstanceOfType(UserManager.class);
	this.jiraUserManager = ComponentAccessor.getUserManager();
}

But, constructor component injection doesn't work at all:

public ExampleServlet(UserManager userManager) {
    this.userManager = userManager;
    this.jiraUserManager = ComponentAccessor.getUserManager();
}

In atlassian-plugin.xml I've got:

<component-import key="userManager" interface="com.atlassian.sal.api.user.UserManager" filter="" />

UserManager class is imported using:

import com.atlassian.sal.api.user.UserManager;

In every example, tutorial, documentation is described, that using <component-import ... /> is enough, is there anything else I should do?

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

Checkout http://www.j-tricks.com/tutorials/atlassian-spring-scanner-and-nosuchbeandefinitionexception and see if it helps.

[kravemir]

Thank you very much. I've spent hours on this issue and couldn't find why it's not working. All I needed was to read: https://bitbucket.org/atlassian/atlassian-spring-scanner from the link you've provided. But, that makes almost every atlassian tutorial not valid anymore!

[kravemir]

I tried to use 

@ComponentImport

before, but didn't work. All I needed was to use 

@Scanned

annotation. 

[Jobin Kuruvilla [Adaptavist]]

Been there and hence the post 

[crf]

If I had to guess, it's that spring components get keyed by name and that using "userManager" for the SAL UserManager is colliding with JIRA's.  Explicitly importing both of them with different keys could solve this, but adopting Spring Scanner as Jobin suggested is probably a better solution, if you have the time to make that switch.

For reference, SAL is exporting this with the key "pluginUserManager" so the fact that you are calling it just "userManager" when JIRA's own UserManager (which would get that key for itself) is also getting requested could well be the problem.

<component key="pluginUserManager" name="User Manager" class="com.atlassian.sal.jira.user.DefaultUserManager" public="true">
        <interface>com.atlassian.sal.api.user.UserManager</interface>
    </component>

One way to figure out what's really going on is to extract your plugin's JAR and dig through the generated META-INF files, particularly the MANIFEST.MF and anything under spring/.  My guess is you'll find that the host components XML has picked a single winner for "userManager" (because it has to).

[Nick Clarke]

Note that if this is an old-style transformed plugin using `<component-import>` in the xml (i.e. NOT using atlassian-spring-scanner), then the jar you need to look at is the transformed one that JIRA creates at startup, as described here: https://extranet.atlassian.com/questions/2319388210/where-does-jira-put-transformed-plugins-at-runtime

That will have auto-generated spring files resulting from your <component-import>s, and you can see whether names collide.

[Vasiliy Zverev]

You should use other UserManager: com.atlassian.jira.user.util. See documentation here: https://docs.atlassian.com/jira/6.2.1/com/atlassian/jira/user/util/UserManager.html

[kravemir]

These two have a different purpose... I need to use both

[crf]

I find this difficult to understand.  SAL's UserManager just delegates everything to CrowdService just the same as JIRA's UserManager does.  It doesn't make any sense to need it in in anything that isn't a cross-product plugin.

[kravemir]

Well. Maybe not, but I'm following a tutorial which uses it to retrieve username of logged user in servlet, and using another usermanager it gets a applicationuser instance. I'm new into this, and I'll look more deeply, but I just wanted to get the tutorial running first