RE: The server has not found anything matching the request URI
hello Shrileckha, could you precise the way your application is set up in the web.xml too? Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609339
RE: Re: Amazon S3 Auth
Hello Jean-Philippe, I think you're totally right. The status of the reponse is set to 401 during authentication, and not reset when necessary (in "unauthenticated" method. I will discuss this point with Jérôme. Thanks a lot for your work! best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609338
The server has not found anything matching the request URI
Hi All, I am getting "The server has not found anything matching the request URI" when I run a sample application deployed in the weblogic server. Attached are the sample REST app that is taken from the restlet website. Below is the following entry in web.xml file: RestletServlet com.noelios.restlet.ext.servlet.ServerServlet RestletServlet /* This is not only one entry in web.xml file. I have other application entries too. The url to access the web app is: http://localdev.gartner.com:8010/myApp/ I don't get any error on web logic server console. But I get "The server has not found anything matching the request URI" in the browser. Out put from console: May 14, 2010 3:37:07 PM com.noelios.restlet.LogFilter afterHandle INFO: 2010-05-1415:37:07127.0.0.1 - 127.0.0.1 8010GET /myApp/ - 404 0 - 16 http://localdev.mydomain.com:8010 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3- It would be really helpful if any one can find the problem. Thanks, Shrileckha Chaithanya -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609211
Re: Amazon S3 Auth
Alright I was able to fix that problem. I overwrote the HttpAmsS3Helper
class so that the serverSide property is set to true. That allowed my
Verifier implementation to finally get executed. Unfortunately though i'm
seeing some behavior which feels like a bug in restlet. I've configured the
Authenticator so that authentication is optional. The behavior i'm seeing is
that if a request has missing credentials or returns invalid I get an
authentication required response. What is more strange is that if I change
the optional boolean I get the exact same results. No matter what it appears
a user must have proper credentials to be passed though. This doesn't seem
right. If authentication is optional and there is any sort of failure I
would expect the request to still be fulfilled. Is this not a correct
expectation?
On Fri, May 14, 2010 at 12:53 PM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> Ok i've created the authenticator and pass in ChallengeScheme.HTTP_AWS_S3
> to super in the constructor but i'm still getting this message from restlet
> whenever I make a call...
>
> *Challenge scheme HTTP_AWS not support by the Restlet engine.*
>
>
> On Fri, May 14, 2010 at 12:04 PM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> Nevermind... I see my mistake now...
>>
>> public DigestAuthenticator(Context context, boolean optional, String realm,
>> List domainRefs, String serverKey) {
>>
>>
>>
>> super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
>>
>> Time to implement the HttpAwsS3Authenticator =)
>>
>>
>> On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
>> caskate...@gmail.com> wrote:
>>
>>> I'm pretty sure I understand and have it set up correctly but I am
>>> clearly missing something.
>>>
>>> Here's what I have.
>>>
>>> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier
>>> similar to the DigestVerifier. My understanding was that this is how I can
>>> hook in the actual identifier/password list and your response appears to
>>> confirm that. Now in my application I have everything hooked up via Spring.
>>> Here is what my beans look like...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >> static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>>>
>>>
>>>
>>> >> class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>>>
>>> >> class="com.company.restlet.security.MyLocalVerifier"/>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> When my application is running and a request is sent I get the following
>>> message...
>>>
>>> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>>>
>>> I also get an authentication required required error sent back to the
>>> client. I'm looking at the source for
>>> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
>>> that seems to set what ChallengeScheme is supported by it. I'm also
>>> generally unclear where the mapping of ChallengeScheme to
>>> Authenticator/Verifier occurs.
>>>
>>>
>>> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
>>> thierry.boil...@noelios.com> wrote:
>>>
Hello Jean-Phillipe,
that's a great news!
> Now that I have all the pieces i'm ready to plug it in for testing and
ultimately submission to the project.
> I've been digging around a lot but am so far unable the location where
the correct verifier is selected/instantiated for a given ChallengeScheme.
Basically, a verifier is attached to an authenticator by the developer.
If you have a look at the "crypto" extension, you will see a
DigestAuthenticator that aims to handle Digest-based authentication,
especially HTTP_DIGEST. This authenticator is aimed to be used as follow
(see [1]):
***
DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
"mySecretServerKey");
// Instantiates a Verifier of identifier/secret couples based on a
simple Map.
MapVerifier mapVerifier = new MapVerifier();
// Load a single static login/secret pair.
mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
guard.setWrappedVerifier(mapVerifier);
***
As you can see, a verifier is provided manually, and this verifier seems
totally agnostic of the challenge scheme. That's true. You may have also
noticed that this verifier is attached to the authenticator as a "wrapped"
verifier.
Actually, the DigestAuthenticator has its own verifier (see the
constructor) which is an instance of DigestVerifier that wraps the user's
one. This verifier supports a given ChallengeScheme which i
Re: Amazon S3 Auth
Ok i've created the authenticator and pass in ChallengeScheme.HTTP_AWS_S3 to
super in the constructor but i'm still getting this message from restlet
whenever I make a call...
*Challenge scheme HTTP_AWS not support by the Restlet engine.*
On Fri, May 14, 2010 at 12:04 PM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> Nevermind... I see my mistake now...
>
> public DigestAuthenticator(Context context, boolean optional, String realm,
> List domainRefs, String serverKey) {
>
>
> super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
>
> Time to implement the HttpAwsS3Authenticator =)
>
>
> On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
> caskate...@gmail.com> wrote:
>
>> I'm pretty sure I understand and have it set up correctly but I am clearly
>> missing something.
>>
>> Here's what I have.
>>
>> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
>> to the DigestVerifier. My understanding was that this is how I can hook in
>> the actual identifier/password list and your response appears to confirm
>> that. Now in my application I have everything hooked up via Spring. Here is
>> what my beans look like...
>>
>>
>>
>>
>>
>>
>>
>>
>> > static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>>
>>
>>
>> > class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>>
>> > class="com.company.restlet.security.MyLocalVerifier"/>
>>
>>
>>
>>
>>
>>
>>
>>
>> When my application is running and a request is sent I get the following
>> message...
>>
>> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>>
>> I also get an authentication required required error sent back to the
>> client. I'm looking at the source for
>> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
>> that seems to set what ChallengeScheme is supported by it. I'm also
>> generally unclear where the mapping of ChallengeScheme to
>> Authenticator/Verifier occurs.
>>
>>
>> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
>> thierry.boil...@noelios.com> wrote:
>>
>>> Hello Jean-Phillipe,
>>>
>>> that's a great news!
>>>
>>>
>>> > Now that I have all the pieces i'm ready to plug it in for testing and
>>> ultimately submission to the project.
>>> > I've been digging around a lot but am so far unable the location where
>>> the correct verifier is selected/instantiated for a given ChallengeScheme.
>>>
>>> Basically, a verifier is attached to an authenticator by the developer.
>>>
>>> If you have a look at the "crypto" extension, you will see a
>>> DigestAuthenticator that aims to handle Digest-based authentication,
>>> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
>>> (see [1]):
>>>
>>> ***
>>>
>>> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
>>> "mySecretServerKey");
>>>
>>> // Instantiates a Verifier of identifier/secret couples based on a simple
>>> Map.
>>> MapVerifier mapVerifier = new MapVerifier();
>>> // Load a single static login/secret pair.
>>> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
>>> guard.setWrappedVerifier(mapVerifier);
>>>
>>> ***
>>>
>>> As you can see, a verifier is provided manually, and this verifier seems
>>> totally agnostic of the challenge scheme. That's true. You may have also
>>> noticed that this verifier is attached to the authenticator as a "wrapped"
>>> verifier.
>>> Actually, the DigestAuthenticator has its own verifier (see the
>>> constructor) which is an instance of DigestVerifier that wraps the user's
>>> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
>>> Here is an answer to your question.
>>> Another question is "why using a DigestVerifier that wraps a simple
>>> LocalVerifier?". The reason is that we try to support the case where the
>>> user's verifier leverages credentials that are already encrypted...
>>>
>>> I hope this get the things clearer, but I'm not really sure. Please let
>>> us know!
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>> [1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
>>>
>>>
>>> Can you point me in the right direction? Ultimately it would be great if
>>> it "just worked." Any help on plugging this is would be greatly appreciated.
>>>
>>> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau <
>>> thierry.boil...@noelios.com> wrote:
>>>
Hello Jean-Philippe,
unfortunately the server side has been implemented for the moment.
Best regards,
Thierry Boileau
Hi,
I'm using Amazon S3 authentication in my web application. I'm looking to
moving to restlet 2.0 from 1
Re: Amazon S3 Auth
Nevermind... I see my mistake now...
public DigestAuthenticator(Context context, boolean optional, String realm,
List domainRefs, String serverKey) {
super(context, optional, ChallengeScheme.HTTP_DIGEST, realm);
Time to implement the HttpAwsS3Authenticator =)
On Fri, May 14, 2010 at 11:54 AM, Jean-Philippe Steinmetz <
caskate...@gmail.com> wrote:
> I'm pretty sure I understand and have it set up correctly but I am clearly
> missing something.
>
> Here's what I have.
>
> I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
> to the DigestVerifier. My understanding was that this is how I can hook in
> the actual identifier/password list and your response appears to confirm
> that. Now in my application I have everything hooked up via Spring. Here is
> what my beans look like...
>
>
>
>
>
>
>
>
> static-field="org.restlet.data.ChallengeScheme.HTTP_AWS_S3"/>
>
>
>
> class="org.restlet.ext.crypto.internal.HttpAwsS3Verifier">
>
> class="com.company.restlet.security.MyLocalVerifier"/>
>
>
>
>
>
>
>
>
> When my application is running and a request is sent I get the following
> message...
>
> *Challenge scheme HTTP_AWS not supported by the Restlet engine.*
>
> I also get an authentication required required error sent back to the
> client. I'm looking at the source for
> org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
> that seems to set what ChallengeScheme is supported by it. I'm also
> generally unclear where the mapping of ChallengeScheme to
> Authenticator/Verifier occurs.
>
>
> On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
> thierry.boil...@noelios.com> wrote:
>
>> Hello Jean-Phillipe,
>>
>> that's a great news!
>>
>>
>> > Now that I have all the pieces i'm ready to plug it in for testing and
>> ultimately submission to the project.
>> > I've been digging around a lot but am so far unable the location where
>> the correct verifier is selected/instantiated for a given ChallengeScheme.
>>
>> Basically, a verifier is attached to an authenticator by the developer.
>>
>> If you have a look at the "crypto" extension, you will see a
>> DigestAuthenticator that aims to handle Digest-based authentication,
>> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
>> (see [1]):
>>
>> ***
>>
>> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
>> "mySecretServerKey");
>>
>> // Instantiates a Verifier of identifier/secret couples based on a simple
>> Map.
>> MapVerifier mapVerifier = new MapVerifier();
>> // Load a single static login/secret pair.
>> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
>> guard.setWrappedVerifier(mapVerifier);
>>
>> ***
>>
>> As you can see, a verifier is provided manually, and this verifier seems
>> totally agnostic of the challenge scheme. That's true. You may have also
>> noticed that this verifier is attached to the authenticator as a "wrapped"
>> verifier.
>> Actually, the DigestAuthenticator has its own verifier (see the
>> constructor) which is an instance of DigestVerifier that wraps the user's
>> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
>> Here is an answer to your question.
>> Another question is "why using a DigestVerifier that wraps a simple
>> LocalVerifier?". The reason is that we try to support the case where the
>> user's verifier leverages credentials that are already encrypted...
>>
>> I hope this get the things clearer, but I'm not really sure. Please let us
>> know!
>>
>> Best regards,
>> Thierry Boileau
>>
>> [1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
>>
>>
>> Can you point me in the right direction? Ultimately it would be great if
>> it "just worked." Any help on plugging this is would be greatly appreciated.
>>
>> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau <
>> thierry.boil...@noelios.com> wrote:
>>
>>> Hello Jean-Philippe,
>>>
>>> unfortunately the server side has been implemented for the moment.
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>>
>>> Hi,
>>>
>>> I'm using Amazon S3 authentication in my web application. I'm looking to
>>> moving to restlet 2.0 from 1.1 and was wondering if there is finally a
>>> server side implementation of the authentication protocol?
>>>
>>> Jean-Philippe Steinmetz
>>>
>>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609207
Re: Amazon S3 Auth
I'm pretty sure I understand and have it set up correctly but I am clearly
missing something.
Here's what I have.
I've implemented the HttpAwsS3Verifier which wraps a LocalVerifier similar
to the DigestVerifier. My understanding was that this is how I can hook in
the actual identifier/password list and your response appears to confirm
that. Now in my application I have everything hooked up via Spring. Here is
what my beans look like...
When my application is running and a request is sent I get the following
message...
*Challenge scheme HTTP_AWS not supported by the Restlet engine.*
I also get an authentication required required error sent back to the
client. I'm looking at the source for
org.restlet.ext.crypto.DigestAuthenticator but I do not see anything inside
that seems to set what ChallengeScheme is supported by it. I'm also
generally unclear where the mapping of ChallengeScheme to
Authenticator/Verifier occurs.
On Fri, May 14, 2010 at 6:58 AM, Thierry Boileau <
thierry.boil...@noelios.com> wrote:
> Hello Jean-Phillipe,
>
> that's a great news!
>
>
> > Now that I have all the pieces i'm ready to plug it in for testing and
> ultimately submission to the project.
> > I've been digging around a lot but am so far unable the location where
> the correct verifier is selected/instantiated for a given ChallengeScheme.
>
> Basically, a verifier is attached to an authenticator by the developer.
>
> If you have a look at the "crypto" extension, you will see a
> DigestAuthenticator that aims to handle Digest-based authentication,
> especially HTTP_DIGEST. This authenticator is aimed to be used as follow
> (see [1]):
>
> ***
>
> DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
> "mySecretServerKey");
>
> // Instantiates a Verifier of identifier/secret couples based on a simple
> Map.
> MapVerifier mapVerifier = new MapVerifier();
> // Load a single static login/secret pair.
> mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
> guard.setWrappedVerifier(mapVerifier);
>
> ***
>
> As you can see, a verifier is provided manually, and this verifier seems
> totally agnostic of the challenge scheme. That's true. You may have also
> noticed that this verifier is attached to the authenticator as a "wrapped"
> verifier.
> Actually, the DigestAuthenticator has its own verifier (see the
> constructor) which is an instance of DigestVerifier that wraps the user's
> one. This verifier supports a given ChallengeScheme which is HTTP_Digest.
> Here is an answer to your question.
> Another question is "why using a DigestVerifier that wraps a simple
> LocalVerifier?". The reason is that we try to support the case where the
> user's verifier leverages credentials that are already encrypted...
>
> I hope this get the things clearer, but I'm not really sure. Please let us
> know!
>
> Best regards,
> Thierry Boileau
>
> [1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
>
>
> Can you point me in the right direction? Ultimately it would be great if
> it "just worked." Any help on plugging this is would be greatly appreciated.
>
> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau <
> thierry.boil...@noelios.com> wrote:
>
>> Hello Jean-Philippe,
>>
>> unfortunately the server side has been implemented for the moment.
>>
>> Best regards,
>> Thierry Boileau
>>
>>
>> Hi,
>>
>> I'm using Amazon S3 authentication in my web application. I'm looking to
>> moving to restlet 2.0 from 1.1 and was wondering if there is finally a
>> server side implementation of the authentication protocol?
>>
>> Jean-Philippe Steinmetz
>>
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609206
RE: Restlet - CharacterSet problem in represent method
Hello Fabian, I've just fixed the issue in the 1.1 branch also. Thanks Fabian. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609185
RE: Restlet - CharacterSet problem in represent method
Hi Thierry, You have corrected this for the 1.1 version or for the 2.0 version? Cheers, Fabian. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-CharacterSet-problem-in-represent-method-tp5035725p5051798.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609165
RE: @Get annotation not being detected under a particular circumstance
Hello Kevin, thanks a lot for your report. The fix is available in the svn repository. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609164
Re: Amazon S3 Auth
Hello Jean-Phillipe,
that's a great news!
> Now that I have all the pieces i'm ready to plug it in for testing
and ultimately submission to the project.
> I've been digging around a lot but am so far unable the location
where the correct verifier is selected/instantiated for a given
ChallengeScheme.
Basically, a verifier is attached to an authenticator by the developer.
If you have a look at the "crypto" extension, you will see a
DigestAuthenticator that aims to handle Digest-based authentication,
especially HTTP_DIGEST. This authenticator is aimed to be used as follow
(see [1]):
***
DigestAuthenticator guard = new DigestAuthenticator(null, "TestRealm",
"mySecretServerKey");
// Instantiates a Verifier of identifier/secret couples based on a
simple Map.
MapVerifier mapVerifier = new MapVerifier();
// Load a single static login/secret pair.
mapVerifier.getLocalSecrets().put("login", "secret".toCharArray());
guard.setWrappedVerifier(mapVerifier);
***
As you can see, a verifier is provided manually, and this verifier seems
totally agnostic of the challenge scheme. That's true. You may have also
noticed that this verifier is attached to the authenticator as a
"wrapped" verifier.
Actually, the DigestAuthenticator has its own verifier (see the
constructor) which is an instance of DigestVerifier that wraps the
user's one. This verifier supports a given ChallengeScheme which is
HTTP_Digest. Here is an answer to your question.
Another question is "why using a DigestVerifier that wraps a simple
LocalVerifier?". The reason is that we try to support the case where the
user's verifier leverages credentials that are already encrypted...
I hope this get the things clearer, but I'm not really sure. Please let
us know!
Best regards,
Thierry Boileau
[1] http://wiki.restlet.org/docs_2.0/13-restlet/112-restlet.html
> Can you point me in the right direction? Ultimately it would be great
> if it "just worked." Any help on plugging this is would be greatly
> appreciated.
>
> On Sun, May 9, 2010 at 2:39 AM, Thierry Boileau
> mailto:thierry.boil...@noelios.com>> wrote:
>
> Hello Jean-Philippe,
>
> unfortunately the server side has been implemented for the moment.
>
> Best regards,
> Thierry Boileau
>
>
>> Hi,
>>
>> I'm using Amazon S3 authentication in my web application. I'm
>> looking to moving to restlet 2.0 from 1.1 and was wondering if
>> there is finally a server side implementation of the
>> authentication protocol?
>>
>> Jean-Philippe Steinmetz
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609108
RE: client-side parsing of XML in GWT
Ok. I was trying a test case and was having trouble (possibly due to namespaces). I'll see if I can find Harald to answer some questions. By the way, I am evaluating Restlet/GWT for a big project and we will likely purchase a commercial license and some tech support. Many Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609097
RE: Restlet - CharacterSet problem in represent method
Hello, I've just fixed a bug regarding the transmission of the DomRepresentation's character set to the underlying instance of Transformer that generates the result stream. With that fix, I was able to generate a correct representation encoded with the correct character set and declaring correctly this character set in the XML header (). Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609093
RE: client-side parsing of XML in GWT
Hello Allan, we kindly encourage you to adopt Piriti. The current restlet extension to Piriti should fit your needs. You can find documentation and sample code on the Piriti pages: http://code.google.com/p/piriti/wiki/RestletExtension Note also that the next 2.1 release of the Restlet framework will contain a Piriti exension. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609052
Re: Restlet - CharacterSet problem in represent method
Hi,
I'm not sure where this comes from, but it might come from the original
string that you're reading (it's not clear from your code fragment). It
looks like it could be read in UTF-8 and then written as if it was
ISO-8859-1.
You might be able to get the correct output if you make sure it's the
same character encoding as the input.
Best wishes,
Bruno.
On 11/05/10 13:33, cuaruja wrote:
> Hi,
> I have tried to get a xml representation of an xml structure but each time I
> have an accent it doesn't work. And I have this result:
>
> R�partition par webtracker
>
>
> public Representation represent(Variant variant) throws ResourceException {
>
> if (MediaType.TEXT_XML.equals(variant.getMediaType())) {
> try {
>
> // CREATE dom document
> DomRepresentation representation = new DomRepresentation(
> MediaType.TEXT_XML);
> representation.setCharacterSet(CharacterSet.ISO_8859_1);
> Document d = representation.getDocument();
>
> Element list = d.createElement("list");
> d.appendChild(list);
>
> .
>
> d.normalizeDocument();
> // Returns the XML representation of this document.
> return representation;
> }
>
> catch (IOException e) {
> e.printStackTrace();
> }
> }
> return null;
> }
>
> what's wrong with this code? Could you help me?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609043
RE: HTTP Accepted result code 202 issue
Hello Nina, sorry for the delay of my answer. In the doInit method, you can still set the status and the response's entity: setStatus(Status.SUCCESS_ACCEPTED); getResponse().setEntity(); Another way to achieve what you want, is to cope with this status inside the methods that handle the accepted operation (e.g. a PUT, POST, etc). Does that help you? Best regards, Thierry boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2609027
