A Confluence 8.2 EAP milestone is available now! EAP releases provide a snapshot of our work-in-progress and give you an opportunity to test and fix your apps before the final release.
As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 8.2, so head to Preparing for Confluence 8.2 to find out what’s changed.
If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.
Hi @Wendy, can you please forward this to the team working on the improved emoji support?
I just tested the latest beta1 release and found that the new confluence-emoticons-plugin version breaks exporting of these emojis in our exporter apps.
The plugin version bundled in Confluence 8.1 had defined the module <web-resource key="twemoji-resources"... that could be used to load the emoji files via Confluence’s PluginResourceLocator. We use that to avoid HTTP requests from our code back to the Confluence server, because this often is unreliable and slow depending on network and tomcat configurations.
I can still see this webresource referenced in the emoticon plugin’s code, but it is no longer defined in atlassian-plugin.xml and I assume that code path is now dead.
Is there any chance you could bring it back before the Confluence 8.2 release?
Hey @jens ,
In 8.2 we refactored the code to cache the content of the image files and return them using the same URL we used in 8.1 (/plugins/servlet/twitterEmojiRedirector?id=) without an extra request/redirect to resolve a performance issue.
As a result, unfortunately, we no longer need to expose the files as resources - and they were removed.
Can you please provide more details on why this resource was useful for you so that we can better understand the issue.
For Confluence 8.1 emoji support, we added some code to our exporter apps that
detects the /plugins/servlet/twitterEmojiRedirector URLs,
parses the emoji ID,
rewrites the URL to <BASE_URL>/download/resources/com.atlassian.confluence.plugins.confluence-emoticons-plugin:twemoji-resources/<EMOJI_ID>.svg
When loading the image data we can therefore simply use DownloadableResource resource = pluginResourceLocator.getDownloadableResource(...) and therefore get the data stream within the JVM process, instead of initiating an HTTP request from the Confluence main JVM back to it.
These kind of HTTP calls proved to be prone to network configuration problems, such as name resolution, firewalls etc blocking or slowing down these ‘self-requests’. Another problem could be session stickiness in clustered environments, where an authenticated request would end up on another node (this might be more of a theoretical problem as I don’t have an example).
We therefore try to avoid these requests as much as possible.
bundling the Twitter emoji package is something we’re considering, but it would increase the plugin JAR size by yet another ~4 MB, and we’d need to keep this up to date in case you add more emojis or twitter releases a new package version and you include this.
For now we intend to simply load the files via the emoticon plugin’s classloader from the containing svg folder. This works for both Confluence 8.1 and 8.2, and also later versions - as long as you don’t move the files to some other path.
I fully understand that you can’t make any promises, but could you tell at least if there are currently any plans to move the SVG files to another location with the emoticon plugin’s JAR file?
Hey @jens ,
I can see your point but I’m not so sure using an internal resource is a good idea here - we surely will not be able to support it.
I can confirm that at the moment we have no plans of changing our build process and moving the existing folder around.
Thanks @MaximLeizerovich, that good enough for us, and I understand that you can’t support that.
There is no good solution here, but this is the best one available.
Whether we bundle the icons ourselves or load them from the emoticon plugin does not change the fact that we may need to adapt the approach whenever you change the icon set or move it around, but at least that’s just effort on our side (and hopefully in rare occasions).
If we load the data from the original URLs via the servlet during exports, then customers will report problems due to their networking setups, and analyzing and explaining that over and over again is far more effort than occasionally fixing our loading mechanism.
