The introduction has "...which means that you don't need to take care of
thread-safe concerns." which should be "thread-safety concerns". This might
still be a little strong, as you still have to worry about thread-safety in
all the objects that your Resources refer to that are shared between
threads. You could say that you don't need to make your resource subclasses
thread-safe, but that sounds anticlimactic.
"That's why you will notice that the map of items is made immutable and is
an instance of the ConcurrentHashMap class." You mean "final", not
"immutable". In actual practice, you'd really want to make the items field a
ConcurrentMap rather than just Map, because the @Post and @Put methods
defined below would then be able to use putIfAbsent to avoid races. I know
you want to keep the example simple, but I'd hate for readers to draw the
conclusion that they don't have to worry about races:
// Register the new item if one is not already registered.
if (!getItems().containsKey(itemName) &&
getItems().putIfAbsent(itemName, new Item(itemName,
itemDescription)) == null) {
// Set the response's status and entity
setStatus(Status.SUCCESS_CREATED);
Representation rep = new StringRepresentation("Item created",
MediaType.TEXT_PLAIN);
// Indicates where is located the new resource.
rep.setIdentifier(getRequest().getResourceRef().getIdentifier()
+ "/" + itemName);
result = rep;
} else { // Item is already registered.
setStatus(Status.CLIENT_ERROR_NOT_FOUND);
result = generateErrorRepresentation("Item " + itemName
+ " already exists.", "1");
}
The business about setModifiable is obsolete, right? You get it for free by
defining a method annotated with @Post, @Put, or @Delete. If not, you
should! :-)
Looks great otherwise!
--tim
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1545246
