Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld

Habt ihr euch auch schon mal die Frage gestellt, welche Version einer Mule Applikation auf eurem Mule gerade installiert ist?

Gerade wenn man viele Applikationen zu warten und/oder zu entwickeln hat und die Frequenz der Deployments hoch ist kommt diese Frage sehr oft.

Wer dann noch mit Maven als Build- und Release-Werkzeug arbeitet, stellt sich spätestens dann die Frage: „Wie kann ich z.B. die Versionnummer, welche von Maven verwaltet wird in meiner Mule-Umgebung abfragen?“

Im folgenden möchte ich ein kleines Tutorial anbieten, welches sich dieser Problemstellung widmet.

Um die Versionnummer einer Applikation im Mule zu veröffentlichen bedarf es im Grunde 3 Schritten, die ich im folgenden näher erläutere.

mule-app.properties integrieren

Mule bietet Out-Of-The-Box die Möglichkeit Properties aus einer fest definierten Datei im gesamten Mule-Kontext der Applikation zu verwenden (Mule Dokumentation). Die Datei heißt mule-app.properties und muss, genauso wie die mule-config.xml, im Hauptverzeichnis der Applikation liegen. Alle Properties, die in dieser Datei definiert werden, können entweder über einen Platzhalter in der Mule Konfiguration, z.B. mit

1<beans:beans>
2    <beans:bean class="de.codecentric.Foo">
3        <beans:property name="bar" value="${property.in.mule-app.properties}" />
4    </beans:bean>
5</beans:beans>

oder programmatisch über die Mule-Registry ausgelesen werden.

1public class InfoMBean implements MuleContextAware {
2 
3    private MuleContext context;
4 
5    @Override
6    public void setMuleContext(MuleContext context) {
7        this.context = context;
8    }
9 
10    public String getVersion() {
11        return context.getRegistry().lookupObject("property.in.mule-app.properties");
12    }
13 
14}

Mit diesem Wissen können wir also nun fortfahren und diese Datei mit folgendem Inhalt anlegen:

1app.name=${pom.name}
2app.version=${pom.version}

Wie zu erkennen ist, sind die Werte der Properties selbst wieder Platzhalter. Diese Platzhalter sind hier wiederum Properties, welche innerhalb eines jeden Maven-Builds bekannt sind. Die hier verwendeten Properties sind nur ein beispielhafter Ausschnitt an Möglichkeiten. Hier können alle, innerhalb des eigenen Maven-Build bekannten Properties verwendet werden.

Die Platzhalter werden nun im nächsten Schritt mit Maven durch konkrete Werte ersetzt…

Platzhalter per Maven-Build auflösen

Maven kennt in seinem Build ein sogenanntes Resource-Filtering. Dieses bedeutet, dass Platzhalter innerhalb von Dateien, die der Build als Resource kennt, versucht zu ersetzten – soweit ihm diese Platzhalter bekannt sind. Dieses Resource-Filtering muss explizit aktiviert werden. Im folgenden Beispiel gehe ich davon aus, dass die Applikation bereits mit dem maven-mule-plugin gebaut wird:

1<plugin>
2    <groupId>org.mule.tools</groupId>
3    <artifactId>maven-mule-plugin</artifactId>
4    <version>1.9</version>
5    <extensions>true</extensions>
6    <configuration>
7        <appDirectory>src/main/app</appDirectory>
8        <filterAppDirectory>true</filterAppDirectory>
9        <nonFilteredFileExtensions>
10            <nonFilteredFileExtenion>xml</nonFilteredFileExtenion>
11        </nonFilteredFileExtensions>
12        <copyToAppsDirectory>true</copyToAppsDirectory>
13        <finalName>codecentric-info-app</finalName>
14    </configuration>
15</plugin>

Die Eigenschaft filterAppDirectory des Plugins ist der entscheidende Punkt. Zusätzlich habe ich noch definiert, dass XML-Dateien von Resource-Filtering ausgenommen werden, so dass die Platzhalter in der mule-config.xml nicht ersetzt werden. Mit dieser Konfiguration des Plugins lässt sich nun ein Build durchführen. Nach dem Build sieht die mule-app.properties in der erzeugten ZIP-Datei beispielsweise wie folgt aus:

1app.name=codecentric-info-app 
2app.version=1.2.3

Nun ist die Applikation also gebaut und beinhaltet Informationen (z.B. die Versionsnummer) über den eigenen Build. Diese Informationen können nun innerhalb der Applikation abgerufen werden und z.B. der JMX veröffentlich werden …

JMX MBean implementieren

Um die, nun innerhalb der Applikation bekannten Informationen zum Build öffentlich bekannt zu machen, wird in der Applikation ein MBean exportiert, welches diese Informationen bereitstellt. Hierzu nutzen wir den Spring-MBeanExporter und einen Annoation-Driven MetadataMBeanInfoAssembler – Siehe auch Spring Dokumentation .

1package de.codecentric.foo;
2 
3import org.mule.api.MuleContext;
4import org.mule.api.context.MuleContextAware;
5import org.springframework.jmx.export.annotation.ManagedAttribute;
6import org.springframework.jmx.export.annotation.ManagedResource;
7 
8@ManagedResource
9public class InfoMBean implements MuleContextAware {
10 
11    private MuleContext context;
12 
13    @Override
14    public void setMuleContext(MuleContext context) {
15        this.context = context;
16    }
17 
18    @ManagedAttribute
19    public String getVersion() {
20        return context.getRegistry().lookupObject("app.version");
21    }
22 
23    @ManagedAttribute
24    public String getName() {
25        return context.getRegistry().lookupObject("app.name");
26    }
27 
28}

Die Konfiguration in der mule-config.xml

1<beans:beans>
2    <beans:bean class="org.springframework.jmx.export.MBeanExporter">
3        <beans:property name="beans">
4        <beans:map>
5            <beans:entry key="Mule.${app.name}:name=InfoMBean"
6                value-ref="infoMBean" />
7        </beans:map>
8        </beans:property>
9        <beans:property name="assembler">
10        <beans:bean
11            class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
12            <beans:property name="attributeSource">
13                <beans:bean
14                    class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource" />
15            </beans:property>
16        </beans:bean>
17        </beans:property>
18    </beans:bean>
19    <beans:bean id="infoMBean" class="de.codecentric.foo.InfoMBean" />
20</beans:beans>

In der Konfiguration enthalten ist bereits die Nutzung einer Property aus den mule-app.properties: Beim Namen des exportierten MBeans in der MBeanExporter-Map beans. Einige Beans einer Mule Applikation sind standardmäßig bereits per JMX exportiert. Die JMX-Domain dieser MBeans lautet per Konvention immer Mule., so dass wir das MBean hier, wie gezeigt, in diese JMX-Domain einhängen können.

Ergebnis

Mit diesen Bausteinen kann die Applikation nun neu gebaut und installiert werden. Über das JDK-Tool jconsole lassen sich nun die registrieren MBeans ansehen. Das Ergebnis sieht wie folgt aus:

Ausblick

Wenn man nun mehrere solcher Applikationen auf den Mule installiert hat könnte man auf die Idee kommen, eine weitere Mule Applikation zu erstellen, die diese Informationen aus den MBeans kummuliert und als Informationsseite zum Status der installierten Applikationen darstellt. Diese Applikation ist Bestandteil meines nächsten Posts (folgt )

Weitere Teile dieser Artikelserie

1. Was ist ein ESB und wofür kann man ihn nutzen?
2. Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus
3. Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten
4. Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren
5. Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen
6. Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…
7. Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads
8. Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX
9. Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld
10. Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email
11. Kummulieren von Informationen zu Mule Applikationen per JMX