Re: Congratulation!"Restlet: Official Developer's Guide to RESTful Web Applications in Java" will be out!
Jerome Louvel schrieb: Hi all, It seems that Dan found out about the upcoming release earlier than I expected. We are busy writing the manuscript, so there is still a long way to go before you can pick up the book at your local bookstore :) The book will cover Restlet 1.1 which we hope to release at the same time. There is currently no plan for a French version, but I have just asked about this to my editor. I'll keep you informed. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Jean-Yves Cronier Envoyé : vendredi 22 février 2008 15:50 À : discuss@restlet.tigris.org Objet : Re: Congratulation!“Restlet: Official Developer’s Guide to RESTful Web Applications in Java” will be out! And, Which version is concerned ? RESTlet 1.0 or RESTlet 1.1 ? Jean-Yves Cronier a écrit : Is a french version planned ? Great news --- I just preordered a copy at amazon --- this should come _really_ handy for my diploma thesis which is (in part) about implementing a RESTful Web Service. This book is _exactly_ what I need - I just hope it won't be delayed. In the meantime - are there any other good resources about learning to use RESTful (Tutorials, guides, etc) other than those found on the Restlet-Homepage? Greetings Ralf
Re: File extensions to select variants
Hello, I personally think this is definitely a great idea! I'm planing to use URIs with extensions to support different media-types in my current project and at the moment I'm just looking at the resourceRef in the resource-class and then manipulate the available variants and so on - its just very dirty! What I'm interested in: How will the API support this: Will there be just a method resource.addExtension(MediaType mime, String ext) or will it somehow get integrated with the setVariant-method. I'm relatively new to RESTLET so sorry if the answers to my questions are obvious or so... ;-) Greetings Ralf Jerome Louvel schrieb: Hi all, We have started to discuss with Chuck Mortimer and Stephan Koops the support of file extensions to influence the content negotiation in Restlet. This is tracked in the following RFE: "Support variant selection based on file extension" http://restlet.tigris.org/issues/show_bug.cgi?id=463 The solution we are now considering is to enhance the TunnelService (one for each application) to support the automatic modification of the "Accept", "Accept-Language", "Accept-Encoding", "Accept-Charset" headers (actually the Restlet equivalents in ClientInfo) based on the given file extensions and on the metadata associated (via the MetadataService). When processing a request with a resourceRef having file extensions, the idea is to update the client preferences and cut the URI reference to remove the extensions. With this, the application itself would not know or have to care about which way was used to select the variants (via Accept* headers, via tunnel query parameters or via tunnel file extensions). Also, we want to enable it by default and to refactor the Directory Restlet to take advantage of it instead of its internal mechanism. Any opinion on this new feature before we start coding it? Best regards, Jerome
Re: Restlet book update
That's sad, I was really looking forward to this. "The good news is that we are currently considering alternative ways to bring the manuscript to interested readers." --> that would be great! Jerome Louvel schrieb: Hi all, Some of you who with pre-orders of the upcoming Restlet book might have received a cancelling notification. This results from a joint decision between us and our initial publisher to not move forward together with the book. We apologize for the troubles and the confusion. The good news is that we are currently considering alternative ways to bring the manuscript to interested readers. Two third of it is already written and we still hope to have it published in time for Restlet 1.1 release ! Stay tuned, Jerome
Re: Tracking Request and Patterns
Hello, I'm trying to do something similar, parsing the path-components
of an URI to create a kind of query. I dont know the count,type or order
of the parameters (the path-components) of this query at compile-time so
I thought about creating the query on the fly with chained routers and
extending the query at each step.
Anyway, I have my reasons not to use query-parameters for this (because
theres hypermedia with info/links to further application states involved
at each resource-step) and want to dynamically collect the semantic of
the query at each path-step.
Could you please provide me with a code-snippet how you did it Sanjay,
because I think thats very close to the thing I would need
Ralf
Sanjay Acharya schrieb:
Hi Jerome,
Thanks for the suggestion. I have actually subclassed the Router class and
overriden the getNext() method to provide me the URI. I am storing the partial
uri in the case of router chaining to and finally aggregating the same.
Thanks again.
Sanjay
From: [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Date: Fri, 11 Apr 2008 18:38:19 +0200
Subject: RE: Tracking Request and Patterns
Hi Sanjay,
Here is another idea:
1) Create a subclass of the Route class (which is a Filter) and add the
logic to save the URI template in each request handled. You have access to
the template via the Route.getTemplate() method.
2) Create a subclass the Router class and override the createRoute(String
uriTemplate, Restlet target) to return instances of your Route subclass.
3) Use your Router subclass instead of normal Router instances.
That's all you should need! :)
Best regards,
Jerome
-Message d'origine-
De : Sanjay Acharya [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 avril 2008 17:43
À : discuss@restlet.tigris.org
Objet : Tracking Request and Patterns
Hi,
I am trying to develop a tracker to determine which pattern
uri of a restlet service has been invoked. For example, an
OrderApplication may support:
/order
/order/{orderId}
/order/lineItem/{lineItemId}
I would like to be able to intercept a request and place the
pattern uri (example:/order/{orderId}) into the request
object so that I might be able to use it later for tracking
purpose. For example,
being able to use the the result that I place in the request
within a Tomcat Valve or Filter:
I am searching for the best place to handle this. My first
thought was to extend the Application class by providing a
custom AbstractApplication that would do the following:
public abstract class MyApplication extends Application {
public void handle(Request request, Response response) {
super.handle(request, response);
Restlet root = super.getRoot();
if (! (root instanceof Router)) {
return;
}
Router router = (Router) root;
RouteList rlist = router.getRoutes();
Route route = rlist.getBest(request, response,
router.getRequiredScore());
Template t = route.getTemplate();
String servicedPattern = t.getPattern();
Map attributes = new HashMap();
attribues.put("SERVICED_PATTERN", servicedPattern);
// Place the pattern serviced in the request so that it
may be extracted later.
request.setAttributes(attributes);
}
}
I however do not believe the above is the correct place for
this sort of tracking as the above code assumes that the
routers are not chained. Further placing I am not sure whether
placing objects in org.restlet.data.Request will be available
after the restlet finishes the processing, something I have
yet to try.
Any suggestions/thoughts/experiences with where the best
place to plugin this tracking information would be appreciated.
Regards,
Sanjay
_
Pack up or back up–use SkyDrive to transfer files or keep
extra copies. Learn how.
hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_T
AGLM_WL_Refresh_skydrive_packup_042008=
_
Going green? See the top 12 foods to eat organic.
http://green.msn.com/galleries/photos/photos.aspx?gid=164&ocid=T003MSN51N1653A
Re: Restlet book update
Great news. I can see the "resource" isn't up yet, but I'm looking forward to it! Ralf Jerome Louvel schrieb: Hi Jean-Yves, We are currently converting the manuscript to DocBook XML format to publish a free multi-page HTML version on a http://book.restlet.org site. The idea is to get more feed-back and to increase the amount of online Restlet documentation to facilitate and broaden usage of the technology. In parallel, we are looking for publishers interested in publishing a PDF and a paperback version of the book. Several persons from the community have proposed help (thx!), given advices and we are currently looking through the various options. We are also quite busy with other high priority issues, so the process takes more time than what we would like. We will keep you posted when significant progress is made. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Jean-Yves Cronier Envoyé : mardi 6 mai 2008 19:58 À : discuss@restlet.tigris.org Objet : Re: Restlet book update Any news about that ? Ralf Bommersbach a écrit : That's sad, I was really looking forward to this. "The good news is that we are currently considering alternative ways to bring the manuscript to interested readers." --> that would be great! Jerome Louvel schrieb: Hi all, Some of you who with pre-orders of the upcoming Restlet book might have received a cancelling notification. This results from a joint decision between us and our initial publisher to not move forward together with the book. We apologize for the troubles and the confusion. The good news is that we are currently considering alternative ways to bring the manuscript to interested readers. Two third of it is already written and we still hope to have it published in time for Restlet 1.1 release ! Stay tuned, Jerome
Firefox content-negotiation preferences
Hello list, while I absolutely love Firefox, there's one thing that's disturbing me for a while now (well since I started developing in a RESTful way) : The standard behavior of Firefox 2 is to prefer an XML-Representation over an HTML-Representation. You can easily see that in the Accept-header of the HTTP-Request: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 this means if I have a resource that has an human-readable HTML-Representation and also an XML-Representation (e.g. for machine-based parsing of the resource) - that if the url has no extension that explicitly specifies the mime-type (like .atom, or .htm) - the user gets the xml-Representation of the Resource. This is often confusing for the user and clearly not very helpful: The default choice for a Web-Browser (all other things being equal) should IMHO be Hypermedia. This Behavior of Firefox 2 is also incosistent with all other Browser out there (at least as far as I know), which adds to the confusion... so,my question is: does anyone know of a (preferrably non-hacky) way to set HTML as the default first choice across _all_ browser (like, if no extension is given, always assume html...) ? P.S. By the way, In Firefox 3, HTML seems to be the default
Re: Firefox content-negotiation preferences
Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor of my Application-subclass but no change, still defaults to xml... :-( Do I have to edit the agent/accept.properties? My Firefox2 user-agent reads: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 best regards Ralf Stephan Koops schrieb: Hi Ralf, Thierry implemented a feature for this. Take a look at the TunnelService.userAgentTunnel. You find the config file to replace the accept header in org/restlet/service/accept.properties and the config file for check the name of the browser in org/restlet/data/agent.properties. As first try to call TunnelService.setUserAgentTunnel(true) and look, if it works. best regards Stephan Ralf Bommersbach schrieb: Hello list, while I absolutely love Firefox, there's one thing that's disturbing me for a while now (well since I started developing in a RESTful way) : The standard behavior of Firefox 2 is to prefer an XML-Representation over an HTML-Representation. You can easily see that in the Accept-header of the HTTP-Request: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 this means if I have a resource that has an human-readable HTML-Representation and also an XML-Representation (e.g. for machine-based parsing of the resource) - that if the url has no extension that explicitly specifies the mime-type (like .atom, or .htm) - the user gets the xml-Representation of the Resource. This is often confusing for the user and clearly not very helpful: The default choice for a Web-Browser (all other things being equal) should IMHO be Hypermedia. This Behavior of Firefox 2 is also incosistent with all other Browser out there (at least as far as I know), which adds to the confusion... so,my question is: does anyone know of a (preferrably non-hacky) way to set HTML as the default first choice across _all_ browser (like, if no extension is given, always assume html...) ? P.S. By the way, In Firefox 3, HTML seems to be the default
Re: Firefox content-negotiation preferences
Yes I already use the extension-Tunnel (its a nice feature by the way) and yes, if i explicitly write .htm or .html at the end of the uri it works. What I want though is that the user gets html even if he doesn't use any extension. There are many use cases imaginable, where a user will not know about extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS) He should then - per default - get Hypermedia which is human-readable and points to other representation/resources. Anyway right now this is not a very urgent problem for me, its just something thats been bugging me and I thought I'd share ;-) P.S. I'm using Restlet 1.1M4 Stephan Koops schrieb: Hi Ralf, I only see that feature, but do not used it yet. Thierry, could you help? Ralf, you could try the extension tunnel. If you add ".html" to the URI it automaticly sets the acept header to "text/html". best regards Stephan Ralf Bommersbach schrieb: Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor of my Application-subclass but no change, still defaults to xml... :-( Do I have to edit the agent/accept.properties? My Firefox2 user-agent reads: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 best regards Ralf
Re: Firefox content-negotiation preferences
Ok will do, I'll keep you informed. Thanks Ralf Thierry Boileau schrieb: Hello Ralf, could you tell us what is the content of the "accept" header? Is this exactly the one specified in the "accept.properties"? If not, you will have to provide your own file. Proceed as follow: - in a directory of your convenience, add your own "accept.properties" file in the following sub-path: org/restlet/service/accept.properties - add in your classpath the directory. Could you keep us informed? Best regards, Thierry Boileau Yes I already use the extension-Tunnel (its a nice feature by the way) and yes, if i explicitly write .htm or .html at the end of the uri it works. What I want though is that the user gets html even if he doesn't use any extension. There are many use cases imaginable, where a user will not know about extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS) He should then - per default - get Hypermedia which is human-readable and points to other representation/resources. Anyway right now this is not a very urgent problem for me, its just something thats been bugging me and I thought I'd share ;-) P.S. I'm using Restlet 1.1M4 Stephan Koops schrieb: Hi Ralf, I only see that feature, but do not used it yet. Thierry, could you help? Ralf, you could try the extension tunnel. If you add ".html" to the URI it automaticly sets the acept header to "text/html". best regards Stephan Ralf Bommersbach schrieb: Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor of my Application-subclass but no change, still defaults to xml... :-( Do I have to edit the agent/accept.properties? My Firefox2 user-agent reads: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 best regards Ralf
Re: Firefox content-negotiation preferences
Ok it seems to work now: The problem was I didn't realize that the org.restlet.jar library (1.1M4) that I had referenced in my project did _not_ contain the agent.properties / accept.properties. There are only the class files in it and so of course the properties couldn't be loaded I guess. So I followed your advice, copied the 2 files into my project-classpath and voila! - responses default now to HTML in Firefox2 Thanks again! Ralf Thierry Boileau schrieb: Hello Ralf, could you tell us what is the content of the "accept" header? Is this exactly the one specified in the "accept.properties"? If not, you will have to provide your own file. Proceed as follow: - in a directory of your convenience, add your own "accept.properties" file in the following sub-path: org/restlet/service/accept.properties - add in your classpath the directory. Could you keep us informed? Best regards, Thierry Boileau Yes I already use the extension-Tunnel (its a nice feature by the way) and yes, if i explicitly write .htm or .html at the end of the uri it works. What I want though is that the user gets html even if he doesn't use any extension. There are many use cases imaginable, where a user will not know about extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS) He should then - per default - get Hypermedia which is human-readable and points to other representation/resources. Anyway right now this is not a very urgent problem for me, its just something thats been bugging me and I thought I'd share ;-) P.S. I'm using Restlet 1.1M4 Stephan Koops schrieb: Hi Ralf, I only see that feature, but do not used it yet. Thierry, could you help? Ralf, you could try the extension tunnel. If you add ".html" to the URI it automaticly sets the acept header to "text/html". best regards Stephan Ralf Bommersbach schrieb: Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor of my Application-subclass but no change, still defaults to xml... :-( Do I have to edit the agent/accept.properties? My Firefox2 user-agent reads: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 best regards Ralf
resourceRef.getSegments()
Hi there.
Suppose I have an URL that itself has an URL embedded, like
.../service/{service_url}/resource1/resource2/.../...
If I call request.getResourceRef.getSegments(), I get a list of all the
Segments of the URL, BUT because the method only looks for slashes it
also tokenizes the pieces of the embedded url. What if I want the
embedded URL as ONE Segment. Is there a built-in way in Restlet to do
this? (hint: I have already declared the template param service_url as
Variable.TYPE_URI_PATH.
Best regards
Ralf
Re: resourceRef.getSegments()
I have a vague idea about somehow comparing the routing-template that
lead to this resource with the actual Resourc-Reference... but I can't
find a way to get the template that routed to this resource (I have
multiple templates that sometimes route to the same resource)
so what I need is something like resource.getRequest.getTemplate
or Application.getCurrent.getRouter.getTemplate(thisResource)
Ralf Bommersbach schrieb:
Hi there.
Suppose I have an URL that itself has an URL embedded, like
.../service/{service_url}/resource1/resource2/.../...
If I call request.getResourceRef.getSegments(), I get a list of all the
Segments of the URL, BUT because the method only looks for slashes it
also tokenizes the pieces of the embedded url. What if I want the
embedded URL as ONE Segment. Is there a built-in way in Restlet to do
this? (hint: I have already declared the template param service_url as
Variable.TYPE_URI_PATH.
Best regards
Ralf
MODE_ENDS_WITH?
Hello, its me again.
I see that the Template class support a MODE_STARTS_WITH and MODE_EQUALS
but no MODE_ENDS_WITH. I think that would be very helpful in many
use-cases, for example if you have a URL like /.../.../.../result where
the path before the result-resource is variable but you always have a
results-resource at the end...
Right now I have to explicitly set a route for every possible mutation
of the paths with a result-resource at the end, would be much easier if
I could just write router.attach("/result",
ResultResource.class).getTemplate().setMatchingMode(Template.MODE_ENDS_WITH)
just an idea, what do you think?
Help: IE chunked-http problem
Hello, I'm getting strange errors when loading restlet-pages in IE, it sometimes does insert seemingly random numbers at the start of the page and at the end like 800 0 I did some reseach and think it has to do with chunked-transfer-encoding of http packets. (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) for some reasons IE (6&7) don't seem to handle chunked http-packets correctly and inserts the chunk-length as content or so. Needless to say this totally screws up my pages... At least this is the only explanation I have as other browsers don't have this problem (did I mention that I HATE IE?). BTW, I'm using the integrated Noelios HTTP-server. Anyone else getting this? Anyone knows how I can disable the hppt-chunking on the noelios http-server? Best regards Ralf
Re: Help: IE chunked-http problem
Hi, first its nice to hear I'm not the only one with this problem. It's driving me crazy... ;-) Yes, I also have the problem very randomly (sometimes it loads just fine, sometimes it doesn't even do CSS, sometimes there are the numbers) but _only_ with IE and the internal noelios server. Until now I have only used the internal server connector, as its easy to setup and use for testing-purposes. Maybe I should try another, like the Apache tomcat? I'll have to look how to do that. Do you by any chance know if this htpp-chunking can be disabled via the restlet-api? To test my theory that its the http-chunking thats causing the errors... Ralf Thierry Boileau schrieb: Hello Ralf, I've encountered also this strange behaviour but randomly and only a few times with the internal server connector. What is yours? Did you try to use another one? best regards, Thierry Boileau Hello, I'm getting strange errors when loading restlet-pages in IE, it sometimes does insert seemingly random numbers at the start of the page and at the end like 800 0 I did some reseach and think it has to do with chunked-transfer-encoding of http packets. (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) for some reasons IE (6&7) don't seem to handle chunked http-packets correctly and inserts the chunk-length as content or so. Needless to say this totally screws up my pages... At least this is the only explanation I have as other browsers don't have this problem (did I mention that I HATE IE?). BTW, I'm using the integrated Noelios HTTP-server. Anyone else getting this? Anyone knows how I can disable the hppt-chunking on the noelios http-server? Best regards Ralf
Re: Help: IE chunked-http problem
Ok thanks that helped a lot! I use now the jetty server-connector and not only did the speed improve, but also (so far) the error can't be reproduced with Internet Explorer. Everythings just fine! thanks again :-) p.s. so yeah - it seems that the internal server just has some problems handling/delivering http-chunks (in combination with Internet-Explorer as client), or so... Best regards Ralf Thierry Boileau schrieb: Hi Ralf >Maybe I should try another, like the Apache tomcat? I'll have to look how to do that. Oh, that's simple, have a look at this page: http://www.restlet.org/documentation/1.1/connectors You only have to put the jar of one of the server connectors and the jars of its dependencies (try with Jetty first) in your classpath. Et voilà, that's all! best regards, Thierry Boileau Hi, first its nice to hear I'm not the only one with this problem. It's driving me crazy... ;-) Yes, I also have the problem very randomly (sometimes it loads just fine, sometimes it doesn't even do CSS, sometimes there are the numbers) but _only_ with IE and the internal noelios server. Until now I have only used the internal server connector, as its easy to setup and use for testing-purposes. Maybe I should try another, like the Apache tomcat? I'll have to look how to do that. Do you by any chance know if this htpp-chunking can be disabled via the restlet-api? To test my theory that its the http-chunking thats causing the errors... Ralf Thierry Boileau schrieb: Hello Ralf, I've encountered also this strange behaviour but randomly and only a few times with the internal server connector. What is yours? Did you try to use another one? best regards, Thierry Boileau Hello, I'm getting strange errors when loading restlet-pages in IE, it sometimes does insert seemingly random numbers at the start of the page and at the end like 800 0 I did some reseach and think it has to do with chunked-transfer-encoding of http packets. (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) for some reasons IE (6&7) don't seem to handle chunked http-packets correctly and inserts the chunk-length as content or so. Needless to say this totally screws up my pages... At least this is the only explanation I have as other browsers don't have this problem (did I mention that I HATE IE?). BTW, I'm using the integrated Noelios HTTP-server. Anyone else getting this? Anyone knows how I can disable the hppt-chunking on the noelios http-server? Best regards Ralf
Re: Help: IE chunked-http problem
ahem ok, sure, dumb question: how do I do this? :-/ Kevin Conaway schrieb: Ralf, can you open a ticket for this? Perhaps we're not setting the correct header combination or IE requires a strange one to parse chunked encodings. On Fri, Jun 6, 2008 at 11:47 AM, Ralf Bommersbach < [EMAIL PROTECTED]> wrote: Ok thanks that helped a lot! I use now the jetty server-connector and not only did the speed improve, but also (so far) the error can't be reproduced with Internet Explorer. Everythings just fine! thanks again :-) p.s. so yeah - it seems that the internal server just has some problems handling/delivering http-chunks (in combination with Internet-Explorer as client), or so... Best regards Ralf Thierry Boileau schrieb: Hi Ralf >Maybe I should try another, like the Apache tomcat? I'll have to look how to do that. Oh, that's simple, have a look at this page: http://www.restlet.org/documentation/1.1/connectors You only have to put the jar of one of the server connectors and the jars of its dependencies (try with Jetty first) in your classpath. Et voilà, that's all! best regards, Thierry Boileau Hi, first its nice to hear I'm not the only one with this problem. It's driving me crazy... ;-) Yes, I also have the problem very randomly (sometimes it loads just fine, sometimes it doesn't even do CSS, sometimes there are the numbers) but _only_ with IE and the internal noelios server. Until now I have only used the internal server connector, as its easy to setup and use for testing-purposes. Maybe I should try another, like the Apache tomcat? I'll have to look how to do that. Do you by any chance know if this htpp-chunking can be disabled via the restlet-api? To test my theory that its the http-chunking thats causing the errors... Ralf Thierry Boileau schrieb: Hello Ralf, I've encountered also this strange behaviour but randomly and only a few times with the internal server connector. What is yours? Did you try to use another one? best regards, Thierry Boileau Hello, I'm getting strange errors when loading restlet-pages in IE, it sometimes does insert seemingly random numbers at the start of the page and at the end like 800 0 I did some reseach and think it has to do with chunked-transfer-encoding of http packets. (http://en.wikipedia.org/wiki/Chunked_transfer_encoding) for some reasons IE (6&7) don't seem to handle chunked http-packets correctly and inserts the chunk-length as content or so. Needless to say this totally screws up my pages... At least this is the only explanation I have as other browsers don't have this problem (did I mention that I HATE IE?). BTW, I'm using the integrated Noelios HTTP-server. Anyone else getting this? Anyone knows how I can disable the hppt-chunking on the noelios http-server? Best regards Ralf
Re: resourceRef.getSegments()
Ok thanks I think I will do that!
Jerome Louvel schrieb:
Hi Ralf,
Stephan's idea is probably the best for now as the slashes will be encoded
and ignore by the parsing done in getSegments().
In the future, we want to add automatic encoding and decoding to the
Template class so this would be fully transparent as you expected. Just
marking a variable as TYPE_URI_PATH should be enough for the Template class
to know that the {servier_url} value needs to be encoded or decoded.
We have a related RFE already:
"Generation of URIs from URI templates and encoding"
http://restlet.tigris.org/issues/show_bug.cgi?id=506
Best regards,
Jerome
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 30 mai 2008 12:43
À : discuss@restlet.tigris.org
Objet : Re: resourceRef.getSegments()
Hi Ralf,
you could url encode the service url.
best regards
Stephan
Ralf Bommersbach schrieb:
Hi there.
Suppose I have an URL that itself has an URL embedded, like
.../service/{service_url}/resource1/resource2/.../...
If I call request.getResourceRef.getSegments(), I get a list of all
the Segments of the URL, BUT because the method only looks for slashes
it also tokenizes the pieces of the embedded url. What if I want the
embedded URL as ONE Segment. Is there a built-in way in Restlet to do
this? (hint: I have already declared the template param service_url as
Variable.TYPE_URI_PATH.
Best regards
Ralf
Re: resourceRef.getSegments()
Ooopps ok I just read the RFE and saw that apparently its solved in the
newest milestone. Very nice I will try and test it as soon as possible! :-)
greetings
Ralf
Ralf Bommersbach schrieb:
Ok thanks I think I will do that!
Jerome Louvel schrieb:
Hi Ralf,
Stephan's idea is probably the best for now as the slashes will be
encoded
and ignore by the parsing done in getSegments().
In the future, we want to add automatic encoding and decoding to the
Template class so this would be fully transparent as you expected. Just
marking a variable as TYPE_URI_PATH should be enough for the Template
class
to know that the {servier_url} value needs to be encoded or decoded.
We have a related RFE already:
"Generation of URIs from URI templates and encoding"
http://restlet.tigris.org/issues/show_bug.cgi?id=506
Best regards,
Jerome
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé :
vendredi 30 mai 2008 12:43
À : discuss@restlet.tigris.org
Objet : Re: resourceRef.getSegments()
Hi Ralf,
you could url encode the service url.
best regards
Stephan
Ralf Bommersbach schrieb:
Hi there.
Suppose I have an URL that itself has an URL embedded, like
.../service/{service_url}/resource1/resource2/.../...
If I call request.getResourceRef.getSegments(), I get a list of all
the Segments of the URL, BUT because the method only looks for
slashes it also tokenizes the pieces of the embedded url. What if I
want the embedded URL as ONE Segment. Is there a built-in way in
Restlet to do this? (hint: I have already declared the template param
service_url as Variable.TYPE_URI_PATH.
Best regards
Ralf
Safari content-negotiation...
Hello, some time ago I posted a question regarding Firefox content-negotiation preferences (problem: prefers XML over HTML), see here: http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html as you can see in the thread I was able to solve the problem (with the help of the list, thanks very much) by using the Tunnelservice and the agent.properties / accept.properties files. I face now the same problem with Safari 3.1 for Windows. It also - per default - show the XML (only the text-content of the nodes) if there are multiple available representations and no explicit mimeType is requested (e.g. per file-extension). The difficulty I have in correcting this behavior is that the User-Agent template provided in the agent.properties seems to be the one for Safari-2 on Mac and the new one for Safari-3 on Windows is slightly different, as you can see here: http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html I have been trying to modify the user-agent template in the file so that it fits the Safari3, but so far I have no luck: I must be doing something wrong and I fear I have not enough in-depth understanding of how exactly the tunnelservice/user-agent mechanism works to get this right... and ideas/help would be appreciated, thanks! Best regards Ralf Bommersbach
Re: Safari content-negotiation...
That was my first idea too...
well,I've tested it and unfortunatley this doesn't work :-(
Thierry Boileau schrieb:
Hello Ralf,
what you need to do is to provide your own agent.properties file (as
said in the thread you mention), then add the following pattern, which
should work (I've not tested it):
Mozilla/{mozillaVersion} (Macintosh; U; {agentOs};{osData})
AppleWebKit/{appleWebKitVersion} ({appleWebKitComment})
Version/{familyVersion} {agentName}/{agentVersion}
best regards,
Thierry Boileau
Hello,
some time ago I posted a question regarding Firefox
content-negotiation preferences (problem: prefers XML over HTML), see
here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
as you can see in the thread I was able to solve the problem (with the
help of the list, thanks very much) by using the Tunnelservice and the
agent.properties / accept.properties files.
I face now the same problem with Safari 3.1 for Windows. It also - per
default - show the XML (only the text-content of the nodes) if there
are multiple available representations and no explicit mimeType is
requested (e.g. per file-extension).
The difficulty I have in correcting this behavior is that the
User-Agent template provided in the agent.properties seems to be the
one for Safari-2 on Mac and the new one for Safari-3 on Windows is
slightly different, as you can see here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
I have been trying to modify the user-agent template in the file so
that it fits the Safari3, but so far I have no luck: I must be doing
something wrong and I fear I have not enough in-depth understanding of
how exactly the tunnelservice/user-agent mechanism works to get this
right...
and ideas/help would be appreciated, thanks!
Best regards
Ralf Bommersbach
Re: Safari content-negotiation...
p.s. I changed "Macintosh" to "Windows" in the user-agent template,
still doesn't work.
Ralf Bommersbach schrieb:
That was my first idea too...
well,I've tested it and unfortunatley this doesn't work :-(
Thierry Boileau schrieb:
Hello Ralf,
what you need to do is to provide your own agent.properties file (as
said in the thread you mention), then add the following pattern, which
should work (I've not tested it):
Mozilla/{mozillaVersion} (Macintosh; U; {agentOs};{osData})
AppleWebKit/{appleWebKitVersion} ({appleWebKitComment})
Version/{familyVersion} {agentName}/{agentVersion}
best regards,
Thierry Boileau
Hello,
some time ago I posted a question regarding Firefox
content-negotiation preferences (problem: prefers XML over HTML), see
here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
as you can see in the thread I was able to solve the problem (with
the help of the list, thanks very much) by using the Tunnelservice
and the agent.properties / accept.properties files.
I face now the same problem with Safari 3.1 for Windows. It also -
per default - show the XML (only the text-content of the nodes) if
there are multiple available representations and no explicit mimeType
is requested (e.g. per file-extension).
The difficulty I have in correcting this behavior is that the
User-Agent template provided in the agent.properties seems to be the
one for Safari-2 on Mac and the new one for Safari-3 on Windows is
slightly different, as you can see here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
I have been trying to modify the user-agent template in the file so
that it fits the Safari3, but so far I have no luck: I must be doing
something wrong and I fear I have not enough in-depth understanding
of how exactly the tunnelservice/user-agent mechanism works to get
this right...
and ideas/help would be appreciated, thanks!
Best regards
Ralf Bommersbach
Re: Safari content-negotiation...
Ok thanks I tried the agent.properties from the svn and now it works...
again, Thanks a lot!
Ralf :-)
Thierry Boileau schrieb:
Hi Ralf,
>p.s. I changed "Macintosh" to "Windows" in the user-agent template,
still doesn't work.
Oops, I forget it.
I've tried with this one (that is to say after replacing "Macintosh" by
"Windows") and it works for me.
Mozilla/{mozillaVersion} (Windows; U; {agentOs};{osData})
AppleWebKit/{appleWebKitVersion} ({appleWebKitComment})
Version/{familyVersion} {agentName}/{agentVersion}
You have to create a org/restlet/data hierarchy of directory where you
put your "agent.properties" file in. Then, update your classpath with
this path (put it before the declaration of the org.restlet.jar.
I've also refreshed the agent.properties file in the svn repository.
best regards,
Thierry Boileau
p.s. I changed "Macintosh" to "Windows" in the user-agent template,
still doesn't work.
Ralf Bommersbach schrieb:
That was my first idea too...
well,I've tested it and unfortunatley this doesn't work :-(
Thierry Boileau schrieb:
Hello Ralf,
what you need to do is to provide your own agent.properties file (as
said in the thread you mention), then add the following pattern,
which should work (I've not tested it):
Mozilla/{mozillaVersion} (Macintosh; U; {agentOs};{osData})
AppleWebKit/{appleWebKitVersion} ({appleWebKitComment})
Version/{familyVersion} {agentName}/{agentVersion}
best regards,
Thierry Boileau
Hello,
some time ago I posted a question regarding Firefox
content-negotiation preferences (problem: prefers XML over HTML),
see here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
as you can see in the thread I was able to solve the problem (with
the help of the list, thanks very much) by using the Tunnelservice
and the agent.properties / accept.properties files.
I face now the same problem with Safari 3.1 for Windows. It also -
per default - show the XML (only the text-content of the nodes) if
there are multiple available representations and no explicit
mimeType is requested (e.g. per file-extension).
The difficulty I have in correcting this behavior is that the
User-Agent template provided in the agent.properties seems to be
the one for Safari-2 on Mac and the new one for Safari-3 on Windows
is slightly different, as you can see here:
http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html
I have been trying to modify the user-agent template in the file so
that it fits the Safari3, but so far I have no luck: I must be
doing something wrong and I fear I have not enough in-depth
understanding of how exactly the tunnelservice/user-agent mechanism
works to get this right...
and ideas/help would be appreciated, thanks!
Best regards
Ralf Bommersbach
Routing problem
Hello I have a little problem with routing which I just can't seem to
find a workaround, perhaps someone here has some idea...
Okay the thing is this:
In my application I have some routers that are linked together like this:
Router rootRouter = new Router(getContext());
Router fooRouter = new Router(getContext());
Router barRouter = new Router(getContext());
rootRouter.attach("", rootResource.class);
rootRouter.attach("/foo", fooRouter);
fooRouter.attach("", fooResource.class);
fooRouter.attach("/bar", barRouter);
barRouter.attach("", barResource.class);
... and so on...
My problem is this: At the moment I use as matching route for the
templates MODE_STARTS_WITH. The advantage is that its very forgiving,
particular it doesn't care wether there is a slash a the end of the url
or not. So HOST/foo leads to fooResource as well as HOST/foo/ .
The disadvantage is a that HOST/foo/nonsense matches (because of
MODE_STARTS_WITH) fooResource as well, which is _not_ what is intended.
(should get a 404 instead)
Okay I can always use MODE_EQUALS right? Thats what I thought too, but I
quickly realised that that mode is a litte _too_ unforgiving for my
needs: For example because of the very strict matching it will match
HOST/foo but HOST/foo/ will lead to a 404. I tried with setting 2 strict
routes, one with and one without the slash but then I got problems with
the next router down the line.
Summary: MODE_STARTS_WITH is a litte too forgiving, MODE_EQUALS a little
to strict, particular in regard to slashes at the end (which should make
no difference anyways)
Any ideas, tips, workarounds are highly welcome!
Best regards
Ralf
Bugfix for possible Nullpointer in Template.java
Okay I think I found a little bug in the Template.java (in the 1.1snapshot):
It occurrs when the UserAgentTunnel in the Application is set enabled
(setUserAgentTunnel(true) and your application gets a request where the
user-agent is omitted.
The Template then tries to parse the user-agent string and gets a
Nullpointer.
Here is the relevant part of the stackTrace:
java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.restlet.util.Template.parse(Template.java:756)
at org.restlet.data.ClientInfo.getAgentAttributes(ClientInfo.java:336)
at
com.noelios.restlet.application.TunnelFilter.processUserAgent(TunnelFilter.java:316)
at
com.noelios.restlet.application.TunnelFilter.beforeHandle(TunnelFilter.java:74)
and here a code snippet of the relevant part of Template.java at line
752 (with the fix):
public int parse(String formattedString, Map variables) {
int result = -1;
// fix
if (formattedString == null)
return result;
...}
Apparently Google Maps does this (i.e. no user-agent), as I pasted an
URL which points to an KML-Representation of a Resource in the Google
Maps Query Box and got the Nullpointer. (I can also see in the Server
log that there is no user-agent)
When I disable the UserAgentTunnel it works (google maps neatly displays
the kml then)
Okay thats it I think.
Greetings
Ralf Bommersbach
P.S. The fixed file is attached
/*
* Copyright 2005-2008 Noelios Consulting.
*
* The contents of this file are subject to the terms of the Common Development
* and Distribution License (the "License"). You may not use this file except in
* compliance with the License.
*
* You can obtain a copy of the license at
* http://www.opensource.org/licenses/cddl1.txt See the License for the specific
* language governing permissions and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each file and
* include the License file at http://www.opensource.org/licenses/cddl1.txt If
* applicable, add the following below this CDDL HEADER, with the fields
* enclosed by brackets "[]" replaced with your own identifying information:
* Portions Copyright [] [name of copyright owner]
*/
package org.restlet.util;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;
import java.util.logging.Logger;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import org.restlet.data.Reference;
import org.restlet.data.Request;
import org.restlet.data.Response;
/**
* String template with a pluggable model. Supports both formatting and parsing.
* The template variables can be inserted using the "{name}" syntax and
* described using the modifiable map of variable descriptors. When no
* descriptor is found for a given variable, the template logic uses its default
* variable property initialized using the default [EMAIL PROTECTED] Variable}
constructor.
*
* Note that the variable descriptors can be changed before the first parsing or
* matching call. After that point, changes won't be taken into account.
*
* Format and parsing methods are specially available to deal with requests and
* response. See [EMAIL PROTECTED] #format(Request, Response)} and
* [EMAIL PROTECTED] #parse(String, Request)}.
*
* @see Resolver
* @see http://bitworking.org/projects/URI-Templates/";>URI Template
* specification
* @author Jerome Louvel ([EMAIL PROTECTED])
*/
public class Template {
public static final int MODE_EQUALS = 2;
public static final int MODE_STARTS_WITH = 1;
/**
* Appends to a pattern a repeating group of a given content based on a
* class of characters.
*
* @param pattern
*The pattern to append to.
* @param content
*The content of the group.
* @param required
*Indicates if the group is required.
*/
private static void appendClass(StringBuilder pattern, String content,
boolean required) {
pattern.append("(");
if (content.equals(".")) {
// Special case for the TYPE_ALL variable type because the
// dot looses its meaning inside a character class
pattern.append(content);
} else {
pattern.append("[").append(content).append(']');
}
if (required) {
pattern.append("+");
} else {
pattern.append("*");
}
pattern.append(")");
}
/**
* Appends to a pattern a repeating group
Re: Routing problem
Okay thanks for all the answers. I see I'm not the only one with this problem. [EMAIL PROTECTED] schrieb: > using MODE_EQUALS on both, though, because when I use MODE_STARTS_WITH, > the user can pass, "/bar/this_is_nonsensical_garbage" and it matches Exactly Bruno Harbulot schrieb: To solve this at the moment, I make sure the users start using the system via a correct URI; all the subsequent URIs they get have the appropriate trailing slashes, since the representation that lead them to these other resources have been generated accordingly. If the user just follows the links I provide him in the representations, I'm fine yes. But this doesn't help if the user decides to alter the URI manually (e.g. in the adress bar of the browser) At the moment I have only the option between allowing the strangest uris to match or practically crippling my application to the point where its not usable anymore. Anyway, thanks for the helpful suggestions. Perhaps someone will have a glorious idea for how to solve this! :-) Greetings Ralf
get Resource-class for a specific URI
Hello I have a short question: Is there a way to get the resource-class for a specific URI from an RESTLET-Application during runtime, without actually doing the request? Something like "Class App.getMatchingResourceClass(String uriString)" ? I'm pretty sure there is something like this in the API - after all the Routers do exactly that during runtime to decide which resource matches an URI - but I can't for the life of me find the corresponding method(s) in the API... Any help would be very appreciated! Thanks! :-) Greetings Ralf
Re: get Resource-class for a specific URI
Ok thanks for the extensive answer, I will try to implement something along the lines you suggested. > ps: what is your need? Well I want to implement something like a "navigation-history" of the uri-syntax in my application. I want to display that graphically (either image-map or treenodes or something like that) and it's not enough to just list the urisegments as in my app there are differt possible 'uri-routes' to the same target and i need to determine at runtime which routes was taken, so I need a way to analyse each part of the hierarchical uri and find ou t which resource that is Because in REST you have no persistant state on the server, the only way to do that (I think) is to look at the differnt uri-segments and map them to the resources they belong. (hmm okay I know it sounds confusing, I hope the point comes across ;-) ) best regards Ralf Thierry Boileau schrieb: Hello Ralf, well, I'm not aware of such method... When routing a URI, the upper call is Router#getNext(Request, Response). This method is in charge to determine the right route according to the request and response objects (because URI templates may reference request and response properties). Then, the chosen route is in charge to handle the request and response (second call: Route#handle(Request, Response)). As it is a filter, it transfers the call to its "next" attribute (third call:Filter#getNext()) which is either a Restlet instance (such as an application, a guard, etc) or a Finder instance that wraps a resource class and instantiates it dynamically. At the end, the given Restlet or Resource instance handles the call. As you may have notice, Router does not really handle "Resource classes". Calls are routed to Restlet instances : a "true Restlet instance" or a Finder instance that wraps a Resource class which may explain why "Class App.getMatchingResourceClass(String uriString)" method does not exist at this time. An implementation of such method may more or less have to create the Request/Response couple from the URI: - request = new Request(Method.GET, uriString); response = new Response(request); Then, get the upper router of the application (application#getRoot()), call Router#getNext(Request, Response) and check the type of the returned object. If it is a finder, then call Finder#getTargetClass() in order to retrieve the resource class. Hum... best regards, Thierry Boileau ps: what is your need? Hello I have a short question: Is there a way to get the resource-class for a specific URI from an RESTLET-Application during runtime, without actually doing the request? Something like "Class App.getMatchingResourceClass(String uriString)" ? I'm pretty sure there is something like this in the API - after all the Routers do exactly that during runtime to decide which resource matches an URI - but I can't for the life of me find the corresponding method(s) in the API... Any help would be very appreciated! Thanks! :-) Greetings Ralf
WADL howto?
Hello, I read in the RC1 release note about the wadl-support and since it is one of the requirements of my application that it should be discoverable, it thought that it would be nice if I could automatically generate a WADL description of my application (e.g. to publish it in a catalogue/registry instance). Does the WADL extension support this (from my understanding it does) and are there any tutorials for it? It haven't found anything yet, besides the API, and to figure it out with from API alone is a litte tiresome ;) Best regards Ralf Bommersbach
Re: WADL howto?
Thanks alot. I'm able to retrieve descriptions of individual resources now, when I do a OPTIONS request on the resources URI. The *-targetUri however doesn't work. I get an empty response. But its okay for me now. Greetings Ralf Vincent Ricard schrieb: Hi Ralf, Does the WADL extension support this (from my understanding it does) and are there any tutorials for it? It haven't found anything yet, besides the API, and to figure it out with from API alone is a litte tiresome ;) I used the wadl component in the other way (specify the wadl file, and let WadlComponent load my Resource subclasses); but in your case, i think you "just" have to inherit WadlApplication to register your WadlResource subclasses (with createRoot), and for each resource override the 'describe' method. Excerpt from the javadoc: This description can be customized by overriding the #describe() and #describeMethod(Method, MethodInfo) methods. Hope this help. Regards,
Re: Restlet + Dojo?
Yes I am. Have a look at this: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/@http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos@/OFFERINGS/Buchensteige/observations (It's still a litte slow) Basically I use FreeMarker to dynamically generate HTML-representations of resources at runtime, including various Dojo elements. For example, one of them is a dojo-grid which uses the JSON-representation of the same resource as data-input for the grid embedded in the HTML-page. Greetings Ralf Justin Stanczak schrieb: Anyone using this combo? Any tips? Just wanted to give a shout out. I'm looking into using this combo, seems like a good fit. I would just use JSON services with Restlet resources.
Re: Restlet + Dojo?
Okay the link below seems to be broken: This should work: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/%40http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos%40/OFFERINGS/Buchensteige/observations Ralf Bommersbach schrieb: Yes I am. Have a look at this: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/@http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos@/OFFERINGS/Buchensteige/observations (It's still a litte slow) Basically I use FreeMarker to dynamically generate HTML-representations of resources at runtime, including various Dojo elements. For example, one of them is a dojo-grid which uses the JSON-representation of the same resource as data-input for the grid embedded in the HTML-page. Greetings Ralf Justin Stanczak schrieb: Anyone using this combo? Any tips? Just wanted to give a shout out. I'm looking into using this combo, seems like a good fit. I would just use JSON services with Restlet resources.
