SharePoint Server 2007:
net stop SPTimerV3
net start SPTimerV3

Windows SharePoint Services:
net stop WSSTimerV3
net start WSSTimerV3

Eine weitere Alternative die mittels stsadm.exe Extension arbeitet ist unter folgenden Link zu finden.
http://www.mindsharpblogs.com/ben/archive/2007/09/25/2965.aspx

Wer sich schon immer mal darüber geärgert hat, dass mehrere SQL-Anweisungen nötig waren, um in einer Tabelle, abhängig von den Bedingungen in einer anderen Tabelle, Daten einzufügen, zu ändern und/oder zu löschen, der wird über die neue MERGE-Anweisung in SQL Server 2008 hocherfreut sein - … vorausgesetzt, er kann sich für komplexe SQL-Anweisungen begeistern .

Das absolute Standard-Szenario für die Anwendung von MERGE ist die Aktualisierung von Daten in einem Data Warehouse auf Basis der Daten aus dem Produktivsystem: Im Data Warehouse sollen

• Adressdaten, die im Produktivsystem vorhanden sind, aber nicht im Data Warehouse, eingefügt werden (INSERT)
• Adressdaten, die im Produktivsystem und im Data Warehouse vorhanden sind, geändert werden (UPDATE)
• Adressdaten, die im Data Warehouse, nicht aber im Produktivsystem vorhanden sind, gelöscht werden (DELETE)

Dafür waren bisher 3 Anweisungen der folgenden Art nötig (je eine für INSERT, UPDATE und DELETE):

Mit dem MERGE-Befehl nun ist das alles in einer Anweisung unterzubringen:

Das kommt nicht nur deutlich eleganter daher, sondern ist auch ressourcensparend, da nur eine anstelle mehrerer Lookup-Operationen durchgeführt wird.

Wichtig: Die MERGE-Anweisung muss immer mit einem Semikolon abgeschlossen werden.

Natürlich ist die MERGE-Anweisung noch deutlich flexibler als hier abgebildete Variante, z.B. kann die USING-Klausel auch eine Unterabfrage (dann mit einem Alias) enthalten oder die MATCHED-Klausel beliebig mit weiteren logischen Ausrücken kombiniert werden, des Weiteren sind beliebig viele MATCHED-Klauseln von jeder Art möglich. Ein etwas komplexeres Beispiel könnte z.B. so aussehen:

Ausführliche Syntaxinformationen finden sich unter http://msdn.microsoft.com/de-de/library/bb510625.aspx.

Confluence 2.10

Schon relativ konkret ist die Confluence Version 2.10, die Ende November veröffentlicht werden wird. Der Office Connector, erstmals in Confluence 2.9 enthalten, wird mit einigen Verbesserungen und Erweiterungen standardmäßig mit Confluence ausgeliefert. Außerdem wird die Suche um die Schnellsuche (vergleichbar mit dem “Livesearch”-Plugin) erweitert. Nicht so schön in einem Screenshot abbildbar, aber sehr wichtig für alle Plugentwickler ist die Einführung von Plugin 2.0 - einem neuen Pluginframework, das für alle Atlassian Produkte eingeführt wird und auf OSGi basiert. Dann kann ein Plugin beispielsweise für Confluence und Jira verwendet werden oder Abhängigkeiten zwischen Plugins definiert werden. In diesem Zusammenhang werden auch die meisten Core-Plugins, die mitden Confluence-Quellen verwoben sind, in “echte” Plugins umgewandelt.
Vorbote für Confluence 3.0 ist die erste Version des überarbeiteten Editors,  des sogenannten “Writers”. Er beinhaltet ein Upgrade auf TinyMCE3 und Bugfixes beim Umschalten zwischen WYSIWYG-Editor und Wikimarkup und Arbeiten mitTabellen.  Ich bin wirklich gespannt auf die Verbesserungen im Editor, da die momentanen Unzulänglichkeiten des Editors Akzeptanzprobleme bei der Einführung von Confluence verursachen können.

Confluence 3.0

Der Writer wird auch in Confluence 3.0 Hauptthema sein, beispielsweise steht dann die Integration eines Macrobrowsers auf dem Releaseplan. Der Macrobrowser erlaubt das leichtere Auswählen, Einfügen und Konfigurieren von Macros in die Wikseiten über einen Nutzerdialog. Außerdem wird an neuen Plugins gearbeitet - zum Beispiel zur Anzeige von Inhalten mit hoher Aktivität auf dem Dashboard.
Die Verbesserung der Performance wird auch im Vordergrund stehen - inbesondere da immer mehr Confluence-Installationen mit sehr großen Nutzerzahlen (z.B. bei Accenture mit 80.000 Nutzern) entstehen. So wird Confluence zu einer richtige Enterprise Anwendung, die wenig mit herkömmlichen Web 2.0 Tools gemein hat.
Confluence 3.0 wird im Frühjahr 2009 im normalen Releaseabstand von 3-4 Monaten pro Hauptversion veröffentlicht - auch wenn das erste Mal die ‘3′ in der Releasenummer enthalten sein wird.

Confluence 3.x

Am meisten freue ich mich schon auf das Dashboard, dass sich jeder Nutzer individuell anpassen kann und dass alle Atlassian Produkte erhalten sollen. Es basiert der Technologie, die auch für die Google Gadgets verwendet wird.  Damit erlaubt das Dashboard die Anzeige von externen Gadgets und von Inhalten aus den verschiedenen Atlassian Produkten und eine noch engere Integration zwischen den Produkten (für einen ersten Blick auf die mögliche Umsetzung siehe den Bericht vom FedexDay 8: Configurable Dashboard). Auch die Entwicklung des Sharepoint Connectors wird weiter vorangetrieben.

Die in Confluence verwendeten Actions sind in Packages organisiert und werden in der Datei xwork.xml verwaltet. Jedes der dort enthaltenen Packages kann in der Datei “atlassian-plugin.xml” des eigenen Plugins erweitert werden. Soll z.B. die Klasse ViewPageAction überschrieben werden, muß das Package “pages” erweitert werden. Ein solcher Abschnitt kann wie folgt aussehen:

<xwork name="View Page Action" key="myviewpageaction">
	<package name="pages" extends="pages" namespace="/pages">
	<default-interceptor-ref name="validatingStack"/>
	<action name="viewpage" class="de.communardo.confluence.plugins.actions.MyViewPageAction">
		<result name="error" type="velocity">/pages/myerrorsite.vm</result>
		<result name="page" type="velocity">/pages/myviewpage.vm</result>
	</action>
	</package>
</xwork>

Dabei ist grundsätzlich darauf zu achten, dass im Parameter “extends” der Name des zu erweiternden xwork-Packages angegeben wird. Mit dem Tag <action> können dann eigene Action-Definitionen für dieses Package angegeben werden. Wird dabei im Parameter “name” der Name einer bereits existierenden Action eingetragen, wird diese durch die in “class” angegebene Klasse ersetzt. Dabei können auch die nach einer Action aufzurufenden Velocity-Templates und Actions im Tag <result> mit eigenen Results, Templates und Klassen ersetzt werden.

Beim Überschreiben der ViewPageAction ist allerdings eine Besonderheit zu beachten: beim Aufruf einer Seite durch die ViewPageAction wird standardmäßig in der Methode getWebInterfaceContext überprüft, ob die Seite von der Klasse “com.atlassian.confluence.pages.actions.ViewPageAction.class” aufgerufen wurde. Anhand dieses Klassennamens wird ermittelt, ob die aufgerufene Seite gerade angezeigt oder editiert wird.
Ersetzt man nun die originale ViewPageAction durch eine eigene Klasse, muß also auch in dieser Klasse die Methode getWebInterfaceContext implementiert und entsprechend des neuen Klassennamens angepasst werden. Für obiges Beispiel muss also folgende Methode implementiert werden:

public WebInterfaceContext getWebInterfaceContext() {
	DefaultWebInterfaceContext result = new
		DefaultWebInterfaceContext(super.getWebInterfaceContext());
	if (getClass().equals(MyViewPageAction.class)) {
		result.setParameter(ViewingContentCondition.CONTEXT_KEY, Boolean.TRUE);
	}
	return result;
}

Den Anfang machte Ralf Ebert (Freelancer) mit seinem Vortrag zur EclipseRCP. Ihm folgte Stefan Saring (Saxonia Systems AG) mit der Vorstellung des Swing Application Frameworks (JSR 296). Beschlossen wurde der Abend durch Geertjan Wielenga (NetBeans/SUN) mit NetbeansRCP. Nach drei Stunden voller Informationen und praktischer Vorführungen lautete das Fazit: Alle drei Frameworks haben ihre Daseinsberechtigung. Entwickler mit SWT Background greifen zu EclipseRCP, Swing Fans je nach benötigtem Funktionsumfang und Projektgröße zum Swing Application Framework (kleinere bis mittlere Projekte) oder zu NetBeans RCP (mittlere und größere Projekte).

Wir hoffen am 27.11.2008 mit der vierten Veranstaltung  der JUG Saxony – diesmal zum Thema Rational Jazz/Team Concert - erneut allen Besuchern ein ansprechendes Programm zu bieten.

Auch für das Jahr 2009 sind bereits fünf Vorträge in Vorbereitung.

Für jeden Seitenaufruf im Confluence-Wiki wird der aufrufende Nutzer benötigt. Um diesen zu ermitteln werden verschiedene Quellen abgefragt (Cookies, Session, …). Erst wenn auf diese Weise kein angemeldeter Nutzer festgestellt werden kann, wird die Login-Seite angezeigt. Der vollständige Ablauf der Authentikation kann im Confluence Development Hub nachgelesen werden. Diese Ermittlung des Nutzers erfolgt durch einen sog. Authentikator. Der muss nun so angepasst werden, dass er mit dem zu unterstützenden Single Sign-On Dienst zusammenarbeitet (also den über diesen Dienst angemeldeten Nutzer ermittelt). Dazu schreibt man am besten einen eigenen Authentikator der den Confluence Standardauthentikator beerbt und passt die entscheidenden Methoden an.

Die hier vorgestellte Lösung basiert darauf, dass der Name des bereits am Single Sign-On Dienst authentifizierten Nutzers dem Servlet Container von Confluence bereitgestellt wird. Damit kann er über das Request-Objekt ermittelt werden (HttpServletRequest.getRemoteUser()). Dies ist für jedes Single Sign-On System auf andere Weise einzurichten und verursacht auch den meisten Aufwand. Um beispielsweise eine Anbindung an einen Kerberos-Dienst zu realisieren ist folgendes Vorgehen denkbar:

• Die Confluence-Anwendung ist über einen vorgeschaltenen Apache Webserver zu erreichen, der Servlet Container ist ein Apache Tomcat.
• Der Webserver wird mit dem Modul mod_auth_kerb betrieben, welches die Authentikation gegen einen Kerberos-Dienst ermöglicht.
• Der bei der Authentikation ermittelte Nutzername wird vom Apache über den AJP-Connector an den Tomcat weitergereicht. Dazu kann das Apache Modul mod_proxy_ajp verwendet werden.

Um nun die Authentikation gegen den weitergereichten Nutzernamen durchzuführen ist nur die Methode getUser() des Standardauthentikators (ConfluenceAuthenticator) zu überschreiben:

package my.auth.package;
public class MySSOAuthenticator extends ConfluenceAuthenticator{

    public Principal getUser(HttpServletRequest request, HttpServletResponse response) {
        Principal principal = null;
        // check if the user is already logged in (cookies & co.)
        principal = super.getUser(request, response);

        if (principal == null) {
            String remoteUserName = request.getRemoteUser();

            if (remoteUserName != null && remoteUserName.trim() != "") {
                // try to get the user's account using his name
                principal = this.getUser(remoteUserName);
                if (principal != null) {
                    // success, some additional code here (add user to session, ...)
                } else {
                    // some error handling as user can't be acquired from request
                }
            }
        }
        return principal;
    }

}

Nun muss nur noch der Standardauthentikator durch den neuen Authentikator ersetzt werden. Dies ist zum Glück mit wenig Aufwand machbar:

• deploy der kompilierten Klasse in das WEB-INF Verzeichnis von Confluence (entweder als jar nach WEB-INF/lib oder unter WEB-INF/classes mit der dem Paket entsprechenden Unterordnerstruktur)
• Austauschen des Authentikators durch Anpassung der Konfigurationsdatei WEB-INF/classes/seraph-config.xml:
  

  ...
  <authenticator class="my.auth.package.MySSOAuthenticator"/>
  ...
  

Nach einem Neustart von Confluence sollte nun der neue Authentikator verwendet und somit Single Sign-On unterstützt werden.

Leider waren damit der erste Konferenztag und unser Besuch der Berlin.jar schon vorbei. Am Tag zwei haben wir u.a. die Vorträge der ubigrate GmbH (Drahtwanderung: WIIr machen den NäXTen Schritt) und der buschmais GbR (Integrationsmuster am Beispiel von Apache Camel, Paradigmenhochzeit: Felix und ServiceMix in trauter Zweisamkeit vereint, Modellierung statischer Domänenmodelle mit Xtext) verpasst, aber vielleicht gibt es ja schon bald ein Wiedersehen bei der JUG Saxony

Dieses wird es auf alle Fälle im kommenden Jahr bei der zweiten Ausgabe der Berlin.jar geben.

Wenn eine solche Entwicklungsumgebung eingerichtet wurde, kann der Buildprozess eines Plugins noch weiter vereinfacht werden. Dafür stellt Atlassian das Plugin Developer Kit for Maven2 (kurz PDK) zur Verfügung. Dabei handelt es sich um ein Maven-Plugin, welches einfach in der POM des eigenen Projektes eingebunden werden muss und dann automatisch beim Buildprozess heruntergeladen und installiert wird. Ein solcher Aufruf kann z.B. so aussehen:

<plugin>
   <groupId>com.atlassian.maven.plugins</groupId>
   <artifactId>atlassian-pdk</artifactId>
   <executions>
      <execution>
         <phase>package</phase>
         <goals>
            <goal>uninstall</goal>
            <goal>install</goal>
            <goal>rescan</goal>
         </goals>
      </execution>
   </executions>
</plugin>

Dabei können verschiedene Goals angegeben werden, welche hintereinander ausgeführt werden und z.B. das Plugin direkt nach dem kompilieren in einem laufenden Confluence deinstallieren und die neue Version installieren. Eine sinnvolle Reihenfolge wäre z.B. Uninstall - Install - Rescan.

Vorsicht ist allerdings bei der Benutzung des Confluence Trigger Plugin Moduls geboten. Hat man einen Trigger in seiner atlassian-config.xml eingebunden und installiert das Plugin über das PDK direkt in ein laufendes Confluence, sollte nach einem Install kein explizites Enable des Plugins ausgeführt werden. Der Grund dafür ist: der Job wird bereits beim Install angelegt. Bei einem folgenden Enable wird dann erneut versucht, dieser Job anzulegen - was natürlich fehlschlägt und mit einer ObjectAlreadyExistsException quittiert wird. Ein Install und ggf. Rescan ist in diesem Fall also ausreichend.

Wenn Confluence kein direkter Internetzugang ermöglich werden kann (z.B. wenn das System innerhalb eines internen Netzes betrieben wird), besteht die Möglichkeit einen WebProxy anzugeben. Dafür muß im Startscript des Applikationsservers (beispielsweise eine Datei “catalina.bat” im “bin” Verzeichnis eines Tomcat-Applikationsservers) die Variable

JAVA_OPTS

mit dem Parameter

set JAVA_OPTS="-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=3128"

versehen werden.

Der Export aus einem MediaWiki neuerer Version schlägt jedoch aufgrund geänderter Datenbankfelder fehl. Dies kann behoben werden, indem in der Properties-Datei folgende angepasste SQL-Abfragen angegeben werden:

db.sql.pagedata=select page_id, page_namespace, page_title, page_latest from page where
     page_namespace!='8' and page_namespace!='12';
db.sql.textdata=select old_text from pagecontent where old_id = (
     select rev_text_id from revision where rev_id = 'db.column.textid' );
db.column.title=page_title
db.column.namespace=page_namespace
db.column.pageid=page_id
db.column.textid=page_latest
db.column.text=old_text

(Angepasst in den exporter.mediawiki.properties, Getestet mit MediaWiki Version 1.11)