One of the best aspects of RESTful orientated services is getting your resources connected, possibly even achieving HATEOAS. Making that jump with with legacy object models or data can be tricky, depending on how intrusive you want to be.

There is such a large amount of legacy data in various forms, usually with minimal links/relations that could be leveraged.

So it is a worthy challenge to try and do it in the least intrusive manner possible.

This is one approach that is reasonably decoupled from an existing legacy model.

There are three main parts to this technique:

1. Enhance your model objects so they have a placeholder/collection so you can accumulate links
2. Annotate your model at interesting points with link templates, around attributes or methods or classes
3. Use a custom ContainerResponseFilter class of jersey to scan for annotations of interest, then evaluate your link templates (at run time), using the data of your models and any request based information you may require.

I chose to enhance my model classes using AspectJ at compile time.

Download the source

mvn glassfish:run
./curl_test #will hit two urls

and you should see some results, with links like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<country xmlns:ns2="http://www.w3.org/1999/xlink">
  <links>
    <link rel="" ns2:type="locator"
        ns2:href="http://localhost:8080/hateoas4legacy/rs/cities/Brisbane"/>
    <link rel=""
        ns2:type="locator" ns2:href="http://localhost:8080/hateoas4legacy/rs/cities/Sydney"/>
    <link rel=""
        ns2:type="locator" ns2:href="http://localhost:8080/hateoas4legacy/rs/cities/Melbourne"/>
    <link rel=""
        ns2:type="locator" ns2:href="http://localhost:8080/hateoas4legacy/rs/countries/AU"/>
  </links>
  <cities>
    <city>
      <links/>
      <name>Brisbane</name>
    </city>
    <city>
        <links/>
        <name>Sydney</name>
    </city>
    <city>
      <links/>
      <name>Melbourne</name>
    </city>
  </cities>
  <isoCode>AU</isoCode>
  <name>Australia</name>
</country>

All countries Results

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<countries>
<country xmlns:ns2="http://www.w3.org/1999/xlink">
  <links>
    <link rel=""
        ns2:type="locator" ns2:href="http://localhost:8080/hateoas4legacy/rs/countries/AU"/>
  </links>
  <cities/>
  <isoCode>AU</isoCode>
  <name>Australia</name>
</country>
<country xmlns:ns2="http://www.w3.org/1999/xlink">
  <links>
    <link rel=""
        ns2:type="locator" ns2:href="http://localhost:8080/hateoas4legacy/rs/countries/USA"/>
  </links>
  <cities/>
  <isoCode>USA</isoCode>
  <name>United States of America</name>
</country>
</countries>

It is very crufty, but does work in the simple cases. I haven't had a chance to demonstrate all of the features yet.

I'm likely to further flesh out this example as it is interesting in other RESTful related ways.

Anyway I liked the Circuit Breaker pattern, as I've seen a number of apps with highly coupled systems that barf once latency increases in the back ends then you get "Cascading Failures" and the webapp's request handler thread pool is exhausted and they all wait their mandatory 30 seconds for a response. Eventually the app either dies, or gets taken out of a load balance farm causing a "Chain Reaction".

Here is an Experimental Circuit Breaker Implementation (circuit_breaker.tgz) , NOT built or tested FOR PRODUCTION use in anyway. There is explicity no thread safety no the actual CircuitBreakerSimple class.

download, extract and run ant.

Play around with the parameters to see the affect. Generally it seems to thrash more with increased concurrent threads and interestingly in jdk1.6 sometimes reverts to the default timeout instead of the instance value.

Based roughly on the following logic:
When Circuit is Closed:
on call = pass through
call succeeds = reset count
call fails = count failure
threshold reached = trip breaker. Open State

when Circuit is Half-Open
on call = pass through
call succeeds = reset go. Close State
call fails = trip breaker. Open State

when Circuit is Open
on call = return/fail
on timeout = attempt reset. Half-Open State

I've seen it fail prior to any of your own js executing.

Try this for an experiment have an onload event log something but also return:

You have an large list of table results that are fed back to the browser with a slight delay per row (ie. an unfortunate logging statement per row)

What comes first?

Both parties were interested in avoiding iframes and it's baggage.

Ideally we were looking for a solution that involved:

• minimal (html,css,js) code on affiliates pages. After all who would want deployment dependencies across organisations?
• dynamic json data served from our site
• long lived highly compressed components
• efficient use of connections to our server

We evaluated dojo and google web toolkit

Dojo won out, among it's many features it has:

• Nice Custom Widgets
• Cross Domain IO via ScriptSrcIO
• compression and packaging into a single js. create your own profile listing your dependencies and dojo buildscripts
• XDomain package loading. You need to build it from source, Although this wasn't required for us in the end.

Widget Issues

Unfortunately widgets are not completely self-contained. CSS is a bit of a problem. Typical custom widget will result in your css being inlined into your html widget, but this isn't required or always the bestway to go.

CSS relative image references are resolved relative to the host the base page was served from not our site.

We decided to keep our relative image references and have our stylesheet added to our affiliate pages dynamically.

Give namespaces are changing in new version we didn't create our own and just used dojo.widget...

Should Dojo be called Sumo? (says teagles)

Most ajax libraries are fairly heavy, you are looking at atleast 100K with the average closer to 200K to get simple io, events, effects and dom manipulation functionality. Disclaimer, it was a pretty quick scan a couple of weeks ago, of mochikit, dojo and scriptaculous.

After various packaging experimentation the Animation.js heavyweight seemed pretty core if you want to use custom widgets.

Why GWT wasn't for us

• binary format
• can't use 5.0 features
• not all features supported, ie new ArrayList(size)
• active monitoring
• components served off google
• ...

GWT does have some upsides though:

• testability
• small footprint
• cross browser compatibility verified by google

Firebug

* Status bar icon shows you when there is an error in a web page
* A console that shows errors from JavaScript and CSS
* Log messages from JavaScript in your web page to the console (bye bye "alert debugging")
* An JavaScript command line (no more "javascript:" in the URL bar)
* Spy on XMLHttpRequest traffic
* Inspect HTML source, computed style, events, layout and the DOM

So Tom mentioned the ant-contrib tasks, Compile With Walls and VerifyDesign.

Compile with Walls is great, packages won't compile if layers are broken. It is marked as deprecated with Verify Design to replace it.

Verify Design works after compilation and can't detect the source code violations of constants imported from other packages.

Compile With Walls requires dependant packages to declare all dependencies and the dependencies of dependencies, which could get unwieldly, but still potentially useful. An option to not have to do that would be nice.

But now in 10g you have alot more freedom, for starters the expression list is now limited to 1000 plus you can have multiple "IN" conditions in the query to extend that and if you want something less smelly, create a collection and use the CAST and TABLE commands to join an in memory collection of predefined type to real tables.

When I first tried the latter method in 8i it was too unreliable to use, but now it seems better, thanks to Gary Mandelkow for doing the leg work and testing 10g, we can reliably do this with atleast a 3000 member collection.

It seems really ironic to me that the "V" in WebDAV is optional, but that's the way it is. It does mean you can have your DAV location backed by a file system and only one version.

Get subversion installed with ssl support:
./configure --with-ssl so it will build neon as well. This is important if you want your svn client to access your server via https://myserver.com/svn.

Follow the subversion documentation or checkout the subversion book to create a repository add a test file, and make sure all that is working before doing the httpd integration.

When you follow the svn httpd setup one thing that tripped me up in setting up the config was turning AutoVersioning option function, in the books example they have config for the mod_dav_fs not mod_dav_svn.

DAV svn
SVNPath /fullpath
SVNAutoversioning on
...


And if that worked you should have no problems viewing one of the files in your repository, via http://myserver.com/svn/index.html

Back at the start of this blog I wanted to setup some versioned docs that I could access over the net, but chances are that if you browse to that location you will only get the plain text version of the file.

WebDAV supports meta data about files, called Properties, which is exactly how mime-type's are treated, so by doing something like this svn propset svn:mime-type text/html index.html.

You only need to add it manually if the svn client you used to add the file had "auto-props" option set to "no", which is the default.

Now that that is up and running, you can get your life in order with sunbird
and keep versioned remote calendars on your server. Creating a remote calendar is pretty straight forward, although the screenshots from that link didn't match with the current build, I couldn't import, since the authentication option was not provided in the gui, so I had to add the local file directly with svn then subscribe to it.

I went straight for setting up https over the other types of secure options subversion supports. You might also want to checkout the "LimitExcept" options for creating a anonymous read but write protected repository.

There are some other common tools available for WebDAV like cadaver, but since i'm only interested in dav locations backed by svn, the svn client is the only cli tool I'll need.

You could try out the litmus test to see how good the support is, although be warned, subversion does not yet fully support the WebDAV protocol.

I had a superficial look mainly from a scripting point of view and it looks great, I might never have to write another awk script again!

Here is the socketcount program from a recent post rewritten in ruby.

#!/usr/bin/ruby
#socketcount in ruby
if $*.size > 0
regex = $*[0]
else
regex = '^..p'
end
result = %x{sudo netstat -tpa | grep #{regex} | grep -v LISTEN }
# All Socket connections counted (originating and terminating)
h = {}
result.each() { |s|
service = s.split(' ')[4]
h[service] = h[service].to_i + 1
}
h.each { | key, value | print key, " ",value, "n" }


It suits my purposes for scripting and seems to be pretty impressive in other aspects.

I don't know how many plugins I thought would be cool, download and try and configure it no doco and buggy configuration forms to not get any results.

So in disgust I thought I'd look at debugging some, so I had a look at jetstyle, it was bugging me that it didn't work and the cvs version looked like it should work in 4.5.

http://www.intellij.org/twiki/bin/view/Main/PluginTesting had some tips for debugging in IntelliJ, I wrote some unix scripts for option 1, it didn't work very cleanly but it does run.

After all of that it was easy to see a problem at configuration time and then a problem at run checkstyle execution, I just had to remove our Custom Checkstyle Rule and hey presto it worked. It would be nice if they could support that and do a release for 4.5, it's been along time between releases for the jetstyle project.

The PSIViewer plugin is very cool and would be worth looking at if you are thinking about writing a plugin.