custom fields disappear after restart

[francis]

I'm wondering if someone encountered follwoing issue

* Setup JIRA 4.4
* Install the jira-confluence-link plugin from customware
* Configure a confluence link custom field and configure it
* Restart the instance

Effect

* The custom field disappeared

* The logging states

[jira.issue.managers.DefaultCustomFieldManager] Could not load custom field type plugin with key 'net.customware.jira.plugins.jiraconfluencelink.jira-confluence-link:confluencelink'. Is the plugin present and enabled?

*BUT*

The plugin is available in the UPM.

[francis · Accepted solution]

This issue is resolved with JIRA 4.4.3 and Greenhopper 5.8.1

Francis

[JamieA]

IMHO this class was doing something very iffy: http://docs.atlassian.com/greenhopper/5.6.1/com/atlassian/greenhopper/dev/Reloader.html - it caused me problems too. Removed from 5.7 and above.

[Vincent Thoulé]

It is problem I met since long time with my customfield and alos my listener.

Similar issues may also occurs with MercuryListener from Go2Group and Gantt plugin.

These plugins access to CustomfieldManager, ServiceManager or init Listerner, before Plugin System is ready.

This causes a failure of your components if your customfield, Service or Listener have dependencies on other part of your plugins.

The only workaround is to remove direct dependencies (in constructor) and resolves the dependencies on demand (by calling getComponentOfInstance for V1 or getOSGiComponentOfInstance for V2) ... You will gain an IllegalCallException (or something like that) as Warning from JIRA that a naughty call has bee done, but your component is enabled and working.

[JamieA]

Interesting but to me that doesn't explain how when greenhopper 5.7 is out of the picture, everything works normally.

[Vincent Thoulé]

When GH uses CustomFieldManager (before that Plugin System has loaded all plugins), DefaultCustomFieldManager loads all Customfield defined in Database. In most case, their are loaded whitout issue, but if they have direct dependencies (in Constructor), if these dependencies are provided by a not yet loaded Plugin, then the customfield is disabled (due to missing dependencies), since CustomfieldManager is defined to load customfield when Plugin System is ready, not before.

[Andrey Larionov]

There is bug found by me today. When Plugin System perform start (ComponentRegistrar performs during calling quickStart() method) it broadcasts PluginEnableEvent. It may be processed by some listeners and produce too early initialization. For example RankService of GreenHopper plugin calls CustomFieldManager during processing this event. CustomFieldManager instantiates all the registered at this time CustomFieldTypes, but they can have dependencies, which are located not in loaded yet plugins.

[francis]

Andrey,

This could be a root cause & thanks for mentioning it. On what JIRA version did you find this issue ?

Francis

[Andrey Larionov]

JIRA 4.4. But i think simmilar problems could be found in any version with different plugins, especially with static calls as mentioned by you

[francis]

Well, this is the first time I've seen this behaviour.

[Andrey Larionov]

Right now i made a test, which show what without GreenHopper my customFields plugins starts normaly

[francis]

Yes - I can confirm. Disabling Greenhopper and restarting JIRA is solving the issue.

Scratch head.

[francis]

Hi Jamie,

Yes the plugins are enabled.
I found some references where plugins who instantantiate a customfieldmanager statically got into troubles.

Francis

[Nic Brough -Adaptavist-]

Mmm, can you go into the logs in more detail? And maybe turn up the logging levels a bit?

[francis]

Hi Nic,

I'm trying to narrow down the root cause by doing a step by step. I will bring up logging also to debugging level and see if this reveals something.

Francis.

[JamieA]

Is it definitely "enabled" after the restart? I have seen some plugins that persistently disable themselves on startup, for no obvious reason.