-
Bug
-
Resolution: Fixed
-
High
-
5.5
-
None
There are still methods throwing UnsupportedOperationException("Unavailable, need to implement the 2.0 API");
[CONFSERVER-33167] TransactionalCacheFactory is not fully implementing atlassian-cache-2.0 in 5.5-beta-1
In general, we need the plugin development guidelines to strongly encourage developers to wire/use a CacheManager rather than a CacheFactory.
https://developer.atlassian.com/pages/viewpage.action?pageId=2031764 already encourages this but we could add a warning against CacheFactory to that page.
Sorry, I think this was a red herring. The stacktrace did not lead back to TransactionalCacheManager but to EhCacheManager, which also did not have those methods implemented in the 5.5-api-m03 build that we were previously testing against, but— unlike TransactionalCacheManager— does have them implemented in 5.5-beta1. I had simply failed to retest against that build because I could see that the TransactionalCacheManager code, which I thought was the only place that that specific exception message could be thrown from, had not changed. I haven't been able to do a full test run again yet since our code is in flux, but I'm pretty sure it'll be OK.
After discussion with ebishop, it seems that Confluence is returning the TransactionalCacheFactory service to the cache-compat library . This is peculiar, since it should preferentially export the CacheManager service, and only return the TransactionalCacheFactory if it can't find CacheManager (which should never be the case). My initial tests (with Confluence 5.5-beta1 and cache-compat 1.0.1) confirm that it should work fine, so something specific to Eli's setup is triggering this.
So the problem here's isn't so much that TransactionalCacheManager is only partially implemented, it's that it's being incorrectly selected by the cache-compat library.
Skipping QA as this changeset adds new methods that aren't used anywhere yet.