RHQ 4.1.0 BETA released

The RHQ team has just released version 4.1.0.beta of the RHQ systems management and monitoring suite. This release serves as a preview of the upcoming version 4.1.0 and has a wealth of new features.

Some of the new features are work in progress and will only be finished after 4.1, which means that you can still influence the features with your ideas and feedback.

Release notes are on the RHQ wiki and also contain the link to the download at the bottom.

We want to especially thank Elias Ross, Fusayuki Minamoto, Jijun Liu, Zhongqianglee

and Rafael Torres Coelho Soares for their contributions (even if some are not in this build)

 

Some progress with REST for RHQ and new questions

As written some time ago on the rhq-devel mailing list, I've started implementing a RESTful interface for RHQ. A page on the RHQ wiki shows the requirement and some progress about the implemented API. Development currently happens in a personal feature branch in order to have some code to play around and gather some experience from.

One thing that I found out over the weekend is that at least with JAX-B setting up the interface and REST resource classes is far from trivial and I have been surprised a lot by interesting error messages.

Anyway, the current state of the API is already in a somewhat usable shape (mostly read-only at the moment). The implementation has been done via RESTeasy (RE). Security integration with the RHQ security model is also done and the session bean methods can just use a Subject called caller.

So, having solved some stuff rises even more questions:

1. Would stuff get easier when not trying to support XML, but only Json?
2. How to use much / more of the original RHQ domain model without running into LazyLoadExceptions all over the place (RE runs as a servlet to do the marshalling - at this point in time the connection to the entity manager is already closed).
3. How to implement linking between related classes / concepts. E.g. a Resource can have Alerts. Now instead of embedding Alert elements when returning a Resource object, I would like to at most have a list of Links to /alert/{id}. I feel that the answer may have to do with the next question
4. In RHQ we often pass just primitive ids around (e.g. int resourceId) How can easily turn them into a link to the target Resource (given that Resource lives below /resource/{id})
5. In the Atom-PUB linking I would add links to sub-resources like e.g. /resource/1234/availability or /resource/1234/schedules without the need to first obtain those values from the database.
6. Does it make sense to transfer date/times as long? Especially as Json seems to have some issues there. Complex date strings require a lot of processing on server and client.
7. Is there a preferred way to expose id elements ((XML) attribute, element, not at all? With Atom-PUB links present, I think the id would not need any special treatment at all, as it is available in the URI of the resource and in the link.

A part of the solution to questions 3+4 seem to be to only use Objects in REST domain objects, as the marshalling will skip elements where the corresponding object is null, so for e.g. the parent Resource it is enough to initialize its resource with the Resource id to only include this, but not all the other fields that should then be obtained from their real URI.

 

But then I am not sure how much my ideas are RESTful at all :-)

I would love to get some feedback here.