The Smoke and Mirrors Behind Oddjob Drag And Drop

For those that read my last post on Oddjob’s server Drag n’Drop capabilities here’s the smoke and mirrors, sorry configuration, behind the trick.

First the XML. There are two server configuration files, server1.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<oddjob id="this">
    <job>
        <sequential>
            <jobs>
                <jmx:server root="${server-jobs}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <oddjob id="server-jobs" name="Server Oddjob">
                    <configuration>
                        <xml>
                            <oddjob>
                                <job>
                                    <folder>
                                        <jobs>
                                            <echo id="echo-job"><![CDATA[Hello from ${server.name}]]></echo>
                                        </jobs>
                                    </folder>
                                </job>
                            </oddjob>
                        </xml>
                    </configuration>
                </oddjob>
                <wait/>
            </jobs>
        </sequential>
    </job>
</oddjob>

This has the original Job in it. Some points to note:

  • Although the server can export any job as the root, it is only possible to configure the configuration belonging to a ConfigurationOwner which Oddjob is. This is why we export a nested Oddjob as the root node.
  • The nested Oddjob is configured with in-line XML provided using the <xml> type. This is just laziness on my part but it does result in a configuration that can’t be saved back into original file from the client. If the nested Oddjob was also configured with a file, then changes could be saved from the client back into that file.
  • It isn’t possible to paste onto a nested Oddjob, because we have to decide whether to treat it as the child of it’s parent or as a parent in it’s own right, and in Oddjob Explorer we treat it as the child of a parent, but give it a ‘Design Inside’ action to be able to get at that internal configuration. Having to go this circulus route wouldn’t look slick in the demo which is why I introduced a <folder> who’s children can be dragged about but any parent such as <sequential> or <parallel> would have done too.
  • Oddjob will automatically terminate when it hasn’t got anything else to do – i.e. no more running threads. Because our jobs don’t do anything we need something to keep Oddjob alive, which is why there is a final <wait> job. This wouldn’t be needed if we had something such as a timer to keep Oddjob alive instead.

Then there is server2.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<oddjob id="this">
    <job>
        <sequential>
            <jobs>
                <jmx:server root="${server-jobs}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <oddjob id="server-jobs" name="Server Oddjob">
                    <configuration>
                        <xml>
                            <oddjob>
                                <job>
                                    <folder id="job-folder"/>
                                </job>
                            </oddjob>
                        </xml>
                    </configuration>
                </oddjob>
                <wait/>
            </jobs>
        </sequential>
    </job>
</oddjob>

This is very similar to the previous configuration except there is no echo job in the folder and the folder has been given an id so it is accessible from the code.

And the client.xml:

<oddjob>
    <job>
        <sequential>
            <jobs>
                <jmx:client id="client1" name="Client 1" url="service:jmx:rmi:///jndi/rmi://localhost:9101/jmxrmi" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <jmx:client id="client2" name="Client 2" url="service:jmx:rmi:///jndi/rmi://localhost:9102/jmxrmi" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
            </jobs>
        </sequential>
    </job>
</oddjob>

This is quite straight forward – but note how Oddjob isn’t always very cleaver when it writes out the XML namespaces!

And finally here are the commands to kick off the servers:

java -Dcom.sun.management.jmxremote.port=9101 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dserver.name=Server1 -jar run-oddjob.jar -f server1.xml

and

java -Dcom.sun.management.jmxremote.port=9102 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dserver.name=Server2 -jar run-oddjob.jar -f server2.xml

And that’s it – so now you too can impress friends by dragging an XML bean configuration between two servers!

Comments are closed.