These are guidelines related to the development of Confluence. The guidelines mainly apply to Atlassian employees, but reading them should provide insight for third-party plugin developers as well, so we decided to make them public.
Here's a quick overview of some of the services defined in Confluence (for more details of what a service is, see the High Level Architecture Overview).
This service is defined in databaseSubsystemContext.xml and productionDatabaseContext.xml. It provides database connectivity and Hibernate ORM to the application.
The reason for splitting the service into two files is to allow for easier testing. productionDatabaseContext.xml extracts the database configuration from the bootstrap configuration, and brings up Confluence with the Tangosol Coherence clustered cache. If you substitute that one file with testDatabaseContext.xml you will instead get a pre-configured in-memory HSQL database and in-memory caching.
Because configuring Hibernate dynamically is non-trivial, the database service is unavoidably dependent on every class we want to persist via Hibernate. You can see this in the list of .hbm.xml files loaded in databaseSubsystemContext.xml.
Provides a generic configuration/preferences storing service using XStream to serialize POJO configuration objects to XML. Confluence's bandana service persists to the database.
Provides centralised management of in-memory cached data. The backing cache implementation is provided by ehcache in the standard edition of Confluence, and Oracle Coherence in the clustered edition. For more information about the cache service, see Confluence Caching Architecture.
NOTE: For more information about standard and clustered editions of Confluence, please refer to the Coherence license changes document.
Provides a simple service for producing and consuming events. Defined in eventServiceContext.xml. Confluence's event service is cluster-aware, distinguishing between events that are limited to a single node of the cluster, and events that must be broadcast to every node.
Provides the Atlassian plugin framework, in pluginServiceContext.xml. Confluence's plugin service is customised to deal with bundled plugins (plugins that are provided with the application but that may be upgraded by the end user), and to behave mostly sanely in a cluster.
The plugin system hasn't been entirely service-ised yet, as all the different plugin module loaders result in dependencies back to whatever subsystem they're being plugged into.
A central manager for queues in Confluence. I'm not entirely sure this should exist as it currently adds no value whatsoever beyond being a lookup mechanism, which Spring does already.
Things that should be services, but aren't.
Pretty obvious next candidate for servicization, but possibly tricky because the Spring/Quartz integration might not be very friendly.
Something to keep in mind if we clean up the backup/restore code
I wasn't going to mess with user-management while there was a different atlassian-user task in the release pipeline.
This seems like a reasonably trivial candidate to convert to a service. There's only one dependency on non-service code (the image renderer depends on the attachment manager).
The sending and receiving of email is currently a mess of singleton configurations, clients sticking mail jobs directly on the queue, and very little going through Spring at all. This should be fixed.
It would be nice to have Confluence provide a service for accessing the outside world so we can throttle number of connections, provide central configuration of time-outs and authentication, and so on.
Right now we have a thumbnail manager that lives with attachments, but it would be nice to make this more generic, and at least support multiple thumbnail sizes.
Rate this page: