Re: Netty, JSON and Chunked Encodings
Hello Grant, the usage of the chunk encoding is perfectly normal and must be supported by HTTP servers and clients (except GAE...). I guess this reveals a problem with the Netty extension, which should correctly parameter the underlying netty http server in such case. Having said that, I propose you to simplify your code, as there is no need to specify the netty connector (this is due to a kind of magic that I will explain later). Component component = new Component(); component.getServers().add(new Server(Protocol.HTTP, port)); Injector injector = Guice.createInjector(new APIModule(apiClass)); API theAPI = injector.getInstance(apiClass) // Then attach it to the local host component.getDefaultHost().attach(/api, theAPI); // Now, let's start the component! component.start(); At this time, you are only required to add to the classpath the jar of the netty extension (org.restlet.ext.netty.jar), and the jar(s) of the libraries it depends on. At runtime, the engine detects the presence of an HTTP server connector, instantiates it, and voila! This magic is based on a simple mechanism integrated in the JDK, made public since jdk 6 and called ServiceLoader. As a matter of test, I suggest you to remove the workaround (which is useless) and just replace the netty connector by the jetty one : you are only required to update your classpath. I make some tests also and keep you informed. Best regards, Thierry Boileau My attempted patch at this, which appears to work at first blush, is at https://github.com/lucidimagination/restlet-framework-java/tree/2.0.11-patch -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2924788 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925360
Re: Post problems when using Restlet Javascript Edition...
Hello Richard,
Regarding the post HTTP method and the annotated methods server
resources, I updated the header management in the JavaScript edition.
The routing to such methods is based on the Content-Type header. I
committed all my updates in GitHub, so feel free to make some tests and
give me a feedback.
Be aware that there is a bug in Restlet 2.1 regarding the routing to the
right methods. If a media isn't specified for the first method, this
method will be used and it's not correct...
@Put
(...)
@Put(json)
(...)
It works with the following:
@Put(json)
(...)
@Put
(...)
This problem is about to be fixed in the Java version of Restlet.
Thierry
Thanks again for your help. I downloaded tcpmon and made the
suggested changes to my Java client. I then did a post through Java
and below are the Request and the Response.
Request
POST /commitments/ HTTP/1.1
Date: Wed, 15 Feb 2012 22:19:58 GMT
Content-Length: 109
Content-Type: application/json; charset=UTF-8
Accept: */*
Host: localhost:8880
User-Agent: Restlet-Framework/2.1rc2
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
{id:0,title:Added through post - Java client,description:This
is a description of post Java client}
Response...
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Wed, 15 Feb 2012 22:19:59 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.1rc2
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Length: 1
4
Then I moved to the Javascript side. I didn't install Firebug, but
instead I just changed the ClientResource creation from:
var clientResource = new ClientResource(/commitments/); /
To:
var clientResource = new
ClientResource(http://localhost:8880/commitments/;);
where TCPmon was running on 8880 and forwarding to , which is
where my server was listening.
Below are the Request and Response - and they are definitely different
than the Java version...
Request...
OPTIONS /commitments/ HTTP/1.1
Host: localhost:8880
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11
(KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11
Access-Control-Request-Headers: Origin, Content-Type, accept
Accept: */*
Referer: http://localhost:/oldTest.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response...
HTTP/1.1 200 OK
Content-Type: application/vnd.sun.wadl+xml; charset=UTF-8
Date: Wed, 15 Feb 2012 22:22:22 GMT
Accept-Ranges: bytes
Allow: POST, GET
Server: Restlet-Framework/2.1rc2
Transfer-Encoding: chunked
5D2
?xml version=1.0 standalone=yes?
?xml-stylesheet type=text/xsl href=wadl2html.xslt?
application xmlns=http://wadl.dev.java.net/2009/02;
doc title=Commitments resource/
representation id=commitment mediaType=text/plain
doc title=CommitmentSimple string containing the commitment ID/doc
/representation
resources
resource path=commitments/
doc title=Commitments resourceThe resource that contains the list
of commitments in the system/doc
method name=GET
response
representation href=#commitment/
representation href=#commitment/
representation href=#commitment/
representation href=#commitment//response
/method
method name=POST
request
representation href=#commitment/
representation href=#commitment/
representation href=#commitment/
representation href=#commitment//request
response
representation href=#commitment/
representation href=#commitment/
representation href=#commitment/
representation href=#commitment/
representation href=#commitment/
representation href=#commitment//response
/method
/resource
/resources
/application
One small typo on the
http://templth.wordpress.com/2011/05/17/activating-tracing-mode-in-restlet/
article, in the ClientResource section the line:
Context context = clientResource.getContext();
should be
context = clientResource.getContext();
(but this is minor - the ease of getting the trace using Restlet
tracing was awesome).
Thanks again for all your assistance! (And my apologies in advance if
the problem turns out to be some silly mistake in my code - always a
real possibility).
RB
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925370
Re: Netty, JSON and Chunked Encodings
Hello Grant, I've entered an issue for this point : http://restlet.tigris.org/issues/show_bug.cgi?id=1376 Best regards, Thierry Boileau Hello Grant, the usage of the chunk encoding is perfectly normal and must be supported by HTTP servers and clients (except GAE...). I guess this reveals a problem with the Netty extension, which should correctly parameter the underlying netty http server in such case. Having said that, I propose you to simplify your code, as there is no need to specify the netty connector (this is due to a kind of magic that I will explain later). Component component = new Component(); component.getServers().add(new Server(Protocol.HTTP, port)); Injector injector = Guice.createInjector(new APIModule(apiClass)); API theAPI = injector.getInstance(apiClass) // Then attach it to the local host component.getDefaultHost().attach(/api, theAPI); // Now, let's start the component! component.start(); At this time, you are only required to add to the classpath the jar of the netty extension (org.restlet.ext.netty.jar), and the jar(s) of the libraries it depends on. At runtime, the engine detects the presence of an HTTP server connector, instantiates it, and voila! This magic is based on a simple mechanism integrated in the JDK, made public since jdk 6 and called ServiceLoader. As a matter of test, I suggest you to remove the workaround (which is useless) and just replace the netty connector by the jetty one : you are only required to update your classpath. I make some tests also and keep you informed. Best regards, Thierry Boileau My attempted patch at this, which appears to work at first blush, is at https://github.com/lucidimagination/restlet-framework-java/tree/2.0.11-patch -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2924788 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925375
Re: Restlet + GAE + JAX-RS
Hello Guillaume, ouups, I'm sorry for the wrong org.reslet.application instead of org.restlet.application... Best regards, Thierry Boileau Finally its ok I misspell the parameter-name (the evil copy/paste) but thank you for focusing me on these line. Thank you very much -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-GAE-JAX-RS-tp3890645p7288677.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2923023 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925376
Re: V2. RC.3 : java.lang.NoSuchMethodError when POSTing xml
Hi Guillaume, this error Exception in thread main java.lang.NoClassDefFoundError: com/google/gwt/user/client/rpc/IsSerializable is due to the missing library com.sun.syndication.jar in your classpath. This library is shipped with tthe Restlet in the lib directory. this error Exception in thread main java.lang.NoClassDefFoundError: com/google/gwt/user/client/rpc/IsSerializable is due to the missing library com.google.gwt.server.jar in your classpath. This library is shipped with the Restlet in the lib/com.google.gwt.server directory. But I think this class is already hosted by the gwt-servlet.jar archive... Best regards, Thierry Boileau I've the same issue my war lib directory look like this appengine-api-1.0-sdk-1.6.2.jar appengine-api-labs-1.6.2.jar appengine-jsr107cache-1.6.2.jar c2dm-server.jar c2dm-server-src.jar datanucleus-appengine-1.0.10.final.jar datanucleus-core-1.1.5.jar datanucleus-jpa-1.1.5.jar geronimo-jpa_3.0_spec-1.1.1.jar geronimo-jta_1.1_spec-1.1.1.jar google_sql.jar gwt-servlet.jar javax.servlet.jar javax.xml.bind.jar javax.xml.stream.jar jdo2-api-2.3-eb.jar json-1.5.jar jsr107cache-1.1.jar org.codehaus.jackson.core.jar org.codehaus.jackson.mapper.jar org.json.jar org.restlet.ext.jackson.jar org.restlet.ext.json.jar org.restlet.ext.servlet.jar org.restlet.jar validation-api-1.0.0.GA.jar validation-api-1.0.0.GA-sources.jar An the exception Exception in thread main java.lang.NoClassDefFoundError: com/google/gwt/user/client/rpc/IsSerializable at org.restlet.ext.gwt.GwtConverter.getVariants(GwtConverter.java:75) at org.restlet.engine.converter.ConverterUtils.getVariants(ConverterUtils.java:93) at org.restlet.service.ConverterService.getVariants(ConverterService.java:116) at org.restlet.engine.resource.AnnotationInfo.getResponseVariants(AnnotationInfo.java:438) at org.restlet.engine.resource.ClientInvocationHandler.invoke(ClientInvocationHandler.java:217) at $Proxy5.getUsers(Unknown Source) at com.youfood.client.Client.main(Client.java:23) or Exception in thread main java.lang.NoClassDefFoundError: com/sun/syndication/feed/synd/SyndFeed at org.restlet.ext.rome.RomeConverter.getVariants(RomeConverter.java:76) at org.restlet.engine.converter.ConverterUtils.getVariants(ConverterUtils.java:93) at org.restlet.service.ConverterService.getVariants(ConverterService.java:116) at org.restlet.engine.resource.AnnotationInfo.getResponseVariants(AnnotationInfo.java:438) at org.restlet.engine.resource.ClientInvocationHandler.invoke(ClientInvocationHandler.java:217) at $Proxy7.retrieve(Unknown Source) at com.restletexample.Test.main(Test.java:18) Thierry Boileau wrote Hello, could you describe what are your needs? That is to says, the kind of Restlet extensions you need. Then, in each distribution, you can have a look at the /lib/readme.txt file. it lists extensions and their dependencies. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2702700 -- View this message in context: RE: V2. RC.3 : java.lang.NoSuchMethodError when POSTing xmlhttp://restlet-discuss.1400322.n2.nabble.com/V2-RC-3-java-lang-NoSuchMethodError-when-POSTing-xml-tp5114202p7292103.html Sent from the Restlet Discuss mailing list archivehttp://restlet-discuss.1400322.n2.nabble.com/at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925388
Re: Using MetadataService to specify the default media type
Hello Avi,
I've made some tests using Restlet 2.0 and 2.1. From what I notice, in this
case, the order is not significant.
I get the xhtml representation instead of the html one in both cases :
@Get(“html|xhtml”) and @Get(“xhtml|html”)
Here is my explanation : html is a shortcut for text/html and xhtml
stands for application/xhtml+xml.
When the client provides no preference, then the default one set on the
MetadataService is applied : by default application/octet-stream.
The curent score algorithm gives a better affinity between
application/xhtml+xml and application/octet-stream than between
text/html and application/octet-stream, because of application/...
The scores are very low : 0.0006 and 0.0003 but the difference is real.
Good news anyway, you can set the default media type of the application's
MetadataService to a neutral one : */* :
getMetadataService().setDefaultMediaType(MediaType.ALL);
In this case, the order is significant, once again.
Best regards,
Thierry Boileau
The proper/standard way in HTTP to do this is to correctly set the
preferences of your clients (via the “Accept” header typically)…
Otherwise,
the order of the annotated methods declaration might be taken into
account
by Restlet when deciding how to dispatch the method call, but I wouldn’t
say
it is a safe bet to solely rely on this default behavior.
You could customize the ConnegService attached to your parent
application to
force the variant when client preferences are not explicitly given
(MediaType.ALL), or plug a custom filter in the routing chain to enforce
your policy.
Jerome,
I’m using 2.0, and I need a way to set the default variant of my
resources. I’m frustrated because I’d think this’d be a common need
and it really should be easier and clearer how to do this. I need to
support requests which don’t include an Accept header, and I need to
be able to set the default variant concisely on a resource-by-resource
basis — not in a centralized Service or Filter.
With the resource I’m working on now, I first tried to just use a
single annotation:
@Get(“html|xhtml”)
public Representation getRep(Variant variant) { … }
I assumed that when a request didn’t include an Accept header, the
conneg algorithm would take into account the order specified and use
html as the default. Unfortunately it does not — for some reason,
xhtml is chosen as the default.
Unsurprisingly, the same is true if I use two separate methods:
@Get(“html”)
public Representation getHtml() { … }
@Get(“xhtml”)
public Representation getXhtml() { … }
IIRC, in Restlet 1 this was fully supported — the first variant passed
to getVariants().add() was considered the default. I still need this
functionality.
I don’t know if it’s too late to change this for 2.0 (I’d love to
submit a patch…) but I’d at least like to see this improved for 2.1 —
I think the order specified in the annotation parameter should be
significant, with the first one specified used as the default.
For now, I’m not even sure how I’m going to make this work in the
resource I’m working on today — I might just do something hacky like
this:
if (acceptHeader != null
acceptHeader.contains(application/xhtml+xml) !
acceptHeader.contains(text/html))
representation.setMediaType(MediaType.APPLICATION_XHTML);
Thanks,
Avi
Avi Flax » Arc90 » http://arc90.com
Kindling » Innovation through Collaboration » http://kindlingapp.com
Readability » Enjoy Reading, Support Writing » http://readability.com
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2916957
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925400
how to set ETag response header from ServerResource annotated method?
I'd like to set an ETag response header while processing a request within my ServerResource subclass. I tried getResponseEntity().setTag(new Tag(foo)); but this doesn't work, because there is no entity in the response object yet (getResponseEntity returns null). What's the right way to do this? Thanks. -Andy -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925566
RE: Gwt 2.4 + restlet2.1RC2 return null
Hello again, I had test this with the new restlet2.1RC3 and it still doesn't work. Also I my server I receive the following error: 2012-02-22 19:15:36127.0.0.1 - - 8111GET /v1/environment/objects/- 200 - 0 1 http://localhost:8111 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 http://127.0.0.1:/Freedomotic_gwt_client.html?gwt.codesvr=127.0.0.1:9997 An exception occured writing the response entity org.simpleframework.http.core.ProducerException: Stream has been closed at org.simpleframework.http.core.ChunkedProducer.produce(ChunkedProducer.java:148) at org.simpleframework.http.core.Transfer.write(Transfer.java:184) at org.simpleframework.http.core.Transfer.write(Transfer.java:167) at org.simpleframework.http.core.Accumulator.write(Accumulator.java:219) at org.simpleframework.http.core.Accumulator.write(Accumulator.java:190) at org.simpleframework.http.core.Accumulator.write(Accumulator.java:169) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1857) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1766) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1560) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:349) at org.restlet.representation.ObjectRepresentation.write(ObjectRepresentation.java:168) at org.restlet.engine.adapter.ServerCall.writeResponseBody(ServerCall.java:506) at org.restlet.engine.adapter.ServerCall.sendResponse(ServerCall.java:450) at org.restlet.engine.adapter.ServerAdapter.commit(ServerAdapter.java:193) at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:150) at org.restlet.ext.simple.internal.SimpleContainer.handle(SimpleContainer.java:80) at org.simpleframework.http.core.Dispatcher.dispatch(Dispatcher.java:107) at org.simpleframework.http.core.Dispatcher.run(Dispatcher.java:90) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Please, does anyone point me what I'm doing wrong? Thank you Gabriel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2925529
