This was detected by analysing leaked SesssionImpls from Hibernate. It appears that the ActionValidatorManager maintains an internal cache of DelegatingValidatorContexts, which in turn hold references to instances of LocaleProvider, TextProvider and ValidationAware.

As ConfluenceActionSupport implements all these interfaces , this means that the object that will be cached is the instance of the Action which is created for the first request to each corresponding action which requires validation (due to the three methods outlined below, in which Object will be an instance of ConfluenceActionSupport) . This means that all data associated with that Action will not be able to be garbage collected.

public static TextProvider makeTextProvider(Object object, LocaleProvider localeProvider) {
if (object instanceof TextProvider)

{ return (TextProvider) object; }

else

{ return new TextProviderSupport(object.getClass(), localeProvider); }

}

protected static LocaleProvider makeLocaleProvider(Object object) {
if (object instanceof LocaleProvider)

{ return (LocaleProvider) object; }

else

{ return new ActionContextLocaleProvider(); }

}

protected static ValidationAware makeValidationAware(Object object) {
if (object instanceof ValidationAware)

{ return (ValidationAware) object; }

else

{ return new LoggingValidationAware(object); }

}

The superclass of ConfluenceActionSupport, ActionSupport, itself implements all three of these interfaces. This means that it may not be possible to avoid this behaviour without significant changes to our Action hierarchy.