Hello,
We've been greatly enjoying migrating our WCM and commerce platform
to the Restlet API. We have a versioned filesystem historically
exposed via a WebDAV Servlet, which was reasonably straightforward to
adapt to Restlet.
One issue, however, seemed to require a patch to get past;
d'origine-
De : Rob Heittman [mailto:[EMAIL PROTECTED]
Envoyé : mardi 14 août 2007 20:35
À : discuss@restlet.tigris.org
Objet : Proposed OPTIONS compliance patch
Hello,
We've been greatly enjoying migrating our WCM and commerce platform
to the Restlet API. We have a versioned
I just saw this behavior in svn trunk on Simple with not just POST, also
PROPFIND and PUT ... anything with an entity body in the request. I worked
around it with the new Request.release() mechanism, but was not able to locate
the underlying cause.
-Original Message-
From: Adam Taft
-
De : Rob Heittman [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 16 août 2007 01:51
À : discuss@restlet.tigris.org
Objet : Re: Keep Alive Problem with Simple Framwork
Confirming all three methods exhibit the same problem on
Simple with 1.0-current as well as trunk. I'll look at it
further
This is a requirement of our application as well. Thanks for the patches ...
this will hold us short term.
-Original Message-
From: Alex Milowski [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: 8/16/07 6:25 PM
Subject: Patches for Adding/Removing Hosts between Component Restarts
I have a number of services that expose their API via HTTP. These services are
independent, but interoperate; thus, a Content Service might interrogate a User
Service to determine profile information for a user. The services might be on
the same host, or they might be on distributed hosts.
Sorry, I missed that RFE when I searched (I thought optimize internal calls
meant something about refactoring) I'll look at the approach you recommend. But
the customized HTTP Client extension might be a less patch-intensive way for me
to bridge the gap in between now and 1.2M1.
I
Jerome has some nice discussion and illustrations on blog.noelios.com that
covers the relationship of Restlet to JSR 311 -- and, by induction, Jersey.
Restlet is more mature (still young, but stable) and offers broad coverage of
the tasks involved in coding and fielding a web application ... I
To my mind, what's misleading about the current setup is the inconsistent
semantics. Other flavors of getEntityAsXXX return XXXRepresentation:
DomRepresentation getEntityAsDom()
SaxRepresentation getEntityAsSax()
By association, developers may intuit that getEntityAsObject should
Not my experience. With the grizzly test target removed or the needed
dependencies added, it should work well, except for new/experimental stuff.
We're developing against trunk pretty actively at our shop.
-Original Message-
From: Sean Landis [EMAIL PROTECTED]
To:
Why do you think DOM or Form does not belong? You should be able to represent
resources in any language, markup, or format you want and still follow the REST
architectural style. For example, I have a service for interacting with user
profile data:
GET .../profile/[EMAIL PROTECTED]
From an architectural purity perspective, I agree with you ... while I like
and use the syntactic sugar provided by getEntityAs, the methods currently
provided are a bit inconsistent (per our earlier discussion), don't cover
every possible case, and don't lend themselves readily to user
Thanks, I'll check it out. Sorry I was never able to condense the test case; we
only reproduce it cleanly with our prototype WebDAV server (which I'm not ready
to share yet) and wdfs.
- Original Message -
From: Thierry Boileau [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent:
-nameServerServlet/servlet-name
* url-pattern/*/url-pattern
* /servlet-mapping
*
* @author Rob Heittman [EMAIL PROTECTED]
*/
public class RestletServlet extends ServerServlet {
private String module = null;
private static final long serialVersionUID = 1L
Thanks, Tom,
I started with that, but there were resourceRef problems in my application when
mounting the ServerServlet anywhere other than root under GWT. Operations like
getBaseRef() and did not return the same as if the application was mounted at
the same path under a normal web-app, or
Been looking for it, but I'm trying to find where the Restlet framework does
any URL decoding at all ... my apps get a lot of special characters in URIs,
and we have to decode them explicitly with URLDecoder.decode(...) or
Reference.decode(...) which wraps it. Restlet's Reference class is
On #1, I don't know much about Atom but if it's an XML type feed, I'd extend
XmlRepresentation, SaxRepresentation, or DomRepresentation, or at the very
least OutputRepresentation (which the API recommends as a good starting point
for user defined Representations).
On #2, the incoming
It bit me too, the other day. The hang seems to be limited to https
connections. I was able to workaround by using http, which isn't a long term
solution. A fix isn't obvious, and sadly I won't be able to dig deeper for
about a week due to other commitments. Thierry, any ideas?
-
There's a massive amount of er, what did you say, dry theory and voluntary
speak on the question of sessions and continuations vis-a-vis REST. Unashamed,
I'll add more.
The rub here is adherence to Fielding's Stateless constraint (5.1.3: each
request from client to server must contain all
I attached a test case that's repeatable for me. Takes 3 requests (of any
flavor) to cause the lockup. No idea why.
- Original Message -
From: Thierry Boileau [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Wednesday, September 5, 2007 5:33:02 PM (GMT-0500) America/New_York
Hi Justin,
Purely practical cookie issues:
1) Browsers that follow the original Netscape cookie definition limit a single
cookie to 4096 bytes, with a maximum of 20 cookies per site. Due to encoding
issues and overhead your actual storage limit will vary by a few bytes. IE
recently
Hi Jim,
I was trying to find how to manipulate http headers (standard or
extension) from a Resource class. I can't seem to get access to the
headers through the Response class.
http://www.restlet.org/documentation/1.0/faq#01
But the mechanism described here only allows you to set
- Original Message
From: Rob Heittman [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Wednesday, September 5, 2007 9:52:55 AM
Subject: Re: Routing and URL decoding
Been looking for it, but I'm trying to find where the Restlet framework does
any URL decoding at all ... my apps
Ooops. Not P/R/G. You want, then:
response.setStatus(Status.SUCCESS_CREATED);
response.setLocationRef(yourCreatedURIString);
- R
- Original Message -
From: Jim Alateras [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Thursday, September 6, 2007 4:23:17 PM (GMT-0500)
We just started integrating JRuby and are already using Rhino.
In our case, though, the script does not have full access to the request and
response; the scripting just provides access to middle tier applicaiton level
objects. We do put our script factories at the Application level for now
I gotta quit working in trunk all the time.
setRedirectRef(...) does the same thing in 1.0.5, but is deprecated in trunk
(1.1 and forward), I assume because Location: gets used for other things than
redirects (e.g. creates).
- Original Message -
From: Jim Alateras [EMAIL PROTECTED]
Is this different from using CLAP, or is this what you need:
component.getClients().add(Protocol.CLAP);
router.attach(/content,new Directory(getContext(),
clap://thread/com/solertium/example/content));
- Rob
- Original Message -
From: Alex Milowski [EMAIL PROTECTED]
To:
If you mean from a browser-based form, you probably want to use POST to emulate
a PUT, unless you want to use AJAX. Restlet provides help for tunneling PUT
over POST; see this FAQ entry:
http://www.restlet.org/documentation/1.0/faq#19
- Original Message -
From: katrin [EMAIL
Justin S: If you don't want to have sessions, show us a pattern that can fill
the void.
Kyrre K: ...implement it either as a plug-in, code templates, or document it
as the recommended way.
I think the documentational path is the first approach, and I don't know that
the discuss list is the
What I don't under stand is in the documents talk about
creating domain object using Resources, but doesn't have the Finder
create them for you limit a developers control?
Yes. In trade for looser binding between a resource and the
infrastructure that manages its URI space.
I find it
Storage/SAN vendors are pushing a lot of solutions in the cluster
shared resources space and I'm seeing this crop up a lot more in
enterprises with HA applications.
If one could find a solution that doesn't have driver issues and
properly does atomic NIO locks, etc., in concept it would be very
We will try
to launch a Developer Guide effort ASAP. I want to build it with DocBook,
one XML document per chapter, all versionned in SVN and automatically
published on the Restlet.org web site. That will allow contributions via SVN
patches and publication to various output formats.
can help decide by answering specific questions and/or
lending a hand...
regards,
-marc=
Rob Heittman wrote:
We will try
to launch a Developer Guide effort ASAP. I want to build it with DocBook,
one XML document per chapter, all versionned in SVN and automatically
published
Hi Jeff,
I'd say it makes sense the way it is; most two-factor systems can look up the
second factor given only the username, certificate-hash, or some other
Stringified representation of the first factor. For a multi-factor system,
chained Guards sometimes work well to do multiple checks
Just remember: Bugzilla URLs make Jakob Nielsen cry.
// +1 for new issue tracker soonish ;-)
- Original Message -
From: Jerome Louvel [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Saturday, September 15, 2007 7:49:52 AM (GMT-0500) America/New_York
Subject: RE: 1.1
Very cool, Jerome, I'd almost forgotten about this one. That was how I
originally hoped you could make it work.
- Original Message -
From: Jerome Louvel [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Monday, September 17, 2007 4:16:50 PM (GMT-0500) America/New_York
Subject:
: DirectoryResource is broken if used with relative paths
On Mon, 17 Sep 2007 11:26:08 -0400, Rob Heittman wrote:
1)
// Create a directory able to expose a hierarchy of files
Directory directory = new Directory(getContext(),
LocalReference.createFileReference(new File(./).getPath()));
This one
I'm getting a test failure building trunk 2181, probably this change is the
culprit?!?
[junit] java.lang.ClassCastException: org.restlet.data.Reference
[junit] at
org.restlet.data.LocalReference.getTargetRef(LocalReference.java:333)
etc.
- Rob
- Original Message -
From:
The XML parser in use is complaining about whitespace or characters
appearing before the ?xml version=1.0? statement. I just ran the
example on my OS X 10.4 machine and did not have trouble, though I'm
using Eclipse and not Xcode.
Can you insert something like
My gut feeling is that this is something you should configure explicitly.
You're looking for information that J2EE does not require passing to
servlets as part of their initialization mechanism, so Restlet has no way
of knowing this. (There may be a tomcat specific way using attributes
of
I concur with Mitch, RESTful authentication is done per request -- there are
lots of good ways to do it; if each request contains sufficient information to
be independently authenticated and acted upon by the server, it's RESTful.
It sounds from your description that you might be building
No, SSL operates at the transport layer. It is not sniffable in transit.
One highly undesirable feature, though, is that it will be recorded in
logfiles, which are generally not treated with care.
- Original Message -
From: Mitch Stewart [EMAIL PROTECTED]
To:
The main reason I've used it is to fetch content-length and make any
necessary provisions (check storage space, warn user, etc.) on the
client side before fetching the representation.
In this case you definitely don't want the whole GET response coming
at ya.
- Original Message -
Very interesting reference about the double checked locking idiom. I was
unaware of the problems, and had actually read some of the papers advocating
it.
I do a lot of multithreaded Java work in critical environments, and probably
need a refresher on these issues. Can you recommend any good
... but I'd like them to.
I assume the trouble is that you can't really get listings from the classpath,
so the content negotiation behavior is broken.
Do you think there is a way I could add workarounds to the existing
Directory/DirectoryResource implementation, or do I just need a custom
Nope, this doesn't work:
Directory d = new Directory(getContext(),
clap: //thread/client-bin);
d.setNegotiateContent(false);
d.setIndexName(index.html);
guard1.setNext(d);
Though this does:
Directory d = new Directory(getContext(),
file: //home/imaginary/build/dir/client-bin);
Interesting question on a number of levels.
Are you using HTTP as the transport mechanism, or your own protocols following
REST principles? In the absence of a correct and bounded Content-length header
property, you will have problems with a number of client and server libraries,
and
trunk sends the deprecation INFO message when setting Cache-control via the
addAdditionalHeaders hack.
The Cache-control header setting is important for trying to interoperate with
certain browsers.
I searched but did not find any traffic on the planned means for supporting it.
I'd love to
I currently have some spare cycles to do some transplanting from the old Wiki
to the new one; if I just look for things that fit roughly somewhere into the
proposed new TOC and graft them over, would that be helpful or a hindrance? If
appropriate, I can add a NOTE: This information is copied
Restlet is available under GPL as one of the licensing choices.
I think GPL2 was the only valid choice at the time that
http://www.restlet.org/about/legal was authored, and it links to it at
http://www.opensource.org/licenses/gpl-license.php.
Is it the intent to keep Restlet available only
oo. good catch. this fixes an outstanding bug in my WebDAV implementation :-)
- Original Message -
From: Alex Milowski [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Wednesday, November 14, 2007 4:46:48 PM (GMT-0500) America/New_York
Subject: Patch for if-match: *
I found
I think this is what you want:
http://www.restlet.org/documentation/1.0/tutorial#part06
- Original Message -
From: Paul J. Lucas [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Thursday, November 15, 2007 1:05:56 PM (GMT-0500) America/New_York
Subject: New user: guidance
() and
getIndexVariants(), yes?
- Paul
On Nov 15, 2007, at 11:02 AM, Rob Heittman wrote:
I think this is what you want:
http://www.restlet.org/documentation/1.0/tutorial#part06
- Original Message -
From: Paul J. Lucas [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent
: Thursday, November 15, 2007 11:07:17 PM (GMT-0500) America/New_York
Subject: Re: New user: guidance for server?
On Nov 15, 2007, at 1:24 PM, Rob Heittman wrote:
For the resizing and conversion operations, that's a larger question
with some design decisions involved. Here, I think you
to convince him ...
;-)
- Rob
- Original Message -
From: Paul J. Lucas [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Saturday, November 17, 2007 3:43:55 PM (GMT-0500) America/New_York
Subject: Re: Easier way to get an HTTP header?
On Nov 17, 2007, at 12:28 PM, Rob Heittman wrote
PROTECTED]
To: discuss@restlet.tigris.org
Sent: Sunday, November 18, 2007 12:26:50 PM (GMT-0500) America/New_York
Subject: Restlet 1.2 (Was: Easier way to get an HTTP header?)
On Nov 17, 2007, at 2:42 PM, Rob Heittman wrote:
It, and other full WebDAV stuff is targeted to land in Restlet 1.2.
When
I read the setModifiable() behavior as equivalent to setting write
privileges on a mounted filesystem -- it determines whether the
entire Directory (tree) supports modification operations in concept.
The METHOD_NOT_ALLOWED vs INTERNAL_SERVER_ERROR observation makes
sense to me. Might be
Jerome,
In my noodling with DAV method support, COPY and MOVE are especially
challenging to implement. By extending Directory and friends, you
can model a COPY as a GET and a PUT, and a MOVE as a GET, DELETE, and
PUT, but this is messy, not atomic in the right ways, and not very
performant.
Just wanted to report that my team has started using an updated
trunk for active development and it's successfully purged a
number of our hacks.
The optimized internal calls are working better than
our version, and the fixes to the behavior of clap: have made
a big difference in our ability to
That would be great. While doing this, be very careful when dealing with
content negotiation aspects. It took us a lot of efforts to get those right.
What is your take on the semantic meaning of content negotiation in
conjunction with a PUT or DELETE operation, as that obviously informs
Isn't this just more evidence that it's very hard to specify interfaces in
unstable APIs?
Yep. And yet, why it's tempting to use them in certain ways. In full
disclosure mode, these public API design questions interest me deeply for
reasons of state not strictly related to Restlet, so
To me, the Reference class actually seems quite lightweight and efficient for
the amount of usefulness and flexibility it provides to consumers and mutators
of the Reference. I understand the idea of having nice syntax for building up
a Reference. What if there was something independent,
Oh, no, I'm about to agree unconditionally with Paul. :-)
Why should it enforce the order? The burden should be on the
implementor, not the user. Don't use a StringBuilder: use simple
fields:
class URI {
private String scheme;
private String host;
// ...
}
Yeah, that. The
I have to ask - why not just WebDAV here? Subversion supports it already,
AFAIK.
I tend to agree, but pragmatically it's not that easy. WebDAV isn't quite a
done deal in Restlet yet, though it's possible with some extra flexing, as some
recent threads here rehearse.
And the versioning
Sounds reasonable to me and would fill our use case nicely.
I agree it should not derive from IOException. In the WebDAV code where we
use the exception idiom most heavily, only about 20% of the exceptions are
thrown due to I/O issues, the rest relate to other issues. For example, I
feel that a
Pragmatically, we have found Jetty the best to embed; our apps usually need
HTTPS support.
The new Net connector in 1.1 (which requires no external dependencies) is
great for a very simple http based embedded solution with a minimal
footprint. We are experimenting with this for installable
In the case you give, I would use a redirect, with Response.redirectOther as
described in http://permalink.gmane.org/gmane.comp.java.restlet/2971 -- for
exactly the reason Stephan describes. This is established practice as
codified in the HTTP RFCs, and ensures that any random well-behaved user
I think, before I made any sound observations, I'd want to know more about
your use case and what functional effects are exposed by this particular
POST.
In general, there's nothing illicit about POST returning either a meaningful
representation, or a redirect. Either of these are the two most
I apologize for being dusty.
I just gave it a try on several user agents and 201 Created worked fine. I
did have problems with it in the past, but the past is, well, past. :-)
- Rob
Did we ever come up with a definitive list of which high level Restlet
objects are expected to be thread-safe and which are not? I thought so, but
could not find it on the list. I wanted to add some JCIP concurrency
annotations to some of our code base and wanted to make sure I was
expressing
Thanks, Tim, that confirms what I generally thought.
I guess John's idea was one of the things that got me wondering what the
policy was supposed to be for Resources, and whether it could possibly
change in the future.
- Rob
Hi Pavel,
I'd start with the resource reference exposed by Request, and use the
methods of the Reference object to do what you want, e.g.
response.redirectTemporary(
new Reference(
request.getResourceRef().getParentRef().getParentRef(),
group/ + groupId
)
);
But Jerome and friends,
I left out a step in the first example I typed. You have to explicitly
getTargetRef() ... I did this in the second block of code but omitted it in
the first. So, that example, corrected is:
response.redirectTemporary(
new Reference(
request.getResourceRef ().getParentRef().getParentRef(),
On 12/19/07, David Koelle [EMAIL PROTECTED] wrote:
But at this point, doing such a thing would amount to lying, wouldn't you
agree?
In my case, certainly. I could not claim to not have been exposed to the
source. And in any case, I would prefer to be able to credit the original
proponent of
What a great holiday gift! Thanks, Jerome and Thierry, for all your hard
work, and receptiveness to crazy ideas from the list.
- R
We have now reached our first milestone towards the release of Restlet 1.1
which is scheduled for the beginning of Q2 2008.
Just a clarification to my earlier comment, allowing protocols to remain
null causes an NPE in ServletWarClient -- Tim's patch does not have that
problem.
On 12/29/07, Tim Peierls [EMAIL PROTECTED] wrote:
Are there really use cases where the list of protocols needs to be changed
dynamically? (I can construct an artificial example, but I want to know if
anyone really does this in practice.)
I kind of doubt dynamically -- but in practice, we
Anybody already have a good pattern for implementing OpenID login to a
Restlet based web site?
- Rob
I'm in process of adding the ability to specify the component to
instantiate
via a Servlet parameter. This is useful for multi-applications components
as
well as for specifying client connectors. See related issue:
http://restlet.tigris.org/issues/show_bug.cgi?id=407
Cool! I added myself
I was thinking specifically about browsers authenticating to a Restlet-based
Web site (so that would mean a little code for doing the necessary
redirects, cookie settings, and response interrogation -- probably plugging
in the sxip library).
But now that you mention it, it would be really neat if
Here's my GWT-invoking-via-reflection ServerServlet. It does seem to work
from the GWT perspective. But, I don't think the custom Component
instantiation is working quite right (or I broke it, or I still don't have
it configured correctly) -- my custom Component is instantiated, but its
Client
This thread too (also featuring Aron) ...
http://restlet.tigris.org/servlets/ReadMsg?list=discussmsgNo=2930
There's no police force that requires you to version a service, but if you
think there will be evolution of the URI space in the future and can't
control clients' upgrade behavior, it's
I suspect you want this instead:
Form headers = (Form) response.getAttributes().get(
org.restlet.http.headers);
per
http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes()
and http://www.restlet.org/documentation/1.1/faq#01
The headers are not mapped
Is there a particular reason you are using 1.0.4, since 1.0.7 is current
(and I can't think of too many reasons to resist upgrading)?
This works for me right now. I'm using trunk, but I know of nothing in the
1.0.7 tag that would make it work any differently.
import org.restlet.Client;
import
Concerning the support of a Restlet client API for GWT, I'm eagerly
waiting
for the release of GWT 1.5 (with support for most Java 5 language
features)
Aren't we all! I want my generics back.
I'm also open to finding ways to merge both efforts. For example, Jon R.
Crosby could lead the
Jerome,
What's the advantage of Filter.handle being final?
- R
The Restlet project sort of gives the message (by the example of
restlet.orgetc.) that Simple is the best thing to run Restlet servers
on top of, when
-- at least in my opinion -- in fact it's really not. The Simple project
seems kind of unresponsive to Restlet's needs. So maybe it's time for a
I shyly point out that Restlet is very capable of interacting with simple
relational databases without requiring an object-relational mapping layer.
You definitely want the ORM layer if your application domain objects need to
be mapped to a complex multi-table relational structure.
On 1/12/08,
I can't fault your design given your constraints. I think the general
concept: identifying links with hierarchical URIs descending from the URI of
each linked object, is at least a common idiom if not an established
pattern. I have both seen and used this style a number of times.
I have also
1.) Instead of sending a PUT to
/resource1/{r1_identifier}/resource2/{r2_identifier}, you could try
sending a PUT to /resource1/{r1_identifier}/resource2/ with
{r2_identifier} as the entity body?
It's not reversible for a many to many relationship unless
I have not come across a situation where I needed to use my own status
code, so I do not know if you are prohibited in doing so.
Though, this does sound like a useful feature.
The behavior of intermediaries, such as forward and reverse proxies, would
be undefined in relation to a custom
Perhaps, but that shouldn't be for you^D^D^DJerome to decree.
Fixed that for ya. :-)
In my case, we're dealing with a custom server and a custom client
that talk only to each other.
Then my comment about intermediaries obviously does not apply to your case.
Custom HTTP status codes should
The httpbis drafts mentioned in another thread clarify the intent of
Berners-Lee, Fielding et al. in support of Paul's view:
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-01.txt(Expires
July 15, 2008)
HTTP status codes are extensible. HTTP applications are not required
Awesome. I didn't know this effort existed. I did not see that they have
already cleared up this point in the drafts, although they did shed light on
the Status code issue in another thread.
I'll join the list ... this is stuff we should stay abreast of.
- R
I'd make Restlet 1.1 available in my Tomcat application and use the Restlet
client API to talk to the Restlet server, but that's just me :-)
In fact we do this fairly often -- to be minimal about it, you need
org.restlet.jar, com.noelios.restlet.jar, and I'd recommend
I don't think this error is actually harmful, especially if you're not
planning on using the Grizzly connector. You can just say stopOnError=false
in the junit target or disable the Grizzly junit test in build.xml.
On 1/18/08, dev dev [EMAIL PROTECTED] wrote:
Got this error when running ant
(in best ghostly Obi-Wan voice)
Use the Jetty connector, Luke.
On 1/18/08, Thierry Boileau [EMAIL PROTECTED] wrote:
yes you're right. I see in the log that someone tries to get the 1.1M1
windows installer a lot of time. Unfortunately, I failed to contact
Jérôme.
This question comes up in the context of the Google Web Toolkit extension
and thinking about GWT-Restlet as a Restlet-API-oriented alternative to
the GWT-REST API (see issue #127,
http://restlet.tigris.org/issues/show_bug.cgi?id=127).
Google Web Toolkit compiles Java to Javascript and runs it in
On 1/22/08, Jerome Louvel [EMAIL PROTECTED] wrote:
Are you aware of safe and
efficient mechanisms to block in GWT while waiting for a given event
to
occur?
No, but I can make the browser freeze up like an early Swing client at
garbage collection time, if people really, really want the
If I read this correctly, it sounds like your client is posting the data in
ISO-8859-1 format.
The Form constructor you need is available in the Restlet 1.1 snapshots.
With this you can say:
Form form = new Form(request.getEntity(),CharacterSet.ISO_8859_1);
You can read the API documentation
1 - 100 of 374 matches
Mail list logo
