Modelling restful properties


I’ve recently been playing with Liberty and JAX-RS and in an effort to remember some of what I’ve discovered, I’m going to try and keep a few notes and post them here, probably along with a few questions. If anyone else finds them useful, or knows the answers, that’s a bonus!!

To start with Creating an efficient REST API with HTTP provides a nice overview of REST APIs and JAX-RS basics has a great simple sample application to get going with… and break!

JAXRSServiceModel_Main

Armed with the basics I thought it would be interesting to model the sample application to compare the working code with what Rational Software Architect (RSA) would generate for me. Obviously that’s not the most complex model in the world but it was good to have a few examples to follow:

(Those articles made much more sense when I’d tracked down all the likely looking JAXRS, REST and UML features in the RSA installer!)

Before generating any code, it was quite nice to get some basic API documentation out of the model. Not as fancy as using Swagger UI but certainly better than no documentation!

systemproperties-apidoc

It’s only a start but that’s all for part 1. Hopefully there’ll be more posts at some point when I get further, probably along these lines:

  • Creating an OSGi Web project and generating some code
  • Using a REST client to check it works, including a puzzling Wink problem
  • Adding some debug
  • Expanding the sample with some awkward long running processing
  • Deploying to Bluemix
  • Anything else I encounter along the way!

If you know of any good articles/books/fancy new media that would help, please leave recommendations below. If there are better ways to design REST services (Swagger looks interesting but I haven’t had a chance to investigate), please share them. And any other tips, comments, or questions of your own are also very welcome!

 

Advertisements

Java dumps


I recently had to debug a problem with the MDM Workbench where exporting a tailoring project for Information Server didn’t do anything. In fact it didn’t even report any problems!

Unfortunately the code in question likes to put a brave face on things and just reports that everything was OK, even when something goes wrong. This was the perfect opportunity to try out some of the diagnostic tools available for the IBM Java runtime, which I’ve been meaning to try for ages. I had an idea where the problem was likely to be but to find out for sure I started the workbench using the following command line:

eclipsec -vmargs -Xdump:system:events=catch,filter=java/lang/AbstractMethodError#com/ibm/mdm/tools/export/infoserver/job/MDMDatabaseDAO.queryDatabaseWithoutFilter

Sure enough the failing export produced a dump which I could check using the Memory Analyzer tool. You can get the IBM version via IBM Support Assistant but it’s probably easier to get the standard Eclipse Memory Analyzer and add the required IBM plugins from the DTFJ update site.

I’m fortunate enough to work in Hursley so I could pester someone who works on IBM Java runtime diagnostics, but there’s also a helpful article on developerWorks with details of how to trigger dumps, and how to run queries using OQL:

Debugging from dumps: Diagnose more than memory leaks with Memory Analyzer

So mystery solved- if you have an Oracle database and want to exporting tailoring projects for Information Server, make sure you set up the database connection with a more recent JDBC driver than the defaults.

Generated… not


Using JMerge makes it easy to combine generated code with custom code, preserving any modifications when re-generating. So, for example, you might have this generated code:

/**
  * some generated code which hasn't been modified
  * @generated
  */

public void doSomething() {
   // anything here can get overwritten when the
   // code is regenerated
}

Which you might modify:

/**
  * some generated code which has been modified
  * @generated NOT: added important bit
  */

public void doSomething() {
   // really important stuff which I don't want overwritten
   // when the code is regenerated
}

Nice but, having a short memory, I need a way to keep track of all these modified bits of code and luckily the Java task tag feature in Eclipse comes to the rescue with a simple solution. Open ‘Window > Preferences…’ in the main Eclipse menu. Find the ‘Java > Compiler > Task Tags’ page. Press the ‘New…’ button and enter the following details:

  • Tag: “@generated NOT”
  • Priority: Low

Problem solved: the tasks view will list everything you changed!