Re: Unit test Resource
Hello,
if you have an instance of your techIssueResource, you can set up some
of its properties (preferences via the clientInfo member attribute,
credentials, etc.) and invoke its get method.
Otherwise, you can have a look at the org.restlet.test module. It
contains some tests cases, especially in the class
org.restlet.test.ext.spring.SpringBeanFinderTestCase, and more precisely
in the testReturnsServerResourceBeanWhenExists method.
Best regards,
Thierry Boileau
How can I unit test my Resource class alone?
I have public class ServiceResource extends Resource {
}
which is being injected using Spring IoC
bean id=techIssueRestResource name=techIssueResource
class=com.gs.webservice.rest.ServiceResource scope=prototype
I got this techIssueResource from spring context in my test case but not
sure how to test/call its represen(Variant) method? to complete my test?
Any pointers would be appreciated.
Thanks,
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457434
RE: rest practice : how do you join linked resources from 2 providers ?
Thank you both of you. For your information we evolved in our use case so in our design : we first make a selection (through a kind of search if required) of a given item on the first resource, and make a search on the second resource with the selected items as additional filtering criterias. To say it differently, with different providers, we cascade the queries. We achieve 'jointures' only 'inside' one given resource provider. It does change the use case, definitely; but in our case it's satisfying to acheive the overall business process. Concerning web join on large resources, perhaps we can imagine a query system coupled to an indexing system, similarly to current web search engines: aka building asynchronously a local extract of remote ressource providers and making the join query using local data indexes instead of on-the-fly web resources ? For discussion only... -- View this message in context: http://n2.nabble.com/rest-practice-how-do-you-join-linked-resources-from-2-providers-tp4651158p4708078.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457509
Reliabily decoding different clients resource reference (different) URIs
Hello there, I'm having some problems (Restlet 2.0snapshot from mid-February 2010) with resource references encoding. Concretely, my app supports DAV access to some resources, I'm currently testing with XXE (an XML editor with a dav plugin) and with Microsoft XP's 'web folders' (dav-enabled folders, surprisingly not available in Windows Vista and Windows 7... but that's another story). The resource is named /workspaces/W1/content/Sin título.xml. Notice the space and the i acute, FYI Sin título is Spanish for Untitled, and it's the default name XXE gives to untitled files (I'm sure other editing tools do the same, I'm not blaming the IMVHO excellent XXE here at all). Now, here's what the URI looks like in a GET request (to open the file): Mar 10, 2010 11:33:07 AM com.calenco.resource.workspace.AbstractContentResource init INFO: langOrFile (before): Sin%20t%C3%83%C2%ADtulo.xml Mar 10, 2010 11:33:07 AM com.calenco.resource.workspace.AbstractContentResource init INFO: langOrFile (after) : Sin tÃtulo.xml Mar 10, 2010 11:33:07 AM org.restlet.engine.log.LogFilter afterHandle INFO: 2010-03-1011:33:07127.0.0.1 admi...@calenco.com - 9000GET /workspaces/W1/content/Sin%20t%C3%83%C2%ADtulo.xml - 404 353 0 29 http://localhost:9000 Java/1.6.0_15 - The langOrFile 'variable' is the one the router matched for the URI in question and correctly dispatched to the resource handler, I've printed it for debugging this annoying behaviour (HTTP 404 because the file name is not properly decoded). The resource's code excerpt is: langOrFile = Reference.decode((String)getRequestAttributes().get(langOrFile)); // NOI18N The (before) line in the log above is of course before this call, the 'raw' request stuff; and (after) is just after running the Reference.decode(). Now, MS DAV client gives this trying to access the same file: Mar 10, 2010 11:37:52 AM com.calenco.resource.workspace.AbstractContentResource init INFO: langOrFile (before): Sin%20t%EDtulo.xml Mar 10, 2010 11:37:52 AM com.calenco.resource.workspace.AbstractContentResource init INFO: langOrFile (after) : Sin t�tulo.xml Mar 10, 2010 11:37:52 AM org.restlet.engine.log.LogFilter afterHandle INFO: 2010-03-1011:37:52192.168.1.10admi...@calenco.com - 9000GET /workspaces/W1/content/Sin%20t%EDtulo.xml - 404 352 0 9 http://192.168.1.10:9000 Microsoft Data Access Internet Publishing Provider DAV 1.1- You can clearly see that both clients are encoding the resource reference in a different way, though they both pretend to access the same resource. Is there a reliable way to pass parameters to Reference.decode() so both requests URI get the same 'Sin título.xml' decoded string? I've tried passing CharSet.DEFAULT and CharSet.UTF-8, but both throw null pointer exceptions. Thanks in advance for your help. -- Fabián Mandelbaum IS Engineer -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457619
Re: Reliabily decoding different clients resource reference (different) URIs
Hello Fabian,
can you tell us what kind of client generates the request?
On my side, I've tested with Firefox and created a file having the same
name as yours.
I've tried to access it via a Directory and a Restlet instance that
decodes the langOrFile attribute (according to the defined route). It
just works.
I may add that you can ask the router to put the decoded value inside
the request's attributes :
TemplateRoute route =
component.getDefaultHost().attach(/test/{langOrFile}, restlet);
Variable var = new Variable();
var.setDecodingOnParse(true);
route.getTemplate().getVariables().put(langOrFile, var);
Best regards,
Thierry Boileau
Hello there,
I'm having some problems (Restlet 2.0snapshot from mid-February 2010)
with resource references encoding. Concretely, my app supports DAV
access to some resources, I'm currently testing with XXE (an XML
editor with a dav plugin) and with Microsoft XP's 'web folders'
(dav-enabled folders, surprisingly not available in Windows Vista and
Windows 7... but that's another story).
The resource is named /workspaces/W1/content/Sin tÃtulo.xml. Notice
the space and the i acute, FYI Sin tÃtulo is Spanish for Untitled,
and it's the default name XXE gives to untitled files (I'm sure other
editing tools do the same, I'm not blaming the IMVHO excellent XXE
here at all). Now, here's what the URI looks like in a GET request (to
open the file):
Mar 10, 2010 11:33:07 AM
com.calenco.resource.workspace.AbstractContentResource init
INFO: langOrFile (before): Sin%20t%C3%83%C2%ADtulo.xml
Mar 10, 2010 11:33:07 AM
com.calenco.resource.workspace.AbstractContentResource init
INFO: langOrFile (after) : Sin tÃÂtulo.xml
Mar 10, 2010 11:33:07 AM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-03-10 11:33:07127.0.0.1 admi...@calenco.com
- 9000GET /workspaces/W1/content/Sin%20t%C3%83%C2%ADtulo.xml
- 404 353 0 29 http://localhost:9000
Java/1.6.0_15 -
The langOrFile 'variable' is the one the router matched for the URI in
question and correctly dispatched to the resource handler, I've
printed it for debugging this annoying behaviour (HTTP 404 because the
file name is not properly decoded). The resource's code excerpt is:
langOrFile =
Reference.decode((String)getRequestAttributes().get(langOrFile));
// NOI18N
The (before) line in the log above is of course before this call, the
'raw' request stuff; and (after) is just after running the
Reference.decode().
Now, MS DAV client gives this trying to access the same file:
Mar 10, 2010 11:37:52 AM
com.calenco.resource.workspace.AbstractContentResource init
INFO: langOrFile (before): Sin%20t%EDtulo.xml
Mar 10, 2010 11:37:52 AM
com.calenco.resource.workspace.AbstractContentResource init
INFO: langOrFile (after) : Sin t�tulo.xml
Mar 10, 2010 11:37:52 AM org.restlet.engine.log.LogFilter afterHandle
INFO: 2010-03-10 11:37:52192.168.1.10admi...@calenco.com
- 9000GET /workspaces/W1/content/Sin%20t%EDtulo.xml
- 404 352 0 9 http://192.168.1.10:9000
Microsoft Data Access
Internet Publishing Provider DAV 1.1 -
You can clearly see that both clients are encoding the resource
reference in a different way, though they both pretend to access the
same resource.
Is there a reliable way to pass parameters to Reference.decode() so
both requests URI get the same 'Sin tÃtulo.xml' decoded string? I've
tried passing CharSet.DEFAULT and CharSet.UTF-8, but both throw null
pointer exceptions.
Thanks in advance for your help.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457689
RE: Tomcat with Restlet behind Proxy: Communication Error (1001)
Hi, I have done so, and in the startup-arguments I have set to following: -DproxySet=true -DproxyHost=proxy.intern -DproxyPort=8080 -DproxyUsername=myUsername -DproxyPassword=mySecret -Dhttp.nonProxyHosts=localhost|127.0.0.1|192.168.100.210 Now the Redirector does try to access the resource via proxy, but I get 407 - Proxy Authentication Required. The -DproxyUser and -DproxyPassword seem not to work... do you know perhaps why? Thank you, ab jlouvel wrote: It is however possible to replace it with a client connector based on HttpURLConnection. This is the purpose of the org.restlet.ext.net extension. Just add its JAR in your classpath and try again :) -- View this message in context: http://n2.nabble.com/Tomcat-with-Restlet-behind-Proxy-Communication-Error-1001-tp2992998p4710456.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457709
Re: Bad Status(400) returned on Android Client by the store() resource method with GAE in HTTPS instead of HTTP
Hi Thierry, Thx a lot for your quick reply. Anyway, adding the code below in the OnCreate before all others RestLet invocations/instanciations does not resolve the issue, still having the error. so as said it works well with GAE in http but not in https :( just also apologize as it is Bad Request not Bad Status. just took a look in the debugger Did you try this example : http://wiki.restlet.org/docs_2.0/13-restlet/181-restlet/303- restlet.html?layoutType=plain by replacing http with https in the android client url to reproduce the issue. Maybe did I forgot a org.restlet.ext.? something in the server war libs ? or on the client which force the store() to fail with https but not with http ? Don't know if I am the only one having https (no authentification only, encryption) issues with restlet but maybe having the example above upgraded to 2.0 m7 also having a version with https instead of http could be interesting ? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457734
To be shorter in the issue faster in explanation, did you try the example in the url below ?
To sumarize to be faster on the issue: I was talking about this example in my previous post, so, did you try this example : http://wiki.restlet.org/docs_2.0/13-restlet/181-restlet/303-restlet.html but by accessing your GAE with https in the URL instead of http, it should failed like my development As said, tried with the last snapshot : same issue ! for sure after removing xstream extensions as imcompatible with GAE so by only using org.restlet defaults. As said, with the last snapshot without xstream, so with only org.restlet.jar org.restlet.ext.servlet.jar, it works well in http but not in https :( thx in advance for your clarification. really don't understand why the android client receives a bad status exception in https when sending a store() command to the Google AppEngine restlet servlet :( -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457617
Re: Bad Status(400) returned on Android Client by the store() resource method with GAE in HTTPS instead of HTTP
Hello Louis, yes it works for me, but I've updated the protocol of the client connector... Engine.getInstance().getRegisteredClients().add(new HttpClientHelper(new Client(Protocol.HTTPS))); Best regards, Thierry Boileau ps : there is an issue about the automatic discovering of connectors: http://restlet.tigris.org/issues/show_bug.cgi?id=941 Hi Thierry, Thx a lot for your quick reply. Anyway, adding the code below in the OnCreate before all others RestLet invocations/instanciations does not resolve the issue, still having the error. so as said it works well with GAE in http but not in https :( just also apologize as it is Bad Request not Bad Status. just took a look in the debugger Did you try this example : http://wiki.restlet.âEUR restlet.html?layoutTâEUR -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457755
RE: Re: Bad Status(400) returned on Android Client by the store() resource method with GAE in HTTPS instead of HTTP
Arg, I really dont' understand why... but still having the issue, continues to
work in html but not in https :(
Did you try on a deployed instance of your webserver on the GAE appspot server ?
the only jar used on my android client is org.restlet.jar
I also put in the onCreate of my activity this as you recommended :
getConnectorService().getClientProtocols().add(Protocol.FILE);
getConnectorService().getClientProtocols().add(Protocol.HTTP);
getConnectorService().getClientProtocols().add(Protocol.HTTPS);
On the server, as said, I use also only org.restlet.jar org.restlet.jar,
org.restlet.ext.servlet are put in the war
here is my servlet application instansciation below... I also attached the
web.xml in this post... as you will see my only differences are in the web.xml
the servlet routing...
all the other code is really similar to the example provided for android/gae
implementation.
I really would like in advance to thank each of you for providing an expert
look/eye.
Louis
Servlet routing:
package name.lecaroz.google.fleet.app.server.restlet;
import java.io.File;
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.LocalReference;
import org.restlet.data.Protocol;
import org.restlet.resource.Directory;
import org.restlet.routing.Router;
public class RestLetApplication extends Application {
/**
* When launched as a standalone application.
*
* @param args
* @throws Exception
*/
/*
public static void main(String[] args) throws Exception {
Component component = new Component();
component.getClients().add(Protocol.FILE);
component.getServers().add(Protocol.HTTP, 8081);
component.getDefaultHost().attach(new RestLetApplication());
component.start();
}
@Override
public Restlet createInboundRoot() {
Router router = new Router(getContext());
getConnectorService().getClientProtocols().add(Protocol.FILE);
// Serve the files generated by the GWT compilation step.
File warDir = new File();
if (!war.equals(warDir.getName())) {
warDir = new File(warDir, war/);
}
Directory dir = new Directory(getContext(), LocalReference
.createFileReference(warDir));
router.attachDefault(dir);
router.attach(/RestLet/ShipLocation,
ShipLocationServerResource.class);
return router;
}
*/ /**
* Creates a root Restlet that will receive all incoming calls.
*/
@Override
public synchronized Restlet createInboundRoot() {
getConnectorService().getClientProtocols().add(Protocol.FILE);
getConnectorService().getClientProtocols().add(Protocol.HTTP);
getConnectorService().getClientProtocols().add(Protocol.HTTPS);
// Create a router Restlet that routes each call to a
// new Resource
Router router = new Router(getContext());
router.attachDefault(ShipLocationServerResource.class);
return router;
}
}?xml version=1.0 encoding=UTF-8?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
context-param
param-nameorg.restlet.clients/param-name
param-valueCLAP FILE HTTP HTTPS/param-value
/context-param
!-- Servlets --
servlet
servlet-namegreetServlet/servlet-name
servlet-classname.lecaroz.google.fleet.app.server.GreetingServiceImpl/servlet-class
/servlet
servlet-mapping
servlet-namegreetServlet/servlet-name
url-pattern/googlefleet/greet/url-pattern
/servlet-mapping
!-- Default page to serve --
welcome-file-list
welcome-fileGoogleFleet.html/welcome-file
/welcome-file-list
servlet
servlet-namerestlet/servlet-name
servlet-classorg.restlet.ext.servlet.ServerServlet/servlet-class
init-param
param-nameorg.restlet.application/param-name
param-valuename.lecaroz.google.fleet.app.server.restlet.RestLetApplication/param-value
/init-param
/servlet
servlet-mapping
servlet-namerestlet/servlet-name
url-pattern/RestLet/*/url-pattern
/servlet-mapping
!--
security-constraint
web-resource-collection
url-pattern/RestLet/*/url-pattern
/web-resource-collection
auth-constraint
role-name*/role-name
/auth-constraint
/security-constraint
--
/web-app
RE: REQUEST FireFox cache control
Hi Jerome, We are planning to use RESTLET 2.0 as part of data services PoC. As Caching is one of the requirements, does RESTLET 2.0 support caching as indicated by you in this thread?. Also, any suggestions on integrating with EHCache as it is already used in our organization?. Any help would be highly appreciated. Thanks, Bala. Hi Rob, Finally I'm back in this list :-) So, you are totally right about the meaning of the transient property: nothing to do with caching. Thanks also for the nice write up about caching behaviors: I've added a link back to your post in issue #25. Caching support is definitely something high on Restlet 1.2 priority list, but I'm not too keen on changing the API in an incremental Restlet 1.1 release. I , will however make sure that Restlet 1.2 is released in time, adjusting the features scope if necessary. I'm hoping for a 1.2 M1 in January. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Rob Heittman [mailto:rob.heitt...@solertium.com] Envoye : mardi 9 decembre 2008 03:48 A : discuss@restlet.tigris.org Objet : Re: REQUEST FireFox cache control Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the transient property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes() This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/ (which is hopefully correct), FF will only respond as expected if you also set no-store. In otherwords, Cache-control: no-cache no-store. See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 no-cache will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use no-store if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using no-store for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use no-store on pages that absolutely must not be reloaded for any reason, but generally use no-cache for good performance combined with good liveness of content. - R -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457868
Re: Bad Status(400) returned on Android Client by the store() resource method with GAE in HTTPS instead of HTTP
Hello Louis,
could you try by adding a dependency to the net client connector (ie
add the org.restlet.ext.net.jar archive to the classpath of your android
project) and with the following code?
Engine.getInstance().getRegisteredClients().clear();
Engine.getInstance().getRegisteredClients().add(new HttpClientHelper(new
Client(Protocol.HTTPS)));
This code explicitely references the net client connector based on the
HttpUrlConnection class, instead of the internal client connector which
fails under Android, for the moment.
Best regards,
Thierry Boileau
Arg, I really dont' understand why... but still having the issue, continues
to work in html but not in https :(
Did you try on a deployed instance of your webserver on the GAE appspot
server ?
the only jar used on my android client is org.restlet.jar
I also put in the onCreate of my activity this as you recommended :
getConnectorService().getClientProtocols().add(Protocol.FILE);
getConnectorService().getClientProtocols().add(Protocol.HTTP);
getConnectorService().getClientProtocols().add(Protocol.HTTPS);
On the server, as said, I use also only org.restlet.jar org.restlet.jar,
org.restlet.ext.servlet are put in the war
here is my servlet application instansciation below... I also attached the
web.xml in this post... as you will see my only differences are in the
web.xml the servlet routing...
all the other code is really similar to the example provided for android/gae
implementation.
I really would like in advance to thank each of you for providing an expert
look/eye.
Louis
Servlet routing:
package name.lecaroz.google.fleet.app.server.restlet;
import java.io.File;
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.LocalReference;
import org.restlet.data.Protocol;
import org.restlet.resource.Directory;
import org.restlet.routing.Router;
public class RestLetApplication extends Application {
/**
* When launched as a standalone application.
*
* @param args
* @throws Exception
*/
/*
public static void main(String[] args) throws Exception {
Component component = new Component();
component.getClients().add(Protocol.FILE);
component.getServers().add(Protocol.HTTP, 8081);
component.getDefaultHost().attach(new RestLetApplication());
component.start();
}
@Override
public Restlet createInboundRoot() {
Router router = new Router(getContext());
getConnectorService().getClientProtocols().add(Protocol.FILE);
// Serve the files generated by the GWT compilation step.
File warDir = new File();
if (!war.equals(warDir.getName())) {
warDir = new File(warDir, war/);
}
Directory dir = new Directory(getContext(), LocalReference
.createFileReference(warDir));
router.attachDefault(dir);
router.attach(/RestLet/ShipLocation,
ShipLocationServerResource.class);
return router;
}
*//**
* Creates a root Restlet that will receive all incoming calls.
*/
@Override
public synchronized Restlet createInboundRoot() {
getConnectorService().getClientProtocols().add(Protocol.FILE);
getConnectorService().getClientProtocols().add(Protocol.HTTP);
getConnectorService().getClientProtocols().add(Protocol.HTTPS);
// Create a router Restlet that routes each call to a
// new Resource
Router router = new Router(getContext());
router.attachDefault(ShipLocationServerResource.class);
return router;
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2457990
