RE: Java 6
I can run JVM6. The issue seems to be J6/Tomcat calling Restlet (J5) calling my resources J6. I can do 5/5/5 and 6/5/5, but not 6/5/6-as far as I can tell. Cliff Binstock Coyote Reporting _ From: Malcolm Sparks [mailto:malc...@congreve.com] Sent: Thursday, April 02, 2009 11:15 AM To: discuss@restlet.tigris.org Subject: Re: Java 6 A more general note: Applications compiled with Java 5 typically run on Java 6 JVMs without problems. Applications compiled with Java 6 don't run on Java 5 JVMs- the Java 5 JVM detects that the bytecode version is higher and therefore rejects it. So, in theory, you don't need a Java 6 build of Restlet. Which JVM are you running on? On 31 Mar 2009, at 17:57, Cliff Binstock wrote: Is it correct that the current build is based on Java 1.5? Is there a Java 6 build available? Or do I have to build this myself? Notably, I cant run a Java 6 compiled application under tomcat w/Java 6. Im not 100% certain, but it appears that this is because Restlet itself is 1.5 (I get class version errors loading the restlet application). Thanks much, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1565626
Java 6
Is it correct that the current build is based on Java 1.5? Is there a Java 6 build available? Or do I have to build this myself? Notably, I can't run a Java 6 compiled application under tomcat w/Java 6. I'm not 100% certain, but it appears that this is because Restlet itself is 1.5 (I get class version errors loading the restlet application). Thanks much, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1497681
POST redirect to GET
My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When I'm done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember I'm inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried ?method=get, but I suppose that's getting ignored because I'm not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335863
RE: POST redirect to GET
Thank you! Cliff Binstock Coyote Reporting _ From: Erik Beeson [mailto:erik.bee...@gmail.com] Sent: Monday, March 16, 2009 4:09 PM To: discuss@restlet.tigris.org Subject: Re: POST redirect to GET Go back and reread the HTTP spec. In particular, read about 303 See Other on the first hit here: http://www.google.com/search?q=http+status --Erik On Mon, Mar 16, 2009 at 3:57 PM, Cliff Binstock cliff.binst...@coyotereporting.com wrote: My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When Im done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember Im inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried ?method=get, but I suppose thats getting ignored because Im not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1336044
RE: DOM formatting
I would concur. The default should probably be false. However, I still think the feature is very useful: theres a lot to be said for having the default return readable. Also, I know I suggested indent, but it should probably be auto-format or pretty-print or some such: indent sounds like it should be a number (e.g., indent 4 characters). Cliff Binstock Coyote Reporting _ From: remidewi...@gmail.com [mailto:remidewi...@gmail.com] On Behalf Of Rémi Dewitte Sent: Friday, February 06, 2009 4:02 AM To: discuss@restlet.tigris.org Subject: Re: DOM formatting Jérôme, I have the feeling that defaulting it to true is not really the right thing to do. I think you don't need very often to have the XML output in a fashionable way and it will by default consume more resources for nothing. Because most of the time xml is not meant to be consumed by humans (except debugging). Moreover, IE or FF are both able to display XML trees. If you use curl to test your XML Restlet, just do somthing like this : curl url | xmllint --format - And you are done. Rémi On Fri, Feb 6, 2009 at 12:54, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Cliff, Good suggestion. I've just added this indent property to DomRepresentation in SVN trunk. Its value is true by default. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com _ De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoyé : vendredi 6 février 2009 00:40 À : discuss@restlet.tigris.org Objet : RE: DOM formatting Stephen, Thanks for the input still seems like it should be more trivial [ DomRepresentation#setIndent(boolean), perhaps ] Cliff Binstock Coyote Reporting _ From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] Sent: Thursday, February 05, 2009 1:41 PM To: discuss@restlet.tigris.org Subject: Re: DOM formatting Hi, Have you considered subclassing DomRepresentation and overriding its createTransformer() method to set the output properties you want (in your case, OutputKeys.INDENT to yes)? I had a case where I had to modify some properties of the XML being produced, and I found that the easiest way to do it was to subclass the representation in this way. On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock cliff.binst...@coyotereporting.com wrote: The DOMRepresentation, writes out the DOM as-is. Certainly this is great in most cases. However, it would be nice if there was pretty-print option that provided easy-to-look at XML. Of course, I can (and probably will) run the DOM through my own transformation to pretty-print, but it seems like use case might be a common desire. My current use case is building a Document with Elements, but no Text nodes, so the resultant XML is one unreadable line. If there is an existing trivial way to do this, great. If not, consider this a feature request. Thanks! Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1113782
DOM formatting
The DOMRepresentation, writes out the DOM as-is. Certainly this is great in most cases. However, it would be nice if there was pretty-print option that provided easy-to-look at XML. Of course, I can (and probably will) run the DOM through my own transformation to pretty-print, but it seems like use case might be a common desire. My current use case is building a Document with Elements, but no Text nodes, so the resultant XML is one unreadable line. If there is an existing trivial way to do this, great. If not, consider this a feature request. Thanks! Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1109135
Magic File Feature request
Another feature request: It would be very nice to have a way to tell the FileRepresentation to set the MediaType based on the magic type determination. There is no way to return the right type based a java.io.File today, is there? Thanks again, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1109596
RE: Custom conneg for (X)HTML media types
Simon,
Like you, I've been struggling between the default content negotiation, and
the fact that I want a) flexibility; b) reasonable default handling in the
browsers. Note that most of my routes can return many media types.
While I am considering revisiting the Metadata classes (per Jerome), I
currently have what you might call content negotiation logic in
Resource#generateRepresentation overrides.
One of the things I do here is just handle IE as an exceptional case.
Literally:
if (agent.equals(MSIE)
mtype.equals(MediaType.APPLICATION_XHTML_XML)) {
mtype = MediaType.TEXT_HTML;
}
So, the default (when reasonable) is to return XHTML. FF/Opera/etc. get the
XHTML content type; IE gets HTML.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Simon Reinhardt [mailto:simon.reinha...@koeln.de]
Sent: Friday, January 30, 2009 12:25 PM
To: discuss@restlet.tigris.org
Subject: Custom conneg for (X)HTML media types
Hi,
When working with XHTML you have to be careful how to deliver it. The
appropriate content type is application/xhtml+xml in which case the
supporting browser will treat it as XML (for parsing, in the DOM and in
CSS for example). However non-supporting browsers like IE will choke on
that and offer you the page for download. Therefore you can alternatively
serve it as text/html - with the disadvantage that it will be parsed and
treated as HTML.
Now, of course you can look into the Accept header to find out if the
browser will support XHTML or not and serve it under an appropriate
content type accordingly. The problem with that are the Accept headers
that browsers actually send. Opera and FF ask for both media types, with
the same preference, text/html coming first. IE doesn't ask for any HTML
media type at all but just tells you that it accepts some other stuff and
then anything with a preference of 1. So, the default conneg algorithm
doesn't work here: If I register two variants, the HTML one coming first,
then all browsers will get the HTML version. If I register two variants,
the XHTML one coming first, then all browsers will get the XHTML version,
even IE which doesn't support it.
This situation was being recognised by the W3C and they came up with a
custom conneg algorithm [1]. The idea is to only serve XHTML when it is
explicitly listed in the Accept header - and when it is, give it
precedence over HTML. They say there that you should do that for XHTML
documents that follow the compatibility guidelines and therefore can be
rendered by non-supporting browsers properly, so they don't really do
conneg but just serve one variant with different media types. But of
course nothing stops you from really writing two variants, one in HTML
4.01 and one in XHTML+SVG+MathML for example (the latter wouldn't be valid
to serve as text/html at all).
So the question here is, can you think of an easy way to implement this
custom conneg (or rather just Accept-header inspection) algorithm in
Restlet?
Thanks,
Simon
[1] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#media-types
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=107
6412
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1077338
RE: media type adaptor
Jerome, I am using the standard content negotiation, and am declaring multiple variants. The issue is that I have LOTS of variants (HTML, XML, Excel spreadsheets, and more), and sometimes the variant I return might have NOTHING to do with the content list requested (Excel, for example, is not in the IE or FF content request list). I will look at the MetadataService rewrite, which might help. However I don’t currently have a “general” rule (which I think is what the MetadataService remap might accomplish), but the type-to-return rules are determined by the requested URLs. I will consider this, however, maybe I can (and should) make it more consistent. Thanks for the pointing these items out. I definitely will look at both the MetadataService and the TunnelService to see if I can better use the infrastructure. Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:jerome.lou...@noelios.com] Sent: Friday, January 16, 2009 12:49 AM To: discuss@restlet.tigris.org Subject: RE: media type adaptor Hi Cliff, It seems like doing what you propose would overlap with the normal content negotiation which should be driven by client preferences. If you want to return the same representation as both application/xhtml+xml and text/xml, if can simply declare the two variants and return the same technical representation for each one of them, either via the current if/else if approach or in the near future via the representXhtml() and representXml() methods. Also, in the MetadataService, the same extension (ex: xml) can be mapped to several media types (ex: text/xml and application/xml) so in this case, the representXml() method would match both. Regarding the browser nonsense, we did implement a solution in the TunnelService that can automatically rewrite the preferences based on the user agent name (see the userAgentTunnel property). 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 : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoyé : jeudi 15 janvier 2009 19:31 À : discuss@restlet.tigris.org Objet : RE: media type adaptor J�r�me, Some more thoughts … from experience … 1. Need a flag to determine if alternate representations are acceptable (Requester asked for HTML, but I don’t have that, and wish to return XML). 2. If alternate is acceptable, need a prioritized (ordered) list of acceptable variants (look for XHTML, then look for HTML, then look for XML).� You should probably have a default, but it should be easy to override. 3. If you feel like getting into the browser nonsense (and I’d understand if you didn’t), bypass/translate to another type.� For example, IE doesn’t behave kindly to XHTML return type.� Of course, any behavior here must be customizable (overridable). Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:jerome.lou...@noelios.com] Sent: Wednesday, January 14, 2009 10:14 AM To: discuss@restlet.tigris.org Subject: RE: media type adaptor Hi all, We have a similar plan in the tube! Faciliate Resource to Representation mapping http://restlet.tigris.org/issues/show_bug.cgi?id=303 The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) and storeRepresentation(*) to the more specific versions if available like: representXml(?) for an XML representation (xml being mapped in MetadataService like for file extensions) representJson(?) for a JSON representation ... This would handle the dispatching automatically while still allowing a manual dispatching by overriding the generic represent(*) method when more appropriate (and for backward compatibility). How does it sound? 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 : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoy� : mardi 13 janvier 2009 17:43 � : discuss@restlet.tigris.org Objet : RE: media type adaptor Taylor, I have implemented a solution like this and I highly recommend it. I actually have taken it one step further and bound the routes (and the implementation) dynamically: there is very little Java code, mostly just XML-based configuration. In the cases where configuration does not make sense, then I have subclasses that provide an implementation as your message implies. I can tell you that you will want to pass in the request to the callback: you don’t always need it, but sometimes you need some contextual information (see previous post about wanting the original route URI, for example). Cliff Binstock Coyote Reporting _ From: Taylor Cowan
RE: Retrieving the UriTemplate associated to a Resource class
Fabio,
I had asked this question as well. The answer is to do this:
final Router router = new Router(getContext()) {
@Override
public Restlet getNext(final Request request,
final Response response) {
final Restlet result = super.getNext(request, response);
if (result instanceof Route) {
final Route route = (Route) result;
final String uriPattern =
route.getTemplate().getPattern();
s_logger.log(Level.INFO,User requested route: +
uriPattern);
request.getAttributes().put(TEMPLATE_URI_PATTERN_ATTRIBUTE, uriPattern);
}
return result;
}
};
You can then get the value with request.getAttribute
Cliff Binstock
Coyote Reporting
-Original Message-
From: Fabio Mancinelli [mailto:fabio.mancine...@gmail.com]
Sent: Wednesday, January 07, 2009 8:07 AM
To: discuss@restlet.tigris.org
Subject: Retrieving the UriTemplate associated to a Resource class
Dear all,
I have already implemented this by building additional infrastructure, but
I was wondering if, from inside a Resource, there is a way for retrieving
which UriTemplate is associated to a given Resource class.
To be more explicit:
In application:
router.attach(/myResource, MyResource.class)
In MyResource I would like to have something like:
getUriTemplateFor(MyResource.class) - /myResource
I digged a bit into the API but I haven't find anything like this.
Thanks,
Fabio
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=101
0096
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1022243
RE: media type adaptor
Taylor,
I have implemented a solution like this and I highly recommend it. I
actually have taken it one step further and bound the routes (and the
implementation) dynamically: there is very little Java code, mostly just
XML-based configuration. In the cases where configuration does not make
sense, then I have subclasses that provide an implementation as your message
implies.
I can tell you that you will want to pass in the request to the callback:
you don't always need it, but sometimes you need some contextual information
(see previous post about wanting the original route URI, for example).
Cliff Binstock
Coyote Reporting
_
From: Taylor Cowan [mailto:taylor_co...@yahoo.com]
Sent: Tuesday, January 13, 2009 7:12 AM
To: discuss@restlet.tigris.org
Subject: media type adaptor
I'm new to restlets and would like some feedback from the community on some
experimentation. Instead of if/else'ing through the list of variant types
and calling the appropriate logic, I'd like reslets to do that for me.
The example MediaType below is similar to the restlet version, except that
each enumeration overrides a call back, for example, the text/html type
calls back to handleTextHTML().
TEXT_HTML(text/html, HTML document) {
@Override
public Representation callBack(VariantHandler arg0) {
return arg0.handleTextHTML();
}
},
The application developer then extends a resource from BaseResource, and
implements the methods they'd like to handle. (like the AWT MouseEvent
adaptors of old) The examples are not complete, I only implmented 4 media
types. The BaseResource gets the media type, converts to the appropriate
extended MediaType, and the invokes the callback.
@Override
public Representation represent(Variant variant) throws
ResourceException {
String mediaType = variant.getMediaType().getName();
return MediaType.value(mediaType).callBack(this);
}
So to handle HTML, the developer just does this:
@Override
public Representation handleTextHTML() {
// here's where we respond to HTML clients.
}
http://restlets.s3.amazonaws.com/VariantHandler.java
http://restlets.s3.amazonaws.com/BaseResource.java
http://restlets.s3.amazonaws.com/MediaType.java
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1022252
RE: REQUEST FireFox cache control
Wow. Thanks for the great, detailed response. I will look at the non-standard header mechanism. And . I concur with you that IE isn't always right. Or worse, for things that you would think would be basic (like content-types, and cache control)-or at least handled consistently by 2008-IE, FF, Opera (and most certainly all others) have different ideas. Cliff Binstock Coyote Reporting _ From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 6:48 PM To: discuss@restlet.tigris.org Subject: Re: REQUEST FireFox cache control Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the transient property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#g etAttributes() This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-fire fox-and-ie-caching/ (which is hopefully correct), FF will only respond as expected if you also set no-store. In otherwords, Cache-control: no-cache no-store. See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 no-cache will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use no-store if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using no-store for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use no-store on pages that absolutely must not be reloaded for any reason, but generally use no-cache for good performance combined with good liveness of content. - R -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981752
Simple Reference suggestion
Another Restlet suggestion: The Reference class should definitely have a #toURI method. It should possibly also have a URI constructor. Thanks, Cliff -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981233
REQUEST FireFox cache control
It appears that Firefox doesn't respect expiration date or cache-control properly. I would like most/all of my routes to expire immediately (and require a reload). I'm guessing that Representation#setTransient sets the Cache-control: no-cache for the return headers. However, according to http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-and-ie-caching/ (which is hopefully correct), FF will only respond as expected if you also set no-store. In otherwords, Cache-control: no-cache no-store. REQUEST: Perhaps the indirect effect of setTransient could set both of these? Could someone point me to where the effect of #isTransient actually does something to the header? Thanks much, Cliff -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981380
RE: Restlet Directory suggestion
Jerome, Inline ... Thanks for the good feed-back on Directory. 1) Could you give more information/pointers? What do you want to transform with XSLT, the directory listing? Yes, the directory listing. While quite obtuse, in Tomcat there is a built-in XML directory listing to which you can apply a stylesheet. Perhaps you could automatically return different variants? 3) You could add a Guard filter in front of your Directory that would deal with that, unless the authorization is based on the actual file. Could you detail your use case a bit more? The basic guard isn't friendly enough. If I have users 'John', 'Fred', and 'Alice', I'd like to have /user/John; /user/Fred; /user/Alice. Each person has access only to their own directory (or perhaps some other complex authorization like groups). Cliff
Restlet Directory suggestion
Thierry, et al, I have been working with the Directory class, and running into limitations. I realized that because I am also running Tomcat, the built-in webdav met my needs. However--and because you were asking for suggestions--I realized that the Directory class could easily be improved: 1) Allow for stylesheets, see Tomcat's WebdavServlet setup (localXsltFile, and globalXsltFile). Note that a URI (instead of a path) would be even better. 2) Have the default representation return XHTML (instead of the current non X HTML). This would allow a programmatic caller to read the list as XML (a request from one of my users). 3) Add a simple authorization hook, or at least clearly describe how to authorize access to certain directories. Note that even in Tomcat, I had to go digging through the code to figure out how to subclass. 4) Add full webdav capability. Given that WebdavServlet is Apache License--and not very big--it seems that you could easily support full webdav out of the box. Cliff Binstock Coyote Reporting
Usurping Directory
I would like to modify the standard Directory to return something different than the file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the bottom (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom DirectoryResource which is attached to a Directory via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
RE: Usurping Directory
As an upgrade (Restlet request!), looking through the source code it seems that the simplest thing would be if I could insert my own ReferenceList implementation. Perhaps you could have a #setReferenceList option which would take my own (sub-)class. Not only could I change the HREF, but it would be great to put in my own HTML representation anyway, with style, logo, etc. Cliff _ From: Cliff Binstock [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 2:54 PM To: discuss@restlet.tigris.org Subject: Usurping Directory I would like to modify the standard Directory to return something different than the file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the bottom (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom DirectoryResource which is attached to a Directory via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
routes with URIs
To all,
Wondering if anyone has any experience or great ideas:
I have a need to specify URLs (not the uri-pattern) when fetching Resources.
A simple degenerate case is this:
/urls/{url}
Where {url} points to some random place on the web. While I have thought of
a number of workarounds, I can't come up with an elegant solution. As a
point of reference, a URL encoded URL doesn't seem to work with most
browsers. You might, for example, think that this:
http://www.example.com/foo.xml
Might turn into this:
http%3A%2F%2Fwww.example.com%2Ffoo.xml
or more precisely, for the aforementioned route:
/urls/http%3A%2F%2Fwww.example.com%2Ffoo.xml
But again, most browsers (at least IE and Firefox) aren't happy about this.
So far I've thought of solutions like:
* POST
* Require something besides / delimiter
* Pre-cache using something else (with POST), like /specify-url ...
* Use some sort of (non-standard) encoding
Has anyone had to do anything similar? Or any ideas on a user-friendly
solution?
Thanks in advance,
Cliff
RE: Router swallowing exceptions
I am using V1.1 RC2
Cliff Binstock
_
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2008 2:33 AM
To: discuss@restlet.tigris.org
Subject: Re: Router swallowing exceptions
Hello Cliff,
I get an Instantiation exception with a warning trace when running with the
current trunk.
ATTENTION: Exception while instantiating the target handler.
java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Instan
tiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.restlet.Finder.createTarget(Finder.java:186)
[...]
What release of Restlet are you using?
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/
I unfortunately accidentally discovered that if a Resource is not
instantiable (e.g., the class is abstract, constructor is protected, etc.),
the router-which is unable to complete its work-does nothing and doesn't
log anything either
It would be most appreciated if it would log a (probably SEVERE) error if it
was unable to instantiate the Resource.
For example, if you have this:
attach(router, /not-instantiable,
com.example.resource.MyAbstractResource.class);
and of course:
package com.example.resource;
public abstract class MyAbstractResource
extends Resource {
.
}
Thanks much,
Cliff Binstock
Coyote Reporting
Form Processing bug?
I believe there is something wrong, or at least unpleasant in the Restlet
Engine (V1.1 RC2).
I am using the language as a form input.
I have a simple test case (below) which mimics the form input.
Input of this:
http://localhost:8080/test?lang=all
http://localhost:8080/xbrlet/test/test?lang=alllanguage=allxyz=all
language=allxyz=all
Provides (expected):
Test Form Data:
lang = all
xyz = all
language = all
But, input of this:
http://localhost:8080/test?lang=fr
http://localhost:8080/test?lang=frlanguage=frxyz=fr language=frxyz=fr
Provides (unexpected):
Test Form Data:
lang = fr
xyz = fr
(note missing language = fr text).
Random sampling: It works for language=it, and de, but not en or
fr.
Is there something special about the language name? I can of course use
some other name, but I spent hours tracing this down. I have tried it in
Tomcat (my standard environment) and standalone.
Here's the quick test code, pasted basically into your HelloWorldResource
example:
@Override
public Representation represent(final Variant variant) {
final Form form = getRequest().getResourceRef().getQueryAsForm();
final StringBuffer formsb = new StringBuffer();
if (form != null) {
formsb.append(Form Data:\n);
for (String name : form.getNames()) {
final String value = form.getFirstValue(name);
formsb.append(\t);
formsb.append(name);
formsb.append( = );
formsb.append(value);
formsb.append(\n);
}
}
final Representation representation = new StringRepresentation(Test
+ formsb.toString(), MediaType.TEXT_PLAIN);
final Response response = getResponse();
response.setStatus(Status.SUCCESS_OK);
return representation;
}
Cliff Binstock
Coyote Reporting
RE: uriPattern exactness
Erik,
Great question. Its not so much that the routes change at runtime
(although I was contemplating user-configurable routingwouldnt that be
intriguing!), but I want the behavior to change at runtime. Ultimately, we
will allow users to define their own behaviors (you dont like the XML we
return for one of the routes? Specify your own).
The immediate (and most annoying) problem is that the web server Resources
are extremely light weight, and we have a whole bunch of one-line
Resource classes to call the corresponding behaviors, which is ridiculous,
not to mention tedious, error prone, and a maintenance annoyance. Even
today, all of the behavior-switching is taken care of by a single abstract
class.
Cliff Binstock
Coyote Reporting
_
From: Erik Beeson [mailto:[EMAIL PROTECTED]
Sent: Monday, October 20, 2008 3:23 PM
To: discuss@restlet.tigris.org
Subject: Re: uriPattern exactness
In what scenario (other than maybe development) do your routes change at
runtime?
--Erik
On Mon, Oct 20, 2008 at 2:44 PM, Cliff Binstock
[EMAIL PROTECTED] wrote:
Jérôme,
I thought of another reason why it would be *really nice* to know the
matching URI pattern: I would like to be able to dynamically determine how
to handle a resource request from a configuration. To simplify my actual
use case, suppose for example that I implemented a default resource, and the
default resource could look at, say, an external XML configuration file to
determine which class to really call (dynamically). This external
configuration might look like:
entry
matching-uri-pattern/foo/{foos}/bar/matching-uri-pattern
invokecom.coyotereporting.foo.Bar/invoke
/entry
Right now, I can see how to use the above to dynamically define *resources*
once on startup, but not how to abstract this one level to have the
default resource call different handlers on the fly.
So, if I can add to the long term request list:
1) Get back the original URI (e.g., /foo/{foos}/bar)
2) Get back the as-matched URI (e.g., /foo/myFoo/bar).
Note that #1 above (original URI Pattern), would enable a very flexible
default handler.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 4:02 AM
To: discuss@restlet.tigris.org
Subject: 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: uriPattern exactness
Thierry,
This works great, thank you very, very much! I now have fully dynamic
behaviors.
Can I suggest that you make this a standard attribute? Regardless, this
works for me.
Cliff Binstock
Coyote Reporting
_
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2008 12:26 AM
To: discuss@restlet.tigris.org
Subject: Re: uriPattern exactness
Hi Cliff,
as a workaround, you can derive the Router class and override the getNext
method. It will give you access to the route, and then the matched pattern:
Router router = new Router(getContext()) {
@Override
public Restlet getNext(Request request, Response response) {
Restlet result = super.getNext(request, response);
if (result instanceof Route) {
Route route = (Route) result;
request.getAttributes().put(pattern,
route.getTemplate().getPattern());
}
return result;
}
};
By doing so, you're able to update the request and include the pattern as an
attribute.
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/
Jérôme,
I thought of another reason why it would be *really nice* to know the
matching URI pattern: I would like to be able to dynamically determine how
to handle a resource request from a configuration. To simplify my actual
use case, suppose for example that I implemented a default resource, and the
default resource could look at, say, an external XML configuration file to
determine which class to really call (dynamically). This external
configuration might look like:
entry
matching-uri-pattern/foo/{foos}/bar/matching-uri-pattern
invokecom.coyotereporting.foo.Bar/invoke
/entry
Right now, I can see how to use the above to dynamically define *resources*
once on startup, but not how to abstract this one level to have the
default resource call different handlers on the fly.
So, if I can add to the long term request list:
1) Get back the original URI (e.g., /foo/{foos}/bar)
2) Get back the as-matched URI (e.g., /foo/myFoo/bar).
Note that #1 above (original URI Pattern), would enable a very flexible
default handler.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 4:02 AM
To: discuss@restlet.tigris.org
Subject: 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: uriPattern exactness
Jérôme,
I thought of another reason why it would be *really nice* to know the
matching URI pattern: I would like to be able to dynamically determine how
to handle a resource request from a configuration. To simplify my actual
use case, suppose for example that I implemented a default resource, and the
default resource could look at, say, an external XML configuration file to
determine which class to really call (dynamically). This external
configuration might look like:
entry
matching-uri-pattern/foo/{foos}/bar/matching-uri-pattern
invokecom.coyotereporting.foo.Bar/invoke
/entry
Right now, I can see how to use the above to dynamically define *resources*
once on startup, but not how to abstract this one level to have the
default resource call different handlers on the fly.
So, if I can add to the long term request list:
1) Get back the original URI (e.g., /foo/{foos}/bar)
2) Get back the as-matched URI (e.g., /foo/myFoo/bar).
Note that #1 above (original URI Pattern), would enable a very flexible
default handler.
Cliff Binstock
Coyote Reporting
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 4:02 AM
To: discuss@restlet.tigris.org
Subject: 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: 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: uriPattern exactness
Thierry,
Actually what I want to do, sometimes, is abort the processing.(and probably
return a Not Found error).
Right now, the caller can use a somewhat garbage uri, and the uriPattern
will match. Note that I want to be very selective, because I want to match,
for example ./bar.xml, but probably not ./barlksjfljj.xml.
Thanks.
Cliff Binstock
Coyote Reporting
_
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 2:27 AM
To: discuss@restlet.tigris.org
Subject: Re: uriPattern exactness
Hi Cliff,
I'm sorry, but I think I miss your question. ;)
What do you want to do? What kind of entity will handle the data: the exact
matched pattern for /foos/myFoo/barlksjfljj.xml ?
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/
I was wondering if there is some trick way to find the exact matched
pattern. Specifically, I am seeing this (somewhat logical) behavior.
If the uriPattern is /foos/{foo}/bar
This of course matches something like /foos/myFoo/barlksjfljj.xml
What I want is: If I type in /foos/myFoo/barlksjfljj.xml, I could
determine that /foos/myFoo/bar was the actual match.
Maybe I just missed an existing API call? :)
Thanks much in advance,
Cliff Binstock
RE: uriPattern exactness
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.
Cliff Binstock
Coyote Reporting
_
From: Cliff Binstock [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 8:54 AM
To: discuss@restlet.tigris.org
Subject: RE: uriPattern exactness
Thierry,
Actually what I want to do, sometimes, is abort the processing.(and probably
return a Not Found error).
Right now, the caller can use a somewhat garbage uri, and the uriPattern
will match. Note that I want to be very selective, because I want to match,
for example ./bar.xml, but probably not ./barlksjfljj.xml.
Thanks.
Cliff Binstock
Coyote Reporting
_
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 2:27 AM
To: discuss@restlet.tigris.org
Subject: Re: uriPattern exactness
Hi Cliff,
I'm sorry, but I think I miss your question. ;)
What do you want to do? What kind of entity will handle the data: the exact
matched pattern for /foos/myFoo/barlksjfljj.xml ?
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/
I was wondering if there is some trick way to find the exact matched
pattern. Specifically, I am seeing this (somewhat logical) behavior.
If the uriPattern is /foos/{foo}/bar
This of course matches something like /foos/myFoo/barlksjfljj.xml
What I want is: If I type in /foos/myFoo/barlksjfljj.xml, I could
determine that /foos/myFoo/bar was the actual match.
Maybe I just missed an existing API call? :)
Thanks much in advance,
Cliff Binstock
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
uriPattern exactness
I was wondering if there is some trick way to find the exact matched
pattern. Specifically, I am seeing this (somewhat logical) behavior.
If the uriPattern is /foos/{foo}/bar
This of course matches something like /foos/myFoo/barlksjfljj.xml
What I want is: If I type in /foos/myFoo/barlksjfljj.xml, I could
determine that /foos/myFoo/bar was the actual match.
Maybe I just missed an existing API call? :)
Thanks much in advance,
Cliff Binstock
