MultiSelectCF

[elena slobodnik]

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.

[Nic Brough -Adaptavist-]

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.

[elena slobodnik]

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?

[Nic Brough -Adaptavist-]

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.

[Nic Brough -Adaptavist-]

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,