Why do you want to do that?

There are two alternatives. Confluence provides the web service plugin module, which offer good support for rpc-style services. However, these don’t work well with some clients, as some platforms do not support rpc-style web services.

Instead of using web services REST might be an alternative. Since Confluence 3.1. there is a plugin module type for REST interfaces, which builds the JAX-WS reference implementation called Jersey. Btw, the REST plugin module type also work on Confluence 3.0, but you will have to install some plugins manually. While REST is certainly the way to go for future developments, it has the same short coming as RPC-style web services: client platforms may not be able to use it (or at least make it hard to use it).

In my case the doc-literal web service client is InfoPath (part of Microsoft Office), which works allows users to edit pages in a office-style application and better keeps the structure of a page than the Word editor.

Overview

XFire is a quite old project and is actually now maintained/developed as CXF at Apache. However, there are three reasons for using XFire: XFire is included in the Confluence distribution, CXF still has some dependencies to XFire and introducing another library doesn’t make things easier (believe me I tried).

In order to use XFire we need to setup the dependencies correctly, create and deploy a XFireServlet as a servlet module, which handles the HTTP request and invokes the XFire web service stack.

POM Configuration

It is not possible to import the XFire packages through OSGi Bundle-Instructions (Atlassian does not expose it to plugins for whatever reason), so it is necessary define XFire as a dependencies. On the other hand it is necessary to exclude all unneeded or conflicting dependendencies of XFire. I added the following dependencies to the default dependency section:

<dependency>
    <groupId>org.codehaus.xfire</groupId>
    <artifactId>xfire-aegis</artifactId>
    <version>1.2.6</version>
</dependency>
<dependency>
    <groupId>org.codehaus.xfire</groupId>
    <artifactId>xfire-java5</artifactId>
    <version>1.2.6</version>
    <exclusions>
        <exclusion>
            <groupId>org.codehaus.xfire</groupId>
            <artifactId>xfire-annotations</artifactId>
        </exclusion>
        <exclusion>
            <groupId>xfire</groupId>
            <artifactId>xfire-jsr181-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.codehaus.xfire</groupId>
    <artifactId>xfire-core</artifactId>
    <version>1.2.6</version>
    <exclusions>
        <exclusion>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
        </exclusion>
        <exclusion>
            <groupId>javax.mail</groupId>
            <artifactId>mail</artifactId>
        </exclusion>
        <exclusion>
            <groupId>jaxen</groupId>
            <artifactId>jaxen</artifactId>
        </exclusion>
        <exclusion>
            <groupId>stax</groupId>
            <artifactId>stax-api</artifactId>
        </exclusion>
        <exclusion>
            <groupId>commons-codec</groupId>
            <artifactId>commons-codec</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.apache.ws.commons</groupId>
            <artifactId>XmlSchema</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.codehaus.woodstox</groupId>
            <artifactId>wstx-asl</artifactId>
        </exclusion>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
        <exclusion>
            <groupId>commons-httpclient</groupId>
            <artifactId>commons-httpclient</artifactId>
        </exclusion>
    </exclusions>
</dependency>

The XFire-Servlet

The XFire-Servlet handles HTTP Requests and invokes the XFire web service stack, which in turn hands over the web service call to our service implementation. Therefore the servlet initializes the service in the servlets init() method (when trying this yourself, please not that the init() method gets called lazily on first access).

public class MyXfireServlet extends XFireServlet {

    public void init() throws ServletException {
        super.init();

        // The ObjectServiceFactory creates services from Java objects
        ObjectServiceFactory factory = new ObjectServiceFactory(getXFire().getTransportManager(), null);

        // we don't want to expose compareTo
        factory.addIgnoredMethods("java.lang.Comparable");
        Service service = factory.create(DokumentService.class, "dokument", null, null);
        service.setProperty(ObjectInvoker.SERVICE_IMPL_CLASS, DokumentServiceImpl.class);

        // unregister old Service
        Service oldService = getServiceRegistry().getService("dokument");
        if(oldService != null) {
            getServiceRegistry().unregister(oldService);
        }

        getServiceRegistry().register(service);
    }

    protected ServiceRegistry getServiceRegistry() throws ServletException {
        return getController().getServiceRegistry();
    }
}

To register the service the following is needed in Atlassian XML:

<servlet name="Form Editor Servlet" key="com.k15t.example"
    class="com.k15t.example.webservice.XfireServlet">
  <url-pattern>/xfire/*</url-pattern>
</servlet>

This will make the XfireServlet to be available at http://localhost:1990/confluence/plugins/servlet/xfire/ (replace the hostname, port and context root and note the trailing slash). It will list the available services including a link to retrieve the WSDL for the service. In our case there is one service called “dokument”.

Implementing the Service

As you can see above the service is defined in the interface DokumentService and the implementation is implemented in DokumentServiceImpl. XFire will take care of converting the SOAP message to method parameters, if the service interface only uses the following types (source):

• Basic types: int, double, float, long, byte[], short, String, BigDecimal
• Arrays
• Collections
• Dates: java.util.Date, java.util.Calendar, java.sql.Timestamp, java.sql.Date, java.sql.Time
• XML: org.w3c.dom.Docmument, org.jdom.Element, XMLStreamReader, Source
• Complex types which are aggregations of the above

This is the interface of the service, the implementation is calling the Confluence API to do stuff (Dokument is a complex bean containing some page data):

public interface DokumentService {

    public Dokument load(String spaceName, String pageId, String token);

    public void save(Dokument document, String token);

}

That’s all.

It is important to notice, that the ServiceRegistry is shared between different XFireServlets, so take care if you install multiple of those.

Looking forward to 2010.

What we do at K15t Software (K15t is a shortcut for my last name, which is too hard to spell for almost everyone):

• Scroll Wiki Exporter - a single source publishing solution for Atlassian Confluence. Being able to work full-time for K15t will show a difference in terms of new features - 1.1 is due next week.
• Solutions for Wiki/Confluence-based documentation. At the moment this is on a consulting basis but we plan to release something product-like, too.

So, here comes the plug: If you want to do single source publishing from Atlassian Confluence or have always thought about using Wikis/Confluence for documentation, you should drop me an email.

This is copied from http://www.k15t.com/2009/05/scroll-10-released/:

We are proud to announce the 1.0 release of the Scroll Wiki Exporter for Confluence. It’s been a long way from CONF-762 to where are we now, but we made it!

Thanks for all the support we got along the way, to name a few in no particular order: Scott, Sebastian, Alex, Arne, Charles, Martin, Petra, Bob, Dan, Sarah, Giles, David, … Huge thanks also to the people who have beta-tested Scroll and provided great feedback.

The are already a lot of cool features in Scroll, and we are looking forward to add more. High on our list are better theming (add your own DocBook customization layer) and WordML export.

You can find more information in Release Notes.

Download an evaluation license at http://www.k15t.com/scroll/download.

Buy license at http://www.k15t.com/scroll/buy.

About Scroll: Scroll is a plugin for the popular Atlassian Confluence wiki. Scroll generates professional documentation in DocBook and PDF from wiki pages.

About K15t Software: K15t Software is a small development shop from Stuttgart, Germany. Its mission is to build useful software products with the focus on tools for wiki-based documentation.

WebKit for SWT (ver. 0.5) is an embeddable Java™ WebKit browser component developed by Genuitec. This component can be used in the development of a wide range of Java SWT applications that require integration of rich HTML5, CSS3, JavaScript and Flash content and functionality.

The solution seems a little bit more high-level than Sun’s approach: While Sun is integrating WebKit directly, Genuitec build on top of Google’s chromium. The biggest difference however at this time: They provide code, documentation and samples.

You might want to check out http://www.xenocode.com/browsers/, where all popular browsers (on Windows) are provided as executable .exe files. No installation, but in a isolated virtual environment.

Update: High Resolution (German) warns, that the virtual sandboxes will slow down your computer. Although I didn’t notice a slow down, I stopped using it. As an alternative they recommend IETester, and virtual machines provided by MS.

Not tested, not even downloadable yet, just wanted to let you know…

Quote from the website:

Seed is a library and interpreter, dynamically bridging (through GObjectIntrospection) the WebKit JavaScriptCore engine, with the GObject type system. In a more concrete sense, Seed enables you to immediately write applications around a significant portion of the GNOME platform, and easily embed JavaScript as a scripting-language in your GObject library.

Go JavaScript, go!

Wiki-based documentation will become the single source for documentation in 2009. While wikis have been great for collaboratively created documentation ever since, the problem is that they are not very well export their contents to other formats in order to ship documentation as printed books or integrated online help. DocBook export is needed here.

I have requested this^[1] for my favourite wiki^[2] back in 2004 with no luck. However, this year we will ship a solution^[3] for this. The Scroll Wiki Exporter for Confluence lets wiki-users export their documentation from trees of wiki pages to DocBook and PDF. Eventually we will support other output formats, pluggable, themes, and much more.

[1] Feature request for DocBook Export: CONF-762
[2] Atlassian Confluence
[3] Scroll Wiki Exporter