Logging is an issue in such an environment: the surrounding application configures the logging API – there is no way to provide log4j configuration fragments.

The best way I found to solve the problem was (again) to use the native logging API to the configuration manually. Since Jira has already setup the logging API, all I needed was to add some categories with some levels, or, if I need to, create my own appenders. That’s all possible with the API exposed by log4j.

So I created a Jira component module inside my plugin that does the configuration magic. Jira uses PicoContainer (lightweight, embedable, configurable, POJO based IOC/DI component runtime) as the runtime for their own and for components provided by plugins. As components get initialized along with the Jira application it is good place to implement the required logging configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package x.y;
 
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
 
public class LogConfigurationComponent {
 
	private static final Logger LOG = Logger.getLogger(LogConfigurationComponent.class);
 
	public LogConfigurationComponent() {
 
		Level level = Level.toLevel("DEBUG");
		Logger logger = Logger.getLogger("x.y.somethingcool");
 
		Level oldLevel = logger.getLevel();
		logger.setLevel(level);
 
		String message = "Changing loglevel for logger "
				+ logger.getName() + " from " + oldLevel.toString()
				+ " to " + level.toString();
 
		LOG.info(message);	
	}
}

Just by adding this component to the atlassian-plugin.xml in my plugin I solved my problems with distributed logging configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13

<atlassian-plugin key="x.y.coolthings"
	name="CoolThings">
	<plugin-info>
		<description>Simple plugin</description>
		<version>1.0</version>
		<vendor name="PGT Technology Scouting" url="http://www.pgt.de" />
	</plugin-info>
 
	<component key="logConfig" name="The logging configuration for this plugin"
		class="x.y.LogConfigurationComponent">
	</component>
	<!-- ... -->
</atlassian-plugin>

Gerade in kleine, agil arbeitende Teams ist das wesentlich effizienter: in einem Projekt ist man der Projektleiter, bei einem anderem lediglich ein Entwickler. So flexibel wie Entwickler heute die Rollen wechseln müssen, so flexibel konfigurierbar muss heute auch unternehmenskritische Software sein. In der Vergangenheit musste man in Jira für jede mögliche Kombination der Rollen in einem Projekt entsprechende Benutzergruppen einführen. Benutzergruppen sind aber statisch/ global und nehmen keine Rücksicht auf besondere Projektgegebenheiten. Am Ende bekommt jedes Projekt eigene Benutzergruppen.

Die Einführung von Projektrollen und Sicherheitskonfigurationen für Projektrollen im Allgemeinen reduziert die Konfiguration drastisch. Danke Atlassian!

Ein Rollenmodell ist nicht mit den heute üblichen deklarativen Mitteln konfigurierbar. Wir scheitern an der instanzbasierten Sicherheit. Je nach Projekt hat der Benutzer andere Rollen. Um so wichtiger ist es, ein Security Framework zu wählen, mit dem man die nötige Flexibilität und die Möglichkeit bekommt, eigene Anforderungen umzusetzen.

Auch wenn JAAS ein beeindruckendes Werk ist, mangelt es meiner Meinung nach an Flexibilität. Anpassungen sind sehr schnell nicht mehr portabel, eine Bindung zu der Laufzeitumgebung und oder Infrastruktur ist das Ergebenis. Spring Security (formerly known as Acegi) ist hingegen sehr flexibel. Security wird dadurch nicht trivial, aber besondere Anforderungen und entsprechende Lösungsansätze scheitern nicht mehr an dem Framework.

Schade dass in der Spring Security Dokumentation zu diesem Thema nichts zu finden ist. Eine Interessante Ausarbeitung zum Thema Gruppen und Rollen auf Konzeptebene ist hier zu finden.