Re: RFC - Restlet edition for JavaScript
This sounds like an interesting project. Currently the Ajax support in the JavaScript libraries lack a full-fledged REST model/support; although they are very simple to use in the basic use-cases. I work with YUI 3 and we use Restlet in our server-side stack. YUI 3 has a Y.io static class/object to make Ajax requests; the features of this utility module weren't up to par with what I wanted, and I wanted to make complex client-server interactions easier for me. I decided to wrap Y.io with my REST Resource class, Y.Resource, to make a more RESTful client API for me to communicate with the server. REST Resource YUI 3 Module: http://yuilibrary.com/gallery/show/resource Code on GitHub: http://github.com/ericf/yui3-gallery/blob/master/src/gallery-resource/js/resource.js This is definitely not anything close to a full-fledged Restlet JavaScript client, but the features I added to YUI 3's Ajax support were inspired by Restlet. Eric On Jul 8, 2010, at 9:30 AM, Jerome Louvel wrote: Hi all, Following a recent customer project experience involving GXT + GWT + Restlet/GWT + Restlet/JEE and discussions about the interest of scripting languages as opposed to a statically type language with Jean-Paul Figer [1], I reconsidered an idea initially suggested by Yuri de Wit [2] to add a pure JavaScript edition of Restlet. Due to the emergence of HTML 5 on all sorts of browser platforms (mobile), the improvement of JavaScript engines such as Chrome V8 and the overall convergence with REST and Restlet/Java on the server-side, it seems like a good time to push for a more RESTful JavaScript client API, reusing the Restlet API semantics in pure JavaScript. Eclipse 3.6 also improved its support for JavaScript developments Of course, we already have the GWT edition of Restlet which provides a nice solution, but there seems to be room for a more hypermedia driven/document oriented solution, combining AJAX and UI libraries such as jQuery, Ext JS, YUI to name a few popular ones. I’ve collected my thoughts on this wiki page and look forward to reading your ideas and experiences. “JavaScript edition” http://wiki.restlet.org/developers/172-restlet/368-restlet.html Best regards, Jerome Louvel [1] REST paper in French: http://www.figer.com/publications/REST.htm [2] “Add JavaScript client”: http://restlet.tigris.org/issues/show_bug.cgi?id=129 [3] AJAX Tools Framework: http://www.eclipse.org/atf/ -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632421
Re: Internal Connector Error (problem with gwt restlet client)
Hello Sjoerd,
this should not happen with the latest snapshot. Could you check the sample
project attached to this issue, for example?
http://restlet.tigris.org/issues/show_bug.cgi?id=1144
Best regards,
Thierry Boileau
Hi,
I've created a simple gwt-restlet testproject.
Snippet from the server which runs on localhost port 28080
@Override
public Restlet createInboundRoot() {
Router router = new Router(getContext());
router.attach(/crm/organisaties/kristalsoftware,
OrganisatieServerResource.class);
return router;
}
When I type http://localhost:28080/crm/organisaties/kristalsoftware in
Firefox, then I see the expected result.
GET /crm/organisaties/kristalsoftware HTTP/1.1
Host: localhost:28080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Fri, 02 Jul 2010 12:38:29 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0rc4
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/x-java-serialized-object+gwt; charset=UTF-8
--
The serverlog shows also the expected lines:
Jul 2, 2010 2:37:53 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-07-02 14:37:53 0:0:0:0:0:0:0:1%0 - - 28080 GET
/crm/organisaties/kristalsoftware - 200 - 0 459 http://localhost:28080
Mozilla/5.0
(Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100315
Firefox/3.5.9 -
But when I make the call from within the gwt client, then the client throws
an exception and I see no GET but an OPTIONS method which is not supported
by my serverimplementation.
Jul 2, 2010 1:47:48 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-07-02 13:47:48 0:0:0:0:0:0:0:1%0 - - 28080 OPTIONS
/crm/organisaties/kristalsoftware - 405 323 0 62 http://localhost:28080
Mozilla/5.0
(Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100315
Firefox/3.5.9 -
My question is: Where does that OPTIONS method comes from ?
snippet from my client
package nl.kristalsoftware.crudrest.client;
import org.restlet.client.resource.ClientProxy;
import org.restlet.client.resource.Delete;
import org.restlet.client.resource.Get;
import org.restlet.client.resource.Put;
import org.restlet.client.resource.Result;
public interface OrganisatieResourceProxy extends ClientProxy {
@Get
public void retreive(ResultOrganisatieData callback);
@Put
public void store(OrganisatieData data, ResultOrganisatieData callback);
@Delete
public void remove(ResultOrganisatieData callback);
}
organisatieResource.getClientResource().setReference(
http://localhost:28080/crm/organisaties/kristalsoftware;);
organisatieResource
.getClientResource().getClientInfo().getAcceptedMediaTypes().add(new
PreferenceMediaType(MediaType.APPLICATION_JAVA_OBJECT_GWT));
organisatieResource.retreive(new ResultOrganisatieData() {
...
}
The Exception:
Internal Connector Error (1002) - (NS_ERROR_NOT_AVAILABLE): Component
returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE)
[nsIXMLHttpRequest.statusText]
QueryInterface: function QueryInterface() {
[native code]
}
result: 2147746065
filename: http://127.0.0.1:
lineNumber: 30
columnNumber: 0
inner: null
data: null
initialize: function initialize() {
[native code]
}
at
nl.kristalsoftware.crudrest.client.OrganisatieResourceProxyProxy$3.handle(
OrganisatieResourceProxyProxy.java:87)
at org.restlet.client.engine.http.adapter.ClientAdapter$1.handle(
ClientAdapter.java:102)
at org.restlet.client.engine.http.GwtClientCall$2.onResponseReceived(
GwtClientCall.java:245)
at com.google.gwt.http.client.Request.fireOnResponseReceived(
Request.java:287)
at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(
RequestBuilder.java:393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at com.google.gwt.dev.shell.OophmSessionHandler.invoke(
OophmSessionHandler.java:157)
at
com.google.gwt.dev.shell.BrowserChannel.reactToMessagesWhileWaitingForReturn(
BrowserChannel.java:1713)
at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(
BrowserChannelServer.java:165)
at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(
ModuleSpaceOOPHM.java:120)
at
Re: XML tag in xstream json output?
Hello Patrik,
thanks for your report, the fix is available in the svn repository.
Best regards,
Thierry Boileau
I'm using Restlet 2.0-RC4 with Xstream extension to marshall objects to xml
and json. My problem is that the json output contains xml tag as the first
row
?xml version=1.0 encoding=UTF-8 ?
{Shipment:{shipmentId:121SE ...
My resource looks like this:
public class ShipmentResource extends ServerResource {
@Get
public ShipmentDto getShipment() {
I have found that the problem is in write method of XstreamRepresentation.
It does:
writer.append(?xml version=\1.0\ encoding=\
+ charSet.getName() + \ ?\n);
Is this a bug, or am I using it incorrectly?
/Patrik
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2629525
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2631809
Re: ClientResource leaves an inactive thread
Hello Nina,
the internal connectors have been updated recently, and some adjustements
make your code running fine with the current snapshot.
Sorry for the delay of this answer.
Best regards,
Thierry Boileau
Hello All,
I am experiencing memory/thread leak ,with Restlet-2.0-RC4 and
Restlet-2.0-SNAPSHOT , when using ClientResource. Basically, ClientResource
doesn't close the thread it spawns and this result in number of inactive
threads and severe memory leak.
Here is some very simple code to illustrate this behaviour. The same code
runs fine in Restlet-2.0-M6 (which doesn't span new thread in
ClientResource).
public void run(int instances) throws Exception {
for (int i=0; i instances;i++) {
ClientResource clientResource = null;
Representation r = null;
try {
clientResource = new ClientResource(http://restlet.org;);
r = clientResource.get();
} finally {
try { r.release(); } catch (Exception x) {}
try { clientResource.release(); } catch (Exception x) {}
}
}
}
public static void main(String[] args) throws Exception {
ThreadTest test = new ThreadTest();
test.run(1000);
}
I guess there might be something missing in the code to explicitly close
threads, but since the same code runs fine in M6, it is quite confusing to
experience leaks after upgrade.
Best regards,
Nina Jeliazkova
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2624682
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632010
Re: Status of Asynchronous Support
Jerome, even though setCommitted(false) gets called, there still the usual processing of handle() in the entire restlet chain (the Finder, delegating to the UniformResource, etc.). Within these routines, the return values from various callbacks are handled. Stuff that happens there on the response can override work being done in another thread. The response is thread safe, but it's still not the intended result. I don't have a test case right now, but it would be easy to produce: simply call setCommitted(false) in a ServerResource annotated @Get implementation, and immediately move processing to a thread, where commit() is eventually called. The worker handler thread would overlap with the work done in the regular Restlet handling thread and you would get weird statuses and response entities. The reason I suggest an exception (and I share Tim's unease with it) is that it's a way to stop the handling chain in the regular thread, so that only the new handler thread would have free reign on the response. But it doesn't have to be an exception. Another solution would be for ServerResource, UniformResource and Finder to be refactored specifically to handle the committed=false case. I worry, though, that future work or custom implementations would not handle the case properly. -Tal On Sun, Jul 11, 2010 at 9:00 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Tal and Tim, There is a way to signal an asynchronous response on a per-call basis, calling Response#setCommitted(false). Then, if you call Response#commit() before the initial request thread reaches back the connector, this should work fine as well. I’m not sure yet how it could get ‘corrupted’. Do you have a precise scenario? Note that the NIO version of the asynchronous internal connector has been moved to version 2.1. This feature should indeed be considered as preview feature for 2.0. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com *De :* tpeie...@gmail.com [mailto:tpeie...@gmail.com] *De la part de* Tim Peierls *Envoyé :* vendredi 18 juin 2010 13:51 *À :* discuss@restlet.tigris.org *Objet :* Re: Status of Asynchronous Support I never saw a response to this, but it does seem like a problem. I don't love the idea of a special exception used purely to handle control flow, but I can't think of anything better off-hand. --tim On Sat, May 22, 2010 at 8:05 PM, Tal Liron tal.li...@threecrickets.com wrote: Hi Jerome, 2. There is a TaskService associated to your application that you could leverage. It separates threads usage from tasks to process (such as committing responses). I've tried this, but there is a concurrency problem with this pattern in ServerResource -- If I set autoCommiting to false during a ServerResource.get() and put my task on a separate thread pool, then my own task might try to update the response at the same time as the upper parts of the call stack (Finder.handle(), for example) also try to update the response according to my return value from get(). Both threads might be doing it at the same time, and the response ends up corrupted (no concurrency exceptions, but it's mismatched status/entity, for example). What would be the correct way to defer a response from within a ServerResource? My thought is that there should be a way to return from get() while signaling to the rest of the call stack that I am handling the response. A null won't work, because it internally signifies an unavailable entity. Perhaps a new kind of ResourceException? DefferedResponseResourceException? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2612147 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632674
Re: RFC - Restlet edition for JavaScript
Great stuff, Eric. I will experiment with this. I would love for Prudence to have a matching client-side API. By the way, take a look at Ext-JS -- recent versions have really well thought-out RESTful widgets. You'll need to have your Restlet resources aware of the Ext-JS requirements, but this is so easy to do that I haven't even bothered with boilerplate code. -Tal On Mon, Jul 12, 2010 at 10:42 PM, Eric Ferraiuolo eferraiu...@gmail.comwrote: This sounds like an interesting project. Currently the Ajax support in the JavaScript libraries lack a full-fledged REST model/support; although they are very simple to use in the basic use-cases. I work with YUI 3 and we use Restlet in our server-side stack. YUI 3 has a Y.io static class/object to make Ajax requests; the features of this utility module weren't up to par with what I wanted, and I wanted to make complex client-server interactions easier for me. I decided to wrap Y.io with my REST Resource class, Y.Resource, to make a more RESTful client API for me to communicate with the server. REST Resource YUI 3 Module: http://yuilibrary.com/gallery/show/resource Code on GitHub: http://github.com/ericf/yui3-gallery/blob/master/src/gallery-resource/js/resource.js This is definitely not anything close to a full-fledged Restlet JavaScript client, but the features I added to YUI 3's Ajax support were inspired by Restlet. Eric On Jul 8, 2010, at 9:30 AM, Jerome Louvel wrote: Hi all, Following a recent customer project experience involving GXT + GWT + Restlet/GWT + Restlet/JEE and discussions about the interest of scripting languages as opposed to a statically type language with Jean-Paul Figer [1], I reconsidered an idea initially suggested by Yuri de Wit [2] to add a pure JavaScript edition of Restlet. Due to the emergence of HTML 5 on all sorts of browser platforms (mobile), the improvement of JavaScript engines such as Chrome V8 and the overall convergence with REST and Restlet/Java on the server-side, it seems like a good time to push for a more RESTful JavaScript client API, reusing the Restlet API semantics in pure JavaScript. Eclipse 3.6 also improved its support for JavaScript developments Of course, we already have the GWT edition of Restlet which provides a nice solution, but there seems to be room for a more hypermedia driven/document oriented solution, combining AJAX and UI libraries such as jQuery, Ext JS, YUI to name a few popular ones. I’ve collected my thoughts on this wiki page and look forward to reading your ideas and experiences. “JavaScript edition” http://wiki.restlet.org/developers/172-restlet/368-restlet.html Best regards, Jerome Louvel [1] REST paper in French: http://www.figer.com/publications/REST.htm [2] “Add JavaScript client”: http://restlet.tigris.org/issues/show_bug.cgi?id=129 [3] AJAX Tools Framework: http://www.eclipse.org/atf/ -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2632678
