RE: Re: Using JUnit with JacksonRepresentation
Hi, Thanks for the reply. Yes I tried calling Representation.getTest() on either side of the call and the JSON appears to be correctly formed. I did notice the following message in my output when running under JUnit. WARNING: The GAE edition is unable to get an InputStream out of an OutputRepresentation. This is a GAE application. Could this be the problem? Thanks, Alex -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3086557
Using JUnit with JacksonRepresentation
Hi,
I'd like to be able to write some tests using JUnit to rest server resource
classes. I'm encountering a problem when I try to pass a JacksonRepresentation
in. My test class looks something a little like this:
{
TransactionResource resource = new MyResource();
MyData data = new MyData(etc);
Representation entity = new JacksonRepresentationMyData(myData);
entity.setMediaType(MediaType.APPLICATION_JSON);
Representation response = resource.post(entity);
}
This is all fine as far as I know. But I receive an error in my ServerResource
derived class when I try and deserialize the object using Jackson:
MyData myData = new JacksonRepresentation(entity, MyData.class)
.getObject();
com.fasterxml.jackson.databind.JsonMappingException: No content to map due to
end-of-input
at [Source: UNKNOWN; line: 1, column: 1]
at
com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:164)
at
com.fasterxml.jackson.databind.ObjectReader._initForReading(ObjectReader.java:1298)
at
com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:1199)
at
com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:798)
at
org.restlet.ext.jackson.JacksonRepresentation.getObject(JacksonRepresentation.java:309)
Is this the correct approach? Am I doing something wrong in my test case in
setting up the call to my resource class?
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3086450
ConverterService is swallowing exceptions
I would like to be able to return a custom Status (CLIENT_ERROR_UNPROCESSABLE_ENTITY) and error message (Field XXX is missing, for example) if my deserializer detects a problem when converting the request payload into an object (and throws an exception within the deserialize() method). The problem is that the ConverterService.toObject() method simply logs the exception and doesn't pass it along. The StatusService only sees a generic ResourceException with a 415 (Unsupported Media Type) status - the original exception is lost. Is there any way to get the ConverterService to preserve the original deserailization exception so the StatusService can do something useful with it? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3064952
Re: Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
Hello Jerome, thanks a lot for responding. If gaving the org.restlet.ext.net.jar on your classpath is enough, then I've already done what you're suggesting. As I stated on my first post, I'm not using the internal http connector, but instead the apache httpclient. In any case, I've even explicitly created the ClientResource calling the external http connector (Engine.getInstance().getRegisteredClients().add(new org.restlet.ext.net.HttpClientHelper(null));), but I'm still getting the 1001 error. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578781.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054979
Re: Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
This doesn't have the desired result either. :/ br, Alex On 6 Μαϊ 2013, at 6:08 μ.μ., Jerome Louvel-3 [via Restlet Discuss] ml-node+s1400322n7578782...@n2.nabble.com wrote: Alex; You to put the connector in the first postion doing this: Engine.getInstance().getRegisteredClients().add(0, new org.restlet.ext.net.HttpClientHelper(null)); Best regards, Jerome 2013/5/6 Alex [hidden email] Hello Jerome, thanks a lot for responding. If gaving the org.restlet.ext.net.jar on your classpath is enough, then I've already done what you're suggesting. As I stated on my first post, I'm not using the internal http connector, but instead the apache httpclient. In any case, I've even explicitly created the ClientResource calling the external http connector (Engine.getInstance().getRegisteredClients().add(new org.restlet.ext.net.HttpClientHelper(null));), but I'm still getting the 1001 error. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578781.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054979 If you reply to this email, your message will be added to the discussion below: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578782.html To unsubscribe from Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001, click here. NAML -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578783.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054983
Re: Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
Ok, I found the root cause of the problem. It had nothing to do with Restlet or my code. It was all a matter of installing correctly the intermediate certificates on AWS. The certificate chain of my CA consists of 4 certificate files, and AWS needs this chain in a very specific order (signing certificate first, CA root certificate last, and all other certificates in between), given in a pem/text format. Unfortunately the AWS documentation is a mess, so I had to dig around and do some trial-and-error before making it work. Your suggestion about checking the getStatus() stack (and the java.security.cert.CertPathValidatorException exception) of the response was the trigger that lead me to investigate and revise the way I installed my certs on AWS, so thanks for that. :) So I guess this matter is closed. Thanks for the support, I really appreciate it. :) Keep up the good work you're doing on Restlet. br, Alex -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578786.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054994
Re: Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
Ok, it is as I was suspecting. The problem is that the certificate (having a
CNAME = www.mydomain.com, but being loaded from
https://mywebservice.elasticbeanstalk.com) seems to the Android client as
invalid, thus it doesn't even send the GET/POST request to the server.
I realized this when I send a POST method from the terminal (using curl),
ignoring the ssl verification warnings (-k option). This time the secure
connection responded as expected, sending back the json reply.
Based on Google's own Android documentation suggestion
(http://developer.android.com/training/articles/security-ssl.html#CommonHostnameProbs),
I tried to alter the HostnameVerifier method in order to get past the
certification validation. This is how my ClientResource is currently
created:
/public static ClientResource createClientResource(String resourceUri) {
Reference reference = new Reference(resourceUri);
System.setProperty( ssl.TrustManagerFactory.algorithm,
javax.net.ssl.KeyManagerFactory.getDefaultAlgorithm());
org.restlet.Context context = new org.restlet.Context();
context.getAttributes().put(hostnameVerifier, new
HostnameVerifier() {
@Override
public boolean verify(String arg0, SSLSession arg1) {
return true;
}
});
ClientResource resource = new ClientResource(context,
reference);
Engine.getInstance().getRegisteredClients().clear();
Engine.getInstance().getRegisteredClients().add(new
HttpClientHelper(null));
Engine.getInstance().getRegisteredConverters().add(0, new
JacksonConverter());
resource.release();
return resource;
}/
But this doesn't work either, I still get the 1001 recoverable error. Still,
the Android client can't get past the invalid request.
I'd greatly appreciate any suggetions. :)
br,
Alex
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578778.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054928
Re: Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
Hello again, I've also tried the Android project with 2.1.2 libraries, but now I'm stuck on the exception /*java.lang.RuntimeException: Unable to create SSLContext*/ caused by /*java.security.NoSuchAlgorithmException: TrustManagerFactory SunX509 implementation not found*/. The only reference I could find is this one http://stackoverflow.com/questions/12192536/java-security-nosuchalgorithmexception-trustmanagerfactory-sunx509-implementati , but I didn't have any luck with that. It includes some kind of workaround, but I'm not sure where exactly it should be applied. I'm really stuck here, so any help would be much appreciated. br, Alex -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771p7578774.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054835
Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001
Hi all, I have written an Android web service client using the Restlet framework for Android (2.0.15), and I've also written the web service backend as well (again with Restlet 2.0.15 JEE) which has been uploaded on AWS Elastic Beanstalk (so the client calls would be in the form of http://my_web_service.elasticbeanstalk.com/this/is/my/request;). Everything works fine on HTTP, so now I'd like to replace it with HTTPS, but this has proven more difficult that I initially thought. I have created a trial SSL certificate from Comodo, where I have declared, as a CNAME, a domain that I own (unfortunately, I cannot declare the elasticbeanstalk.com subdomain, where the AWS load balancer is running, as a certificate hostname). This certificate has been uploaded to my AWS instance, and it seems to be running succsefully (tested via web browser, a couple of https calls get through succesfully after I accept the certificate on the browser). The only thing that I don't like about this certificate is the fact that I get a warning that this may be an invalid certificate, since the declared hostname (my domain) and the actual hostname that the certificate is running (elasticbeanstalk.com) do not match. In my client I'm using the apache http client (have loaded the org.apache.httpclient.jar on claspath), and this is how I create the client resource I use on every call, which is plain and simple: /ClientResource resource = new ClientResource(resourceUri); Engine.getInstance().getRegisteredClients().clear(); Engine.getInstance().getRegisteredClients().add(new HttpClientHelper(null));/ Of course, /resourceUri/ is in the form of https://my_web_service.elasticbeanstalk.com/this/is/my/request;, and this is the only difference between the working HTTP case and the non-working HTTPS case. With HTTPS, I get the error below: A recoverable error was detected (1001), attempting again in 2000 ms. I've tried several suggestions that I found on google (using org.restlet.ext.net httpclient instead of apache or even loading the org.restlet.ext.ssl jar from Restlet Android 2.1), but nothing has worked so far. I've even captured a network trace with Wireshark, and here's the callflow: ssl_call_flow.txt http://restlet-discuss.1400322.n2.nabble.com/file/n7578771/ssl_call_flow.txt From the callflow above, it seems that client and server fail to complete a succesful negotiation, but I have no idea why. Any suggestions on how to resolve this problem are welcome. I believe that the issue exists on the client side (Android app using Restlet 2.0.15 framework), but not on the app code itself (since everything works fine when using HTTP) but rather on the SSL negotiation/handshake before actually making any calls. I also believe that the Certificate Authority (Comodo) is successfully accepted/trusted by Android (I've done https calls through the android device browser), but it still gives you a certificate warning that you need to accept before continuing. Could it be that Restlet 2.0.15 is not handling smoothly SSL communication, and I would need to upgrade to 2.1 or later? Looking forward to hearing your suggestions. In case you'd like to get some more info that could help, just ask me. :) Thanks in advance, Alex -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3054809
OpenId showcase
Hey, Unfortunately, the code in the wiki does not allow the user to choose her own OpenId provider and it does not tell the user that she will be redirected. Can I give the user a form to select her OpenId provider? Is there a more complete example somewhere? Regards, Alex -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3011434
HTTPS/SSL on Android client with Restlet 2.0.14
Hi all, I'm new to Restlet (and WS in general), so I'm counting on your understanding if my questions seem stupid. :) I've been playing around with a test web service using Restlet 2.0.14 framework. My server uses JSE whilst my client is on Android. I've created a self-signed certificate, which has been already added (configuring the various parameters) on the server side. I have checked this using openssl and also a web browser (as a client), and the certificate seems to be working fine on the server. The problem is, as you have probably guessed, the fact that Android doesn't trust my certificate, since it's not in the trusted authorities list. I have found this workaround (http://stackoverflow.com/a/4837230) in order to overcome the problem, which basically creates a custom http client (based on the apache client) including some ssl related parameters, in order for the client to trust all authorities. Now, let me not bother you any more with the generics and get to my question. This workaround creates a custom http client, so it returns an object of DefaultHttpClient type. But, on my client app this is how I register new client: Engine.getInstance().getRegisteredClients().add(0, new HttpClientHelper(null)); This method requires an HttpHelper object, not a DefaultHttpClient object like the one I have prepared for the ssl connection. So, I would like to ask (hoping that this is not the stupidest question ever) for some guidance or example on how to correlate the custom http client with the http client/connector that my app uses by default (which is supposed to be the apache http client). Or put it simple, how do I load the custom - self-signed certificate ready - http client on my Android client? Also, one more question. If I had purchased a CA-provided certificate (for example from Verisign), I wouldn't have to do any of these workarounds, right? All I had to do is define the client protocol (when creating a resource) to HTTPS instead of HTTP, and the rest (downloading and accepting the certificate from the server) would be done automatically, right? Thanks in advance for any assistance. If you need more info about my implementation, I will happily provide it. br, Alex -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2991328
Re: USing Freemarker with ServletAdapter
Hi Thierry, I understand how to set the protocol on Component. My problem is more fundamental than that I think. When working with ServletAdapter, I don't have a reference to Component anywhere at hand that I can find. The only Restlet framework classes that I'm manipulating in my HttpServlet derived class are Application, Context and ServerAdapter. Do I need to 'new' a Component and manipulate its configuration similar to how ServerServlet is doing and eventually cause it to run? Intuitively to me this doesn't sound correct since I assume that's the role of ServerAdapter? Thanks, Alex On Feb 29, 2012, at 3:55 AM, Thierry Boileau-3 [via Restlet Discuss] wrote: Hello Alex, did you try to update the list of client connectors registered by the Component? You can make a call such as Component#getClients().add(Protocol.CLAP); Best regards, Thierry Boileau Hi, I am integrating Guice and Restlet in an approach that involves using ServletAdapter instead of wiring up ServerServlet. Everything works fine until I want to involve a representation that comes from Freemarker. The problems seem to come from the fact that I can't properly set the client protocol and the Component level in Restlet when I'm using ServletAdapter. Freemarker and Restlet work OK together for me when I use ServerServlet and set the CLAP protocol through web.xml. Unless I'm missing something, I cannot find a way to set the CLAP protocol into Component when using ServletAdapter. I can provide code snippets if it helps. Any suggestions? Thanks! -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/USing-Freemarker-with-ServletAdapter-tp7327160p7327160.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2927727 If you reply to this email, your message will be added to the discussion below: http://restlet-discuss.1400322.n2.nabble.com/USing-Freemarker-with-ServletAdapter-tp7327160p7328614.html To unsubscribe from USing Freemarker with ServletAdapter, click here. NAML -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/USing-Freemarker-with-ServletAdapter-tp7327160p7329508.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2928041
USing Freemarker with ServletAdapter
Hi, I am integrating Guice and Restlet in an approach that involves using ServletAdapter instead of wiring up ServerServlet. Everything works fine until I want to involve a representation that comes from Freemarker. The problems seem to come from the fact that I can't properly set the client protocol and the Component level in Restlet when I'm using ServletAdapter. Freemarker and Restlet work OK together for me when I use ServerServlet and set the CLAP protocol through web.xml. Unless I'm missing something, I cannot find a way to set the CLAP protocol into Component when using ServletAdapter. I can provide code snippets if it helps. Any suggestions? Thanks! -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/USing-Freemarker-with-ServletAdapter-tp7327160p7327160.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2927727
Re: Controlling Server Header?
On Fri, Oct 28, 2011 at 5:18 AM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Alex, The Response.serverInfo.agent property is mapped to this HTTP Server header, so any place where you can update your response object should do. OK. That's what I thought. As an enhancement, it would certainly be nice to be able to set this either on the org.restlet.Server or org.restlet.routing.VirtualHost instance without having to add another filter. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2866164
Controlling Server Header?
Is there any easy way to control the Server header in the response other than using a Filter? --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2865474
Re: Code working on 2.0 doesn't work on 2.1RC1
On Sat, Oct 22, 2011 at 9:58 AM, Gabriel Pulido gabriel.pulidodetor...@gmail.com wrote: This client when I use the 2.0 restlet library works well and I could use the object and the representation. However when I use the 2.1 restlet library the line: EnvObject object = (EnvObject)resource.retrieveObject(); Object is always null (Although objectXml has the data correct). So there is any problem in the proxy mechanism that tries to retrieve the Object. Do I miss something? this is turning me crazy :) Do you have some server logs? Turn on fine logging and see what happens on the server. There should be two requests and maybe the second one failed. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2864513
Authorization Header vs. ChallengeResponse
I keep finding the choice of ChallengeResponse for the Authorization header a poor match. If you look at some of the OAuth specifications, you see uses like the Bearer credential [1] where the Authorization header contains an access token. There is no regular match between a ChallengeRequest and a ChallengeResponse. It makes it even further of a miss match when you need to construct an Authorization header with an access token. You end up doing something like: ChallengeResponse token = new ChallengeResponse(new ChallengeScheme(HTTP_Bearer,Bearer)); token.setRawValue(accessToken); and that feels wrong as it isn't a response to anything. Also, when proxying requests (or passing them internally via RIAP requests), you then need to make special cases to check for Authorization headers as decoded into ChallengeRequest instances. ...just a bit a feedback. I'm not quite sure what I would do about this right now. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-10 --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2859140
Re: Issue in 2.1.m7 with SSL Client Connections
On Wed, Oct 12, 2011 at 1:05 AM, Thierry Boileau thierry.boil...@noelios.com wrote: Hello Alex, I've entered an issue for tracking this bug : http://restlet.tigris.org/issues/show_bug.cgi?id=1338. We're quite busy but will have a look at this preoccupating error. Thanks. I have a test case that I'll attach. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2853937
Re: Issue in 2.1.m7 with SSL Client Connections
On Tue, Sep 27, 2011 at 5:36 AM, Alex Milowski ale...@milowski.org wrote: Yet even more information: On a whim, I switched back to creating a new Client and not using the Client returned by getContext().getClientDispatcher(). I call stop() when I am finished and now everything works fine. So, here's the state of play: Client client = getContext().getClientDispatcher(); ...same code... results in some kind of hang where the number of available clients or sockets is somehow depleted. No comments on this? Feels like a bug to me... --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2853541
Re: Issue in 2.1.m7 with SSL Client Connections
On Mon, Sep 26, 2011 at 2:44 PM, Alex Milowski ale...@milowski.org wrote: I was tracking down an out-of-memory error with my new Atomojo V2 server project where I moved to 2.1.m7 and I found the solution quite disturbing. I have a configuration where I call out to Google's ClientLogin and the code that did that had this code: Client client = new Client(context.createChildContext(),service.getSchemeProtocol()); I am unable to reproduce this problem outside of my large server application (Atomojo V2). In my simple test case, I keep seeing log entries like: Stopping the HTTP Client. which I do not see in my Atomojo V2 server log. I suspect that the client isn't being garbage collected. Should developers allways call stop() on a client they instantiated when they are done? I did this in my test case and I see the memory consumption much more stable. I changed the code to use the Client returned by getClientDispatcher() but I'd like to understand how instantiated clients should be handled. I still have a problem with the Client instance returned by getContext().getClientDispatcher(). After a large number of request, it eventually fails with a status code of 1001. That usually has meant some kind of exception deep in the code but I haven't been able to track that down. I am hoping to reproduce this in a much smaller test case. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2846554
Re: Issue in 2.1.m7 with SSL Client Connections
)
at org.restlet.engine.connector.Connection.close(Connection.java:174)
at
org.restlet.engine.connector.Connection.onTimeOut(Connection.java:617)
at
org.restlet.engine.connector.ConnectionController.controlConnections(ConnectionController.java:93)
at
org.restlet.engine.connector.ConnectionController.doRun(ConnectionController.java:146)
at org.restlet.engine.connector.Controller.run(Controller.java:155)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Sep 27, 2011 5:04:57 AM org.restlet.engine.connector.Connection close
FINE: Connection to www.google.com/72.14.204.147:443 is now closed
Sep 27, 2011 5:04:57 AM org.atomojo.www.apps.login.LoginAction login
INFO: Authorization request for {...} returned: 1001
Any ideas? I'm going to try aborting the response once I've got the
authentication response to see what happens.
--Alex Milowski
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2846630
Re: Issue in 2.1.m7 with SSL Client Connections
Yet even more information: On a whim, I switched back to creating a new Client and not using the Client returned by getContext().getClientDispatcher(). I call stop() when I am finished and now everything works fine. So, here's the state of play: Client client = getContext().getClientDispatcher(); ...same code... results in some kind of hang where the number of available clients or sockets is somehow depleted. Client client = new Client(getContext().createChildContext(),ref.getSchemeProtocol()); ...same code.. client.stop(); client = null and everything works fine (so far). I had just moved to use getClientDispatcher() to solve an out-of-memory issue. I think calling stop() will keep that from happening again but I'll have to run some more tests. Meanwhile, I also see this in the log: INFO: Stopping the internal[HTTPS/1.1] client I have the org.restlet.ext.net.jar in the classpath (jar manifest), should I be seeing that? It doesn't seem right. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2846654
Issue in 2.1.m7 with SSL Client Connections
I was tracking down an out-of-memory error with my new Atomojo V2 server project where I moved to 2.1.m7 and I found the solution quite disturbing. I have a configuration where I call out to Google's ClientLogin and the code that did that had this code: Client client = new Client(context.createChildContext(),service.getSchemeProtocol()); instead of this: Client client = context.getClientDispatcher(); The service URI was over HTTPS and the memory was being consumed by byte arrays instantiated in the SSL handling. I found that out-of-memory error from such a subtle change in the API usage disturbing. Any ideas on what could cause that? I have other issues this code as well in 2.1.m7. After awhile, the client stops being able to connect. If I restart the server, everything is fine. I have been using this code for a long time without any issue. I am using the org.restlet.ext.net.jar client connector but the SSL client support also requires org.restlet.ext.ssl.jar. When I looked at the memory consumption, there were class from org.restlet.ext.ssl.jar involved. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2846045
isAvailable() returning false on EmptyRepresentation
I've been using isEntityAvailable() as a guard for null
representations and ran into a snag with HEAD requests. The server is
returning the Content-Length and Last-Modified header on the HEAD
request and the client's Response instance gets an
EmptyRepresentation. By default, isAvailable() on EmptyRepresentation
returns false and so isEntityAvailable on Request returns false.
The result is that instead of doing:
if (response.isEntityAvailable()) {
Representation entity = response.getEntity();
...
}
I now have to do:
Representation entity = response.getEntity();
if (entity!=null) {
...
}
For other requests where the entity body is returned, the first case
works and is more readable (at least, to me).
After reading the API documentation again, I'm questioning the value
of using isEntityAvailable() as the Represenation instance could cause
undesirable error states when isAvailable() returns false for some
reason.
What is the intended use isEntityAvailable() considering empty
entities and requests like HEAD versus those that just might be
slow?
--Alex Milowski
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2834028
Headers in 2.1
I think this is out of date: http://www.restlet.org/documentation/2.1/jse/api/org/restlet/Message.html#getAttributes() The instance returned for org.restlet.http.headers is typed as Seriesorg.restlet.engine.header.Header --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2833817
Re: Version 2: How to get XML representation
On Fri, Aug 26, 2011 at 1:05 AM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Ivano, Another option would be to do: Document doc = resource.get(Document.class); That should just works with automagic conversion :) That is some magic! I just took a look at this page on the ConverterService: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/331-restlet/360-restlet.html I'm left wanting a bit more of an example other than digging into the source. Neat idea thought and I may have to try this out for my own classes. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2830739
Re: Version 2: How to get XML representation
On Thu, Aug 25, 2011 at 10:10 AM, Ivano Carrara icarr...@studio5.it wrote: Hi all, Using Version 1 of Restlet, I built a client to get Xml from a remote server and to examine it using Xpath expressions - below a fragment of code: Request req = new Request(Method.GET, url); Client client = new Client(Protocol.HTTP); Response resp = client.handle(req); DomRepresentation doc = resp.getEntityAsDom(); How I can obtain the same doc object using the Version 2 ? Below the actual code: ClientResource resource = new ClientResource(url); resource.get(); Then using resource.get().getText()); I obtain the text of my XML, but I need the DOM representation to use with XPath expressions. With Version 2, what is the equivalent code to DomRepresentation doc = resp.getEntityAsDom(); of Version 1 ? You can either use the DocumentBuilder API from JAXP: DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); docBuilder = factory.newDocumentBuilder(); Document doc = docBuilder.parse(new InputSource(resource.get().getReader())); or you can use the DomRepresentation from the XML extension: DomRepresentation domRep = new DomRepresentation(resource.get()); Document doc = domRep.getDocument(); I personally use the DocumentBuilder API so I have control over the DOM construction. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2829756
sslServerAlias use?
As always, SSL configuration is always an adventure. I was testing a configuration UCC certificate (multiple subdomains) with a Restlet-based application and after quite a bit of struggles, I was able to get it to work. The trouble turned out to be with the certificate and once it was generated properly, everything worked the way I thought it would. During my experimentation, I tried setting sslServerAlias as a parameter and got this exception: Javax.net.ssl.SSLHandshakeException: no cipher suites in common I wouldn't expect that to happen. In fact, since the keystore has only one alias, it shouldn't matter whether the sslServerAlias is set or not as long as when it is set, it matches the alias. This seem like a bug. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2829012
Re: Re: Internal Connector Error (1002)
On Wed, Mar 9, 2011 at 8:22 AM, Thierry Boileau thierry.boil...@noelios.com wrote: Hello Cédric, what happens if you test this? ClientResource res = new ClientResource(http://www.restlet.org;); res.get().write(System.out); Did you try another client connector, for example the one provided by the net extension? I mean, can you add the org.restlet.ext.net.jar to the classpath and test? This is similar to a problem I was having with the internal client connector. It was fixed by switch to the net extension for the client connector. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2711025
Re: Warnings from Finder?
On Tue, Aug 3, 2010 at 8:45 PM, Thierry Boileau thierry.boil...@noelios.com wrote: Hello Alex, this warning should happen in very specific cases, when the resource cannot be instantiated. Actually, if you have implemented the default constructor. I think you can move this code to the doInit() method. I'm not following what you are suggesting. Can you be more specific? Thanks! --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2642774
Re: About loading component from XML configuration
On Thu, Jul 22, 2010 at 2:00 PM, Daniel Ferber dfffo...@gmail.com wrote: Hi, I would like do expose some questions about creating the Component from a XML configuration file. This configuration routes the virtual host to several Applications. 1) After the component has been created, is it possible to get a reference to some specific application that were created? For example, query the application by and ID or some other attribute from the XML? You should look at the RIAP protocol for making requests between applications. 2) Is it possible for the XML configuration to describe some parameters/properties that will be passed to the application that will be created? Yes. You just use the 'parameter' element. The schema is available here: http://www.restlet.org/schemas/1.1/Component 3) I want to set a different status service for each application. Is that possible from the XML configuration? Not sure about that... --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2638272
Warnings from Finder?
Why does the Finder now output this warning: WARNING: No target resource was defined for this finder: ... ? This happens with the find() fails to return an instance. I thought returning a null was the way to handle not found and now I get warnings. I'd rather not create a ServerResource instance for every non-existent resource on the server. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2636938
Re: Access Logging - Multiple Files
On Thu, Jul 8, 2010 at 3:13 PM, Alex Milowski ale...@milowski.org wrote: I've been playing around with the AccessLogFileHandler rather than what I've usually been doing and it works reasonably well except that, somehow, I get two files. I configure my pattern as: org.restlet.engine.log.AccessLogFileHandler.pattern=%h/access-%g.log but then when I run the application via the Grizzly connector, I get the following log-related files: access-0.log access-0.log.lck access-0.log.1 access-0.log.1.lck This is most certainly coming from my log configuration but I'm certain why. I've been messing around with the configuration and the problem has gone away. ...which is good, but not knowing why is bad. :( --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2631430
Access Log Examples - Out of Date?
I think this page is a bit out of date for 2.0: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Specifically, the org.restlet.util.AccessLogFileHandler properties should be org.restlet.engine.log.AccessLogFileHandler. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2630974
Access Logging - Multiple Files
I've been playing around with the AccessLogFileHandler rather than what I've usually been doing and it works reasonably well except that, somehow, I get two files. I configure my pattern as: org.restlet.engine.log.AccessLogFileHandler.pattern=%h/access-%g.log but then when I run the application via the Grizzly connector, I get the following log-related files: access-0.log access-0.log.lck access-0.log.1 access-0.log.1.lck I'm not certain why two files are created. The .1 suffixed log file is the one that actually logs the requests. The other is always empty. Any ideas? --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2630977
Re: Disable DTD validation doesn't seem to work (DomRepresentation)
On Mon, Jun 28, 2010 at 11:54 AM, Carles Barrobés cbarro...@isigma.es wrote: I'm parsing an XHTML response with DomRepresentation, and it generates an exception: Exception in thread main java.lang.RuntimeException: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd at org.restlet.ext.xml.XmlRepresentation.internalEval(XmlRepresentation.java:556) at org.restlet.ext.xml.XmlRepresentation.getNodes(XmlRepresentation.java:437) at es.isigma.portasigma.client.ClientExample.main(ClientExample.java:32) This is due to the fact that restlet's DomRepresentation is attempting DTD validation even if I explicitly disable it in my client code ( doc.setValidatingDtd(false) ): This isn't because of DTD validation. It is because the parser is reading the external subset. You (or someone) need to allow you to turn off retrieving and parsing the external subset. You could possibly do that by setting the EntityResolver instance. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2626841
Re: Null Pointer Exception when using relative references with RIAP
On Sat, Jun 12, 2010 at 9:42 AM, Jerome Louvel
jerome.lou...@noelios.com wrote:
Hi Alex,
I've added this test case to ReferenceTestCase class and it runs fine:
public void testRiap() throws Exception {
Reference baseRef = new Reference(riap://component/exist/db/);
Reference ref = new Reference(baseRef, something.xq);
assertEquals(riap://component/exist/db/something.xq, ref
.getTargetRef().toString());
}
Could you help me reproduce this NPE?
I believe the problem is that there isn't a call to getTargetRef() in my code
or ChildClientDispatcher.
Looking at the code around line 81, I see:
final LocalReference cr = new LocalReference(request
.getResourceRef());
if (cr.getRiapAuthorityType() == LocalReference.RIAP_APPLICATION) {
So, since I haven't called getTargetRef() and the above code doesn't either,
the reference for cr is a relative reference with a base URI.
Maybe LocalReference should always call getTargetRef() when constructed
with a Reference instance?
--Alex Milowski
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2620173
Who is Using the Component XML Configuration?
I'm curious as to who is using the current XML configuration for Components and what kinds of issues/enhancements they have with it. If it didn't work for you, why? I've been playing around with it today and have been able to get it to work for my projects but only with a bit of tweaking to the Restlet source. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2619808
getServerDispatcher() usage
For most of my work where I call internal resources via RIAP, I've been using getClientDispatcher() to call back to restlets attached to the internal router of the component. In looking at getServerDispatcher(), I'm curious as to which RIAP URI's are supported and whether I should be using the Client instance returned by this method instead of getClientDispatcher(). The javadoc says: Returns a request dispatcher to component's virtual hosts. This is mostly useful for application that want to optimize calls to other applications hosted in the same component or to the application itself. The phrase mostly useful doesn't seem to imply only for. Will any RIAP URI work? Should I use this Client for RIAP URIs over the getClientDispatcher() that I have been using? --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616805
Updated eXist Restlet Integration
I've updated the eXist Restlet integration available at:
http://code.google.com/p/existdb-contrib/
I've moved the code forward to the latest eXist (1.4 or the trunk)
and I've updated it to be compatible with the forthcoming
Restlet 2.0 release. It now uses the 2.0RC4 version.
If you've thought about using an embedded XML database
and may be considering eXist, you might want to try out
this integration.
In this iteration, I've removed the exist protocol as RIAP
seems much more appropriate and flexible. Besides, as
an embedded database, your application really isn't a
client anyway. The essential bit is now that you attached
the property resource to the internal router (or wherever you
want):
getInternalRouter().attach(/exist/,XMLDBResource.class).getTemplate().setMatchingMode(Template.MODE_STARTS_WITH);
For example, to get a document from an embedded version
of eXist, you simply make a reference using their RIAP
scheme:
riap://component/exist/db/doc.xml
the actual code to GET the document is:
Response response = getContext().getClientDispatcher().handle(new
Request(Method.GET,riap://component/exist/db/doc.xml));
Similarly, to query a document:
MediaType queryType = MediaType.valueOf(application/xquery);
Request queryRequest = new
Request(Method.POST,riap://component/exist/db/doc.xml);
queryRequest.setEntity(new
StringRepresentation(doc{//a}/doc,queryType));
Response response = getContext().getClientDispatcher().handle(queryRequest);
For a full description of how to use this integration, visit:
http://code.google.com/p/existdb-contrib/wiki/Restlet
You can download a version using eXist 1.5/trunk + Restlet 2.0RC4 here:
http://code.google.com/p/existdb-contrib/downloads/detail?name=exist-restlet-2007-06-10.zip
This is somewhat an alpha release. It should stabilize soon, especially
as Restlet 2.0 and eXis 1.5 become official releases.
Feedback, comments, suggestions, etc. are all welcome.
--Alex Milowski
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616429
Updating RIAP Documentation?
I was looking for more information on exactly how the virtual host RIAP references work and it doesn't seem to be on the current wiki page: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/86-restlet/45-restlet.html Here's some specific feedback: 1. I really had to dig to find this page. Finding it under Engine/Internal Connectors was not where I expected it to be found. I think it would be really nice to call this out as a feature in a much more obvious place. It is such a useful thing and keeps you from doing unnatural things to your applications. 2. The riap://host/... documentation is missing. 3. I'd like to seem something about the scope of resolving application references. For example, I often use the pattern of having applications attach sub-applications. As a result, although I'm only guessing here, it seems that the sup-application can't refer to its using/parent application. That probably should be described in more detail. 4. In general, there is very little about riap://application/... and how it works and/or is to be used. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616439
More RIAP Features?
I've been thinking more about how I'd like to use and/or limit the use of RIAP, especially in the context of hosted applications where you are trying to limit access to the resources used by each. Here's a couple of things I'd like to be able to do: 1. I'd like to restrict attached resources/restlets to a specific virtual host, much like an internal router on the component, so that I can attach internal applications that are not exposed to the outside world. 2. I'd like to scope access within those hosts to specific application and all their descendant/used applications. My use case is simply that when I startup and include a service like an eXist XML database, I don't really want to attach it to the component as every application would have access to the embedded database. I'd associate that database, via RIAP, with the host or some particular part of the host's overall application. I believe I can currently do some this attaching a guard that only allows access over RIAP from certain clients. Of course, that may require knowing that the request will tell me who the user of the RIAP is in such a way that I can say this is my application. I'm not sure I can always get that and so it may only get me part of the way there. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616443
Difference Between Internal Server Connector and Grizzly in 2.0RC3?
I've been working on migrating my Atomojo [1] project to Restlet 2.0 and I've run into a strange problem. My junit tests hang with the internal server connector but they don't with the grizzly connector. I moved to the recent RC3 release and seem to have the same problem. If I add a call to release on the client side: response.getEntity().release(); it works as expected with the internal connector. My tests basically start up a local server and then use the client libraries to make requests against localhost. Any ideas? I would expect this to work consistently regardless of the connector in use and these tests have all worked flawlessly in the past. I was using the Jetty server connector in 1.1 and I'm now moving to Grizzly. Is this a bug or an incorrect use of the client API? [1] http://code.google.com/p/atomojo/ --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611735
Re: A Couple Restlet 2.0rc2 Documentation Comments
On Thu, May 20, 2010 at 8:31 AM, Jerome Louvel
jerome.lou...@noelios.com wrote:
Hi Alex,
1. This design was already in place for the older Finder, with the
findTarget() and createTarget() methods. The idea is that find() could
potentially reuse instances of ServerResource subclasses created by the
create() method, doing some sort of pooling.
OK. In all of my current instances, I don't do that. If I never override
the create() method, and always create within the find() method, is everything
going to be OK?
The targetClass property points to the ServerResource subclass that must be
instantiated. I'm not sure how to describe it better in the Javadocs. Any
suggestion?
I most certainly don't use this feature. I don't need that kind of
class abstraction
as I know the distinct ServerResource derived instances that I'll be
creating. Is there any reason why I should be concerned about the targetClass
field of the Finder instance?
My basic confusing is the javadoc seems to make it like the targe class
is essential while the code seems to allow you to completely ignore that
facility. If it is optional, it should be described as an optional
feature. If it
is somehow essential, should my code really work?
Of course, I'd like my simple finder to work as it does now. :)
2. Good points. Here is the updated Javadocs for ServerResource:
* Base class for server-side resources. It is a full replacement for the
* deprecated {...@link Resource} class. It acts as a wrapper to a given call,
* including the incoming {...@link Request} and the outgoing {...@link
Response}.
br
* br
* It's life cycle is managed by a {...@link Finder} created either explicitly
or
* more likely implicitly when your {...@link ServerResource} subclass is
attached
* to a {...@link Filter} or a {...@link Router} via the {...@link
Filter#setNext(Class)}
* or {...@link Router#attach(String, Class)} methods for example. After
* instantiation using the default constructor, the final
* {...@link #init(Context, Request, Response)} method is invoked, setting the
* context, request and response. You can intercept this by overriding the
* {...@link #doInit()} method. Then, if the response status is still a
success,
* the {...@link #handle()} method is invoked to actually handle the call.
Finally,
* the final {...@link #release()} method is invoked to do the necessary
clean-up,
* which you can intercept by overriding the {...@link #doRelease()} method.
During
* this life cycle, if any exception is caught, then the
* {...@link #doCatch(Throwable)} method is invoked.br
That's much better.
I've also just added links from the API packages to the relevant section in
the user guide (wiki). There is already a How to page in the wiki that
should probably be expanded (contributors welcome):
http://wiki.restlet.org/docs_2.0/13-restlet/333-restlet/338-restlet.html
Is this online? The development snapshot doesn't seem to have this. Does
it get automatically updated.
I've generally reverted to browsing the source code to understand certain
aspects of how 2.0 works.
--Alex Milowski
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611370
Upgrading to 2.0 Gotchas
I've been happily coding along using Restlet 1.1 and now that I'm attempting to upgrade to 2.0, I've been working through a myriad of issues. The one that caught my attention today is that the default routing mode has changed to MODE_EQUALS and so all my code that assumes MODE_STARTS_WITH needs to be changed some (which is a lot). Are there other gotchas I should be concerned about? Is there somewhere that we are collecting such information? --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611372
Beginner feedback
Hi! Recently I dedicated a couple of hours to learn about restlet (2.0-RC3). Maybe it is too little time, but I think my feedback may be important for restlet improvement. I've used as a documentation this link: http://www.restlet.org/documentation/2.0/firstSteps It is well documented. Unfortunately, I had some troubles in running the example. I have downloaded the distribution, created an eclipse project. The first problem was to set up the classpath of the project. There a dozen of dependencies. I didn't know which of them to add to the classpath. This is where maven would be useful. I use maven for all my projects and find it very easy to get started with other open source project. All you have to do, is to run mvn eclipse:eclipse and maven takes care about all project dependencies. It would be very useful for restelet adoption to 'mavenize' the project. Also, it could be useful to have a archetype - to generate a template of the project ready to run. The next problem, was to start the hello world example. I would expect to add the minimum dependencies to make it work. It seems very strange that hello world requires more than 10 dependencies to work (even java mail, grizzly, etc).. It seems a little bit strange, but maybe there is a reason. I like the way restlet is implemented, I would like to understand it better and use it when I'll have an opportunity. My purpose is not to criticize, but to help improve restlet. Thank you for your work! Alex -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Beginner-feedback-tp4961544p4961544.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595725
Beginner feedback
Hi! Recently I dedicated a couple of hours to learn about restlet (2.0-RC3). Maybe it is too little time, but I think my feedback may be important for restlet improvement. I've used as a documentation this link: http://www.restlet.org/documentation/2.0/firstSteps It is well documented. Unfortunately, I had some troubles in running the example. I have downloaded the distribution, created an eclipse project. The first problem was to set up the classpath of the project. There a dozen of dependencies. I didn't know which of them to add to the classpath. This is where maven would be useful. I use maven for all my projects and find it very easy to get started with other open source project. All you have to do, is to run mvn eclipse:eclipse and maven takes care about all project dependencies. It would be very useful for restelet adoption to 'mavenize' the project. Also, it could be useful to have a archetype - to generate a template of the project ready to run. The next problem, was to start the hello world example. I would expect to add the minimum dependencies to make it work. It seems very strange that hello world requires more than 10 dependencies to work (even java mail, grizzly, etc).. It seems a little bit strange, but maybe there is a reason. I like the way restlet is implemented, I would like to understand it better and use it when I'll have an opportunity. My purpose is not to criticize, but to help improve restlet. Thank you for your work! Alex -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Beginner-feedback-tp4979195p4979195.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2598783
A Couple Restlet 2.0rc2 Documentation Comments
I've been attempting to upgrade my Restlet-based projects to the latest Restlet 2.0rc2 release. Things have been going well but I've had to resort to inspecting the code to figure out how to properly use the API as the javadoc seems to be insufficient. Here's a couple of things I found a bit too terse: 1. The new Finder API is a bit confusing as to when I should override find() versus create() (either one). Since find() calls the create() variant without the Class? extends ServerResource parameter the two methods are almost synonyms. I don't really know when I should use which one. I also don't quite know what the target class information is all about either. 2. I've moved my code to use the ServerResource class from the Resource class. In doing so it isn't clear from the API documentation that if I set response facets (e.g. the status) using the direct setter methods that they will remain as set. In fact, in certain cases, that seems to not be the case (e.g. get() without an entity will change a 200 to a 204). More information about the lifecycle would be really helpful. While I'm quite confortable searching through the code, I'm sure others are not. Maybe putting targeted how to code samples on the wiki would also be helpful as well as back pointers from the javadoc to the online documentation in the wiki? Anyway, so far things are working pretty well and I haven't run into any real issues yet. --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2582036
Setting Http Authorization header (part 2)
Hello Jerome and all Restlet fans!
I have spent my last 2 days trying to set the authorization header to a
certain value, using the restlet gwt api. However, I was unsuccessful, so I
started looking at the source code. You specifically said in the previous
message that an authorization header is automatically created for you when
you specify a ChallengeResponse object (also mentioned in wiki), but the
only code that actually does something with the ChallengeResponse object is
located in GwtHttpClientHelper lines 86-92:
if (request.getChallengeResponse() != null) {
result.getRequestBuilder().setUser(
request.getChallengeResponse().getIdentifier());
result.getRequestBuilder().setPassword(
String.valueOf(request.getChallengeResponse()
.getSecret()));
}
I have tried all kind of value combinations, but none showed the
Authorization header in Firebug. WHAT AM I MISSING here? PS: I don't need
a password set here, just a association between Authorization - Id in
headers map
Thanks, Alex
--
View this message in context:
http://n2.nabble.com/Setting-Http-Authorization-header-part-2-tp4051325p4051325.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2423357
The sample “First Step” application fro m version 2.0 does not work with Tomcat
The sample “First Step” application firstStepsServlet from version 2.0 does not work with Tomcat First I checked the “First Step” application from version 1.1.5 using both building myself and the supplied war file. Both work fine. Second I did the same with the version 2.0. Neither the source version nor the supplied war file work with Tomcat. I tried both 5.5 and 6.0. What will be the recommendations? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380970
Spaces in Media Type Parameters?
I just ran across an issue with media type parameters on the Content-Type header that have spaces. I assumed that quoted values would be OK but I get an exception from Restlet. My assumption was I could send: Content-Type: application/docbook+xml; version='my version 1.0' but the space character inside the quoted parameter value seems to be disallowed. This is allowed: Content-Type: application/docbook+xml; version='my%20version%201.0' In addition, the system throws an exception and I get a 500 response. I would think there would be a more graceful way of handling such an error (e.g 400 Bad request). --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379742
Re: Guidance on Atom/APP in Restlet
Sorry to jump in so late on this thread... On Fri, Jul 17, 2009 at 11:32 AM, Tim Peierlst...@peierls.net wrote: Some rambling newbie Restlet design questions: Background: I'm in the preliminary stages of a ground-up redesign of an existing non-Restlet application. I'm (naturally) convinced that Restlet is the way to go for this redesign, and I'm pretty sure I want the UI to be GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get cracking on a Restlet-Guice extension before too long, or not, depending on how you define too.) My analysis of the existing application keeps leading me to the Atom Publishing Protocol, because the key elements of that application feel like collections of publishable/updatable resources (and collections of such collections). It doesn't fit the canonical examples of APP, however, which leads to my first questions: Does anyone know of APP being used successfully outside of the usual document/news item examples that everyone uses to explain it? If so, what criteria would you use to determine whether APP is really appropriate to my resource design? I use the APP for all kinds of applications. I use it as a basic storage and retrieval mechanism. Of course, I use a lot of advanced features found inside Atomojo for querying feeds and that is most certainly outside of the APP as a protocol. I'm sort of hoping the answer is a resounding yes to this, in which case my second question is: If I want to design my application around APP but I don't intend to use a file-based storage system like eXist, what does Atomojo have for me that the Restlet Atom extension doesn't? Is there something else that I should know about? I think you are a bit confused about what Atomojo has to offer. First of all, there is a server that supports the APP and provides different storage mechanisms. There are currently two storage mechanisms: files and the eXist XML database. I've considered writing an Amazon S3 storage back end but I haven't quite gotten to it yet. Basically, storage is something that you can change in the server. The server itself maintains an index and supports different kinds of metadata and query services independent of the storage used. You can use these services to build applications--which is what I do. Atomojo also provides: * a Java client for interacting with the APP * a Javascript client for doing the same * a web server component that uses configures itself using atom feeds (a special wrap-up of Restlet) * some other application components for building web applications. Much of this still needs documentation. :( --Alex Milowski -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2379543
Re: Problem in serving up static pages
You've got warnings in your log that say you are missing the file protocol.
You should add it to your component's list of client protocols:
getClients().add(Protocol.FILE);
Try that first.
On Fri, Dec 5, 2008 at 9:10 AM, Johnny Doe [EMAIL PROTECTED] wrote:
I've read old messages here that dealt with serving up static pages using
Restlets, but none of the suggestions seem to work for me. I was wondering if
somebody could please take a look at my code and find what I'm doing wrong.
I'm playing with the FirstResource application to also allow it to serve up
an index.html page. I'm deploying the application as a servlet using Tomcat.
Below is my code:
Router router = new Router(getContext());
String path = servletCtxt.getRealPath(.);
int last = path.lastIndexOf(.);
String appPath = file:/// + path.substring(0, last).replace('\\', '/');
Directory indexDir = new Directory(ctxt, new LocalReference(appPath));
indexDir.setIndexName(index.html);
indexDir.setDeeplyAccessible(true);
router.attach(/, indexDir);
// Defines a route for the resource list of items
router.attach(/items, ItemsResource.class);
// Defines a route for the resource item
router.attach(/items/{itemName}, ItemResource.class);
I'm continually getting a 404 error code. Below are the lines from Catalina's
log file
Dec 5, 2008 11:09:38 AM com.noelios.restlet.component.ClientRouter getNext
WARNING: The protocol used by this request is not declared in the list of
client connectors. (FILE)
Dec 5, 2008 11:09:38 AM com.noelios.restlet.component.ClientRouter getNext
WARNING: The protocol used by this request is not declared in the list of
client connectors. (FILE)
Dec 5, 2008 11:09:38 AM com.noelios.restlet.LogFilter afterHandle
INFO: 2008-12-0511:09:38127.0.0.1 - 127.0.0.1
8080GET /RestletFirstResource/ - 404 330 - 31
http://localhost:8080 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 -
Dec 5, 2008 11:09:43 AM com.noelios.restlet.component.ClientRouter getNext
WARNING: The protocol used by this request is not declared in the list of
client connectors. (FILE)
Dec 5, 2008 11:09:43 AM com.noelios.restlet.component.ClientRouter getNext
WARNING: The protocol used by this request is not declared in the list of
client connectors. (FILE)
Dec 5, 2008 11:09:43 AM com.noelios.restlet.component.ClientRouter getNext
WARNING: The protocol used by this request is not declared in the list of
client connectors. (FILE)
Dec 5, 2008 11:09:43 AM com.noelios.restlet.LogFilter afterHandle
INFO: 2008-12-0511:09:43127.0.0.1 - 127.0.0.1
8080GET /RestletFirstResource/index.html- 404 330
- 16 http://localhost:8080 Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 -
Any help is appreciated.
Thanks.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=980200
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=980988
Multiple Charsets with 1.1M5
Now that I've upgraded, any proxy code I have seems to be returning multiple
charset parameters.
That is, I have code that makes a call to another web service. I take
the Representation instance received and return that as the
Representation for the response call:
Client client = ...
Request appRequest = ...
Response appResponse = client.handle(appRequest);
if (appResponse.isEntityAvailable()) {
getResponse().setEntity(appResponse.getEntity());
}
Unfortunately, this results in two charset parameter values. That is, if
the remote service returns application/atom+xml; charset=UTF-8 the
proxy service returns application/atom+xml; charset=UTF-8; charset=UTF-8.
Is that a bug or a feature? Seems like a bug to me.
To fix this, I have to do:
if (appResponse.isEntityAvailable()) {
Representation rep = appResponse.getEntity();
MediaType type = rep.getMediaType();
String charset = type.getParmeters().getFirstValue(charset);
rep.setMediaType(MediaType.valueOf(rep.getMediaType().getName()));
rep.setCharacterSet(CharacterSet.valueOf(charset));
}
That seems rather onerous.
--Alex Milowski
Re: Important Context changes
On Tue, Jul 29, 2008 at 2:21 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi all, Several persons (see [1], [2], [3]) have encountered issues with the way application context is currently managed. The two main issues are: - it isn't obvious how to pass parameters and attributes to an application as the context given to the constructor isn't the one actually used by the application after construction (is uses a wrapped one) - the fact that we pass the component's context to the application constructors could give an opportunity to those applications to gain access to sensitive info about the parent component So, I decided to do some refactoring along these lines: - the Context instance given to an application (or any Restlet actually) will be the one effectively used. If parameters are set, they will be directly and permanently accessible. If none is given, a null context will be returned by getContext(), no default context will be returned anymore. Very predictable! :) - a new Context#createChildContext() method has been created as a standard way to create a protected/isolated child context from a Component context. Looking at the implementation, it would nice if: * the context created by createChildContext() preserved the logger of the parent context. - passing a context instance to an application is now fully optional. Instead when you attach your application to Component virtual hosts or internal router, a child context will be automatically created and set on the target application (via the Restlet#setContext() method). As a result, a true and perfect isolation exists between Component and contained Applications; parameters can now also be used more intuitively. This is not currently (with this change) true when you create an instance of Client. I have a lot of client code that doesn't pass the context when creating an instance of Client. Maybe new Client(Protocol...) should just create an empty context? If the application is still given a component context, a severe log message will be logged to indicate the potential security isssue. In addition RIAP/Application dispatching wouldn't work properly anymore. Nice! That severe log message will cause some questions that should be on a FAQ somewhere. I've been able to get atomojo and my code up and running on this with minor but frequent changes. I'm sure if my experience is typical, but I think this is a really good step forward even if it has causes a minor amount of pain upgrading to the trunk. --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, I have added a paragraph on Confidentiality in the Securing applications page covering this topic: http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest let.html At some point, it might makes sense to split up this page into several ones. Thanks. I think it would be good to have some ssl-specific information make its way into the connector documentation as an example. That is, there is a simple example here: http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-restlet.html Maybe we could have about ssl configuration there as well. Of course, the parameters are specific to the server helper... --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Sat, Jul 12, 2008 at 5:51 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex and Bruno, My understanding is that Alex wants this: - a single server socket accepting all HTTP requests - several SSL certificates selected depending on the matching virtual host I think this can't be done because in order to determine the virtual host, you need to have read and parsed the HTTP request headers to get the Host one. You can only do that if you already use the certificate to read the incoming SSL stream. So, it seems that the only solution is to have two listening server sockets and then two Restlet server connectors. Bruno's solution would let you share the same certificate store by selecting the alias based on the actual socket used, but you still need two sockets. If you want to use HTTPS's default port, that means that you need two separate IP addresses, at least virtual IP addresses. Let me know if I missed something. That makes sense to me. I seem to remember having to do this with apache once or twice. This should certainly be documented somewhere as we go forward. Is there an SSL tips page on the wiki? --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Thu, Jul 3, 2008 at 2:36 PM, Bruno Harbulot [EMAIL PROTECTED] wrote: There can only be one certificate per IP address (unless using a different port), thus one certificate per connector. (An exception to this would be to use something like what GnuTLS does [1], but I've never seen it used in practice. I'm not sure at all how browsers and other clients support that sort of negotiation.) Assuming you'd want to do this on a Connector rather than on a VirtualHost, this would still have to be implemented in the KeyManager (and thus in the SSLContext). I'll try to make things progress on the Jetty side and/or find another solution soon. I'm not sure when the Restlet 1.1 RC1 is due for, but I haven't had much spare time for this recently. What I'd like to be able to do is have a certificate (i.e. alias in a keystore) be associated with a Virtual host so that if I have two virtual hosts on one server I can associate the different SSL certificates with each host's connection. Now, I can work around the IP address limitations by using additional addresses on the server. Is this a Restlet limitation, a Jetty limitation, or a Java SSL implemenation limitation? --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Wed, Jul 2, 2008 at 7:45 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Hi Alex, Any particular reason why you would need two pairs of private key/certificates in the same keystore in practice? If you want to use two certificates, you're going to have to configure two connectors anyway, so I would imagine having two keystore files is not necessarily a major problem. No particular reason. In fact, the lesson I learned here was not to keep them in the same keystore. More details... I don't think this problem is specific to Restlet. What I've tried to do with jSSLutils and the SSL extension to Restlet is to make it a bit easier to configure the SSLContext, preferably independently of the underlying type of connector. Choosing the alias can be done by configuring the X509KeyManager, I've tried to make this a bit more flexible with jSSLutils by providing an X509KeyManagerWrapper (since version 0.3). This being said, it's not something I've tried extensively, but it should be possible to write a relatively simple wrapper that helps you pick a given alias based on the hostname of the socket. OK. Eventually I'm going to need this... :) Currently, although the classes related to SSLContext factories are in the Restlet tree, they're not used. What's missing is: 1. We'd need to agree on a parameter name to pass an SslContextFactory instance, in a similar way to the way the current SSL parameters are passed; this shouldn't be a big problem. 2. The underlying Jetty connectors (of Jetty) used by the Jetty connector (of Restlet) don't support setSslContext. I've submitted a patch to Jetty for this, but I don't think it's been integrated yet. I should follow this up (I think they'd be keen on seeing a unit test), but I haven't had time to do so recently. I haven't really pushed for this, since I doubt this feature will be in Jetty 6.1.x anyway, only in 7.x, which most certainly won't be used in Restlet 1.1. What we could do meanwhile would be to have a custom implementation of a Jetty connector (org.mortbay.jetty.AbstractConnector) that would support setSslContext in the Restlet connector. The other connectors (Grizzly and Simple) can use setSslContext or equivalent. Why can't we set properties on the VirtualHost instance as to what alias and what keystore should be used for SSL transport? --Alex Milowski
SSL + Virtual Hosts and Issue #489?
I ran into a problem just yesterday with wildcard SSL certificates. I had a new keystore with two wildcards certificates in it and, by default, restlet seemed to pick the wrong one. When I deleted the wrong wildcard from the keystore, everything worked fine. I'll confess that the interaction between keystores, SSL, and Restlet is something I just don't quite understand. Now, looking at issue #489, I see that there are some changes coming that should help me. Can some detail how I'll be able to use this new SSL context factory to handle associating certifcates (or aliases in a keystore) with a virtual host? --Alex Milowski
Re: Disabling the TunnelService
On Wed, May 21, 2008 at 3:38 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, Thanks for sharing the Atomojo usage details. The TunnelService has been turned on since 1.0 and nobody complained (yet) about the default query parameters (method, charset, encoding, language and media). If needed they can be renamed by the user. Also note that when they are matched, those query parameters are removed from the resourceRef property. So the current behavior regarding extensions was not really a fundamental change :-), but it's visibility/impact was greater than for query parameters and gave you this feeling. It definitely indicates that there is a lack of documentation regarding the semantics of the resourceRef property. Currently, when the extensions are touched, the TunnelService puts the original reference in a org.restlet.TunnelService.originalRef attribute of the request. But this is not very easy to use. So, I propose to replace this attribute by a more explicit Request.originalRef property and clearer Javadocs regarding Request.resourceRef whit cross-refs with originalRef. Would that work for you? Would Request.originalRef still have getRemainingPart() returning the unmatched portion? Either way, this works for me because I can just turn it off for my uses (which is what I did) and everything works as expected. --Alex Milowski
Re: Disabling the TunnelService
On Mon, May 19, 2008 at 1:31 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, Like Thierry, I have just checked the code again and in trunk the extensions tunnel feature is now off by default. The idea behind this feature is to have a very simple way for a user to specify, for any resource hosted within an application, which representation he wants. The standard way is to use the Accept header (hard with browsers and not very intuitive), the other way is to use the ?media=xml query parameter which is processed by the TunnelService by default and converted into the equivalent Accept header info (the query parameter is then removed from the 'resourceRef' to make this feature transparent to the application resources). I understand this is a good feature but many applications may find intruding on the resource reference a problem. That is, what if the media query parameter is already used. Now, if you want such a feature... having to just make a single call to turn it on is probably really useful. Now with the extensions tunneling, the user can just append .xml to the last segment and have an effect similar to using an Accept: text/xml header, with no change to the application logic. I would be interested to understand why/how it breaks your URI processing logic, but my feeling is that in 90% of cases, it will be a very convenient feature. BTW, we already support something similar for the Directory class. In atomojo, the extension is a choice made by the user using the atom publishing protocol. They send a slug header to control the actual file name. As such, the extension could be .foo or .myrandomxmldocument for text/xml and not .xml. That means that I need to honor the original requested file name in the last segment and attempt to find it in the storage. I have all the requested information for formulating the response and setting the media type in an database external to the actual storage vehicle. In the case of the tunnel service, what doesn't make sense to me is that it seems like the extension information just disappeared. It wasn't that it was placed in another facet of the Reference instance and I had to get at it using getExtensions(). It just completely vanished. As such, I could not reconstruct the original last segment. Also, if you want to have a common configuration policy across all your applications (for example to disable all services and associated filters), then I suggest that you use a BaseApplication class extending o.r.Application. As a policy, I turn off the TunnelService explicitly in all my applications because what tasks it performs do not help me. I do feel your pain regarding the unexpected changes to your URIs and logic, and I apologize for the time lost in figuring out what happened. I think that Rob's proposition to add a requestedRef property and to clarify resourceRef Javadocs is a good way to clarify the actual intent. No need to apologize. I was very surprised and frustrated with what seemed like a very fundamental change. In this case, I do rely upon getResourceRef() related processing. I do want getRemainingPart() to give me the matching portion minus the path that go to my application via routing. It is just that the tunnel service gets inserted automatically that was surprising to me. --Alex Milowski
Disabling the TunnelService
I now strongly believe that the TunnelService needs to be off by default. I've had to go into *every* single class that extends Application and add this line to my constructor: getTunnelService().setEnabled(false); All of my code is now breaking wherever there is a resource with an extension because getRemainingPart() now returns the path minus the extension in the last segment. This magic mucking around with the resource reference has cause me no end of troubles. I'm not really certain why this service needs to be on by default but I can say with 100% certainty that I don't need it on for *any* of my applications that use Restlet. I just want the resource reference as requested by the client. If we apply the policy of least surprise to this, you would think that advanced features for variants/etc. would need to be enabled so that, at minimum, without changing any settings, you just get the URL path for the resource upon which the request was made. That dictates that: * unnecessary filters should be off by default * features like the tunnel service should be required to be turned on * the resource reference should remain the same regardless of whether such filters are enabled. --Alex Milowski
Re: Issues with Directory and Custom contexts
On Wed, May 14, 2008 at 12:27 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, I have fixed this potential NPE in SVN trunk. Can't you directly pass your Component's context to the Application constructor instead of having to recreate it manually via the internal 'createContext()' method? In this case, no. I need to have a different set of parameters and attributes. Maybe my use case is just non-trivial and so the strange constructor for the context is also non-trivial. --Alex Milowski
Troubles with Directory
Oddly enough, with all my uses of Restlet, I haven't really used the Directory class yet and now that I have, I'm having a bunch of troubles that I just don't quite understand. I have a directory on disk that I'm just trying to serve up with the Directory instance. I have an application that returns a single instance of Directory as its root from createRoot() like this: return new Directory(getContext(),LocalReference.createFileReference(dir)); where the 'dir' variable is an instance of File initialized to the content directory. When I try to access any file (or directory), I get 300 returns with a URI list. I've tried turning content negotiation off but that doesn't seem to help. I can easily write the Restlet to do what I want... but I thought I'd use standard objects rather than do that... :) BTW, I'm using the trunk build as of yesterday. --Alex Milowski
Bad TunnelService, Bad! (was Re: File extensions are not taken...)
On Tue, Apr 22, 2008 at 7:12 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Tom, The default behavior of the TunnelService in 1.1 is to remove the trailing extensions matching known metadata (via the MetadataService). It replaces the extensions by updating the client's metadata, ClientInfo.acceptedMediaTypes for example. Now, I'm wondering why your application breaks when this feature is enabled. Are your routers trying to match those extensions explicitly? Are you using a Directory to handle the request? Thanks for sharing those details, that will help us tune the feature if necessary. I feel like I should be wacking the TunnelService with a rolled up newspaper. No cookie for you, TunnelService! :) I just ran into this myself and wasted a bunch of time figuring out that I needed to turn the tunnel service *OFF*. It seems to me that the tunnel service shouldn't mess with the resource reference. I my case it replaced the return of getRemainingPart() with the same path minus the final extension. I had a GET request on an XML document and it not only called setExtensions() along the way but seem to get that wrong in that a call to getExtensions() returns null. Where did that original extension information go? This change will also seriously break Atomojo (which uses Restlet). Good thing that I know about it and can turn off the TunnelService's want to break my resource references by : getTunnelService().setPreferencesTunnel(false); It seems to me that a service such as this: * should be *OFF* by default * shouldn't mess with the original information (e.g. leave the last segment alone) * should provide its information as an optional augmentation of the request. --Alex Milowski
Re: Bad TunnelService, Bad! (was Re: File extensions are not taken...)
On Tue, May 13, 2008 at 1:04 PM, Stephan Koops [EMAIL PROTECTED] wrote: Hi, I propose to switch the extension filter off by default, but let the preferences tunnel by query parameters on by default. The second is also available in Restlet 1.0 and so it is not required to switch it off, IMO Sounds good to me. . To switch the extension tunnel off, you need getTunnelService().setExtensionTunnel(false). Thanks. I'll try that. --Alex Milowski
Issues with Directory and Custom contexts
I'm loading applications directly from jar files and constructing their context. I ran into a problem where an application that uses the Directory restlet would generate a null pointer exception. That is, if I construct the context as: Context appContext = new Context(getLogger()); then I get this stack trace: java.lang.NullPointerException at com.noelios.restlet.application.ApplicationClientDispatcher.parentHandle(ApplicationClientDispatcher.java:105) at com.noelios.restlet.application.ApplicationClientDispatcher.doHandle(ApplicationClientDispatcher.java:90) at com.noelios.restlet.TemplateDispatcher.handle(TemplateDispatcher.java:101) at org.restlet.Uniform.handle(Uniform.java:95) at org.restlet.Uniform.get(Uniform.java:83) at com.noelios.restlet.local.DirectoryResource.init(DirectoryResource.java:170) at com.noelios.restlet.Engine.createDirectoryResource(Engine.java:292) at org.restlet.Directory.findTarget(Directory.java:159) at org.restlet.Finder.handle(Finder.java:316) at org.restlet.Filter.doHandle(Filter.java:137) at org.restlet.Filter.handle(Filter.java:180) at org.restlet.Filter.doHandle(Filter.java:137) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:117) at org.restlet.Filter.handle(Filter.java:180) at org.restlet.Filter.doHandle(Filter.java:137) at org.restlet.Filter.handle(Filter.java:180) at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:140) at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:103) at org.restlet.Application.handle(Application.java:305) I can solve this by constructing the application context from the component as: Context appContext = Engine.getInstance().createHelper(MyComponent.this).createContext(getLogger().getName()); This seems rather non-obvious :( --Alex Milowski
Re: Webdav and restlet
On 2/7/08, Rob Heittman [EMAIL PROTECTED] wrote: I don't know if all the PROPFIND plumbing is really installed yet (Jerome or Thierry will know...) For sure you should be using svn trunk, or at least the 1.1 snapshot, to get the latest relevant bits. I've been able to write a webdav-enabled set of resources with the trunk code. It worked just fine! --Alex Milowski
Security Issues with Dynamic Loading of Applications?
Besides the obvious Java issues of dynamically loading code, are there any restlet-specific considerations for why you dynamically load an Application instance from a jar file? It seems to me that the Component instance in which the Application is running is protected from the Application instance. As such, there isn't a way that the dynamically loaded code could do something bad like call stop() on the component unless you made the component instance directly available in the environment somehow (e.g. as an attribute on the context). Am I correct? Are there other issues to consider? --Alex Milowski
Re: Request in checkSecret()
On 1/4/08, Kevin Conaway [EMAIL PROTECTED] wrote: Perhaps some kind of hook would be appropriate in authenticate(). Adding that kind of behavior to checkSecrets() feels bolted on to me because checkSecrets() now becomes check secrets, but maybe do some other stuff too Perhaps in authenticate(), if checkSecrets() is true, call authenticated(Request) which is a no-op by default. The problem is that I need to chat with a web service to see if the credentials are valid. If they are, then I get some identity information returned that I want to store on the request. If I wanted to make two request to that web service, the current class works fine because the authorize() method has the request and response as parameters. --Alex Milowski
Request in checkSecret()
Multiple times I've found myself needing the Request instance in checkSecret()
on Guard so that I can store the authenticated user's information on the
Request as an attribute. That allows me to later use it in authorize().
Maybe we need to add another method with this implementation:
public boolean checkSecret(Request request,String identity,char [] secret) {
return checkSecret(identity,secret);
}
and then people like myself can override the default implementation.
Then in the authenticate() implementation we call this new form of checkSecret()
with the request instance.
Currently, I've been doing this by recreating the authenticate method and then
calling my new checkSecret() method. That seems a bit clunky.
--Alex Milowski
application/xml in MetadataService
I've noted that I can't get an extension for application/xml from the metadata service. In looking into this, the implementation (specifically, in addCommonExtensions) does not have a mapping for application/xml. Any reason? Also, maybe this could be externalized to an XML document (or whatever) to describe the media types and their extensions. By default this could be packaged in the org.restlet.jar file but could be overridden with a system property that points to a different location to load. --Alex Milowski
Re: Releasing Representation
On 11/23/07, Alex Milowski [EMAIL PROTECTED] wrote:
I see there is a release() method on the Representation class but I can find
any
place in the trunk where this method is actually used.
I have a problem in that I'm using an OutputRepresentation instance to return
a resource from eXist but I need to ensure that the read lock on that
resource is
always released. If not, things will eventually lock up.
Looking into this, I think the following patch will do what I want:
Index: HttpServerCall.java
===
--- HttpServerCall.java (revision 2263)
+++ HttpServerCall.java (working copy)
@@ -320,6 +320,7 @@
*/
public void sendResponse(Response response) throws IOException {
if (response != null) {
+try {
writeResponseHead(response);
Representation entity = response.getEntity();
@@ -343,6 +344,12 @@
if (getResponseEntityStream() != null) {
getResponseEntityStream().flush();
}
+} finally {
+ Representation entity = response.getEntity();
+ if (entity!=null) {
+ entity.release();
+ }
+}
}
}
This patch guarantees that release will always be called on a response
regardless of whether write() is called or whether there is an
IOException. This means that the
life-cycle of a Representation instance in a response always ends with
a release() call.
I'm testing this now to see if this clears up my resource
locking/release issues with my
eXist integration.
--Alex Milowski
Releasing Representation
I see there is a release() method on the Representation class but I can find any place in the trunk where this method is actually used. I have a problem in that I'm using an OutputRepresentation instance to return a resource from eXist but I need to ensure that the read lock on that resource is always released. If not, things will eventually lock up. While I've implemented a finalize() method, that will only do cleanup if the object is garbage collected. What I need is a guarantee from the Restlet platform and server component that my representation will always be released. My assumption here is that any cancelation or network issue in returning the resource to the user will result in the write method either not being called or being interrupted by an I/O exception. While I can handle the case of the I/O exception inside my representation by a finally clause, I can't handle the case where the 'write' method is never called for some reason. --Alex Milowski
Guards and 403 Responses
I've been having continuous problems with guards returning 403 responses
for wrong passwords. Many clients (e.g. Firefox) do not handle the 403 properly
without a challenge.
I wonder if the default response for a wrong password should include a
challenge?
Maybe the forbid() method of Guard class could differentiate between an
unauthorized request (e.g. authenticated by authorize() returned false) and
an non-authenticated request where the credentials do no match.
A simple flag on the forbid method would suffice:
public void forbid(Response response, boolean authenticated) { ... }
and that way someone like myself could override the forbid method on a Guard
instance to add a challenge.
This would fix the problem where Firefox et. al. remember the bad password
and require that I clear passwords before I get the challenge again.
--Alex Milowski
Re: Router.attach Patterns
On 11/6/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
Thanks for sharing all the details.
1) For the root attachment issue, you can use this approach instead:
// To match only URIs that are strictly equal to /
Template template = router.attach(/, rootRestlet).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
// To match all other URIs
router.attach(/, everythingElseRestlet);
2) For the mapping of URIs with a .js extension to a resource you can do:
Template template = router.attach(/{foo}.js).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
template.getDefaultVariable().setType(TYPE_URI_ALL);
or
template.getVariables().put(foo, new Variable(TYPE_URI_ALL));
Does that cover all your needs or am I still missing something ?
That certainly provides a way for my current set of patterns.
This all needs to be better documented in both how to use the API to
accomplish this and the fact that the specification for URI templates mentions
nothing about matching semantics. As such, restlet.org should have
such a specification somewhere.
--Alex Milowski
Re: Router.attach Patterns
On 11/8/07, xasima [EMAIL PROTECTED] wrote: Hi, Jerome and Alex. We can use http://smallx.dev.java.net or cocoon maps notation (http://cocoon.apache.org/2.2/core-modules/core/2.2/853_1_1.html) to provide info for the coordination of such a pipes / URI. I think that reasons to do this are a) to get all advantages that cocoon offers by providing declarative URI model and pipeline support b) do the mentioned actions in distibuted manner, since each pipe can be deployed in any place of the web (or in scope of your cluster), due to REST notion of the pipe (GET, POST) and ability to negotiate on the representation (JAVA_IN_PROCESS, SAX, DOM, or custom one). It many ways, the use of URI templates in the API makes the API itself somewhat declarative. Being the person who started the smallx project, I'm not sure what you mean. I've been using Restlet for awhile now and it provides me a greater degree flexibility. Although, I have create my own set of XML configuration files for specifying virtual hosts and their applications. BTW, smallx has had a major change and is now available from two different google code projects: * http://code.google.com/p/xml-infoset * http://code.google.com/p/smallx The new version of smallx doesn't not contain all the XML infoset processing technology as that has been refactored into the xml-infoset project. All that remains in the smallx project is the XML pipelining technology--which has now moved forward to XProc (http://www.w3.org/TR/xproc/). My eventual plan is to provide an XProc integration with Restlet in the smallx project. --Alex Milowski
Re: Router.attach Patterns
On 11/5/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
As you probably know, we already have a way to specify the type of each
variable in an URI template via the org.restlet.util.Variable class and the
Template.variables and Template.defaultVariable properties.
Could you describe the use case(s) that would require a full regex syntax in
URI templates ?
The problem is that if you look at the specification for URI
templates[1], it explains
how templates can be used to create URI values and not how they are matched.
In fact, I can't really find that information anywhere except in the code.
Unfortunately, looking at the URI templates specification, I can find
inconsistencies
between generating and matching URI values.
One of the examples is:
http://example.com/{q}
http://example.com/hello#world
where q=hello#world.
If you tried to use the URI template http://example.com/{q};, you'd
get 'hello' for the
variable 'q' because the default is to use a URI segment rather than
the remaining
URI path.
In several of my applications I need to be able to match a remaining
URI path. When I've
developed custom code, I attach a Finder to do that but I have
problems when the root needs
to be handled differently than its sub-resources.
I've run into trouble with simple applications that are configured
from a configuration file
where the match pattern is specified and a restlet is attached for
all sub paths.
For example, if you want to map:
/ - RootRestlet.class
/.* - EverythingElseRestlet.class
you can use the two templates:
/ - RootRestlet.class
/{name} - EverythingElseRestlet.class
Now, that does the right thing only because any resource below the
root must have an
additional segment in typical directory hierarchy paths. The problem
is that the Request
instance now has a Reference where the getRemainingPart() does not
return the whole
subpath without prefixing the name attribute value. Then you have
special case your
attached Restlet to deal with that oddity.
Certainly the above problem can be solved by allowing more control
over the Route or
by messing with the template used by the route. It just seems
incomplete that you can
attach a Restlet to a template/pattern that says all sub resources
but not the root without
messing up the getRemainingPart() call.
Another simple use case is knocking out a URI (e.g. a moved or bad
resource) from amongst
valid ones by mapping it to a error handling resource. For example,
you might want to find all
paths then end with .js under a certain resource.
[1]
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-01.html
--Alex Milowski
Re: LocalReference given a Class Instance?
On 9/23/07, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, This is different in that I need to use the ClassLoader associated with a class instance. So, I need to pass MyApp.class and there is no way to make a URI to that resource without reconstructing the jar URL. Agreed. You need to pass a ClassLoader instance to the CLAP connector which can't be done via a URI string AFAIK. Because the code is being setup *inside* the code loaded from the jar file, I have no idea what the jar URL should be. Further, the class loaded could use multiple jar files and so there isn't a way to construct one URI. OK. All that complexity is avoided by using: MyApp.class.getResourceAsStream(path); I'm testing some code right now for this and I'll try to post an example later. Following our side discussion, I've added the following solution that should let you use the Directory with the CLAP URIs while still providing your custom classloader instance. If you set the special attribute name org.restlet.clap.classloader on the Request instances handled by the Directory, the CLAP connector will use the provided ClassLoader instance to load the target CLAP resources. You can set this attribute by using a custom Filter set-up in your Application.createRoot() method. Enhancement checked in SVN trunk. Let me know if this works for you. I'll check it out and let you know. Thanks! --Alex Milowski
Scripting and Restlets
I've been playing around with Java 6 scripting engines and restlet and I've
considered and come up with a few approaches. I'd be interested in opinions
on this.
There certainly is the JSP-like way of write a web page where the page's output
is bound to the request response. There are so many issues with state in
that approach in that you may find that you need to fail a response when
you've already committed output to the response. As such, you can't change
the status of the response. I've avoided this design pattern like the plague.
Instead, I've chosen to pass the request and response to the script and let
the script handle the posts, etc.
The first function-oriented approach looks like this in Javascript:
var theContext = null;
function init(context) {
theContext = context;
}
function post(request, response) {
response.setStatus(Status.SUCCESS_OK);
response.setEntity(new StringRepresentation(request.getMethod()+
is OK,MediaType.TEXT_PLAIN));
}
function get(request, response) {
response.setStatus(Status.SUCCESS_OK);
response.setEntity(new StringRepresentation(request.getMethod()+
is OK,MediaType.TEXT_PLAIN));
}
The script is initialized by passing the context to the the init()
function. Then for
any request, the method is translated into a function call (e.g. a
POST method means
the post() function is called).
A slightly more object-oriented approach looks like:
function RestScript(context) {
this.context = context;
}
RestScript.prototype.post = function(request,response) {
response.setStatus(Status.SUCCESS_OK);
response.setEntity(new StringRepresentation(request.getMethod()+
is OK,MediaType.TEXT_PLAIN));
}
RestScript.prototype.get = function(request,response) {
response.setStatus(Status.SUCCESS_OK);
response.setEntity(new StringRepresentation(request.getMethod()+
is OK,MediaType.TEXT_PLAIN));
}
function init(context) {
return new RestScript(context);
}
The init() function is called. If the init function returns an
object, then methods on
that object are called instread of global functions.
I've currently implemented this as a very terse Application class that
just compiles
the script and passes the requests as appropriate. I could certainly
see expanding
this to handle mapping requests to more than one script file/source.
Comments? Suggestions?
Has anyone tried JRuby or Groovy with Restlets ?
--Alex Milowski
LocalReference given a Class Instance?
I'm loading applications dynamically from a jar file and I'd really like to attach a Directory instance give a class instance. That is, something like: router.attach(/content,new Directory(getContext(),LocalReference.createClassReference(MyApp.class,content)); where the resource path is constructed as: Class.getName()+/ + path so that in the above example, if the package of MyApp was org.example: org/example/content and then the directory instance would load content via the ClassLoader associated with the class instance. It may be the case that Directory is the wrong thing here. Maybe we need a new Finder called ClassResourceFinder such that you can do: router.attach(/content,new ClassResourceFinder(MyApp.clas,content)); and get resources from getResource() calls against the ClassLoader. --Alex Milowski
Re: LocalReference given a Class Instance?
On 9/7/07, Rob Heittman [EMAIL PROTECTED] wrote: 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)); This is different in that I need to use the ClassLoader associated with a class instance. So, I need to pass MyApp.class and there is no way to make a URI to that resource without reconstructing the jar URL. Because the code is being setup *inside* the code loaded from the jar file, I have no idea what the jar URL should be. Further, the class loaded could use multiple jar files and so there isn't a way to construct one URI. All that complexity is avoided by using: MyApp.class.getResourceAsStream(path); I'm testing some code right now for this and I'll try to post an example later. --Alex Milowski
Re: LocalReference given a Class Instance?
Here's what I've done. I have a finder that takes a Class and path:
public class ClassResourceFinder extends Finder
{
Class baseClass;
String packageName;
/** Creates a new instance of ClassResourceFinder */
public ClassResourceFinder(Context context,Class baseClass,String path)
{
super(context);
this.baseClass = baseClass;
this.packageName = path.charAt(0)=='/' ? path :
/+baseClass.getPackage().getName().replace('.','/')+/+path;
if (!this.packageName.endsWith(/)) {
this.packageName += /;
}
}
public Resource findTarget(Request request,Response response)
{
String path = packageName+request.getResourceRef().getRemainingPart();
Resource r = new
ClassResource(getContext(),request,response,baseClass,path);
return r;
}
}
and then I have a simple resource for getting resources from the Class instance:
public class ClassResource extends Resource
{
Class baseClass;
String path;
MediaType type;
/** Creates a new instance of ClassResource */
public ClassResource(Context context, Request request, Response
response,Class baseClass,String path)
{
super(context,request,response);
this.baseClass = baseClass;
this.path = path;
int extPos = path.lastIndexOf('.');
Application app = context.getApplication();
type = app.getMetadataService().getDefaultMediaType();
if (extPos=0) {
String ext = path.substring(extPos+1);
Metadata mdata =
getContext().getApplication().getMetadataService().getMetadata(ext);
if (mdata!=null) {
type = MediaType.valueOf(mdata.getName());
}
}
getVariants().add(new Variant(type));
}
public Representation getRepresentation(Variant v)
{
if (getLogger().isLoggable(Level.FINE)) {
getLogger().info(Class resource: +path);
}
InputStream is = baseClass.getResourceAsStream(path);
if (is==null) {
return null;
} else {
return new InputRepresentation(is,type);
}
}
}
--Alex Milowski
Re: RE: Xeerkat XMPP Restlet
On 8/25/07, Mitch Stewart [EMAIL PROTECTED] wrote: I'm going to answer my own question after fully reading your website. It DOES support XMPP over HTTP. :) Well, requests over XMPP. It provides a way to make HTTP-like requests over XMPP. After forming the URI correctly, you can just use a Client instance to do gets, posts, etc. For servers, it lets you setup a service that receives over XMPP. Your restlet gets invoked just like it would over HTTP and the response gets send back over XMPP to the sender. The whole thing works async on the server side but the client can use the sxeerkat protocol to make an synchronous call. Otherwise, with the xeerkat protocol, responses are returned immediately with 200 status code if the message could be send. You then receive the response message asynchronously via a listener interface. When tunneling over XMPP to a server, the synchronous protocol is gong to be much more useful. In the case of P2P computing, handling responses asynchronously lets the sender continue to do useful work while waiting for the response. --Alex Milowski
Re: Problem building Restlet source
On 8/24/07, Sean Landis [EMAIL PROTECTED] wrote: Alex, Thanks for the patch. Unfortunately the build appears to be in a very bad state. A unit test fails, so I had to run the rest of the targets by hand. The resulting distro doesn't work at all. I checked out a clean copy to fix the build script. I haven't tried using the trunk. I'll try if I have time to do so tonight or tomorrow. --Alex Milowski
Re: Odd issue with VirtualHost.setServerAddress
On 8/22/07, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, In the end, when you add the server the domain name resolves to a single IP address that is the bind address for the server. My only suggestion is that if I can use a name to set the bind address I should be able to use the same name to restrict a VirtualHost instance to that same address. [...] I don't see the issue with allowing VirtualHost.setServerAddress() to do the same a resolve a domain name to a numeric IP address. If you give it the wrong domain name that is the same error as giving it the wrong IP address. Ok, I understand your point of view. It makes sense but things are a little more complex because the serverAddress property is actually a Regex expression that will be matched against a numerical IP address. It would be hard to automatically decode domain names from this regex into IP address. Since I can do what I need with the current API we should just make sure this is clear in java doc. Also, note that you don't have to restrict by serverAddress, by default a VirtualHost will accept any IP address. You could simply restrict by hostDomain instead. That would mean that the virtual host would match any interface on which the request came and I wanted to restrict by interface. Since that mapping happens elsewhere, the result would be the same. Thanks for the patiences but I think you're right in that we don't need a change given the added internal complexity with regex.
Re: Odd issue with VirtualHost.setServerAddress
On 8/18/07, Jerome Louvel [EMAIL PROTECTED] wrote: Alex, The serverAddress property indeed does comparisons based on the numerical IP address. There are some convenience static methods on VirtualHost: - getLocalHostAddress() - getIpAddress(String domain) This seems a bit inconsistent that you can use hostname when adding a server: getServers().add(Protocol.HTTPS,localhost,8080); but you have to use a numeric ip addresses with setServerAddress on VirtualHost: vhost.setServerAddress(127.0.0.1); The problem is that the mapping between domain name and IP address isn't symetric. One IP can be mapped to several domain names. However, a domain name maps to one and only one IP. Hence, using a domain name when adding a server is just a shortcut for adding the equivalent IP address. In the end, when you add the server the domain name resolves to a single IP address that is the bind address for the server. My only suggestion is that if I can use a name to set the bind address I should be able to use the same name to restrict a VirtualHost instance to that same address. I think the fact that a IP address can have multiple names isn't important here. When you use a domain name to specify a bind address, you're going to get *one* IP address that must map to a local address. If you have a server farm, that IP would be the address of the load balancer and not the local machine and so that's never going to happen. In my case, I have a hostname that is load balanced but I have a specific bind address I want to use on the local machine. I setup a DNS name for that bind address so that it can be managed by name. When I add the server, I use that DNS name as the server's bind address. Internally, that address gets resolved to a numeric IP address and that is what you see in the logs. I don't see the issue with allowing VirtualHost.setServerAddress() to do the same a resolve a domain name to a numeric IP address. If you give it the wrong domain name that is the same error as giving it the wrong IP address. --Alex Milowski
Re: How to use servlet connector?
Hi,
I've moved a Restlet.Application and a Restlet.Resource to tomcat. I run into
the following problems.
in servlet-mapping of web.xml, if I use /* or /dir/* , like below:
servlet-mapping
servlet-nameServerServlet/servlet-name
url-pattern/*/url-pattern or url-pattern/dir/*/url-pattern
/servlet-mapping
I can get into the Resource by entering URLs like these:
http://localhost:8081/MyFirstOc4j/dir/abc/afile/
http://localhost:8081/MyFirstOc4j/dir/something
where, however, in the Router.attach() statement, I can only specify an emtpy
String:
router.attach(, IAPRestFileResource.class);
If I use URL pattern like these
router.attach(/dir, IAPRestFileResource.class);
router.attach(/dir/{dir}, IAPRestFileResource.class);
I cannot get into the Resource, though I can clearly see, from the log, that the
URL has been assigned to request.resourceRef /MyFirstOc4j/dir/abc/afile/):
Aug 17, 2007 7:46:03 PM com.noelios.restlet.LogFilter afterHandle
INFO: 2007-08-1719:46:03127.0.0.1 - 127.0.0.1
8081GET
/MyFirstOc4j/dir/abc/afile/ - 404 331 - 1142413
http://localhost:8081
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; OOCL; SV1; .NET CLR 1.1.4322;
InfoPath.1; .NET CLR 2.0.50727) -
1) Why cannot I specify the URL pattern? How would I avoid in reinventing the
wheel to get those parameters from the link by parsing the URL from
request.resourceRef by myself?
2) even more serious, When there is escape character in the URL, e.g.,
http://localhost:8081/MyFirstOc4j/dir/c%3a%5ctemp/afile/
I cannot even get into Application. Why and is there a standard method to cater
for escaped characters?
Yours,
Alex
Re: Odd issue with VirtualHost.setServerAddress
On 8/17/07, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, The serverAddress property indeed does comparisons based on the numerical IP address. There are some convenience static methods on VirtualHost: - getLocalHostAddress() - getIpAddress(String domain) This should get clarified in the Javadocs too. This seems a bit inconsistent that you can use hostname when adding a server: getServers().add(Protocol.HTTPS,localhost,8080); but you have to use a numeric ip addresses with setServerAddress on VirtualHost: vhost.setServerAddress(127.0.0.1); InetAddress will do the right thing and handle both domain names and numeric ip addresses and so this would be easy to implement as either. Internally, we could resolve any domain names to a specific numeric ip address and use that for matching. --Alex Milowski
Re: get and send Cookie not working....
On 8/17/07, Regis Leray [EMAIL PROTECTED] wrote:
private Cookie hasCookie(Request request) {
ListCookie cookies = request.getCookies(); //always NULL
The getCookies() call should not return a null value.
snip/
About my environment all of this it is run in a tomcat container, and i use
the restlet version 1.0.4.
There could be an environment issue. Have you tried running your application
outside of Tomcat using the Simple or Jetty connectors?
Have you checked the return headers using the LiveHttpHeaders [1] or
my Poster [2]
extension for Firefox to see if the Set-Cookie header is there?
[1] https://addons.mozilla.org/en-US/firefox/addon/3829
[2] https://addons.mozilla.org/en-US/firefox/addon/2691
--Alex Milowski
Patches for Adding/Removing Hosts between Component Restarts
I've been experimenting with adding and removing host on a running server and have run into some problems. I've attached two patches that gets you part of the way. With these patches, you can now add or remove VirtualHost instances from the Component and then just call stop() and start() to restart the component. Taking a look at the code, this is much heavier than it should be because at the heart of this is a Router instance. If you could just reload the ServerRouter instance in the ComponentHelper class, you wouldn't actually have stop the server. Unfortunately, that field is private and not available via public methods on the Component class. I suggest this is filed as an enhancement to provide a way to reload the virtual hosts from the host list. It should be very easy to implement but probably requires a special method on Component. --Alex Milowski ComponentHelper.java.diff Description: Binary data ServerRouter.java.diff Description: Binary data
Null pointer exception with anonymous restlets
If you have the following code to create a Restlet instance:
new Restlet() {
public void handle(Request request,Response response)
{
getContext().getLogger().info(Handling test...);
response.setStatus(Status.SUCCESS_OK,OK!);
}
};
you'll get a null pointer exception because getClass().getCanonicalName()
returns null.
I've tracked it down to line 75 of Restlet.java in the getContext() method:
public Context getContext() {
if (this.context == null)
this.context = new Context(getClass().getCanonicalName());
return this.context;
}
There needs to be a default log name:
public Context getContext() {
if (this.context == null) {
String logName = getClass().getCanonicalName();
if (logName==null) {
logName = org.restlet.anonymous;
}
this.context = new Context(logName);
}
return this.context;
}
--Alex Milowski
Re: Keep Alive Problem with Simple Framwork
On 6/4/07, Adam Taft [EMAIL PROTECTED] wrote: I've discovered a problem with the Simple framework web server in conjunction with Keep Alive. Basically, it seems triggered by two POST requests in a row. The first POST request works fine, however a followup POST request will hang. Once a certain time has passed (in Firefox I believe it's 30 seconds), another POST request will go through. Was this ever resolved? I don't see an issue filed on this one. I've been testing atomojo and found the same issue. I suppose I should just switch from the simple framework to Jetty. --Alex Milowski
Null pointer exception with Grizzy Connector
I was testing grizzy when I ran into a null pointer exception while
parsing credentials.
Here's the fix:
Index: SecurityUtils.java
===
--- SecurityUtils.java (revision 2136)
+++ SecurityUtils.java (working copy)
@@ -292,8 +292,12 @@
if (result.getScheme().equals(ChallengeScheme.HTTP_BASIC)) {
try {
-credentials = new String(Base64.decode(result
-.getCredentials()), US-ASCII);
+byte [] credentialsEncoded =
Base64.decode(result.getCredentials());
+if (credentialsEncoded==null) {
+ logger.warning(Cannot decode credentials:
+result.getCredentials());
+ return null;
+ }
+credentials = new String(credentialsEncoded,
US-ASCII);
int separator = credentials.indexOf(':');
Unfortunately, this error is cause by the authorization header being
mangled somehow
in the grizzly connector. I haven't located the problem yet.
BTW, there are some System.out and System.err uses in Base64.java that would be
better served as either an exception or being set to a Logger instance.
--Alex Milowski
Critical Patch for Grizzy Connector
I figured out why I was having troubles with the Grizzy connector. It pools the instances of GrizzyServerCall but doesn't clear the headers. As such, previous random headers remain in the call! In my case, there were two Authorization headers and the parser uses getValues() on the SeriesParameter instance. As such, the credential parser fails (which is why the base64 decoding fails too). That was the previous fix for the null pointer exception. Here is the patch that fixes this issue: Index: GrizzlyServerCall.java === --- GrizzlyServerCall.java (revision 2136) +++ GrizzlyServerCall.java (working copy) @@ -86,6 +86,7 @@ headStream.setSelectionKey(key); headStream.setByteBuffer(byteBuffer); this.socketChannel = (SocketChannel) key.channel(); + this.getRequestHeaders().clear(); // Read the request header readRequestHead(headStream); Now, I suspect there may be other problems with pooling calls but I have reviewed the code in detail. I'd apply this patch ASAP because it is a serious security flaw as a previous Authorization header could remain and randomly allow another user into a resource for which they do not have access. --Alex Milowski
Re: How to use servlet connector?
Hi, How would I chase when both the constructor and the createRoot method of Application subclass have been called but any of Resource counterparts? Suppose Application would only be executed once but Resource would be executed once per client request. Now, 404 not found is resulted. The problem seems to be caused by mismatching URL although nothing abnormal is found from the output of com.noelios.restlet.LogFilter. Thanks. Yours, Alex
Re: How to use servlet connector?
Alex alexlam.hk at gmail.com writes: Hi, http://www.restlet.org/documentation/1.0/faq#02 Actually, i have followed the instruction above. However, there are a number of queries in mind: Why do we still need a main in a servlet container? Why still need a port in the main while the servlet container has already got one? What is the use of lib/javax.servlet_2.4/javax.servlet.jar and lib/javax.servlet_2.5/javax.servlet.jar? Any relationship with lib/com.noelios.restlet.ext.servlet_2.4.jar? Thanks. Yours, Alex
How to use servlet connector?
Hi, Suppose a restlet server implementation is tested to be functioning with lib/com.noelios.restlet.ext.simple_3.1.jar and lib/org.simpleframework_3.1/org.simpleframework.jar, how could i change it to be hosted by a Tomcat? I have tried to replace these 2 files with lib/com.noelios.restlet.ext.servlet_2.4.jar and lib/javax.servlet_2.4/javax.servlet.jar. However, the following error message is given. == Aug 7, 2007 10:52:12 AM com.noelios.restlet.Engine createHelper WARNING: No available server connector supports the required protocols: HTTP . P lease add the JAR of a matching connector to your classpath. == Any code change required? How could i build the war to be deployed onto Tomcat? Thanks. Best Regards, Alex
Re: Atom Support
On 7/31/07, Jim Alateras [EMAIL PROTECTED] wrote: Alex/Jerome, I am also interested in incorporated APP client and server capabilities in our application. I have a couple of questions more so for Alex than Jerome. 1. From the little I've read on atomojo there seems to be a database dependency on the component. Is this still the case? Yes. It stores the feeds in the eXist XML database and indexes them using derby. I plan to allow configurations that store media entry's resource (the resource you stored) external to the eXist database and then just store the atom entry in the XML DB. That's an optimization for certain media types like video that would be better served outside of eXist. Although, eXist is good at storing large binaries, I suspect the transfer rate will be better off the raw filesystem. The client code doesn't require that (of course). 2. How much of the APP spec does the current version support? say in comparison to apache abdera. I don't support server side categories and I don't support etags otherwise the code should be inline with the current version of the APP. --Alex Milowski
