RE: how to set up client certificate in restlet 1.1.4 for HTTPS?

[webpost]

I found a way to work around this, after some searching and testing. The 
workaround is to use the SAME password for both keystore and its key, i.e. 
keytool -keypass and -storepass shoud have the same arg.

After that, the following code will work on the client side (there is no change 
to the server):

System.setProperty("javax.net.ssl.trustStore", 
keystoreFile.getAbsolutePath());
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
System.setProperty("javax.net.ssl.keyStore", 
keystoreFile.getAbsolutePath());
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
Client client = new Client(Protocol.HTTPS);

thanks.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430929

Re: POST ignored in RESTlet 2.0Mx

[Dustin Nicholas Jenkins]

Hi Thierry,

I'm using the 2.0M6 version, and this issue is still happening. I have 
an Apache 2.2.x proxy in front of my Tomcat Container.

I'm trying to track down the method(s) that look for the annotated POST 
methods in the Resource in case they're not coming back properly. Are 
there some set conditions for POST methods? (i.e. Cannot return 
anything, no arguments, etc.).

Thanks, very much!
Dustin



Thierry Boileau wrote:
> Hi Dustin,
>
> something is not clear for me. When you send a post request to your 
> resource, is your "post" method called or not?
> If not, there is a problem. Otherwise, as said Stephan, a redirection 
> makes your browser makes automatically an additional GET request the new 
> location.
>
> Best regards,
> Thierry Boileau
>
>   
>> Hi Dustin,
>>
>> 303 (see other) says, that the result is at the given location, and you 
>> have to get it with GET. So the behaviour is right.
>> Use 301 (Moved Permanently) or 307 (Temporary redirect).
>> See http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection
>>
>> best regards
>>Stephan
>>
>> Dustin N. Jenkins schrieb:
>>   
>> 
>>> I'm using Java 6, Tomcat 6.0.20, RESTlet 2.0M5 on a Linux platform.
>>>
>>> After my business operations in my POST call, I simply call 
>>> redirectSeeOther().  When I make POST calls to the Resource now, the log 
>>> records it as a POST call, but my @Get method is being called instead.  
>>> Does the redirectSeeOther() get cached somewhere or something?  Normally 
>>> I'd see a POST followed by a GET in the log.  Is this a bug in the 
>>> current 2.0 tree?  The snapshot is doing the same thing.
>>>
>>> I've used wget and browser clients just to test this.
>>>
>>> Thanks,
>>> Dustin
>>>
>>> 
>>>   
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420195
>>
>>
>> 
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420445
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430998

Re: MIME Accept Type filter

[Andrzej Berico]

Thierry,

This fillter solution worked very nicely. We'll keep it in place for v
1.1.15 and remove it when we go to v 2.0.
Thank you very much.



Thierry Boileau wrote:
> 
> Andrzej,
> 
> the content negotiation algorithm implemented by the Restlet v1.1 is a 
> bit lost when the preference "*/*" has a quality of 1.0.
> Since it loops over the the declared variants, it first calculates the 
> score of the json variant. Since the "*/*" has a quality of 1, the 
> computed score is the highest possible...
> 
> One way is to systematically under valuate the "*/*" preference in a
> filter:
>  class MyFilter extends Filter {
> @Override
> protected int beforeHandle(Request request, Response response) {
> List> prefs = request.getClientInfo()
> .getAcceptedMediaTypes();
> if (prefs != null && !prefs.isEmpty()) {
> for (Preference preference : prefs) {
> if (preference.getMetadata().equals(MediaType.ALL)) {
> preference.setQuality(0.1f);
> }
> }
> }
> 
> return Filter.CONTINUE;
> }
> }
> 
> NB : the conneg algorithm has been updated in the Restlet 2.0 trunk. It 
> systematically sets a quality of 0.001.
> 
> Best regards,
> Thierry Boileau
> 
>  
>> Thierry,
>>
>> That actually changed the request.  Still get JSON though. Restlet
>> content
>> negotiates APPLICATION_JSON. How can we get APPLICATION_XML ?
>>
>>
>> Request:
>> GET /coralreef-resource/file/status?user=greg.savaged&_=1260974638188
>> HTTP/1.1
>> Accept: application/xml, text/xml, */*
>> Accept-Language: en-us
>> x-requested-with: XMLHttpRequest
>> UA-CPU: x86
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
>> .NET
>> CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR
>> 3.0.30618)
>> Host: 10.1.10.166:8181
>> Connection: Keep-Alive
>> Authorization: Basic Z3JlZy5ob2NoYXJkOmJlcmljbw==
>>
>>
>>
>>
>> Thierry Boileau wrote:
>>   
>>> Hi Andrzej
>>>
>>> could you use the "dataType" argument instead of the "beforeSend" one?
>>>
>>> $.ajax({type: 'GET',
>>> url: myUrl,
>>> success: onAjaxSuccess,
>>> error: onAjaxError,
>>> cache: false,
>>> dataType: "xml");
>>>
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>> 
 Thierry,

 1) Our JQuery Ajax call:

 $.ajax({
  type: 'GET',
  url: myUrl,
  success: onAjaxSuccess,
  error: onAjaxError,
 cache: false,
 beforeSend :
 function(xhr){xhr.setRequestHeader('Accept','application/xml')}
  });

 Will generate Accept header of  "*/*, application/xml". We want
 "application/xml".

 2) Our Restlet 1.1.5

 @Override
 public Restlet createRoot() {
// Create a router Restlet.
Router router = new Router(getContext());

// Attach our routers.
router.attach("/test", HelloWorldResource.class);
router.attach("/file/status", FileStatusResource.class);

return router;
}


 public FileStatusResource(Context context, Request request, Response
 response) {
super(context, request, response);

// Read URI query strings.
Form form = request.getOriginalRef().getQueryAsForm();
if (form != null) {
setUser(form.getFirstValue("user", isIgnoreCase()));
setOriginalUri(form.getFirstValue("originalUri", 
 isIgnoreCase()));
setAction(form.getFirstValue("action", isIgnoreCase()));
}

// Variants that our resource generates.
getVariants().add(new Variant(MediaType.APPLICATION_JSON));
getVariants().add(new Variant(MediaType.APPLICATION_XML));

}

 @Override
 public Representation represent(Variant variant) throws
 ResourceException
 {
Representation representation = null;

// Validate request
if (StringUtils.isBlank(getUser())) {
log.debug("GET FileStatusResource bad user. ");
representation = representError(variant, new 
 ErrorMessage());

 getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return representation;
}

representation = representGet(this,variant);
return representation;
}

 public final Representation representGet(CoralReefResource crr, Variant
 variant)
thro

Re: how to set up client certificate in restlet 1.1.4 for HTTPS?

[Bruno Harbulot]

Hi,

Using client-certificates with Restlet 1.1 is not well supported (in 
fact, it's not supported at all, but there are workarounds to make it 
work in some cases). I'd suggest upgrade to Restlet 2; there might still 
be bugs with some connectors, but the Apache HTTP client and the Net 
connector (default java.net package classes) seem to work fine.

If you can't upgrade to Restlet 2, you could try a few things:
- Using the Net connector and the same settings.
- You might also want to try to have the keystore have the same password 
as the key itself.
- I would also avoid to use the same keystore for the client and the 
server. Either have one common keystore file for the truststore (to 
recognise your CAs) and two separate keystore keystores (one for the 
client, one for the server, with their respective private keys); or 
import the CA certificates into both client and server keystores.
- You could also try the Apache HTTP client connector, using the 
workaround described in this comment 
 (not very 
clean).

Best wishes,

Bruno.

webp...@tigris.org wrote:
> Hi,
> 
> I'm trying to use the Simple HTTPS library to set up a HTTPS connection with 
> mutual PKI authentication, after successful server-only authentication.
> 
> For the server-only authentication, I created a JKS keystore and modified the 
> client/server samples in 
> src\org.restlet.example\org\restlet\example\book\restlet\ch11\{BasicHttpsServer.java,BasicHttpsClient.java}
>  to load that store.
> The client GET request returned the 200 OK.
> 
> For the mutual authentication, the BasicHttpsServer.java becomes:
> 
> System.setProperty("javax.net.ssl.trustStore", 
> keystoreFile.getAbsolutePath());
> System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
> 
> // Component declaring only one HTTPS server connector.
> Component component = new Component();
> Server server = component.getServers().add(Protocol.HTTPS, 8182);
> component.getDefaultHost().attach("/helloWorld", restlet);
> 
> // Update server's context with keystore parameters.
> server.getContext().getParameters().add("keystorePath", 
> keystoreFile.getAbsolutePath());
> server.getContext().getParameters().add("keystorePassword", 
> "changeit");
> server.getContext().getParameters().add("keyPassword", "server");
> server.getContext().getParameters().add("needClientAuthentication", 
> "true");
> 
> 
> and the BasicHttpsClient.java becomes:
> 
> System.setProperty("javax.net.ssl.trustStore", 
> keystoreFile.getAbsolutePath());
> System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
> 
> Component component = new Component();
> Client client = component.getClients().add(Protocol.HTTPS);
> client.getContext().getParameters().add("keystorePath", 
> keystoreFile.getAbsolutePath());
> client.getContext().getParameters().add("keystorePassword", 
> "changeit");
> client.getContext().getParameters().add("keyPassword", "server");
> 
> which is very similar to the server. I used the same jks keystore file for 
> both client and server to make sure they have the same CA. However, the 
> client GET request returns this error status:
> 
> Communication Error (1001) - Software caused connection abort: recv failed
> 
> I also tried to load client side keystore with these:
> 
> System.setProperty("javax.net.ssl.keyStore", 
> keystoreFile.getAbsolutePath());
> System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
> 
> But I got an error status:
> Communication Error (1001) - Default SSL context init failed: Cannot recover 
> key
> 
> I suspect the client would not find the key from the keystore because Java 
> does not provide such property "javax.net.ssl.keyPassword".
> 
> Does anyone know what is wrong? 
> 
> For mutual authentication, how do I set up the trustStore on the server side, 
> and how do I set up the keystore on the client side?
> 
> Thanks a lot.
> 
> Li
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430830
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430857

Re: GWT-RESTLET: API to check the current browser instance is already "basic authencated".

[Thierry Boileau]

Hello sanjib,


I may be wrong, but as far as I know, all the connection aspects related 
to HTTP authentication are handled by the browser.
In case the credentials are wrong (even if entered on your own popup), 
the browser will display its own popup.
However, there may be workarounds (such as generate the authorization 
header from the javascript code, or other technics), but I'm not sure 
this is always successfull.
One idea is to define a special resource that aims uniquely at saying if 
the credentials are correct. If they are, then the desired request is 
sent from the client page in order to set up the browser's session.
Another track for you to explore is the authentication based on cookies.

Best regards,
Thierry Boileau

> Hello,
>
> I am using RESTLET-GWT client to talk to restlet backend using basic 
> authentication. It's working fine.
>
> I am looking for an api in GWT-RESTLET client side to check if the current 
> browser is already authenticated, based on the I would provide a custom-popup 
> to the user to provide the credentials or take it to the logged in page.
>
> Is it available? Otherwise, is there some other way to achieve the same ?
>
> thanks...sanjib
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430501
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430847

Re: how to set up client certificate in restlet 1.1.4 for HTTPS?

[Matt Kennedy]

Here's the server code I use, my keys/certs may be set up a little
differently from yours though, but this code supports client cert handshakes
using browser clients and curl clients.  In this case, the CAs that sign the
client certs are stored in /etc/pki/ca.jks along with the CA that signed
that ewallet.p12 file. Unfortunately, I don't have any restlet client code
to send you, but you can try testing by setting up a client cert in Firefox.

static void setUpSSL(Context workingCtx)
{
System.setProperty('javax.net.ssl.trustStore','/etc/pki/ca.jks');
System.setProperty('javax.net.ssl.trustStorePassword',
System.getenv('TRUSTSTORE_PASS'));
workingCtx.getParameters().add("sslContextFactory",
"org.restlet.ext.ssl.PkixSslContextFactory");
workingCtx.getParameters().add("keystorePath",
"/etc/pki/wallets/${System.getenv('VIRTUAL_HOST')}/ewallet.p12");
workingCtx.getParameters().add("keystorePassword",
System.getenv('KEYSTORE_PASS'));
workingCtx.getParameters().add("keystoreType", "PKCS12");
workingCtx.getParameters().add("keyPassword",
System.getenv('KEY_PASS'));
workingCtx.getParameters().add("certAlgorithm", "SunX509");
}

On Wed, Dec 16, 2009 at 11:06 AM,  wrote:

> Hi,
>
> I'm trying to use the Simple HTTPS library to set up a HTTPS connection
> with mutual PKI authentication, after successful server-only authentication.
>
> For the server-only authentication, I created a JKS keystore and modified
> the client/server samples in
> src\org.restlet.example\org\restlet\example\book\restlet\ch11\{BasicHttpsServer.java,BasicHttpsClient.java}
> to load that store.
> The client GET request returned the 200 OK.
>
> For the mutual authentication, the BasicHttpsServer.java becomes:
>
>System.setProperty("javax.net.ssl.trustStore",
> keystoreFile.getAbsolutePath());
>System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
>
>// Component declaring only one HTTPS server connector.
>Component component = new Component();
>Server server = component.getServers().add(Protocol.HTTPS, 8182);
>component.getDefaultHost().attach("/helloWorld", restlet);
>
>// Update server's context with keystore parameters.
>server.getContext().getParameters().add("keystorePath",
> keystoreFile.getAbsolutePath());
>server.getContext().getParameters().add("keystorePassword",
> "changeit");
>server.getContext().getParameters().add("keyPassword", "server");
>server.getContext().getParameters().add("needClientAuthentication",
> "true");
>
>
> and the BasicHttpsClient.java becomes:
>
>System.setProperty("javax.net.ssl.trustStore",
> keystoreFile.getAbsolutePath());
>System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
>
>Component component = new Component();
>Client client = component.getClients().add(Protocol.HTTPS);
>client.getContext().getParameters().add("keystorePath",
> keystoreFile.getAbsolutePath());
>client.getContext().getParameters().add("keystorePassword",
> "changeit");
>client.getContext().getParameters().add("keyPassword", "server");
>
> which is very similar to the server. I used the same jks keystore file for
> both client and server to make sure they have the same CA. However, the
> client GET request returns this error status:
>
> Communication Error (1001) - Software caused connection abort: recv failed
>
> I also tried to load client side keystore with these:
>
>System.setProperty("javax.net.ssl.keyStore",
> keystoreFile.getAbsolutePath());
>System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
>
> But I got an error status:
> Communication Error (1001) - Default SSL context init failed: Cannot
> recover key
>
> I suspect the client would not find the key from the keystore because Java
> does not provide such property "javax.net.ssl.keyPassword".
>
> Does anyone know what is wrong?
>
> For mutual authentication, how do I set up the trustStore on the server
> side, and how do I set up the keystore on the client side?
>
> Thanks a lot.
>
> Li
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430830
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430838

Re: DomRepresentation fails with saxon9 in 2.0m6

[Thierry Boileau]

Hello Maxime,

this has been fixed in the current snapshot.

Best regards,
Thierry Boileau
> hi,
>
> Our application uses the DomRepresentation to return XML responses.
> We have saxon9.jar and saxon9-dom.jar in our classpath.
> Restlet uses saxon9 when present to construct(serialize?) the response.
> We were using restlet 2.0m5 so far and it was working well.
> Since we switched to 2.0m6 the XML resources fail with the following
> exception:
>
> 14 déc. 2009 12:05:58 org.restlet.engine.http.HttpServerAdapter commit
> GRAVE: An exception occured writing the response entity
> java.lang.IllegalArgumentException: Serialization parameter {indent}
> must have the value yes or no
> at net.sf.saxon.Controller.setOutputProperty(Controller.java:351)
> at
> org.restlet.ext.xml.DomRepresentation.createTransformer(DomRepresentation.java:117)
> at
> org.restlet.ext.xml.DomRepresentation.write(DomRepresentation.java:265)
> at
> org.restlet.engine.http.HttpServerCall.writeResponseBody(HttpServerCall.java:510)
> at
> org.restlet.engine.http.HttpServerCall.sendResponse(HttpServerCall.java:447)
> at
> org.restlet.engine.http.HttpServerAdapter.commit(HttpServerAdapter.java:453)
> at
> org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:150)
> at
> org.restlet.engine.http.StreamServerHelper$ConnectionHandler.run(StreamServerHelper.java:89)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
>
> Does anyone know about this problem, is there any workaround?
>
> Thanks.
>
> Maxime Bégnis, NeoDoc
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430299
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430840

need some help with my project design

[Robert]

Hey!

I want to develop a webapplication with the following functionality:

0) overview: http://dl.dropbox.com/u/1266822/overview.jpg

1) The html,css,javascript content is delivered by the server.
2) The page consists of 2 frames. the second one loads the webpages the user 
wants to open.
3) The server receives the DOM of the loaded page.
4) The client receives data in the form of rdf or xml.


Is restlet appropriate for this needs? How would you realize the communication 
between Client (Javascript) and Server (Java) with the help of restlet? 
Would be really nice if you could give me a short overview of what I have to 
take care of.

Thanks in advance,
Robert

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430835

how to set up client certificate in restlet 1.1.4 for HTTPS?

[webpost]

Hi,

I'm trying to use the Simple HTTPS library to set up a HTTPS connection with 
mutual PKI authentication, after successful server-only authentication.

For the server-only authentication, I created a JKS keystore and modified the 
client/server samples in 
src\org.restlet.example\org\restlet\example\book\restlet\ch11\{BasicHttpsServer.java,BasicHttpsClient.java}
 to load that store.
The client GET request returned the 200 OK.

For the mutual authentication, the BasicHttpsServer.java becomes:

System.setProperty("javax.net.ssl.trustStore", 
keystoreFile.getAbsolutePath());
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

// Component declaring only one HTTPS server connector.
Component component = new Component();
Server server = component.getServers().add(Protocol.HTTPS, 8182);
component.getDefaultHost().attach("/helloWorld", restlet);

// Update server's context with keystore parameters.
server.getContext().getParameters().add("keystorePath", 
keystoreFile.getAbsolutePath());
server.getContext().getParameters().add("keystorePassword", "changeit");
server.getContext().getParameters().add("keyPassword", "server");
server.getContext().getParameters().add("needClientAuthentication", 
"true");


and the BasicHttpsClient.java becomes:

System.setProperty("javax.net.ssl.trustStore", 
keystoreFile.getAbsolutePath());
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Component component = new Component();
Client client = component.getClients().add(Protocol.HTTPS);
client.getContext().getParameters().add("keystorePath", 
keystoreFile.getAbsolutePath());
client.getContext().getParameters().add("keystorePassword", "changeit");
client.getContext().getParameters().add("keyPassword", "server");

which is very similar to the server. I used the same jks keystore file for both 
client and server to make sure they have the same CA. However, the client GET 
request returns this error status:

Communication Error (1001) - Software caused connection abort: recv failed

I also tried to load client side keystore with these:

System.setProperty("javax.net.ssl.keyStore", 
keystoreFile.getAbsolutePath());
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");

But I got an error status:
Communication Error (1001) - Default SSL context init failed: Cannot recover key

I suspect the client would not find the key from the keystore because Java does 
not provide such property "javax.net.ssl.keyPassword".

Does anyone know what is wrong? 

For mutual authentication, how do I set up the trustStore on the server side, 
and how do I set up the keystore on the client side?

Thanks a lot.

Li

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430830

Re: MIME Accept Type filter

[Thierry Boileau]

Andrzej,

the content negotiation algorithm implemented by the Restlet v1.1 is a 
bit lost when the preference "*/*" has a quality of 1.0.
Since it loops over the the declared variants, it first calculates the 
score of the json variant. Since the "*/*" has a quality of 1, the 
computed score is the highest possible...

One way is to systematically under valuate the "*/*" preference in a filter:
 class MyFilter extends Filter {
@Override
protected int beforeHandle(Request request, Response response) {
List> prefs = request.getClientInfo()
.getAcceptedMediaTypes();
if (prefs != null && !prefs.isEmpty()) {
for (Preference preference : prefs) {
if (preference.getMetadata().equals(MediaType.ALL)) {
preference.setQuality(0.1f);
}
}
}

return Filter.CONTINUE;
}
}

NB : the conneg algorithm has been updated in the Restlet 2.0 trunk. It 
systematically sets a quality of 0.001.

Best regards,
Thierry Boileau

 
> Thierry,
>
> That actually changed the request.  Still get JSON though. Restlet content
> negotiates APPLICATION_JSON. How can we get APPLICATION_XML ?
>
>
> Request:
> GET /coralreef-resource/file/status?user=greg.savaged&_=1260974638188
> HTTP/1.1
> Accept: application/xml, text/xml, */*
> Accept-Language: en-us
> x-requested-with: XMLHttpRequest
> UA-CPU: x86
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
> CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
> Host: 10.1.10.166:8181
> Connection: Keep-Alive
> Authorization: Basic Z3JlZy5ob2NoYXJkOmJlcmljbw==
>
>
>
>
> Thierry Boileau wrote:
>   
>> Hi Andrzej
>>
>> could you use the "dataType" argument instead of the "beforeSend" one?
>>
>> $.ajax({type: 'GET',
>> url: myUrl,
>> success: onAjaxSuccess,
>> error: onAjaxError,
>> cache: false,
>> dataType: "xml");
>>
>>
>> Best regards,
>> Thierry Boileau
>>
>> 
>>> Thierry,
>>>
>>> 1) Our JQuery Ajax call:
>>>
>>> $.ajax({
>>>  type: 'GET',
>>>  url: myUrl,
>>>  success: onAjaxSuccess,
>>>  error: onAjaxError,
>>> cache: false,
>>> beforeSend :
>>> function(xhr){xhr.setRequestHeader('Accept','application/xml')}
>>>  });
>>>
>>> Will generate Accept header of  "*/*, application/xml". We want
>>> "application/xml".
>>>
>>> 2) Our Restlet 1.1.5
>>> 
>>> @Override
>>> public Restlet createRoot() {
>>> // Create a router Restlet.
>>> Router router = new Router(getContext());
>>> 
>>> // Attach our routers.
>>> router.attach("/test", HelloWorldResource.class);
>>> router.attach("/file/status", FileStatusResource.class);
>>>
>>> return router;
>>> }
>>>
>>>
>>> public FileStatusResource(Context context, Request request, Response
>>> response) {
>>> super(context, request, response);
>>> 
>>> // Read URI query strings.
>>> Form form = request.getOriginalRef().getQueryAsForm();
>>> if (form != null) {
>>> setUser(form.getFirstValue("user", isIgnoreCase()));
>>> setOriginalUri(form.getFirstValue("originalUri", 
>>> isIgnoreCase()));
>>> setAction(form.getFirstValue("action", isIgnoreCase()));
>>> }
>>> 
>>> // Variants that our resource generates.
>>> getVariants().add(new Variant(MediaType.APPLICATION_JSON));
>>> getVariants().add(new Variant(MediaType.APPLICATION_XML));
>>> 
>>> }
>>>
>>> @Override
>>> public Representation represent(Variant variant) throws ResourceException
>>> {
>>> Representation representation = null;
>>> 
>>> // Validate request
>>> if (StringUtils.isBlank(getUser())) {
>>> log.debug("GET FileStatusResource bad user. ");
>>> representation = representError(variant, new 
>>> ErrorMessage());
>>> 
>>> getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
>>> return representation;
>>> }
>>> 
>>> representation = representGet(this,variant);
>>> return representation;
>>> }
>>>
>>> public final Representation representGet(CoralReefResource crr, Variant
>>> variant)
>>> throws ResourceException {
>>> Representation representation = null;
>>>
>>> log.debug("HTTP GET for : " + variant.getMediaType().getName());
>>> ...
>>>
>>>
>>>
>>>
>>> Thierry Boileau wrote:
>>>   
>>>   
 Hello Andrzej,

 I wonder if the source cause if your issue is out there.
 Could you te

Re: MIME Accept Type filter

[Tal Liron]

Unfortunately, I can confirm that Andrzej's beforeSend fix is the way to 
go on this one. Been doing it for a while now...

@Thierry: The dataType parameter in .ajax is just for jQuery to handle 
the response. It doesn't actually do anything for jQuery's request.

An additional jQuery quirk to think about when working with Restlet is 
that caching really messes things up with IE. Here's what I add every time:

$(function() {
 if($.browser.msie) {
 // Caching breaks Internet Explorer
 $.ajaxSetup({
 cache: false
 });
 }
}

Perhaps it's a good idea to set up a "Client Quirks" page on the Restlet 
wiki? Obviously not Restlet's fault that clients are broken, but we need 
them.

By the way, I had no issues ever with Ext-JS. The Ext-JS Core is 
liberally licensed, and is almost a drop-in replacement for jQuery on 
things like this.

-Tal

P.S. I really wish the browser JavaScript world would abandon the term 
"AJAX." It shows a lack of commitment to what these calls are really 
about -- REST.


On 12/16/2009 07:58 AM, Andrzej Berico wrote:
> Thierry,
>
> 1) Our JQuery Ajax call:
>
> $.ajax({
>   type: 'GET',
>   url: myUrl,
>   success: onAjaxSuccess,
>   error: onAjaxError,
>  cache: false,
>  beforeSend :
> function(xhr){xhr.setRequestHeader('Accept','application/xml')}
>   });
>
> Will generate Accept header of  "*/*, application/xml". We want
> "application/xml".
>
> 2) Our Restlet 1.1.5
>   
> @Override
> public Restlet createRoot() {
>   // Create a router Restlet.
>   Router router = new Router(getContext());
>   
>   // Attach our routers.
>   router.attach("/test", HelloWorldResource.class);
>   router.attach("/file/status", FileStatusResource.class);
>
>   return router;
>   }
>
>
> public FileStatusResource(Context context, Request request, Response
> response) {
>   super(context, request, response);
>   
>   // Read URI query strings.
>   Form form = request.getOriginalRef().getQueryAsForm();
>   if (form != null) {
>   setUser(form.getFirstValue("user", isIgnoreCase()));
>   setOriginalUri(form.getFirstValue("originalUri", 
> isIgnoreCase()));
>   setAction(form.getFirstValue("action", isIgnoreCase()));
>   }
>   
>   // Variants that our resource generates.
>   getVariants().add(new Variant(MediaType.APPLICATION_JSON));
>   getVariants().add(new Variant(MediaType.APPLICATION_XML));
>   
>   }
>
> @Override
> public Representation represent(Variant variant) throws ResourceException {
>   Representation representation = null;
>   
>   // Validate request
>   if (StringUtils.isBlank(getUser())) {
>   log.debug("GET FileStatusResource bad user. ");
>   representation = representError(variant, new 
> ErrorMessage());
>   
> getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
>   return representation;
>   }
>   
>   representation = representGet(this,variant);
>   return representation;
>   }
>
> public final Representation representGet(CoralReefResource crr, Variant
> variant)
>   throws ResourceException {
>   Representation representation = null;
>
>  log.debug("HTTP GET for : " + variant.getMediaType().getName());
> ...
>
>
>
>
> Thierry Boileau wrote:
>
>> Hello Andrzej,
>>
>> I wonder if the source cause if your issue is out there.
>> Could you tell us how are built your resources? How do you send the
>> request using jquery?
>>
>> Best regards,
>> Thierry Boileau
>>
>>  
>>> Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
>>> JQuery
>>> client, sets the Accept Type to "*/*, application/xml". So the Restlet
>>> negotiates that APPLICATION_JSON should be returned as expected. However,
>>> we
>>> want APPLICATION_XML to be served. The problem is that we are unable to
>>> remove the "*/*" as the first Accept type in JQuery. JQuery seems to tack
>>> on
>>> the "*/*" as an Accept Type to every request we send.
>>>
>>> Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL
>>> or
>>> APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
>>> re-arrange the Accept list ourselves to "override" the Restlet
>>> negotiation.
>>> We are thinking of filtering, after Restlet negotiation, based on the
>>> User-Agent header for this particular JQuery client, so as not to "break"
>>> the Restlet behaviour for other clients (which is what we expect.)
>>>
>>>
>> ---

Re: MIME Accept Type filter

[Jonathan Hall]

FYI I filed this bug to jQuery over a year ago 
http://dev.jquery.com/ticket/3408

jon


Thierry Boileau wrote:
> Hi Andrzej
>
> could you use the "dataType" argument instead of the "beforeSend" one?
>
> $.ajax({type: 'GET',
> url: myUrl,
> success: onAjaxSuccess,
> error: onAjaxError,
> cache: false,
> dataType: "xml");
>
>
> Best regards,
> Thierry Boileau
>
>   
>> Thierry,
>>
>> 1) Our JQuery Ajax call:
>>
>> $.ajax({
>>  type: 'GET',
>>  url: myUrl,
>>  success: onAjaxSuccess,
>>  error: onAjaxError,
>> cache: false,
>> beforeSend :
>> function(xhr){xhr.setRequestHeader('Accept','application/xml')}
>>  });
>>
>> Will generate Accept header of  "*/*, application/xml". We want
>> "application/xml".
>>
>> 2) Our Restlet 1.1.5
>>  
>> @Override
>> public Restlet createRoot() {
>>  // Create a router Restlet.
>>  Router router = new Router(getContext());
>>  
>>  // Attach our routers.
>>  router.attach("/test", HelloWorldResource.class);
>>  router.attach("/file/status", FileStatusResource.class);
>>
>>  return router;
>>  }
>>
>>
>> public FileStatusResource(Context context, Request request, Response
>> response) {
>>  super(context, request, response);
>>  
>>  // Read URI query strings.
>>  Form form = request.getOriginalRef().getQueryAsForm();
>>  if (form != null) {
>>  setUser(form.getFirstValue("user", isIgnoreCase()));
>>  setOriginalUri(form.getFirstValue("originalUri", 
>> isIgnoreCase()));
>>  setAction(form.getFirstValue("action", isIgnoreCase()));
>>  }
>>  
>>  // Variants that our resource generates.
>>  getVariants().add(new Variant(MediaType.APPLICATION_JSON));
>>  getVariants().add(new Variant(MediaType.APPLICATION_XML));
>>  
>>  }
>>
>> @Override
>> public Representation represent(Variant variant) throws ResourceException {
>>  Representation representation = null;
>>  
>>  // Validate request
>>  if (StringUtils.isBlank(getUser())) {
>>  log.debug("GET FileStatusResource bad user. ");
>>  representation = representError(variant, new 
>> ErrorMessage());
>>  
>> getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
>>  return representation;
>>  }
>>  
>>  representation = representGet(this,variant);
>>  return representation;
>>  }
>>
>> public final Representation representGet(CoralReefResource crr, Variant
>> variant)
>>  throws ResourceException {
>>  Representation representation = null;
>>
>> log.debug("HTTP GET for : " + variant.getMediaType().getName());
>> ...
>>
>>
>>
>>
>> Thierry Boileau wrote:
>>   
>> 
>>> Hello Andrzej,
>>>
>>> I wonder if the source cause if your issue is out there.
>>> Could you tell us how are built your resources? How do you send the 
>>> request using jquery?
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>> 
>>>   
 Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
 JQuery
 client, sets the Accept Type to "*/*, application/xml". So the Restlet
 negotiates that APPLICATION_JSON should be returned as expected. However,
 we
 want APPLICATION_XML to be served. The problem is that we are unable to
 remove the "*/*" as the first Accept type in JQuery. JQuery seems to tack
 on
 the "*/*" as an Accept Type to every request we send.

 Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL
 or
 APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
 re-arrange the Accept list ourselves to "override" the Restlet
 negotiation.
 We are thinking of filtering, after Restlet negotiation, based on the
 User-Agent header for this particular JQuery client, so as not to "break"
 the Restlet behaviour for other clients (which is what we expect.)

   
 
>>> --
>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430776
>>>
>>>
>>> 
>>>   
>> 
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430802
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430816

Re: MIME Accept Type filter

[Andrzej Berico]

Thierry,

That actually changed the request.  Still get JSON though. Restlet content
negotiates APPLICATION_JSON. How can we get APPLICATION_XML ?


Request:
GET /coralreef-resource/file/status?user=greg.savaged&_=1260974638188
HTTP/1.1
Accept: application/xml, text/xml, */*
Accept-Language: en-us
x-requested-with: XMLHttpRequest
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Host: 10.1.10.166:8181
Connection: Keep-Alive
Authorization: Basic Z3JlZy5ob2NoYXJkOmJlcmljbw==




Thierry Boileau wrote:
> 
> Hi Andrzej
> 
> could you use the "dataType" argument instead of the "beforeSend" one?
> 
> $.ajax({type: 'GET',
> url: myUrl,
> success: onAjaxSuccess,
> error: onAjaxError,
> cache: false,
> dataType: "xml");
> 
> 
> Best regards,
> Thierry Boileau
> 
>> Thierry,
>>
>> 1) Our JQuery Ajax call:
>>
>> $.ajax({
>>  type: 'GET',
>>  url: myUrl,
>>  success: onAjaxSuccess,
>>  error: onAjaxError,
>> cache: false,
>> beforeSend :
>> function(xhr){xhr.setRequestHeader('Accept','application/xml')}
>>  });
>>
>> Will generate Accept header of  "*/*, application/xml". We want
>> "application/xml".
>>
>> 2) Our Restlet 1.1.5
>>  
>> @Override
>> public Restlet createRoot() {
>>  // Create a router Restlet.
>>  Router router = new Router(getContext());
>>  
>>  // Attach our routers.
>>  router.attach("/test", HelloWorldResource.class);
>>  router.attach("/file/status", FileStatusResource.class);
>>
>>  return router;
>>  }
>>
>>
>> public FileStatusResource(Context context, Request request, Response
>> response) {
>>  super(context, request, response);
>>  
>>  // Read URI query strings.
>>  Form form = request.getOriginalRef().getQueryAsForm();
>>  if (form != null) {
>>  setUser(form.getFirstValue("user", isIgnoreCase()));
>>  setOriginalUri(form.getFirstValue("originalUri", 
>> isIgnoreCase()));
>>  setAction(form.getFirstValue("action", isIgnoreCase()));
>>  }
>>  
>>  // Variants that our resource generates.
>>  getVariants().add(new Variant(MediaType.APPLICATION_JSON));
>>  getVariants().add(new Variant(MediaType.APPLICATION_XML));
>>  
>>  }
>>
>> @Override
>> public Representation represent(Variant variant) throws ResourceException
>> {
>>  Representation representation = null;
>>  
>>  // Validate request
>>  if (StringUtils.isBlank(getUser())) {
>>  log.debug("GET FileStatusResource bad user. ");
>>  representation = representError(variant, new 
>> ErrorMessage());
>>  
>> getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
>>  return representation;
>>  }
>>  
>>  representation = representGet(this,variant);
>>  return representation;
>>  }
>>
>> public final Representation representGet(CoralReefResource crr, Variant
>> variant)
>>  throws ResourceException {
>>  Representation representation = null;
>>
>> log.debug("HTTP GET for : " + variant.getMediaType().getName());
>> ...
>>
>>
>>
>>
>> Thierry Boileau wrote:
>>   
>>> Hello Andrzej,
>>>
>>> I wonder if the source cause if your issue is out there.
>>> Could you tell us how are built your resources? How do you send the 
>>> request using jquery?
>>>
>>> Best regards,
>>> Thierry Boileau
>>>
>>> 
 Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
 JQuery
 client, sets the Accept Type to "*/*, application/xml". So the Restlet
 negotiates that APPLICATION_JSON should be returned as expected.
 However,
 we
 want APPLICATION_XML to be served. The problem is that we are unable to
 remove the "*/*" as the first Accept type in JQuery. JQuery seems to
 tack
 on
 the "*/*" as an Accept Type to every request we send.

 Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL
 or
 APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
 re-arrange the Accept list ourselves to "override" the Restlet
 negotiation.
 We are thinking of filtering, after Restlet negotiation, based on the
 User-Agent header for this particular JQuery client, so as not to
 "break"
 the Restlet behaviour for other clients (which is what we expect.)

   
>>> --
>>> http://restlet.tigris.org/ds/viewMessage.do?d

Re: web.xml context-params go missing

[Thierry Boileau]

Hi Dustin,

do you mind send me a sample application with your configuration?

Best regards,
Thierry Boileau


> I have a Spring loaded RESTlet application using the 2.0M6 version.
>
> My ServerResources used to be able to obtain the context-params from the 
> web.xml using the Context.getParameters() method, but that's no longer 
> the case.  Through my debugger, I can see that the parent of the parent 
> of the getContext() method contains the parameters that I need.  This 
> grandparent Context is an instance of ComponentContext, whereas the 
> others are ChildContext instances.
>
> How do I get access to those Parameters again?
>
> Thank you!
> Dustin
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430610
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430813

Re: TunnelService - additional tunnel for quirky browser accept headers

[Thierry Boileau]

Hi Jonathan,

I've entered an issue for this interesting proposition.

http://restlet.tigris.org/issues/show_bug.cgi?id=984

Best regards,
Thierry Boileau

> I wish to propose another tunnel which is a bit more practical in 
> dealing with browser Accept header quirks.
>
> At present, browsers implement the accept header oddly.
>
> to quote Jon Blower's recent email to the list:
>
> "Firefox 3: Accept header is
> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8".
> Hence text/html is used, as expected.
>
> Chrome 0.2.149.30: Accept header is
> "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5".
>  So Chrome prefers application/xml to text/html and hence gets an XML
> representation by default.  Seems odd.
>
> IE7: Accept header does not include text/html, image/png or
> application/xml (!!) but does include "*/*" (yuck) so IE gets the
> variant that happens to be first in the Resource's list.  With the
> above code this just happens to be text/html.  So conneg doesn't
> really happen here at all."
>
> The current way of dealing with this is to use the User Agent (ua) 
> string and then 'fix-up' the accepted media.
>
> However, we have unknown browsers, or companies who change the ua string 
> of known browsers, or future versions that change the ua string, 
> different ua strings for different os, etc. This is hard to maintain and 
> leaves us open to serving incorrect representations to our users. - 
> which happens with chrome at the moment.
>
> An alternative I suggest would be to ignore the accept header and 
> provide html unless the person sending the request has gone to lengths 
> to send something specific. At lengths could mean where the accept 
> header did not contain any mention of html or xhtml at all. Then they 
> would be shown the representation they requested in the accept headers.
>
> This could be wrapped up in a tunnel like setUserAgentTunnel() and be 
> off by default. It would be an 'either or' to have this or the User 
> Agent Tunnel on.
>
> Any thoughts or opinions?
>
> Jon
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430633
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430812

Re: MIME Accept Type filter

[Thierry Boileau]

Hi Andrzej

could you use the "dataType" argument instead of the "beforeSend" one?

$.ajax({type: 'GET',
url: myUrl,
success: onAjaxSuccess,
error: onAjaxError,
cache: false,
dataType: "xml");


Best regards,
Thierry Boileau

> Thierry,
>
> 1) Our JQuery Ajax call:
>
> $.ajax({
>  type: 'GET',
>  url: myUrl,
>  success: onAjaxSuccess,
>  error: onAjaxError,
> cache: false,
> beforeSend :
> function(xhr){xhr.setRequestHeader('Accept','application/xml')}
>  });
>
> Will generate Accept header of  "*/*, application/xml". We want
> "application/xml".
>
> 2) Our Restlet 1.1.5
>   
> @Override
> public Restlet createRoot() {
>   // Create a router Restlet.
>   Router router = new Router(getContext());
>   
>   // Attach our routers.
>   router.attach("/test", HelloWorldResource.class);
>   router.attach("/file/status", FileStatusResource.class);
>
>   return router;
>   }
>
>
> public FileStatusResource(Context context, Request request, Response
> response) {
>   super(context, request, response);
>   
>   // Read URI query strings.
>   Form form = request.getOriginalRef().getQueryAsForm();
>   if (form != null) {
>   setUser(form.getFirstValue("user", isIgnoreCase()));
>   setOriginalUri(form.getFirstValue("originalUri", 
> isIgnoreCase()));
>   setAction(form.getFirstValue("action", isIgnoreCase()));
>   }
>   
>   // Variants that our resource generates.
>   getVariants().add(new Variant(MediaType.APPLICATION_JSON));
>   getVariants().add(new Variant(MediaType.APPLICATION_XML));
>   
>   }
>
> @Override
> public Representation represent(Variant variant) throws ResourceException {
>   Representation representation = null;
>   
>   // Validate request
>   if (StringUtils.isBlank(getUser())) {
>   log.debug("GET FileStatusResource bad user. ");
>   representation = representError(variant, new 
> ErrorMessage());
>   
> getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
>   return representation;
>   }
>   
>   representation = representGet(this,variant);
>   return representation;
>   }
>
> public final Representation representGet(CoralReefResource crr, Variant
> variant)
>   throws ResourceException {
>   Representation representation = null;
>
> log.debug("HTTP GET for : " + variant.getMediaType().getName());
> ...
>
>
>
>
> Thierry Boileau wrote:
>   
>> Hello Andrzej,
>>
>> I wonder if the source cause if your issue is out there.
>> Could you tell us how are built your resources? How do you send the 
>> request using jquery?
>>
>> Best regards,
>> Thierry Boileau
>>
>> 
>>> Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
>>> JQuery
>>> client, sets the Accept Type to "*/*, application/xml". So the Restlet
>>> negotiates that APPLICATION_JSON should be returned as expected. However,
>>> we
>>> want APPLICATION_XML to be served. The problem is that we are unable to
>>> remove the "*/*" as the first Accept type in JQuery. JQuery seems to tack
>>> on
>>> the "*/*" as an Accept Type to every request we send.
>>>
>>> Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL
>>> or
>>> APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
>>> re-arrange the Accept list ourselves to "override" the Restlet
>>> negotiation.
>>> We are thinking of filtering, after Restlet negotiation, based on the
>>> User-Agent header for this particular JQuery client, so as not to "break"
>>> the Restlet behaviour for other clients (which is what we expect.)
>>>
>>>   
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430776
>>
>>
>> 
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430802

Re: Thoughts on renamed functions (setEncodeRequest->setEncodingRequest)

[Thierry Boileau]

Hi Carsten,

thanks for pointing this kind of problems. We are open to any idea and 
preferences and to reconsider the current choice.
We noticed that some boolean attribute were badly named, thus we 
analyzed the code and became quite systematic, maybe too much.

Best regards,
Thierry Boileau

> Hi,
>
> I've just updated from 2.0 M4 to M6 and noticed that quite some methods have 
> been renamed, especially getters and setters of boolean field values.
>
> For example in class
> org.restlet.engine.application.Encoder
> setEncodeRequest(boolean) has been renamed to setEncodingRequest(boolean)
>
> I have to say, that the new name sounds somewhat strange and misleading to me.
> When I read "Encoding", I first think of the noun.
>
> So, "setEncodingRequest" makes me first think of "set the encoding of the 
> request" and I wonder, why hasn't this been named "setRequestEncoding()".
> It's only when I see the boolean parameter and the corresponding 
> isEncodingRequest() function, that I get the logic of this:
> "Encoding" is to be read as a verb: isEncodingRequest() - "Is [the Encoder] 
> encoding [the] Request".
>
> I have to say, that the old name and the use of the imperative verb form 
> ("Encode [the] Request!") seemed more natural to me:
> "setEncodeRequest()".
>
> According to the changeset
> http://restlet.tigris.org/source/browse/restlet?view=rev&revision=5644
> there is also for example:
> org.restlet.routing.Variable
> setEncodedOnFormat() -> setEncodingOnFormat()
> or
> org.restlet.routing.TemplateRoute
> setMatchQuery() -> setMatchingQuery() (possibly confused with a meaning of 
> "set the matching query (the query that matches)" instead of "tell the route 
> to match the query")
>
>
> Of course this is a minor matter and is probably also a matter of taste, but 
> maybe others agree on this, and the change can be rethought over (at least 
> for cases where the -ing verb can be confused with a noun).
>
> Cheers,
> Carsten
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430441
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430799

Re: MIME Accept Type filter

[Andrzej Berico]

Thierry,

1) Our JQuery Ajax call:

$.ajax({
 type: 'GET',
 url: myUrl,
 success: onAjaxSuccess,
 error: onAjaxError,
cache: false,
beforeSend :
function(xhr){xhr.setRequestHeader('Accept','application/xml')}
 });

Will generate Accept header of  "*/*, application/xml". We want
"application/xml".

2) Our Restlet 1.1.5

@Override
public Restlet createRoot() {
// Create a router Restlet.
Router router = new Router(getContext());

// Attach our routers.
router.attach("/test", HelloWorldResource.class);
router.attach("/file/status", FileStatusResource.class);

return router;
}


public FileStatusResource(Context context, Request request, Response
response) {
super(context, request, response);

// Read URI query strings.
Form form = request.getOriginalRef().getQueryAsForm();
if (form != null) {
setUser(form.getFirstValue("user", isIgnoreCase()));
setOriginalUri(form.getFirstValue("originalUri", 
isIgnoreCase()));
setAction(form.getFirstValue("action", isIgnoreCase()));
}

// Variants that our resource generates.
getVariants().add(new Variant(MediaType.APPLICATION_JSON));
getVariants().add(new Variant(MediaType.APPLICATION_XML));

}

@Override
public Representation represent(Variant variant) throws ResourceException {
Representation representation = null;

// Validate request
if (StringUtils.isBlank(getUser())) {
log.debug("GET FileStatusResource bad user. ");
representation = representError(variant, new 
ErrorMessage());

getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return representation;
}

representation = representGet(this,variant);
return representation;
}

public final Representation representGet(CoralReefResource crr, Variant
variant)
throws ResourceException {
Representation representation = null;

log.debug("HTTP GET for : " + variant.getMediaType().getName());
...




Thierry Boileau wrote:
> 
> Hello Andrzej,
> 
> I wonder if the source cause if your issue is out there.
> Could you tell us how are built your resources? How do you send the 
> request using jquery?
> 
> Best regards,
> Thierry Boileau
> 
>> Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A
>> JQuery
>> client, sets the Accept Type to "*/*, application/xml". So the Restlet
>> negotiates that APPLICATION_JSON should be returned as expected. However,
>> we
>> want APPLICATION_XML to be served. The problem is that we are unable to
>> remove the "*/*" as the first Accept type in JQuery. JQuery seems to tack
>> on
>> the "*/*" as an Accept Type to every request we send.
>>
>> Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL
>> or
>> APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
>> re-arrange the Accept list ourselves to "override" the Restlet
>> negotiation.
>> We are thinking of filtering, after Restlet negotiation, based on the
>> User-Agent header for this particular JQuery client, so as not to "break"
>> the Restlet behaviour for other clients (which is what we expect.)
>>
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430776
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/MIME-Accept-Type-filter-tp4173789p4175554.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430798

Re: Building GAE version of restlet

[Thierry Boileau]

Hi Jim,

it seems that the Spring engine is confused because there are 2 
"setAttachments" methods declared in the class. However, as they don't 
have the same parameters, this should not be a problem.

Best regards,
Thierry Boileau

> Excellent Thierry all works as described.
>
> Managed to deploy a GAE application based on Spring + Restlet. I am  
> seeing one warning message during startup (see below) but everything  
> else is working as expected.
>
> Dec 16, 2009 9:37:15 AM  
> org.springframework.beans.GenericTypeAwarePropertyDescriptor  
> getWriteMethod
> WARNING: Invalid JavaBean property 'attachments' being accessed!  
> Ambiguous write methods found next to actually used [public void  
> org.restlet.ext.spring.SpringRouter.setAttachments(java.util.Map)]:  
> [public static void  
> org 
> .restlet 
> .ext 
> .spring 
> .SpringRouter.setAttachments(org.restlet.routing.Router,java.util.Map)]
> 2009-12-16 09:37:15.921::INFO:  Started  
> selectchannelconnec...@127.0.0.1:
>
>
>
> cheers
> 
>
>
>
> On 14/12/2009, at 8:29 PM, Thierry Boileau wrote:
>
>   
>> Hello Jim,
>>
>> the "build" directory contains a ant build script. If you lanch the
>> "build" target, it will first generate the source code of each edition
>> (jse, jee, gae, gwt, android) inside the "temp" subdirectory, then try
>> to compile the code, launch the junit test cases, and build the jar
>> files inside the "temp//dist" subdirectory.
>> If you want to limit the build to a certain list of editions, create a
>> "custom.properties" file and set the "editions" parameter. For  
>> example:
>> editions: gae,jse
>>
>> I hope this will help you.
>> Best regards,
>> Thierry Boileau
>>
>> 
>>> HI,
>>>
>>> Are there any specific instructions for building a GAE-enabled  
>>> version
>>> of the restlet framework from 'trunk'
>>>
>>> cheers
>>> 
>>>
>>> --
>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430133
>>>
>>>
>>>   
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430220
>> 
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430749
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430795

Re: FirstStepsApplication as standalone java app doesnt work

[Thierry Boileau]

hello,

that works for me with org.restlet.jar taken from the jse edition v2.0m6.
Could you tell us what is the context? Eclipse, netbeans, command-line? 
The jar you are using, the kind of client?

Best regards,
Thierry Boileau

> Hey everybody,
>
> I tried the firstSteps-tutorial in both ways - in a servlet container and as 
> a standalone Java application.
>
> Inside the servlet container everything works fine. 
>
> The pure java application doesn't work.I downloaded the source at 
> http://www.restlet.org/documentation/2.0/examples/firstSteps/sources.zip and 
> didn't change anything.
>
> When running it I can see 
> "org.restlet.engine.http.StreamServerHelper start
> INFO: Starting the internal HTTP server" on the terminal.
>
> Now when I try to visit "http://localhost:8182/hello"; all I get is a 
> connection error.
>
> Has anyone an idea what the problem could be?
>
> Best regards
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430704
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430789

Re: MIME Accept Type filter

[Thierry Boileau]

Hello Andrzej,

I wonder if the source cause if your issue is out there.
Could you tell us how are built your resources? How do you send the 
request using jquery?

Best regards,
Thierry Boileau

> Our Restlet resource server APPLICATION_JSON and APPLICATION_XML. A JQuery
> client, sets the Accept Type to "*/*, application/xml". So the Restlet
> negotiates that APPLICATION_JSON should be returned as expected. However, we
> want APPLICATION_XML to be served. The problem is that we are unable to
> remove the "*/*" as the first Accept type in JQuery. JQuery seems to tack on
> the "*/*" as an Accept Type to every request we send.
>
> Is there an elegant way in Restlet to filter the "*/*" values, e.g. ALL or
> APPLICATION_ALL? We can certainly get the Accept Headers in Restlet and
> re-arrange the Accept list ourselves to "override" the Restlet negotiation.
> We are thinking of filtering, after Restlet negotiation, based on the
> User-Agent header for this particular JQuery client, so as not to "break"
> the Restlet behaviour for other clients (which is what we expect.)
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430776

Re: Building GAE version of restlet

[Jim Alateras]

Excellent Thierry all works as described.

Managed to deploy a GAE application based on Spring + Restlet. I am  
seeing one warning message during startup (see below) but everything  
else is working as expected.

Dec 16, 2009 9:37:15 AM  
org.springframework.beans.GenericTypeAwarePropertyDescriptor  
getWriteMethod
WARNING: Invalid JavaBean property 'attachments' being accessed!  
Ambiguous write methods found next to actually used [public void  
org.restlet.ext.spring.SpringRouter.setAttachments(java.util.Map)]:  
[public static void  
org 
.restlet 
.ext 
.spring 
.SpringRouter.setAttachments(org.restlet.routing.Router,java.util.Map)]
2009-12-16 09:37:15.921::INFO:  Started  
selectchannelconnec...@127.0.0.1:



cheers




On 14/12/2009, at 8:29 PM, Thierry Boileau wrote:

> Hello Jim,
>
> the "build" directory contains a ant build script. If you lanch the
> "build" target, it will first generate the source code of each edition
> (jse, jee, gae, gwt, android) inside the "temp" subdirectory, then try
> to compile the code, launch the junit test cases, and build the jar
> files inside the "temp//dist" subdirectory.
> If you want to limit the build to a certain list of editions, create a
> "custom.properties" file and set the "editions" parameter. For  
> example:
> editions: gae,jse
>
> I hope this will help you.
> Best regards,
> Thierry Boileau
>
>> HI,
>>
>> Are there any specific instructions for building a GAE-enabled  
>> version
>> of the restlet framework from 'trunk'
>>
>> cheers
>> 
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430133
>>
>>
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430220

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430749