Re: restful-gwt
Hi, in the JAX-RS JSR discussions some people asked the question for JAX-RS for clients. The answer from the spec leads was, that teh first version is server only, but a later version could include also a client API. best regards Stephan Xavier M. schrieb: > Hello, > Just a link towards a new project in the REST+GWT ecosystem : > http://code.google.com/p/restful-gwt/ > regards > Xavier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460724
RE: Infinite loop in EncodingReader.addValues()
Hello Carsten, thanks for your report, the fix is now available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460655
Re: restful-gwt
Thanks Xavier, the radar will take care of this newcomer. :) Best regards, Thierry Boileau > Hello, > Just a link towards a new project in the REST+GWT ecosystem : > http://code.google.com/p/restful-gwt/ > regards > Xavier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460635
restful-gwt
Hello, Just a link towards a new project in the REST+GWT ecosystem : http://code.google.com/p/restful-gwt/ regards Xavier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460579
RE: Re: A POST request with query parameters?
Thank you. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460610
Re: Content type negotiation with annotations
Hi Thierry,
I've just tried it on 2.0-RC1.
Here is a jUnit test case.
SampleResource1 and SampleResource2 offer both plain text and HTML on
GET, and for simplicity, only HTML on POST (but that's only determined
by the method itself -- the problem is that it's not even called).
SampleResource1 uses @Post.
SampleResource2 uses @Post("html").
SampleResource3 disables content-type negotiation.
The results are that posting a x-www-form-urlencoded entity to
SampleResource1 and SampleResource2 doesn't work (the @Post-annotated
methods are not called). Sending it to SampleResource3 works (but of
course, content-type negotiation doesn't.)
It just seems that the content negotiation feature affects both request
and response types, and that the @Post annotation expect that type to be
the same both ways. Is this by design, or is it a bug?
Best wishes,
Bruno.
import org.junit.*;
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.representation.*;
import org.restlet.resource.*;
import org.restlet.routing.Router;
import static org.junit.Assert.*;
public class PostAnnotationTest {
public final static String PLAINTEXT_TEST = "Hello World!";
public final static String HTMLTEXT_TEST = "Hello
World!";
public final static String HTMLTEXT_FORM_TEST = "Hello
%s!";
public final static String PARAM_NAME = "name";
public static abstract class AbstractSampleResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.TEXT_PLAIN));
}
@Get("html")
public Representation toHtml() {
return new StringRepresentation(HTMLTEXT_TEST,
MediaType.TEXT_HTML);
}
@Get("txt")
public Representation toText() {
return new StringRepresentation(PLAINTEXT_TEST,
MediaType.TEXT_PLAIN);
}
}
public static class SampleResource1 extends AbstractSampleResource {
@Post
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class SampleResource2 extends AbstractSampleResource {
@Post("html")
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class SampleResource3 extends SampleResource2 {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(false);
}
}
public static class SampleApplication extends Application {
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
router.attach("sr1", SampleResource1.class);
router.attach("sr2", SampleResource2.class);
router.attach("sr3", SampleResource3.class);
return router;
}
}
int portnumber = 5;
Component component;
@Before
public void setUp() throws Exception {
Re: Strange problem with redirection
Thierry, yes, you are right. When using the Simple HTTP server with the Simple extension the issue does not appear. Thanks for the clarification! Cheers, Mathias --- math...@parboiled.org http://www.parboiled.org On 16.03.2010, at 12:43, Thierry Boileau wrote: > Hello Mathias, > > the issue is related to the behaviour of the internal server connector. From > what I've noticed, this should not happen with one of the other server > connectors (jetty, simple, etc.). > > Best regards, > Thierry Boileau > >> Thierry, >> >> ok, thanks for the bug confirmation. >> Concerning your suggested work around I'm not quite sure what you mean. >> Basically I would like to redirect an incoming HTTP request to a local file. >> How can I do that with a server connector? >> >> Cheers, >> Mathias >> >> --- >> >> math...@parboiled.org >> http://www.parboiled.org >> >> >> On 16.03.2010, at 12:00, Thierry Boileau wrote: >> >> >> >>> Hello Mathias, >>> >>> thanks for your report, I've added an issue for it: >>> http://restlet.tigris.org/issues/show_bug.cgi?id=1059 >>> . >>> As a workaround, you can use one of the provided server connectors: >>> http://wiki.restlet.org/docs_2.0/13-restlet/37-restlet.html >>> >>> >>> Best regards, >>> Thierry Boileau >>> >>> >>> Gentlemen, thanks a lot for the new release. I guess I missed the bug report/fix for this issue: "Allowed Redirector to plug to another protocol. Reported by Tal Liron." With RC1 the described error is gone, however the new behavior is still not as expected. Now my log looks like this: 09:42:33.208 [Restlet-23191477] INFO org.restlet.PricingEngineApplication - Redirecting via client dispatcher to: file://c/xyz/home.html 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - This client was selected: "[FILE]" 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New base URI: null 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New remaining part: file://c/xyz/home.html 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - Delegating the call to the target Restlet 09:42:33.224 [Restlet-23191477] INFO ACCESS - 2010-03-16 09:42:33 - - - 8182GET /xyz/home.html - 200 39640 16 http://coxxp:8182 - - ... which is ok up to this point. However my browser now displays context looking like this: FILE/1.1 200 The request has succeeded Date: Tue, 16 Mar 2010 08:51:00 GMT Accept-Ranges: bytes Server: Restlet-Framework/2.0rc1 Content-Language: de Content-Length: 3964 Content-Location: file://c/xyz/home.html Content-Type: text/html; charset=UTF-8 Expires: Tue, 16 Mar 2010 09:01:00 GMT Last-Modified: Tue, 16 Mar 2010 08:31:37 GMT ... And the response HTTP headers are completely missing. Looks like for some reason they are included in the content. Also there is now a connection problem since my browser stays in "Transferring from host..." mode, which can only be stopped by forcing the browser to stop loading the page upon which my log shows this exception: 09:53:35.803 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - Error while reading an HTTP message. Closing the connection: 09:53:35.818 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - Error while reading an HTTP message. Closing the connection. java.io.IOException: Unable to parse the request method. End of stream reached too early. at org.restlet.engine.http.connector.ServerConnection.readMessage(ServerConnection.java:164) [org.restlet.jar:na] at org.restlet.engine.http.connector.Connection.readMessages(Connection.java:665) [org.restlet.jar:na] at org.restlet.engine.http.connector.ControllerTask$2.run(ControllerTask.java:94) [org.restlet.jar:na] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_14] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_14] at java.lang.Thread.run(Thread.java:619) [na:1.6.0_14] Maybe I should note that I had the same setup running with 2.0M6 without any problems at all. Under 2.0M6 it works as expected. Could this be a regression? Another difference I note between M7/RC1 and M6 is that while I got a BindException when trying to start a Component with an HTTP Server on a port that is already used. Under M7/RC1 I do not get this exception any more, rather the second instance seems to take over the already used port.
Re: Android and WCF DataService
Hello Matthew, I think your problem is due to the internal connector which does not work with Android (see http://restlet.tigris.org/issues/show_bug.cgi?id=304). Can you try by adding the net extension (org.restlet.ext.net;jar) to the classpath of your project with the following lines, for example in the onCreate() method. Engine.getInstance().getRegisteredClients().clear(); // Add the "net" client connector Engine.getInstance().getRegisteredClients().add(new HttpClientHelper(new Client(Protocol.HTTP))); Note that this is a workaround since the connectors are nor properly discovered on the Android plate-form (http://restlet.tigris.org/issues/show_bug.cgi?id=941). Regarding the log, we will provide a "bridge" between the classic Logger and the android Log class. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460545
RE: Issues with WADL extension
The reason, why the output is empty, when requesting the HTML version of the WADL, seems to be the following: The stylesheet "/org/restlet/ext/wadl/htmlConvert.xsl", which converts the generated WADL, uses the WADL namespace "http://research.sun.com/wadl/2006/10";. But the generated WADL has the namespace "http://wadl.dev.java.net/2009/02"; (see WadlRepresentation.APP_NAMESPACE) So, one of these namespaces has to be changed to the other. cheers, Carsten -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460536
Infinite loop in EncodingReader.addValues()
Hi,
I get an infinite loop when calling EncodingReader.addValues() (in RC1):
new EncodingReader("gzip,deflate").addValues(new ArrayList());
Cheers,
Carsten
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460492
Android and WCF DataService
Gentlemen-
First-
Thanks for getting the RC code to us.
Second-
I seem to still be encountering the problem with the Android build consuming
WCF Dataservices. Code that worked before, has stopped working. I dont get
any logging information from RestLet...
Here is an example of the code-
Service myWCF = new
Service("http://digital-furnace.com/iMeta/webdataservice.svc/";);
Query myFolders =
myWCF.createQuery("/sysFolders",SysFolder.class);
if (myFolders!= null)
{
for (SysFolder folder : myFolders)
{
ret.append("Destination:
"+folder.getFolderName());
}
}
And all I get from the console is
[INFO][org.restlet] Get the metadata for
http://digital-furnace.com/OtherMeta/webdataservice.svc/ at
http://digital-furnace.com/OtherMeta/webdataservice.svc/$metadata
[INFO][org.restlet] Starting the HTTP client
This code worked before...and I know that the services return JSON data.
Any help would be great-
Matthew
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460489
Re: Strange problem with redirection
Hello Mathias, the issue is related to the behaviour of the internal server connector. From what I've noticed, this should not happen with one of the other server connectors (jetty, simple, etc.). Best regards, Thierry Boileau > Thierry, > > ok, thanks for the bug confirmation. > Concerning your suggested work around I'm not quite sure what you mean. > Basically I would like to redirect an incoming HTTP request to a local file. > How can I do that with a server connector? > > Cheers, > Mathias > > --- > math...@parboiled.org > http://www.parboiled.org > > On 16.03.2010, at 12:00, Thierry Boileau wrote: > > >> Hello Mathias, >> >> thanks for your report, I've added an issue for it: >> http://restlet.tigris.org/issues/show_bug.cgi?id=1059. >> As a workaround, you can use one of the provided server connectors: >> http://wiki.restlet.org/docs_2.0/13-restlet/37-restlet.html >> >> Best regards, >> Thierry Boileau >> >> >>> Gentlemen, >>> >>> thanks a lot for the new release. >>> I guess I missed the bug report/fix for this issue: >>> "Allowed Redirector to plug to another protocol. Reported by Tal Liron." >>> >>> With RC1 the described error is gone, however the new behavior is still not >>> as expected. >>> Now my log looks like this: >>> >>> 09:42:33.208 [Restlet-23191477] INFO org.restlet.PricingEngineApplication >>> - Redirecting via client dispatcher to: >>> file://c/xyz/home.html >>> >>> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - This client was >>> selected: "[FILE]" >>> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New base URI: >>> null >>> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New remaining >>> part: >>> file://c/xyz/home.html >>> >>> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - Delegating the >>> call to the target Restlet >>> 09:42:33.224 [Restlet-23191477] INFO ACCESS - 2010-03-16 09:42:33 >>> - - - 8182GET /xyz/home.html - 200 >>> 39640 16 >>> http://coxxp:8182 >>> - - >>> >>> ... which is ok up to this point. >>> However my browser now displays context looking like this: >>> >>> FILE/1.1 200 The request has succeeded >>> Date: Tue, 16 Mar 2010 08:51:00 GMT >>> Accept-Ranges: bytes >>> Server: Restlet-Framework/2.0rc1 >>> Content-Language: de >>> Content-Length: 3964 >>> Content-Location: >>> file://c/xyz/home.html >>> >>> Content-Type: text/html; charset=UTF-8 >>> Expires: Tue, 16 Mar 2010 09:01:00 GMT >>> Last-Modified: Tue, 16 Mar 2010 08:31:37 GMT >>> >>> >>> >>> ... >>> >>> >>> And the response HTTP headers are completely missing. Looks like for some >>> reason they are included in the content. >>> Also there is now a connection problem since my browser stays in >>> "Transferring from host..." mode, which can only be stopped by forcing the >>> browser to stop loading the page upon which my log shows this exception: >>> >>> 09:53:35.803 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - >>> Error while reading an HTTP message. Closing the connection: >>> 09:53:35.818 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - >>> Error while reading an HTTP message. Closing the connection. >>> java.io.IOException: Unable to parse the request method. End of stream >>> reached too early. >>> at >>> org.restlet.engine.http.connector.ServerConnection.readMessage(ServerConnection.java:164) >>> [org.restlet.jar:na] >>> at >>> org.restlet.engine.http.connector.Connection.readMessages(Connection.java:665) >>> [org.restlet.jar:na] >>> at >>> org.restlet.engine.http.connector.ControllerTask$2.run(ControllerTask.java:94) >>> [org.restlet.jar:na] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >>> [na:1.6.0_14] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >>> [na:1.6.0_14] >>> at java.lang.Thread.run(Thread.java:619) [na:1.6.0_14] >>> >>> >>> Maybe I should note that I had the same setup running with 2.0M6 without >>> any problems at all. Under 2.0M6 it works as expected. >>> Could this be a regression? >>> >>> Another difference I note between M7/RC1 and M6 is that while I got a >>> BindException when trying to start a Component with an HTTP Server on a >>> port that is already used. Under M7/RC1 I do not get this exception any >>> more, rather the second instance seems to take over the already used port. >>> Is that intended? Is there another nice way for me to now find out whether >>> there is already something else listening on the given port? >>> >>> Cheers, >>> Mathias >>> >>> -- >>> >>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460395 >>> >>> >>> >>> >>> > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460474 > > -
Re: Strange problem with redirection
Thierry, ok, thanks for the bug confirmation. Concerning your suggested work around I'm not quite sure what you mean. Basically I would like to redirect an incoming HTTP request to a local file. How can I do that with a server connector? Cheers, Mathias --- math...@parboiled.org http://www.parboiled.org On 16.03.2010, at 12:00, Thierry Boileau wrote: > Hello Mathias, > > thanks for your report, I've added an issue for it: > http://restlet.tigris.org/issues/show_bug.cgi?id=1059. > As a workaround, you can use one of the provided server connectors: > http://wiki.restlet.org/docs_2.0/13-restlet/37-restlet.html > > Best regards, > Thierry Boileau > >> Gentlemen, >> >> thanks a lot for the new release. >> I guess I missed the bug report/fix for this issue: >> "Allowed Redirector to plug to another protocol. Reported by Tal Liron." >> >> With RC1 the described error is gone, however the new behavior is still not >> as expected. >> Now my log looks like this: >> >> 09:42:33.208 [Restlet-23191477] INFO org.restlet.PricingEngineApplication - >> Redirecting via client dispatcher to: >> file://c/xyz/home.html >> >> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - This client was >> selected: "[FILE]" >> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New base URI: null >> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New remaining >> part: >> file://c/xyz/home.html >> >> 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - Delegating the >> call to the target Restlet >> 09:42:33.224 [Restlet-23191477] INFO ACCESS - 2010-03-1609:42:33 >> - - - 8182GET /xyz/home.html - 200 3964 >>0 16 >> http://coxxp:8182 >> - - >> >> ... which is ok up to this point. >> However my browser now displays context looking like this: >> >> FILE/1.1 200 The request has succeeded >> Date: Tue, 16 Mar 2010 08:51:00 GMT >> Accept-Ranges: bytes >> Server: Restlet-Framework/2.0rc1 >> Content-Language: de >> Content-Length: 3964 >> Content-Location: >> file://c/xyz/home.html >> >> Content-Type: text/html; charset=UTF-8 >> Expires: Tue, 16 Mar 2010 09:01:00 GMT >> Last-Modified: Tue, 16 Mar 2010 08:31:37 GMT >> >> >> >> ... >> >> >> And the response HTTP headers are completely missing. Looks like for some >> reason they are included in the content. >> Also there is now a connection problem since my browser stays in >> "Transferring from host..." mode, which can only be stopped by forcing the >> browser to stop loading the page upon which my log shows this exception: >> >> 09:53:35.803 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - >> Error while reading an HTTP message. Closing the connection: >> 09:53:35.818 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - >> Error while reading an HTTP message. Closing the connection. >> java.io.IOException: Unable to parse the request method. End of stream >> reached too early. >> at >> org.restlet.engine.http.connector.ServerConnection.readMessage(ServerConnection.java:164) >> [org.restlet.jar:na] >> at >> org.restlet.engine.http.connector.Connection.readMessages(Connection.java:665) >> [org.restlet.jar:na] >> at >> org.restlet.engine.http.connector.ControllerTask$2.run(ControllerTask.java:94) >> [org.restlet.jar:na] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> [na:1.6.0_14] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> [na:1.6.0_14] >> at java.lang.Thread.run(Thread.java:619) [na:1.6.0_14] >> >> >> Maybe I should note that I had the same setup running with 2.0M6 without any >> problems at all. Under 2.0M6 it works as expected. >> Could this be a regression? >> >> Another difference I note between M7/RC1 and M6 is that while I got a >> BindException when trying to start a Component with an HTTP Server on a port >> that is already used. Under M7/RC1 I do not get this exception any more, >> rather the second instance seems to take over the already used port. Is that >> intended? Is there another nice way for me to now find out whether there is >> already something else listening on the given port? >> >> Cheers, >> Mathias >> >> -- >> >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460395 >> >> >> >> -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460474
RE: MetaDataService: Freemarker Template Extension wrong?
Hi, good point. As a workaround (for the moment), you can call the method MetadataService#addExtension(String, Metadata, boolean). Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460469
MetaDataService: Freemarker Template Extension wrong?
Gentlemen, I noticed the default extension of the MetadataService include an extension for Freemarker Templates (line 237 in MetadataService.java), however the extension registered is "fmt" and not "ftl". Isn't "ftl" the standard extension for Freemarker Templates? My IDE doesn't know anything related to Freemarker that ends with "fmt". Just wondering... Cheers, Mathias --- math...@parboiled.org http://www.parboiled.org -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460450
Issues with WADL extension
Hi, first of all, congratulations to the RC1 release and thanks for making Restlet such a pleasure to work with! I just migrated from M7 to RC1 and have issues with the WADL features: I get a NPE when making an OPTIONS request to retrieve the WADL. The problem basically seems to be, that WadlRepresentation.getSaxSource() returns null in my case. Here's how it looks like to me: TransformRepresentation.toSaxSource() calls wadlRepresentation.getSaxSource() and this returns null. In M7, SaxRepresentation.getSaxSource() still returned "new SAXSource(new InputSource(getReader()));" when the 'source' field was not set, but now the null check is not there anymore. And only one WadlRepresentation constructor does set the 'source' field (the constructor with the xmlRepresentation param). I use the constructor with the ApplicationInfo param and so wadlRepresentation.getSaxSource() returns null. As a workaround, I tried setting the sax source manually: wadlRepresentation.setSaxSource(new SAXSource(new InputSource(wadlRepresentation.getStream(; With this, I don't get the NPE anymore. But I still don't get the WADL, the response from the request is empty. Cheers, Carsten -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460459
Re: Strange problem with redirection
Hello Mathias, thanks for your report, I've added an issue for it: http://restlet.tigris.org/issues/show_bug.cgi?id=1059. As a workaround, you can use one of the provided server connectors: http://wiki.restlet.org/docs_2.0/13-restlet/37-restlet.html Best regards, Thierry Boileau > Gentlemen, > > thanks a lot for the new release. > I guess I missed the bug report/fix for this issue: > "Allowed Redirector to plug to another protocol. Reported by Tal Liron." > > With RC1 the described error is gone, however the new behavior is still not > as expected. > Now my log looks like this: > > 09:42:33.208 [Restlet-23191477] INFO org.restlet.PricingEngineApplication - > Redirecting via client dispatcher to: file://c/xyz/home.html > 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - This client was > selected: "[FILE]" > 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New base URI: null > 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New remaining > part: file://c/xyz/home.html > 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - Delegating the > call to the target Restlet > 09:42:33.224 [Restlet-23191477] INFO ACCESS - 2010-03-16 09:42:33 > - - - 8182GET /xyz/home.html - 200 3964 > 0 16 http://coxxp:8182 - - > > ... which is ok up to this point. > However my browser now displays context looking like this: > > FILE/1.1 200 The request has succeeded > Date: Tue, 16 Mar 2010 08:51:00 GMT > Accept-Ranges: bytes > Server: Restlet-Framework/2.0rc1 > Content-Language: de > Content-Length: 3964 > Content-Location: file://c/xyz/home.html > Content-Type: text/html; charset=UTF-8 > Expires: Tue, 16 Mar 2010 09:01:00 GMT > Last-Modified: Tue, 16 Mar 2010 08:31:37 GMT > > > > ... > > > And the response HTTP headers are completely missing. Looks like for some > reason they are included in the content. > Also there is now a connection problem since my browser stays in > "Transferring from host..." mode, which can only be stopped by forcing the > browser to stop loading the page upon which my log shows this exception: > > 09:53:35.803 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - > Error while reading an HTTP message. Closing the connection: > 09:53:35.818 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - > Error while reading an HTTP message. Closing the connection. > java.io.IOException: Unable to parse the request method. End of stream > reached too early. > at > org.restlet.engine.http.connector.ServerConnection.readMessage(ServerConnection.java:164) > [org.restlet.jar:na] > at > org.restlet.engine.http.connector.Connection.readMessages(Connection.java:665) > [org.restlet.jar:na] > at > org.restlet.engine.http.connector.ControllerTask$2.run(ControllerTask.java:94) > [org.restlet.jar:na] > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > [na:1.6.0_14] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > [na:1.6.0_14] > at java.lang.Thread.run(Thread.java:619) [na:1.6.0_14] > > > Maybe I should note that I had the same setup running with 2.0M6 without any > problems at all. Under 2.0M6 it works as expected. > Could this be a regression? > > Another difference I note between M7/RC1 and M6 is that while I got a > BindException when trying to start a Component with an HTTP Server on a port > that is already used. Under M7/RC1 I do not get this exception any more, > rather the second instance seems to take over the already used port. Is that > intended? Is there another nice way for me to now find out whether there is > already something else listening on the given port? > > Cheers, > Mathias > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460395 > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460455
Re: Content type negotiation with annotations
Hello Bruno,
what release of Restlet are you using? I think the 405 status has been
fixed recently.
Best regards,
Thierry Boileau
> Hi,
>
>
> Firstly, I'd like to write a ServerResource that uses @Get("xml") and
> @Get("html") for content negotiation on GET but not on POST (where it
> would return a different content-type depending on what the method does,
> or do the negotiation internally).
> Secondly, I'd like to be able to post some
> "application/x-www-form-urlencoded" content and get another type in return.
>
>
> public class MyResource extends
> ServerResource {
> @Override
> protected void doInit() throws ResourceException {
> super.doInit();
> setNegotiated(true);
> getVariants().add(new Variant(MediaType.TEXT_HTML));
> getVariants().add(new Variant(MediaType.APPLICATION_XHTML));
> getVariants().add(new Variant(MediaType.APPLICATION_RDF_XML));
> }
>
> @Get("html")
> public Representation toHtml() throws ResourceException {
> ...
> }
>
> @Get("xml")
> public Representation toXml() throws ResourceException {
> ...
> }
>
> @Post
> public Representation accept(Representation entity) throws
> ResourceException {
> ...
> }
> }
>
>
> At the moment, if I turn off the content-type negotiation
> (setNegotiated(false)), then 'accept' is being called up receiving a
> POST request. If content-negotiation is on (setNegotiated(true)), I get
> a 405 (method not allowed) error.
> It looks like this is due to the logic in doNegotiatedHandle(), which
> I'd rather not override.
>
>
> I'm not entirely sure it's because of the content-type negotiation on
> the returned type, but it might be due to the input type too. (Hence the
> second part of this problem.)
>
> I've tried this @Post("html"), @Post("xml") and @Post("html|xml"), but
> they're never called anyway, so it doesn't seem to have much to do with
> the negotiated return type (the browser accepts "*/*" by the way).
>
> What's posted is of type "application/x-www-form-urlencoded". It looks
> like the @Post annotation make the negotiation on the input type too.
> If I tweak client to send the same content as "text/html", the
> @Post("html") is called. This seems a bit wrong (posting
> x-www-form-urlencoded forms and getting HTML in return seems quite
> common, and that doesn't seem feasible if content-type negotiation is on).
> Did I miss something? Any workarounds?
>
>
> Best wishes,
>
> Bruno.
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460162
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460434
RE: Strange problem with redirection
Gentlemen, thanks a lot for the new release. I guess I missed the bug report/fix for this issue: "Allowed Redirector to plug to another protocol. Reported by Tal Liron." With RC1 the described error is gone, however the new behavior is still not as expected. Now my log looks like this: 09:42:33.208 [Restlet-23191477] INFO org.restlet.PricingEngineApplication - Redirecting via client dispatcher to: file://c/xyz/home.html 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - This client was selected: "[FILE]" 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New base URI: null 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - New remaining part: file://c/xyz/home.html 09:42:33.208 [Restlet-23191477] DEBUG o.r.P.ClientRouter - Delegating the call to the target Restlet 09:42:33.224 [Restlet-23191477] INFO ACCESS - 2010-03-16 09:42:33 - - - 8182GET /xyz/home.html - 200 3964 0 16 http://coxxp:8182 - - ... which is ok up to this point. However my browser now displays context looking like this: FILE/1.1 200 The request has succeeded Date: Tue, 16 Mar 2010 08:51:00 GMT Accept-Ranges: bytes Server: Restlet-Framework/2.0rc1 Content-Language: de Content-Length: 3964 Content-Location: file://c/xyz/home.html Content-Type: text/html; charset=UTF-8 Expires: Tue, 16 Mar 2010 09:01:00 GMT Last-Modified: Tue, 16 Mar 2010 08:31:37 GMT ... And the response HTTP headers are completely missing. Looks like for some reason they are included in the content. Also there is now a connection problem since my browser stays in "Transferring from host..." mode, which can only be stopped by forcing the browser to stop loading the page upon which my log shows this exception: 09:53:35.803 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - Error while reading an HTTP message. Closing the connection: 09:53:35.818 [Restlet-23191477] DEBUG o.r.PricingEngineComponent.Server - Error while reading an HTTP message. Closing the connection. java.io.IOException: Unable to parse the request method. End of stream reached too early. at org.restlet.engine.http.connector.ServerConnection.readMessage(ServerConnection.java:164) [org.restlet.jar:na] at org.restlet.engine.http.connector.Connection.readMessages(Connection.java:665) [org.restlet.jar:na] at org.restlet.engine.http.connector.ControllerTask$2.run(ControllerTask.java:94) [org.restlet.jar:na] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_14] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_14] at java.lang.Thread.run(Thread.java:619) [na:1.6.0_14] Maybe I should note that I had the same setup running with 2.0M6 without any problems at all. Under 2.0M6 it works as expected. Could this be a regression? Another difference I note between M7/RC1 and M6 is that while I got a BindException when trying to start a Component with an HTTP Server on a port that is already used. Under M7/RC1 I do not get this exception any more, rather the second instance seems to take over the already used port. Is that intended? Is there another nice way for me to now find out whether there is already something else listening on the given port? Cheers, Mathias -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460395
RE: Strange problem with redirection
To make it easier to test the described problem I tried to recreate it with a
very simple test application.
The following Component also doesn't redirect to the given file as expected.
Am I missing something?
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.Protocol;
import org.restlet.routing.Redirector;
public class RestletTest extends Component {
public static void main(String[] args) throws Exception {
new RestletTest().start();
}
public RestletTest() {
getServers().add(Protocol.HTTP, 8182);
getClients().add(Protocol.FILE);
getDefaultHost().attachDefault(new
Application(getContext().createChildContext()) {
@Override
public Restlet createInboundRoot() {
return new Redirector(getContext(), "file://c/xyz/home.html");
}
});
}
}
Cheers,
Mathias
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460414
Re: A POST request with query parameters?
Hello,
the Form class has several constructors that will help you, especially
the one with a Representation and the one with a String.
>but wondering if there is a better way to be getting these key/value pairs, as
>in the original GET example?
You can use the following kinds of "@Post" methods to retrieve the
entity as a form:
@Post
public String accept(String value) {
Form form = new form(value);
[...]
}
or
@Post
public String accept(Representation rep) {
Form form = new form(rep);
[...]
}
or even simpler, because the default representation converter is able to
detect encoded web forms
@Post
public String accept(Form form) {
[...]
}
I must add that there is a distinction between the query part of the
resource's reference and the entity of a request. The former is part of
the resource's identifier, and should not be seen only as a convenient
way to convey data to the target resource.
Best regards,
Thierry Boileau
> Hi,
>
> I just was shown how to get the parameters of a GET request using the
> following:
>
>Form queryParams = getReference().getQuâEUR
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460390
Re: Restlet Framework 2.0 RC1 released
On 2010-03-15 23.48, Jerome Louvel wrote: > Hi all, > > The first 2.0 release candidate is finally ready. Please help us with > bugs reports, patches and wiki contributions, to ship a rock solid 2.0.0 > version! > http://blog.noelios.com/2010/03/15/restlet-framework-2-0-rc1-released/ Excellent work! Ever since I got into using Restlet, it just feels a whole lot better than servlets. Things just "fit". I'm working on a new web framework on top of Restlet, and it allows me to focus on the architectural parts rather than the web details, which is so nice! Keep it up! cheers, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460382
XStream Annotations
When using the xstream extension with restlet, the xstream annotations which are linked-to in the wiki page http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/264-restlet.html are not acknowledged. After drilling into the code, we noticed that the auto detection of annotations is not enabled or configurable with restlet. I feel that it should be configurable or be enabled by default, and it's as simple as: XStream stream = new Xstream(); stream.autodetectAnnotations(true); ... Am I missing something here? How can I get this working without creating my own ConverterHelper and overriding Xstream extension classes. Thanks, Dan -- View this message in context: http://n2.nabble.com/XStream-Annotations-tp4740207p4740207.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460188
RE: Re: A GET with query parameters?
Ok thanks, yeah was missing that you could do that at all, works well now. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460202
A POST request with query parameters?
Hi,
I just was shown how to get the parameters of a GET request using the following:
Form queryParams = getReference().getQueryAsForm();
String size = queryParams.getFirstValue("size");
this works perfectly. I'm constructing a POST on a java client like this:
HttpPost httppost = new HttpPost(url);
List nameValuePairs = new ArrayList(2);
nameValuePairs.add(new BasicNameValuePair(
"param1", "abc"));
nameValuePairs.add(new BasicNameValuePair(
"param2", "123"));
httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
HttpResponse response = httpclient.execute(httppost);
in my servlet, I'm trying this:
@Post
public String acceptRepresentation(String value) {
Form form = getRequest().getResourceRef().getQueryAsForm();
}
The Form object reports that there are no key/value pairs, it's empty. But the
'value' parameter passed into acceptRepresentation() contains my entire query
string like:
param1=abc¶m2=123
that works fine for me, but wondering if there is a better way to be getting
these key/value pairs, as in the original GET example?
Thank you
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460268
Re: Restlet Framework 2.0 RC1 released
felicitations to both of you! Envoyé de mon iPhone Le 15 mars 2010 à 23:48, Jerome Louvel a écrit : > Hi all, > > The first 2.0 release candidate is finally ready. Please help us > with bugs reports, patches and wiki contributions, to ship a rock > solid 2.0.0 version! > http://blog.noelios.com/2010/03/15/restlet-framework-2-0-rc1-released/ > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Technical Lead ~ http://www.restlet.org > Noelios Technologies ~ http://www.noelios.com > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2460331
