after upgrade from 5.0 to 6.1.2 the jira plugin checkup shows the error in extended class (below) MultiSelectCFType#<init> (OptionsManager, CustomFieldValuePersister, GenericConfigManager, JiraBaseUrls):void According to current documentation, the <init> constructor of the class has changed to from 4 to 6 parameters as following: public MultiSelectCFType(OptionsManager optionsManager, CustomFieldValuePersister valuePersister, GenericConfigManager genericConfigManager, JiraBaseUrls jiraBaseUrls, SearchService searchService, FeatureManager featureManager) ) So I have added nulls for two additional parameters, updated references to use current version of the class and resolved all compilation errors. Export finishes without errors and .jar file structure is identical to original). However, while attempting to process the file, plugin checkup shows the same issue with wrong number of parameters. looks like i am missing some other reference/ pointer. Please advice… Note: I do not know java or eclipse, so any help running, debugging or troubleshooting the issue would be appreciated.

1 answer

0 votes

So you have a plugin that needs rewriting wiht more than just a couple of parameters.

I'm afraid you need to understand your code, it's not just a case of whacking in what might be the right parameters.

no an option (unfortunately). java guy left and no one knows the language. I am sr.dev in vb.net, c# and thus was chosen for a task (i know what you are going to say!!!)... if i understand correctly, passing null for added parameters should or work or error out with wrong value/type exception. yet it looks like the parsing script (exe?) does not see them at all. meaning that some file w/ class definition is old or missing..XML?

I'm sorry, but "not an option" is not an option you have the luxury of here.

If you're going to rule out understanding the code and recompiling it properly, then your only other valid option is to remove the plugin. It's not working, it's not going to work, so you can't use it.

Passing in <null> instead of what is expected really isn't going to help you in the slightest - the best result you get from any real language is going to be "I expected you to pass me a valid object of type <what you already had from the api>". Oh, and coding to accept null gracefully is generally a bad idea too - it tells us you haven't thought through problem very well (just because a lot of people do it, doesn't mean it's clever - think about drinking, homeopathy or overeating...)

Which means you need to write the code to get the right object. It's not a case of trying to pull in other references or pointers, it's a case of changing the code to work out and pass in the right thing. Sticking random nulls in really is not an option either - the parameters are there for a reason.

Bother, I've just realised, I kept saying "you" there. You can, of course, find someone who knows java. Or better, someone who knows Jira's API well enough.

Posting the function call you're making here might prompt someone to point you in the right direction,

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,754 views 11 18
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot