Restlet - Posting an XML document
Good Day,
Based on http://www.restlet.org/documentation/1.0/tutorial, I have -
public class HelloWorldServer {
public static void main(String[] args) throws Exception{
HelloWorldRestlet res = new HelloWorldRestlet();
new Server(Protocol.HTTP, 8182, res).start();
}
}
public class HelloWorldRestlet extends Restlet{
public void handle(Request req, Response resp) {
if (req.getMethod().equals(Method.GET)){
// Testing
resp.setEntity(new StringRepresentation(Hello world!));
resp.setEntity(new StringRepresentation(s));
}
if (req.getMethod().equals(Method.POST)){
// ??
Form f = req.getResourceRef().getQueryAsForm();
I would like to post an XML document and convert it to a DOM structure.
req.getResourceRef().getQueryAsForm() returns nothing. Any ideas?
Regards,
Dan
--
View this message in context:
http://n2.nabble.com/Restlet---Posting-an-XML-document-tp2939798p2939798.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2312849
Re: GSON
Stephan, I don't know much about GSON. For various reasons, it didn't suit my needs. Jackson is a work in progress, and my impression is that it's progressing nicely. Documentation is still a bit simple at this point, but if you look at the Jackson wiki, you will find some useful examples. None of it has anything directly to do with Restlet, and you should be able to figure it out. For my own purposes, I use Jackson's simple binding model, which binds directly to standard java.util collections and maps. Otherwise, Jackson has features which are like JAX-RS, but not necessarily trying to mimic it. It's quite a smart architecture, and with excellent performance. The Jackson community is at least as friendly as the Restlet community, and if this is an important technology for you, I recommend joining the mailing lists there and posting about any of your concerns. Is there room for Restlet to switch its JSON extension from using the standard JSON libraries to Jackson? I think there might be, but I also think different Restlet users might have specific needs, and there are many differences between the various Java/JSON libraries. Whatever is decided, I think Jackson is quite easy to use as is without any official support code from Restlet. -Tal Stephan Koops wrote: Hi, because the JSON integration is not very good in JAX-RS, I like it to have a better one integrated. Does I understand right, that GSON can deserialize into objects? And Jackson? Than I like one of them to be integrated. If someone wants to write the MessageBodyWriter and Reader, or shows me, how to use GSON and/or Jackson, than let me know best regards Stephan Tal Liron schrieb: For what it's worth -- I've moved all my applications to use Jackson, a JSON library which is especially fast, and has some very nice features: http://www.cowtowncoder.com/hatchery/jackson/ Very easy to wrap in a Representation if you like, or just throw into a StringRepresentation. -Tal Rob Heittman wrote: GSON is very nice. It is lightweight and fast, simple and stable. It's sad for me that it depends on reflection, because most of my clients are browsers, and it doesn't work in GWT. Of course it's possible to manually deserialize the object in raw Javascript or GWT, but this takes a lot of the GSON goodness away. If I was writing more services with Java on both sides of the API, I would use GSON a lot more! I'm excited about Jerome's work with serialized Restlet representations in a GWT-compatible way. On Tue, May 19, 2009 at 6:48 AM, Zsolt Czinkos czin...@gmail.com mailto:czin...@gmail.com wrote: I'm just working on a very simple app on GAE, where I'm planning to use RESTLET + GSON + JQERY, so I would be very interested in your experiences, too. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2325866 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2325937
RE: Re: GSON - Jackson 1.0
Jackson has been released as 1.0
http://jackson.codehaus.org/Tutorial
I wrote a simple reflection based Json Representation for Jackson.
pre
public class JsonReflectionRepresentation extends StringRepresentation {
public JsonReflectionRepresentation(Object jsonable) throws
ResourceException {
super(new JsonMaker().toJson(jsonable),
MediaType.APPLICATION_JSON);
}
}
class JsonMaker {
public String toPlainJson(Object jsonable) throws ResourceException {
try {
if (jsonable == null) {
return ;
}
StringWriter writer = new StringWriter();
ObjectMapper mapper = new ObjectMapper();
mapper.writeValue(writer, jsonable);
return writer.toString();
} catch (IOException e) {
throw new ResourceException(e);
}
}
}
/pre
/Fireblazeimport org.restlet.data.MediaType;
import org.restlet.representation.StringRepresentation;
import org.restlet.resource.ResourceException;
import org.codehaus.jackson.map.ObjectMapper;
import org.restlet.resource.ResourceException;
public class JsonReflectionRepresentation extends StringRepresentation {
public JsonReflectionRepresentation(Object jsonable) throws
ResourceException {
super(new JsonMaker().toJson(jsonable),
MediaType.APPLICATION_JSON);
}
}
class JsonMaker {
public String toPlainJson(Object jsonable) throws ResourceException {
try {
if (jsonable == null) {
return ;
}
StringWriter writer = new StringWriter();
ObjectMapper mapper = new ObjectMapper();
mapper.writeValue(writer, jsonable);
return writer.toString();
} catch (IOException e) {
throw new ResourceException(e);
}
}
public E E getObject(String string, ClassE clazz) throws
ResourceException {
ObjectMapper mapper = new ObjectMapper();
try {
return mapper.readValue(string, clazz);
} catch (Exception e) {
throw new ResourceException(e);
}
}
}
volatile variable in Tag
Hi all, Just noticed that Tag defines its 'weak' variable to be volatile, although it is never changed. Perhaps this should be final instead? -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2330733
Re: GSON
Thank you for all of you! This was very helpful, a such an active community :). Unfortunatelly the focus of my work temporary shifted to something else, so I cannot give the other Zsolt some feedback, but I will when I have something tangible to show you. Zsolt -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2331428
Problem with Engine.getClassLoader() and Spring DM
We've been using Restlet and OSGi, and recently we've begin using Spring DM (Dynamic Modules) in our stack, which is a way to integrate Spring's dependency injection and other tools with an OSGi server environment. We maintain our own build of Restlet, based on the trunk, with local changes to fix show-stopper bugs, and one change we had to make in order to work with Spring DM is in Engine.getClassLoader(). I figured I should mention it here. :-) Engine.getClassLoader() is used by the Engine class's constructor to find helper classes, like external connector implementations. It's implementation checks first for the Thread context classloader, which it will use in preference to it's own Engine.class.getClassLoader(). The problem with this is that if any other library happens to use the Thread context classloader, even if that use is intended to be independent of Restlet, then the wrong classloader is searched for Restlet helper connectors. This is the case with Spring DM, which sets the thread classloader to be the one used in configuring it's bean contexts. Since this classloader doesn't know anything at all about the location of restlet connector extension libraries, Restlet is unable to load any ext connectors. The change we made locally was to remove this usage of the ContextClassLoader. We also removed the usage of the System classloader, since that code is basically unreachable (only executes if Engine.class.getClassLoader() returns null, which is impossible). Now, it's possible that some people are relying on the existing behavior of checking the thread context classloader first. (My guess is that anyone relying on this probably wishes they didn't have to). If it's important to maintain the current behavior, then I suggest that the helper/extension finding code be changed to look in _multiple_ classloaders for potential helper classes, and not just the first one that happens to be found. This would not disrupt people relying on the current code, and would enable much better behavior for osgi and other environments which don't have one big central classloader. -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2335380
Content negotiation and Encodings
Hi all- We're writing a Directory-like restlet which caches representations for speedier responses. We wanted to make use of some of restlet's built-in support for content negotiation to make sure we send back the best-matched variant. (In particular, we want to call ClientInfo.getPreferredVariant() ). One problem we've run into is that some of the Representations we are storing are pre-compressed (gzipped) versions of the originals, but it appears that restlet's content-negotiation code doesn't consider the Accept-Encoding preferences of the client request, only the Language and MediaType. Why is this? Shouldn't encoding preferences be processed as part of content negotiation? or is this handled somewhere else- if so, why? One other thing we noticed in looking at the org.restlet.data.Encoding class is that in addition to the expected GZIP, ZIP, DEFLATE, COMPRESS encodings, there are also Encoding constants for VELOCITY and FREEMARKER.Why are these considered Encodings? It doesn't seem like they should be. -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2336147
setting Cache-Control metadata
Why doesn't the Representation class have a way to set Cache-Control header-related values? From past mailing-list messages it looks like there is a pending feature for general caching support in Restlet. But I don't want restlet to do any caching in this case, I just want to be able to return Representations with Cache-Control values like max-age, etc, in order to interact more precisely with client browsers. Is it the case that the only way to set these is to use the reponse.getAttributes() headers backdoor? -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2336806
