We need to change the way that the CustomFieldManager discovers the registered plugins of customfield type. The reason is that we may run into a situation where a plugin has a dependancy on the CustomFieldManager which will force the manager to be created and initialized before all plugins have had a chance to register themselves. In the case of the CustomFieldManager it assumes that all custom field types have been registered and it eagerly instatiates its cache, which is incorrect since not all custom field types have been registered. So at the moment we refresh the managers AFTER we know that all has been setup within the ComponentManager.start() method, when this issue is fixed we should remove this quick fix. The problem is not as simple as changing the eager cache to a lazy cache. If we did this we would still find that if a plugin tried to access a custom field when it is initialized then we would be back in the same situation. There are a few options to solving this: 1. Add a lifecycle interface to our managers so you could then have a "postStartup" method and in the component manager you could get all managers that implement the lifecycle interface and alert them that they are now at postStartup 2. Remove the custom field managers cache and force it to query the pluginManager everytime it is looking for custom fields. This would need to have some profiling done before we could decide if this is feasable (it could be the case that performance would take a nose-dive by removing this cache). 3. The best option is probably to include an event system in JIRA and to make certain that events are fired on plugin enable/disable/registration. We would want to include enough information about which plugin is the object of the event so that the CustomFieldManager could look for these events and keep itself in the correct state based on the events its receives. This would allow us to keep a cache (which should propbably be reworked, take a look at it...), but it would allow the manager to be kept abreast of the change state of the system. This will become even more important when we start allowing plugins to be dynamically added to a running JIRA instance. This would also allow use to clean up nasty places like the resetCaches method in the JiraPluginManager. 4. Another option which was discussed was to make the CustomFieldManager not ever talk to the PluginManager but instead to have the CustomFieldModuleDescriptor know about the CustomFIeldManager and on enable/disable/registration the descriptor can register/deregister custom field types with the Manager. In essence we turn the communication around. The only draw back of this is that we would need to come up with some mechanism to "reset" the CustomFieldManager and this could be difficult since it is the PluginManager who will know the current state of the plugins in the system. When we fix this please remember to take out the hack in ComponentManager.start()