Re: uriPattern exactness
Hi Cliff,
you can also update the type of the declared variable in your URI template:
Route route = router.attach(/foos/{foo}/bar, sth);
Template template =
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
template.getVariables().put(foo, new Variable(Variable.TYPE_WORD));
You can find the list of all variable types in the Variable class.
Otherwise, the routing process is based on URI template. If you want one
based on regexp, I send you a sample template class based on regexp
pattern and a server/client test code.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com/
Aron,
Thanks, I didn't realize this was here. This would potentially work, and I
may end up using it.
Frankly, I want to be able to have my cake and eat it too. An exact match
using this construct would work, but would also force me to itemize every
possible variation of a path via router.attach(). I was hoping to do some
fuzzy enforcement in a base Resource class.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Aron Roberts [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 11:37 AM
To: discuss@restlet.tigris.org
Subject: RE: uriPattern exactness
In the message Re: uriPattern exactness, dated 2008-10-16, Cliff
Binstock wrote:
P.S. What is worse (maybe very confusing) is that this might match too:
/foo/myFoo/bar/baz/bletch/fred.xml
Again, I would like to forcefully ensure that this doesn't end up
matching.
From memory - by default, the mode for matching incoming URIs to
your URI templates is 'starts with' rather than 'equals'.
As Jerome wrote back in February 2008:
In some cases, you might want to change this default mode, and this
is easy to do via the defaultMatchingMode property on Router, or by
modifying the matchingMode property of the template associated with
the route created by the Router.attach() methods. For the modes, you can
use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants.
Here's one example of the latter:
router.getTemplate().setMatchingMode(Template.MODE_EQUALS)
Hope this is germane to your needs.
Aron
testTemplateCustomized.jar
Description: application/java-archive
RE: XmlRepresentation.internalEval
Hi guys, I've replaced all catch(final strings with catch(... Checked in SVN trunk. There is even a regular expression feature in Eclipse search/replace feature that we could have leveraged... Eclipse developers can find good workarounds sometimes ;-) Best regards, Jérôme 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:[EMAIL PROTECTED] Envoyé : mercredi 15 octobre 2008 11:29 À : discuss@restlet.tigris.org Objet : Re: XmlRepresentation.internalEval I don't suppose we have any Eclipse developers on the list taking notes? On Wed, Oct 15, 2008 at 3:26 AM, Richard Hoberman [EMAIL PROTECTED] wrote: Tim Peierls wrote: It's not a huge deal, but superfluous final keywords are clutter that distract from the places where final is being used meaningfully. I think it's worth cleaning this up incrementally in Restlet. This would do it: perl -pie 's/final (?=[a-zA-Z]*Exception)//g' `find . -name \*.java`
RE: Authenticating and other thoughts
Wow!! So many great news and shiny projects built on top of Restlet, that make us at Noelios feel really happy. Rob, I will definitely blog about those projects when GoGoEgo is publicly released! If others in this list want to share how they leverage the technology in the real world projects, please feel free to do so here or to contact us directly so we can communicate about that via our blog and our upcoming newsletter... Best regards, Jérôme 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:[EMAIL PROTECTED] Envoyé : mardi 14 octobre 2008 15:55 À : discuss@restlet.tigris.org Objet : Re: Authenticating and other thoughts On Mon, Oct 13, 2008 at 9:18 PM, Hugh Acland [EMAIL PROTECTED] wrote: I don't mean to belittle these web-services but are there any examples of large scale commercial applications (whether open to the world or secured) which are built solidly on a truly distributed, web-based Restful architecture? Yes. My company has so far produced about USD$500,000 worth of deployed commercial applications on this technology, will have produced twice that when all our current engagements are completed, and are continuing to enjoy, recommend and standardize on the Restlet platform. Here are two recent launches: The 2008 IUCN Red List of Threatened Species (http://www.iucn.org/news_events/events/congress/index.cfm?uNewsID=1695) was produced using a ~300,000 line Restlet and GWT based application called the Species Information Service (SIS). In addition to there being a high load central Web version of the application, its Restlet foundation means it can also be easily used in a lightweight offline container; it was distributed on a USB stick, along with a complete taxonomy, to interested species experts. IUCN plans to open source this application if they can figure out the legal mechanics. Protect Planet Ocean (http://www.protectplanetocean.org) was produced using our Restlet and GWT based content management system, GoGoEgo, and also launched last week at Barcelona. Site updates are published to Google App Engine for production hosting; to do this, we wrote a Python emulation of the core dynamic templating of the CMS. But since everything is resource-oriented, it's trivial to move from Java/REST to Python/REST. Interesting, no? With the above two (and others I can't talk about) launched, I'm hoping to finally have time internally to make public releases of GoGoEgo. You also should check out Kauri (www.kauriproject.org) for another non-trivial application of Restlet. I think that the next 3-6 months will see a lot of high visibility Restlet projects emerging into the sun. I know a lot of people on the list have been working on stuff throughout the 1.1 release cycle, and all of us are starting to have things come out. - Rob
RE: Spring configuration example using com.noelios.restlet.ext.spring package
Hi Mark, Thanks for this feed-back. We realize that the Spring extensions still lack a comprehensive documentation. We even have a RFE for that where I've just added your comments: Improve Spring documentation http://restlet.tigris.org/issues/show_bug.cgi?id=614 I won't make any promise but we are currently working on improving the wiki structure and content for the launch. We still have a long way to go and need help from the community on this front (any wiki author candidate out there ?). One thing that will help is the upcoming merging of com.noelios.restlet.ext.spring into org.restlet.ext.spring in Restlet 1.2. This will give a more unified view of the Spring support in Restlet. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Mark Petrovic [mailto:[EMAIL PROTECTED] Envoye : jeudi 16 octobre 2008 17:16 A : discuss@restlet.tigris.org Objet : Re: Spring configuration example using com.noelios.restlet.ext.spring package I took a look at the javadoc for both org.restlet.ext.spring and com.noelios.restlet.ext.spring and conclude that the method outlined here, based on org.restlet.ext.spring, http://wiki.restlet.org/docs_1.1/13-restlet/g2/59-restlet.html is the most viable approach. Having read through that example, I'm still left with the impression that the example contains a mix of specific and general treatments of the subject. For example, I don't understand why this point is raised In this example, the last URI pattern has to be customized to accept complete URIs (possibly including slashes) as the last component of the pattern. We use Spring's nested properties to drill into the configuration of the URI pattern along with Spring's mechanism for accessing a static field in a class. And by don't understand I do not mean I object to the point raised, but rather what, in my lack of understanding, is this really trying to tell me, and does it matter in my case?. The Spring lookup- method reference strikes me the same way: is this central to restlet configuration with Spring, or is it an advanced idiom that I can do without for now? I'm not asking for a clarification of this particular point, but instead for someone to offer a second standalone example of how to configure a simple restlet-based app using Spring. Many, many times in my study of a thing I resort to second and third and fourth references on the subject to gain an understanding of what is fundamental to a subject's elucidation, vs. what is specific in the course of that illustration. This is one of those times, and I'm sure others routinely resort to this same approach. Would someone be kind enough to post some non-proprietary code showing how they configured their restlet app using Spring? The example would configure an app no more complex than the FirstResouce app found elsewhere on the site. Thanks much. Hopefully posterity will benefit from my supplications as much as I do now. Mark On Oct 15, 2008, at 1:57 PM, Mark Petrovic wrote: Good day. I notice that both the FAQ and Wiki have sections treating the use of the org.restlet.ext.spring package to manage a restlet app in a Spring container. Is there a similar example someone might offer on using the com.noelios.restlet.ext.spring package to manage a restlet app in the same way? The FAQ says such a configuration option exists, and I'd like to read about it. Thanks. Mark
RE: Assistance and Question
Hi Sanjay,
I can confirm that Client instances have been designed to be reused
concurrently by several threads. The code should be thread-safe (I've just
fixed the issue Tim noticed).
But, nothing prevents you from having several instances of them if that
makes sense, for example for configuration purpose as pointed out by Stephan
Koops.
In your code snippet, what is missing is a call to c.stop() to make sure
that your connector is stopped and any resource used is freed. You could
also explicitly do a c.start() by this is done implicitly when the requests
is handled.
Best regards,
Jérôme 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 : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tim
Peierls
Envoyé : jeudi 16 octobre 2008 04:55
À : discuss@restlet.tigris.org
Objet : Re: Assistance and Question
I think Client is intended to be thread-safe, but it isn't currently,
because the connectTimeout field is not guarded by a lock (nor is it
volatile) -- sorry Jerome, I just noticed this. This is not likely to cause
any problems, but it *is* wrong.
And there may be other concurrency issues lurking in Client. My feeling is
better safe than sorry. If you really need to have multiple threads talking
to a Client instance -- and it's not clear to me that you do -- use a
ThreadLocalClient. It might be unnecessary, but it limits the number of
open file handles to some small factor of the number of threads talking to
Clients simultaneously.
--tim
On Wed, Oct 15, 2008 at 10:14 PM, Sanjay Acharya [EMAIL PROTECTED]
wrote:
Hi Jerome,
I believe I have found the cause of our problem.
We use Restlet Client by instantiating it every time, for example,
for (int i = 0; i 1000; i++) {
Client c = new Client();
Response response = c.handle(request);
response.release();
}
we end up creating a downstream HttpClient on every client. When release()
is called, the socket connection is released back to the
HttpConnectionManager.
HttpConnectionManager does not close the socket. However, due to garbage
collection, at some point the underlying socket is closed out.
It happens some times and not others, i.e., via the luck of GC running.
If we however, hold a Reference of every client that is instantiated, then
we can easily reproduce the open file handle issue as GC will not free the
underlying socket
and we can see eventually reach a point where all the available file handles
are consumed.
That said, the direction of preference seems to point to using a single
instance of Restlet's Client class and setting the maxConnectionsPerHost
to some
appropriate value. One concern that I have is whether Restlet's Client is
designed to be thread safe so that multiple threads can utilize the same
instance?
In other words, is singleton usage the recommended pattern for using the
client?
Thanks much,
Sanjay
_
From: [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Date: Wed, 15 Oct 2008 08:46:06 +0200
Subject: RE: Assistance and Question
Hi Sanjay,
As a first step, I would highly recommend moving to 1.1 RC2 or a more
recent
snapshot. There is a good chance that it will fix your issue.
If not, we'll investigate more.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Sanjay Acharya [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 15 octobre 2008 02:39
À : discuss@restlet.tigris.org
Objet : Assistance and Question
Hi,
I am using Restlet version 1.1 m1. There are times when we run out of open
file handles in stage environment with too many open file handles error.
I
am also using the JaxbRepresentation to marshall the data.
I am trying to recreate the issue related to
http://restlet.tigris.org/issues/show_bug.cgi?id=439 and not sure how to
do
the same. I would like to be able to recreate a state where connections
are
left in
CLOSE_WAIT and FIN_WAIT_2 state by the client.
I have limited the number of open file handles to 200 for the user.
Any assistance to be able to duplicate the issue would be great.
Thanks,
Sanjay
Code on Resource class:
@Override public void post(Representation representation) {
String greeting = Hello thgere;
Person p = new Person();
p.setFirstName(Foo);
p.setLastName(Bar);
// A Large address list
p.setAddresses(buildAddress());
SayHelloResponse resp = new
SayHelloResponse().withPerson(p).withGreeting(greeting);
JaxbRepresentation responseRep = new
JaxbRepresentation(MediaType.APPLICATION_XML, resp);
getResponse().setEntity(responseRep);
getResponse().setStatus(Status.SUCCESS_OK);
}
Code on Client class:
Person p = new Person()
SayHelloRequest sayHelloRequest = new
RE: Assistance and Question
Sanjay, I agree with your idea. See the new RFE for details: Support connection timeout for Apache HTTP client http://restlet.tigris.org/issues/show_bug.cgi?id=622 Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Sanjay Acharya [mailto:[EMAIL PROTECTED] Envoyé : jeudi 16 octobre 2008 23:46 À : discuss@restlet.tigris.org Objet : RE: Assistance and Question If one can get access to the HttpClientHelper class then one could register the connectionManager of commons HttpClient with commons HttpClient IdleConnectionTimeoutThread. However the Restlet client declares the helper as private. Some challenges there in. It will be interesting to know the preferred direction of setting up the IdleConnectionTimeoutThread. Personally, would prefer something like client.getContext().getParameters().add(inactiveTimeout, 1); and the downstream HttpClientHelper could start the IdleConnectionTimeoutThread and register the connection manager with it. A subsequent call to client.shutdown() can propagate the change to shutdown the IdleConnectionTimeoutThread. Maybe there is a better way. Date: Thu, 16 Oct 2008 17:31:29 -0400 From: [EMAIL PROTECTED] To: discuss@restlet.tigris.org Subject: Re: Assistance and Question Unfortunately, I don't know. In my apps, which tend to be single-user, the maxConnectionsPerHost is usually 2, the HTTP/1.1 recommended number for a single-user agent, (RFC 2616, 8.1.4). I would be very interested to know, however ... as this is important behavior for a proxy representing multiple users. I am sure, though, that an HTTP/1.1 connection will not stay open forever in an unused state; even if the client doesn't close it, any reasonably well behaved and self-preservative server will. So this may be something you need not worry about. Benchmark and see? On Thu, Oct 16, 2008 at 5:20 PM, Sanjay Acharya wrote: Rob, Thanks much for your reply. We are moving more in the direction of reusing the client instance. One question that you might have already dealt with is how you setup Restlet thus HttpClient to release out connections that have not been used for a prolonged period of time. Is there a way to enforce an Idle time out? I do not want to set the maxConnectionsPerHost and maxTotalConnections to a small value as that will throttle requests. What I am hoping to do is set these values large, but in case of a surge of requests and then have these connections close out after a period of un-use. _ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/=
RE: uriPattern exactness
Hi Cliff,
In combination with MODE_EQUALS, you could also add a variable for your
extensions like: /foos/{foo}/bar.{ext}. That could reduce the number of
alternative routes you would have to attach.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Cliff Binstock [mailto:[EMAIL PROTECTED]
Envoye : vendredi 17 octobre 2008 01:28
A : discuss@restlet.tigris.org
Objet : RE: uriPattern exactness
Aron,
Thanks, I didn't realize this was here. This would potentially work, and I
may end up using it.
Frankly, I want to be able to have my cake and eat it too. An exact match
using this construct would work, but would also force me to itemize every
possible variation of a path via router.attach(). I was hoping to do some
fuzzy enforcement in a base Resource class.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Aron Roberts [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 11:37 AM
To: discuss@restlet.tigris.org
Subject: RE: uriPattern exactness
In the message Re: uriPattern exactness, dated 2008-10-16, Cliff
Binstock wrote:
P.S. What is worse (maybe very confusing) is that this might match too:
/foo/myFoo/bar/baz/bletch/fred.xml
Again, I would like to forcefully ensure that this doesn't end up
matching.
From memory - by default, the mode for matching incoming URIs to
your URI templates is 'starts with' rather than 'equals'.
As Jerome wrote back in February 2008:
In some cases, you might want to change this default mode, and this
is easy to do via the defaultMatchingMode property on Router, or by
modifying the matchingMode property of the template associated with
the route created by the Router.attach() methods. For the modes, you can
use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants.
Here's one example of the latter:
router.getTemplate().setMatchingMode(Template.MODE_EQUALS)
Hope this is germane to your needs.
Aron
RE: Assistance and Question
Hi Tim, Thanks for checking this part of the code. I've just fixed all the points you have reported in SVN trunk. Regarding the last point you mentioned, I've entered a RFE: Handlers don't nest consistently when setting current objects http://restlet.tigris.org/issues/show_bug.cgi?id=621 If you or Leigh could add more details and eventually a patch in the comments of the RFE, that would help fixing any issue in this area before 1.1 release. Best regards, Jérôme 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 : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tim Peierls Envoyé : vendredi 17 octobre 2008 05:16 À : discuss@restlet.tigris.org Objet : Re: Assistance and Question On Thu, Oct 16, 2008 at 4:57 PM, Rob Heittman [EMAIL PROTECTED] wrote: Pragmatically, our applications do reuse Client instances in production code and have not had any trouble with this. It's meant to be thread safe. Tim points out a valid thread safety issue, but it's not likely to cause you harm and will probably be corrected eventually. While I was looking to see if there were any obvious serious thread-safety issues in Client and friends, I noticed a few minor things that should probably be fixed: * ConnectorHelper has volatile field protocols, which could and should be final. * ConnectorHelper start/stop both have useless synchronized keywords. * ClientHelper.connectTimeout is neither guarded by a lock nor volatile (similar to connectTimeout in Client). On a related note, Leigh Klotz pointed out privately to me that the handlers that set the current request, response, and context don't nest consistently, and there is a potential for memory leaks. The documentation says not to rely to heavily on the static getCurrent() methods, so maybe it's my own fault for writing the Guice FinderFactoryModule in terms of them, but the possibility of a memory leak is worth checking out. --tim
RE: Spring Engine
Hi Kevin, Thanks for suggestion. For tracking purpose, here is the link to the RFE you created with your patch: Add SpringEngine http://restlet.tigris.org/issues/show_bug.cgi?id=620 In fact, the current plan for Restlet 1.2 is to move the com.noelios.restlet.* packages into org.restlet.engine.*. This would allow us to package the Restlet Engine together with the Restlet API, into a single org.restlet.jar file. This would also ensure that the engine classes would receive the same level of backward compatibility support than the API classes. As a benefit, it would encourage people to build more extensions/connectors for Restlet as their code wouldn't depend on what currently looks like one specific implementation of the API (com.noelios.restlet.*). This would also allow us to simplify the code by removing the *Helper classes. Of course this would complicate the creation of alternative implementations of the API. We would then also remove the engine automatic discovery mechanism as it wouldn't bring value anymore. We would of course keep the mechanism for connector and authenticator pluggability. Maybe we would remove the Engine class itself and replace it with a new Registry for connectors. I'm not fully sure how that would impact your idea yet. What do you want to be able to configure via Spring in the end? Is it just the client and server connectors to use? Best regards, Jérôme 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 : Kevin Conaway [mailto:[EMAIL PROTECTED] Envoyé : mercredi 15 octobre 2008 18:44 À : discuss@restlet.tigris.org Objet : Spring Engine What are folks thoughts on adding a SpringEngine class to the Spring extension? This class would be a helper for configuring an Engine instance. Right now, the noelios Engine doesn't expose some of the necessary properties through setters (registeredClients, registeredServers etc) and you must call a static instance method to set the default Engine. All of that could be done through Spring factory beans but I think having a helper class in the Spring module would make things cleaner. We could also add appropriate setters where necessary to the Engine itself but that class is already quite big. Kevin
RE: Best practices for read-only fields?
Hi Richard, Option 3 seems the best to me. Note that when you do a PUT you shouldn't send a partial representation as the entity sent is expected to fully replace the existing representation. Another option you could consider is to give an URI to each modifiable field and update them individually. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Richard Hoberman [mailto:[EMAIL PROTECTED] Envoyé : vendredi 17 octobre 2008 09:19 À : discuss@restlet.tigris.org Objet : Best practices for read-only fields? Hi The only advice Richardson seems to offer on incoming representations is that a client should be able to fetch a representation, modify it, and PUT it back where it found it. (RESTful Web Services, 2007, p. 235). That is surely right, but how best to handle read-only fields? For example, consider using GET/PUT to change the nickname on the following Account object: Account username (read-only) registration-date (read-only) nickname ... many other properties Option 1. Only accept representations that don't contain the read-only fields. That goes against Richardson's advice, requiring the client to return a subset of the data. That is unacceptable. The client-code would break if new fields where added to the object and the client-code would be truly ungainly. Alternatively, we could allow the client to PUT a partial representation containing only the fields to be modified, but that would become tricky when nested structures are involved. Option 2. Accept the full representation, but only process writeable fields. This is not ideal because it would seem that an attempt to modify a read-only field had succeeded (silent failure). Option 3. Accept the full representation, but reply with a 400 BAD_REQUEST if read-only data has been changed. This seems correct from a behavioural point of view, although it puts additional burden on the implementation, which has to check every field to see whether it has changed - a nuisance, especially where the representation contains useful reference data. For example, the outgoing representation of an itinerary includes the details of the associated agent: itinerary agent name... contactDetails ...etc. /agent startDate1-dec-2009/startDate /itinerary The user does GET-modify-PUT to change the start-date. The server has to check that they haven't attempted to modify the agent's details (just to avoid the silent failure described at option 2). This could be handled as follows: 1. Annotate read-only fields @ReadOnly 2. Inside the acceptRepresentation, GET a fresh copy of the resource 3. Check that copy against the incoming representation by visiting the full object graph using reflection and comparing the fields annotated as read-only 4. Return 400 (BAD REQUEST) if one or more read-only fields have changed The visitor could check version numbers at the same time for optimistic concurrency. There would be a trade-off of performance for ease of code creation and maintenance but I think that would be acceptable for the service I am working on. I'm now considering option 3. Anyone have a better way or useful advice? Best regards Richard Hoberman
RE: Exception when querying DomRepresentation using XPath expression
Hi John,
We should indeed provide a better support for this use case. Your
suggestions sounds good. I've entered this RFE:
Allow DTD/XSD validation to be turned off
http://restlet.tigris.org/issues/show_bug.cgi?id=623
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoye : vendredi 10 octobre 2008 16:44
A : discuss@restlet.tigris.org
Objet : Re: Exception when querying DomRepresentation using XPath expression
Thierry Boileau [EMAIL PROTECTED] wrote on 10/10/2008 03:20:15
AM:
Hi John,
I send you a sample test code that works correctly.
I hope it will help you. Otherwise, could you send us a
reproductible test code?
Hi, Thierry, and thanks for the reply! After doing more research on this
than I had planned, I found that there's a real problem in Java with
trying to use XHTML representations, with DOCTYPE entities, while behind a
Proxy server. The Restlet client code kind of masked what the underlying
problem was when I wrote the email. The code pasted below fails, for
example, when running behind a proxy.
I have gotten some client code to work by specifying a custom
EntityResolver in the DocumentBuilder, and then wrapping the Document in a
DomRepresentation. I wonder if there's a place in Restlet where a client
program can either A) specify that the DomBuilder should set the don't
load external DTDs feature, or B) can send in a custom EntityResolver
that returns an empty DTD?
Thanks for looking at this!
John Wismar
[EMAIL PROTECTED]
package testDomRepresentation;
import org.restlet.Application;
import org.restlet.Client;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.Router;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.DomRepresentation;
import org.restlet.resource.StringRepresentation;
import org.restlet.util.NodeSet;
public class TestApplication extends Application {
public static void main(String[] args) throws Exception {
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
component.getDefaultHost().attachDefault(new TestApplication());
component.start();
Client client = new Client(Protocol.HTTP);
Response response = client.get(http://localhost:8182/;);
DomRepresentation doc = response.getEntityAsDom();
String xpath = //a;
NodeSet nodes = doc.getNodes(xpath); // This returns null
System.out.println(nodes.get(0).getTextContent());
component.stop();
}
@Override
public Restlet createRoot() {
Router router = new Router(getContext());
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
response.setEntity(new StringRepresentation(
!DOCTYPE html PUBLIC \-//W3C//DTD XHTML
1.1//EN\ \http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd\; +
html xmlns=\http://www.w3.org/1999/xhtml\;
version=\-//W3C//DTD XHTML 1.1//EN\ xml:lang=\en\ +
head +
meta http-equiv=\Content-Type\
content=\application/xhtml+xml; charset=utf-8\ / +
/head+
body +
a href=\/test/\some text/a +
/body +
/html,
MediaType.APPLICATION_XHTML_XML));
}
};
router.attachDefault(restlet);
return router;
}
}
Re: Spring configuration example using com.noelios.restlet.ext.spring package
I'm posting my take on the Spring config detailed on the wiki.
Previously I had been using a subclass of Application, with multiple
invocations of router.attach() (per the FirstResource app) to get
routing done to specific restlets.
Hope this helps someone out there get over the hump. In your main()
method, get the bean server and do a server.start() on it as one
would normally do with a Component:
bean id=server class=org.restlet.ext.spring.SpringComponent
property name=server
bean class=org.restlet.ext.spring.SpringServer
constructor-arg value=HTTP /
constructor-arg value=8182 /
/bean
/property
property name=defaultTarget ref=router /
/bean
bean id=router class=org.restlet.ext.spring.SpringRouter
property name=attachments
map
entry key=/account/register
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=registerResource /
/bean
/entry
entry key=/account/login
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=loginResource /
/bean
/entry
entry key=/account/confirm/{confirmationKey}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=confirmationResource /
/bean
/entry
entry key=/callsign/bind
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=bindCallsignResource /
/bean
/entry
entry key=/license/lookup/{callsign}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=lookupLicenseResource /
/bean
/entry
entry key=/log/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=createLogResource /
/bean
/entry
entry key=/log/export/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=exportLogResource /
/bean
/entry
entry key=/qso/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=qsoResource /
/bean
/entry
entry key=/qso/{logname}/{range}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=qsoResource /
/bean
/entry
/map
/property
/bean
bean id=registerResource
class=com.mspetrovic.server.restlet.RegisterResource
scope=prototype/
bean id=loginResource
class=com.mspetrovic.server.restlet.LoginResource scope=prototype/
bean id=confirmationResource
class=com.mspetrovic.server.restlet.AccountConfirmationResource
scope=prototype/
bean id=bindCallsignResource
class=com.mspetrovic.server.restlet.BindCallsignResource
scope=prototype/
bean id=lookupLicenseResource
class=com.mspetrovic.server.restlet.LookupCallsignResource
scope=prototype/
bean id=createLogResource
class=com.mspetrovic.server.restlet.LogResource scope=prototype/
bean id=exportLogResource
class=com.mspetrovic.server.restlet.LogExportResource
scope=prototype/
bean id=qsoResource
class=com.mspetrovic.server.restlet.QSOResource scope=prototype/
On Oct 16, 2008, at 8:16 AM, Mark Petrovic wrote:
I took a look at the javadoc for both org.restlet.ext.spring and
com.noelios.restlet.ext.spring and conclude that the method outlined
here, based on org.restlet.ext.spring,
http://wiki.restlet.org/docs_1.1/13-restlet/g2/59-restlet.html
is the most viable approach.
Having read through that example, I'm still left with the impression
that the example contains a mix of specific and general treatments
of the subject. For example, I don't understand why this point is
raised
In this example, the last URI pattern has to be customized to
accept complete URIs (possibly including slashes) as the last
component of the pattern. We use Spring's nested properties to drill
into the configuration of the URI pattern along with Spring's
mechanism for accessing a static field in a class.
And by don't understand I do not mean I object to the point
raised, but rather what, in my lack of understanding, is this
really trying to tell me, and does it
Re: uriPattern exactness
On Friday 2008.10.17, at 04:01 , Jerome Louvel wrote:
[...]
In combination with MODE_EQUALS, you could also add a variable for
your
extensions like: /foos/{foo}/bar.{ext}. That could reduce the
number of
alternative routes you would have to attach.
Yes and no. I use that trick but I still have to also have e.g.:
/foos/{foo}/bar
as well since the dot shouldn't be there if there's no extension. When
I last looked, I couldn't find any way to make things optional (so if
it's still not possible to do that in the latest versions, I'd suggest
looking into it -- something like /bar(.{ext})? so that it hangs
together properly).
FWIW, I do send both to the same resource and just have the resource
look for the optional parts. e.g.:
ext = (String) request.getAttributes().get(ext);
if (null == ext)
ext = ;
I've also used a combination of EQUALS and the default STARTS_WITH to
keep the numbers of routes a bit more manageable.
Take care,
John
Re: Best practices for read-only fields?
This is an example of the general need to validate all input. IMHO, if you look at it that way then you basically need to do Option #3 anyways since good input validation practice is to default deny + accept only known good input patterns. Depending on the depth and complexity of the full graph of input that you seem to be worried about, you might also consider doing a hash of those big, hairy fields (ala your xml example) to verify their not- changed status more simply. For the fully general case, you'll have to do the full-validation anyways especially if you want to gracefully support compatibility across versions but it's unclear whether or not you actually need/want to go that far given your examples. Hope this helps, John
Getting 403 Forbidden rather than 401 Unauthorized when using HTTP Basic auth
I followed the code in this tutorial: http://www.restlet.org/documentation/1.0/tutorial#part09 But when the authentication fails, I'm getting a 403 error, rather than a 401 error as the code suggests. This is with Restlet v1.0.11 - any ideas? Regards, Ian. -- Ian Clarke CEO, Uprizer Labs Email: [EMAIL PROTECTED] Cell: +1 512 422 3588
Re: Spring configuration example using com.noelios.restlet.ext.spring package
Hi Mark,
You might also consider using SpringBeanRouter. If you only have one
URI mapping per resource, it allows your URIs to be mapped directly in
the bean definitions. Your example would be like this using
SpringBeanRouter (note: not tested):
!-- server bean as before --
bean name=router class=org.restlet.ext.spring.SpringBeanRouter/
bean name=/account/register id=registerResource
class=com.mspetrovic.server.restlet.RegisterResource
scope=prototype/
bean name=/account/login id=loginResource
class=com.mspetrovic.server.restlet.LoginResource scope=prototype/
bean name=/account/confirm/{confirmationKey}
id=confirmationResource
class=com.mspetrovic.server.restlet.AccountConfirmationResource
scope=prototype/
bean name=/callsign/bind id=bindCallsignResource
class=com.mspetrovic.server.restlet.BindCallsignResource
scope=prototype/
bean name=/license/lookup/{callsign} id=lookupLicenseResource
class=com.mspetrovic.server.restlet.LookupCallsignResource
scope=prototype/
bean name=/log/{logname} id=createLogResource
class=com.mspetrovic.server.restlet.LogResource scope=prototype/
bean name=/log/export/{logname} id=exportLogResource
class=com.mspetrovic.server.restlet.LogExportResource
scope=prototype/
bean name=/qso/{logname}/{range} id=qsoResource
class=com.mspetrovic.server.restlet.QSOResource scope=prototype/
Rhett
On Oct 17, 2008, at 9:10 AM, Mark Petrovic wrote:
I'm posting my take on the Spring config detailed on the wiki.
Previously I had been using a subclass of Application, with multiple
invocations of router.attach() (per the FirstResource app) to get
routing done to specific restlets.
Hope this helps someone out there get over the hump. In your main()
method, get the bean server and do a server.start() on it as one
would normally do with a Component:
bean id=server class=org.restlet.ext.spring.SpringComponent
property name=server
bean class=org.restlet.ext.spring.SpringServer
constructor-arg value=HTTP /
constructor-arg value=8182 /
/bean
/property
property name=defaultTarget ref=router /
/bean
bean id=router class=org.restlet.ext.spring.SpringRouter
property name=attachments
map
entry key=/account/register
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=registerResource /
/bean
/entry
entry key=/account/login
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=loginResource /
/bean
/entry
entry key=/account/confirm/{confirmationKey}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=confirmationResource /
/bean
/entry
entry key=/callsign/bind
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=bindCallsignResource /
/bean
/entry
entry key=/license/lookup/{callsign}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=lookupLicenseResource /
/bean
/entry
entry key=/log/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=createLogResource /
/bean
/entry
entry key=/log/export/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=exportLogResource /
/bean
/entry
entry key=/qso/{logname}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=qsoResource /
/bean
/entry
entry key=/qso/{logname}/{range}
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=createResource
bean=qsoResource /
/bean
/entry
/map
/property
/bean
bean id=registerResource
class=com.mspetrovic.server.restlet.RegisterResource
scope=prototype/
bean id=loginResource
class=com.mspetrovic.server.restlet.LoginResource
scope=prototype/
bean id=confirmationResource
class=com.mspetrovic.server.restlet.AccountConfirmationResource
scope=prototype/
bean id=bindCallsignResource
class=com.mspetrovic.server.restlet.BindCallsignResource
scope=prototype/
bean id=lookupLicenseResource
RE: uriPattern exactness
John and Jérôme,
Thanks much, this is *exactly* what I need!
Cliff
-Original Message-
From: John D. Mitchell [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 7:54 AM
To: discuss@restlet.tigris.org
Subject: Re: uriPattern exactness
On Friday 2008.10.17, at 04:01 , Jerome Louvel wrote:
[...]
In combination with MODE_EQUALS, you could also add a variable for
your
extensions like: /foos/{foo}/bar.{ext}. That could reduce the
number of
alternative routes you would have to attach.
Yes and no. I use that trick but I still have to also have e.g.:
/foos/{foo}/bar
as well since the dot shouldn't be there if there's no extension. When
I last looked, I couldn't find any way to make things optional (so if
it's still not possible to do that in the latest versions, I'd suggest
looking into it -- something like /bar(.{ext})? so that it hangs
together properly).
FWIW, I do send both to the same resource and just have the resource
look for the optional parts. e.g.:
ext = (String) request.getAttributes().get(ext);
if (null == ext)
ext = ;
I've also used a combination of EQUALS and the default STARTS_WITH to
keep the numbers of routes a bit more manageable.
Take care,
John
Re: Spring Engine
I agree with everything you've written. It seems to me that while there is a theoretical benefit to having the engine and RI separated, it doesn't see much practical use. The end result of this patch is that I can configure the Engine to use the connectors I want via Spring without using the auto-discovery process. Kevin On Fri, Oct 17, 2008 at 5:44 AM, Jerome Louvel [EMAIL PROTECTED]wrote: Hi Kevin, Thanks for suggestion. For tracking purpose, here is the link to the RFE you created with your patch: Add SpringEngine http://restlet.tigris.org/issues/show_bug.cgi?id=620 In fact, the current plan for Restlet 1.2 is to move the com.noelios.restlet.* packages into org.restlet.engine.*. This would allow us to package the Restlet Engine together with the Restlet API, into a single org.restlet.jar file. This would also ensure that the engine classes would receive the same level of backward compatibility support than the API classes. As a benefit, it would encourage people to build more extensions/connectors for Restlet as their code wouldn't depend on what currently looks like one specific implementation of the API (com.noelios.restlet.*). This would also allow us to simplify the code by removing the *Helper classes. Of course this would complicate the creation of alternative implementations of the API. We would then also remove the engine automatic discovery mechanism as it wouldn't bring value anymore. We would of course keep the mechanism for connector and authenticator pluggability. Maybe we would remove the Engine class itself and replace it with a new Registry for connectors. I'm not fully sure how that would impact your idea yet. What do you want to be able to configure via Spring in the end? Is it just the client and server connectors to use? Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- *De :* Kevin Conaway [mailto:[EMAIL PROTECTED] *Envoyé :* mercredi 15 octobre 2008 18:44 *À :* discuss@restlet.tigris.org *Objet :* Spring Engine What are folks thoughts on adding a SpringEngine class to the Spring extension? This class would be a helper for configuring an Engine instance. Right now, the noelios Engine doesn't expose some of the necessary properties through setters (registeredClients, registeredServers etc) and you must call a static instance method to set the default Engine. All of that could be done through Spring factory beans but I think having a helper class in the Spring module would make things cleaner. We could also add appropriate setters where necessary to the Engine itself but that class is already quite big. Kevin
Re: Restlet-GWT HTTP authentication example
Hello Mark, I've updated the sample application and its description: http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/144-restlet.html Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ Thierry, good day. Is there sample code available showing how to use the HTTP Digest authentication scheme? Hello Mark, the current sample GWT application has been updated with authentication, and usage of JSON and XML representations. See http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/144-restlet.html. Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ Does anyone have a couple of code snippets, with qualifying and explanatory comments, they can share that demonstrate both the client and server side of the new Restlet-GWT HTTP authentication? I just might be getting the hang of Restlet programming, and authentication and login-state without that warm, cozy servlet session state is the last piece I need to envision my app end to end. Thanks. Mark
