[#GLIFFY-430] Gliffy Plugin for Confluence cannot be removed and then re-installed into Confluence without restarting servlet container

Gliffy Product

Gliffy Plugin for Confluence cannot be removed and then re-installed into Confluence without restarting servlet container

Created: 28/Nov/07 05:40 PM Updated: 09/Jun/08 10:21 AM

Component/s:

Confluence Plugin Integration

Affects Version/s:

None

Fix Version/s:

Gliffy Plugin for Confluence - 1.3.6

Security Level:

Anyone may view

Description

« Hide

Currently it is not possible to remove and then re-install our plugin into Confluence without restarting the servlet container that is running Confluence. This essentially makes it really annoying for our customers who wish to upgrade Gliffy as they are forced to restart Confluence after any upgrade.

This is caused by http://jira.atlassian.com/browse/CONF-7600 which Atlassian says is fixed as of Confluence 2.7-m5.

Atlassian also states that there are still problems in the Gliffy Plugin which need to be addressed to ensure this works correctly. Specifically:

============
The next problem looks like Gliffy is putting some objects in the global Confluence cache but doesn't clean up after itself when being uninstalled. So when the plugin is reinstalled, the old object created from the previous classloader is retrieved and things go badly. Hopefully this is a simple fix on the Gliffy side to cleanup after itself and then the plugin can be dynamically reloaded.
============

We need to identify and fix these issues so that re-installing Gliffy is possible without re-installing the servlet container.

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Shannon Krebs - 25/Feb/08 07:18 PM - edited

Just confirming the issue with the confluence cache. If you flush the gliffy cache through the confluence admin console after reinstalling it seems to fix the problem.

I'm not sure if there is any way to get the plugin to "cleanup after itself " but we can possible catch the ClassCastException that is caused by this problem and get the cache flushed at that point. The interesting part will be making this confluence specific only since it doesn't apply to the online version of gliffy.

[ Permlink | « Hide ]

Chris Kohlhardt - 26/Feb/08 06:23 PM - edited

What if we added some code to com.gliffy.confluencePlugin.cache.ConfluenceCache.get() which attempts to detect the error condition.

For example, if the key starts with 'IMAGE', we could attempt to cast the object to DiagramBean in a try/catch block. If the object is non-null AND we get the ClassCastException AND the object is in Fact a DiagramBean, we know that the cache has likely been corrupted with the old objects. We should be able to call the removeAll() method on the cCache object, hopefully cleaning everything up.

Since all this is happening in the 'ConfluenceCache' object, it will only be specific to the plugin.

Do you think that would work?

[ Permlink | « Hide ]

Shannon Krebs - 26/Feb/08 06:33 PM

I've done a quick test just adding a try/catch block to the core core and ignoring the class cast exception at that point, this means the bean gets recreated then readded to the cache since to the following code it appears as though the image wasn't found in the cache.

It would be cleaner to put this in the confluence cache implementation but if it doesn't break the core code it will be more efficient to do it this way since we won't have to try{ cast }catch each object coming out of the confluence cache twice