Re: unicode character in (disposition) headers
Thanks Jerome. I'll see if I can come up with a patch when time allows. On 29/04/2015 07:14, Jerome Louvel wrote: Hi Arjohn, Sorry for the delay. I don't think we support this in version 2.3 either. I've entered this issue to keep track of this RFE: https://github.com/restlet/restlet-framework-java/issues/1062 In case you want to give this a try, the header parsing logic is located here: https://github.com/restlet/restlet-framework-java/blob/master/modules/org.restlet/src/org/restlet/engine/header/HeaderReader.java https://github.com/restlet/restlet-framework-java/blob/master/modules/org.restlet/src/org/restlet/engine/header/HeaderWriter.java Best, Jerome On Fri, Apr 3, 2015 at 7:00 AM, Arjohn Kampman arjohn.kamp...@vound-software.com mailto:arjohn.kamp...@vound-software.com wrote: Hi all, Restlet doesn't seem to support the encoding and decoding of non-ascii characters in http headers; at least not with the 2.2.3 release that we're using. The encoding of such characters is covered by RFC 5987 and RFC 6266. Is this already supported by 2.3.1? If not, any chance it can be added? I'm specifically looking for a way to encode non-ascii filenames in Content-Disposition headers. An overview of browser support for this encoding can be found at http://greenbytes.de/tech/tc2231/. Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3110367 -- Arjohn Kampman Vound, LLC arjohn.kamp...@vound-software.com mailto:arjohn.kamp...@vound-software.com http://www.vound-software.com This email and its attachment are private. The sender does not waive any confidentiality or privilege. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3114990
unicode character in (disposition) headers
Hi all, Restlet doesn't seem to support the encoding and decoding of non-ascii characters in http headers; at least not with the 2.2.3 release that we're using. The encoding of such characters is covered by RFC 5987 and RFC 6266. Is this already supported by 2.3.1? If not, any chance it can be added? I'm specifically looking for a way to encode non-ascii filenames in Content-Disposition headers. An overview of browser support for this encoding can be found at http://greenbytes.de/tech/tc2231/. Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3110367
Re: Transparent reverse proxying using org.restlet.routing.Redirector
Any thoughts on the encoding related bug in Redirector? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3077354
Re: Transparent reverse proxying using org.restlet.routing.Redirector
Hi Jerome, Before moving to 2.2.0 I first tried 2.1.7, but that has the same issue. We do run into a new issue with the Redirector in 2.2.0 now though. The problem appears related to entity encoding. Responses that are encoded by the back-end server aren't properly delivered by the proxy to the client. Typical errors messages on the client are unexpect end-of-streams in converters and this one: org.apache.http.ProtocolException: The server failed to respond with a valid HTTP response at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151) We haven't been able to pinpoint the source of this problem yet. Theories: - Redirector encoding an already encoded entity a second time - Redirector not copying/sending the proper encoding headers to the client Any thoughts on what we can try? Regards, Arjohn On 25/04/2014 03:19, Jerome Louvel wrote: Thanks for the feed-back Arjohn! We have completely replaced the internal HTTP connector in 2.2 so that certainly helped a lot. I don't think 2.1.7 would solve your issue but that could be interesting to confirm. Best, Jérôme -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3077049
Re: Transparent reverse proxying using org.restlet.routing.Redirector
Hi Jerome, others, We've figured out what is going wrong by monitoring the traffic with Wireshark. The problem is indeed, as suspected, related to gzip encoding. I'll try to explain with one of the traces that we've captured: 1. Client sends a request to the proxy with Accept-Encoding: gzip. 2. The proxy forwards the request to the back-end server adding Accept-Charset: * and Accept-Language: *, but otherwise identical. 3. The backend server responds with 127 bytes of gzip encoded data, expanding to 145 bytes when decompressed. 4. The proxy forwards the response to the client, but sends the 145 bytes of uncompressed data. The proxy did remove the Content-Encoding: gzip header so that part is ok. HOWEVER: the response still indicates Content-Length: 127. 5. The client receives the response from the proxy and returns the first 127 bytes to the calling code, resulting in premature end-of-stream errors. I think there are two options to fix this: 1) Let Redirector replace/remove the Content-Length header from the response 2) Let Redirector forward the compressed body as-is. We're very much in favor of the second option as that would benefit both the proxy (less processing overhead) and the client (less network traffic). Is this something that can be addressed sometime soon? Not sure where to start looking for supplying a patch myself. Regards, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3077059
Re: Transparent reverse proxying using org.restlet.routing.Redirector
For whatsoever reason, disabling the decoder service results in a NPE being thrown at org.restlet.routing.Redirector.outboundServerRedirect(Redirector.java:349). That's this line in 2.2.0: next = getContext().getClientDispatcher(); AFAICT, this can only happen if the context is null. Full stack trace attached -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3077064[WARN ] 2014-04-25 15:19:52,721 [qtp1239767987-26 - /shrd/x86_test/users/myUri] Exception or error caught in status service java.lang.NullPointerException: null at org.restlet.routing.Redirector.outboundServerRedirect(Redirector.java:349) at org.restlet.routing.Redirector.handle(Redirector.java:295) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Router.doHandle(Router.java:431) at org.restlet.routing.Router.handle(Router.java:648) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Router.doHandle(Router.java:431) at org.restlet.routing.Router.handle(Router.java:648) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Router.doHandle(Router.java:431) at org.restlet.routing.Router.handle(Router.java:648) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:155) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:211) at org.restlet.engine.application.ApplicationHelper.handle(ApplicationHelper.java:84) at org.restlet.Application.handle(Application.java:384) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Router.doHandle(Router.java:431) at org.restlet.routing.Router.handle(Router.java:648) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Router.doHandle(Router.java:431) at org.restlet.routing.Router.handle(Router.java:648) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:155) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.routing.Filter.doHandle(Filter.java:159) at org.restlet.routing.Filter.handle(Filter.java:206) at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:211) at org.restlet.Component.handle(Component.java:406) at org.restlet.Server.handle(Server.java:516) at org.restlet.engine.connector.ServerHelper.handle(ServerHelper.java:72) at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:152) at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:170) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:724)
Re: Transparent reverse proxying using org.restlet.routing.Redirector
We've updated from restlet 2.1.4 to 2.2.0 now and to our surprise this fixed the Redirector problems. In fact, Redirector works perfectly out-of-the-box, including the digest authentication. No subclassing required. So probably this was a bug in 2.1.4 that has been fixed somewhere in the 2.2 development. Regards, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3076835
Re: Transparent reverse proxying using org.restlet.routing.Redirector
I've debugged the problem to an infinite loop when trying to set the Via header on the request that the proxy sends to the back-end server. This infinite loop is not triggered when Redirector removes the headers becuase HttpInboundRequest.getRecipientsInfo() has a getHeaders() != null check. I've captured the stack trace below when when the loop has gone through three cycles between setRecipientsInfo and getRecipientsInfo using restlet 2.1.4. Is this a bug in HttpInboundRequest or are we doing something wrong? Daemon Thread [Restlet-21015178] (Suspended) * loop break point * HttpInboundRequest.getRecipientsInfo() line: 579 HttpInboundRequest(Message).setRecipientsInfo(ListRecipientInfo) line: 426 HttpInboundRequest.setRecipientsInfo(ListRecipientInfo) line: 804 HttpInboundRequest.getRecipientsInfo() line: 579 HttpInboundRequest(Message).setRecipientsInfo(ListRecipientInfo) line: 426 HttpInboundRequest.setRecipientsInfo(ListRecipientInfo) line: 804 HttpInboundRequest.getRecipientsInfo() line: 579 HttpInboundRequest(Message).setRecipientsInfo(ListRecipientInfo) line: 426 HttpInboundRequest.setRecipientsInfo(ListRecipientInfo) line: 804 HttpInboundRequest.getRecipientsInfo() line: 579 * loop start ** HeaderUtils.addGeneralHeaders(Message, SeriesHeader) line: 264 ClientAdapter.toSpecific(HttpClientHelper, Request) line: 163 HttpClientHelper(HttpClientHelper).handle(Request, Response) line: 111 Client.handle(Request, Response) line: 180 ClientRoute(Filter).doHandle(Request, Response) line: 159 ClientRoute(Filter).handle(Request, Response) line: 206 ClientRouter(Router).doHandle(Restlet, Request, Response) line: 431 ClientRouter(Router).handle(Request, Response) line: 648 ComponentClientDispatcher.doHandle(Request, Response) line: 140 ComponentClientDispatcher(Filter).handle(Request, Response) line: 206 ChildClientDispatcher.parentHandle(Request, Response) line: 148 ChildClientDispatcher.doHandle(Request, Response) line: 121 ChildClientDispatcher(Filter).handle(Request, Response) line: 206 ChildClientDispatcher.parentHandle(Request, Response) line: 148 ChildClientDispatcher.doHandle(Request, Response) line: 121 ChildClientDispatcher(Filter).handle(Request, Response) line: 206 Decoder(Filter).doHandle(Request, Response) line: 159 Decoder(Filter).handle(Request, Response) line: 206 CustomRedirector.serverRedirect(Restlet, Reference, Request, Response) line: 53 CustomRedirector(Redirector).outboundServerRedirect(Reference, Request, Response) line: 352 CustomRedirector(Redirector).handle(Request, Response) line: 295 TemplateRoute(Filter).doHandle(Request, Response) line: 159 TemplateRoute(Filter).handle(Request, Response) line: 206 Router.doHandle(Restlet, Request, Response) line: 431 Router.handle(Request, Response) line: 648 RangeFilter(Filter).doHandle(Request, Response) line: 159 RangeFilter(Filter).handle(Request, Response) line: 206 Decoder(Filter).doHandle(Request, Response) line: 159 Decoder(Filter).handle(Request, Response) line: 206 StatusFilter(Filter).doHandle(Request, Response) line: 159 StatusFilter.doHandle(Request, Response) line: 155 StatusFilter(Filter).handle(Request, Response) line: 206 TunnelFilter(Filter).doHandle(Request, Response) line: 159 TunnelFilter(Filter).handle(Request, Response) line: 206 ApplicationHelper(CompositeHelperT).handle(Request, Response) line: 211 ApplicationHelper.handle(Request, Response) line: 84 TransparentReverseProxyApp(Application).handle(Request, Response) line: 381 VirtualHost$1(Filter).doHandle(Request, Response) line: 159 VirtualHost$1(Filter).handle(Request, Response) line: 206 VirtualHost(Router).doHandle(Restlet, Request, Response) line: 431 VirtualHost(Router).handle(Request, Response) line: 648 HostRoute(Filter).doHandle(Request, Response) line: 159 HostRoute(Filter).handle(Request, Response) line: 206 ServerRouter(Router).doHandle(Restlet, Request, Response) line: 431 ServerRouter(Router).handle(Request, Response) line: 648 StatusFilter(Filter).doHandle(Request, Response) line: 159 StatusFilter.doHandle(Request, Response) line: 155 StatusFilter(Filter).handle(Request, Response) line: 206 LogFilter(Filter).doHandle(Request, Response) line: 159 LogFilter(Filter).handle(Request, Response) line: 206 ComponentHelper(CompositeHelperT).handle(Request, Response) line: 211 Component.handle(Request, Response) line: 392 Server.handle(Request, Response) line: 516 HttpServerHelper(ServerConnectionHelper).handle(Request, Response) line: 257 HttpServerHelper(ServerConnectionHelper).doHandleInbound(Response) line: 186 BaseHelper$2.run() line: 593 ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1145
Re: Restlet Framework 2.2 RC3 released
Hi Jerome, Don't have a lot of time to contribute ATM. My impression is that the Representation.getSize() != 0 checks are the main cause of this issue. IMHO these should be removed from ConverterService.toObject() and Representation.isAvailable(), but perhaps also in other places. On 07/03/2014 02:10, Jerome Louvel wrote: Thanks Arjohn for reporting this again. I have just entered an issue that we'll try to fix before 2.2.0: https://github.com/restlet/restlet-framework-java/issues/861 Do you think you could contribute a fix/pull request? Best, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3074485
Re: Restlet Framework 2.2 RC3 released
Hi Jerome, Will this release also change how empty entity are treated? We've been bitten a couple of times now by restlet's habbit to convert empty entities to null. Cheers, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3074087
Re: Restlet Framework 2.2 RC3 released
Hi Jerome,
Great to hear that.
We were also having problem with incoming entities. To give an example:
SomeServerResource {
@Post void postIdSet(IdSet idSet) {
// code here
}
}
An empty IdSet is serialized to an empty entity (byte[0]). We'd expect
the converter service to deserialize the entity back to an empty IdSet,
but that converter is never invoked and restlet passes null for the
idSet parameter instead.
I've posted a related question to this list some time ago, see
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2950796
Looking at the code in GitHub, I don't think that this has been fixed
yet. Could you have a look?
Cheers,
Arjohn
On 06/03/2014 20:20, Jerome Louvel wrote:
Hi Arjohn,
We had another report for this issue that we just fixed:
https://github.com/restlet/restlet-framework-java/issues/848
It will be part of 2.2 RC4 due early next week. Let us know if it
works for you.
Best regards,
Jerome
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3074126
Re: Routing woes...
Perhaps attachDefault(...) does what you're looking for? Or maybe you don't need the router at all and attach the Finder to whatever you are attaching the Router to? On 08/12/2013 16:46, Niclas Hedhman wrote: Hi, (not sure if this is still the proper mailing list) I have in a new project the need to let a Finder provide the ServerResource subclass for ALL URI paths, instead of individual matching. I want to do something like; Finder finder = createRestletFinder( EntityListServerResource.class, getContext() ); router.attach( /*, finder ); return router; -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3069980
Scoring of entity variants
Hi all, We're running into an issues regarding the scoring of entity variants on the client. We found out that ClientResource.handle(Method method, Object entity, ClassT resultClass) scores the variants for POST entities by the accepted media type for the result entity. Why is that? In our case the POST entity matches with a custom media type as well as JSON. The requested result type (String[]) matches with another custom media type and JSON as well. ClientResource chooses the JSON format over our custom format here because that format is also one of the accepted media types for the result. This looks like an odd choice me. I would expect the code just to look at the scores of the variants and pick the one with the highest score, or the first one of those if there are multiple. Some insight in the reasoning behind this would be welcome. Cheers, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068306
Restlet with Simple connector dropping requests?
Hi all, I'm experiencing some really weird behaviour of a restlet server in combination with the simple connector. I suspect that Simple is discarding specific requests for some unknown reason. Has anyone seen such behaviour before? I've posted the details on stackoverflow: http://stackoverflow.com/questions/16736359/restlet-with-simple-connector-dropping-requests Any clues would be highly appreciated. Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3056451
Re: Restlet Framework 2.1.2 and 2.2 M3 released (+ new web site)
I think the proper location for these artifacts are: http://maven.restlet.org/org/restlet/jee/org.restlet/ http://maven.restlet.org/org/restlet/jee/org.restlet.ext.servlet/ Apache Solr should update the groupId of their dependencies to include the targeted platform, e.g. org.restlet.jee. On 17/04/2013 11:49, Darryl Miles wrote: Great work. But what is broken in the Maven repo ? http://maven.restlet.org/org/restlet/org.restlet/ (should a 2.1.1 version be here?) http://maven.restlet.org/org/restlet/org.restlet.ext.servlet/ (same again, should a 2.1.1 version be here?) I have Apache Solr 4.2.1 and it references: org.restlet:org.restlet:2.1.1 org.restlet:org.restlet.ext.servlet:2.1.1 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3053518
Set StatusService on Application or Component?
Hi all, According the the javadoc for StatusService, one should be able to set it on either the Application or the Component. However, in our case, only the former works. A quick peek at the restlet code shows that Resource.getStatusService() only calls Application.getStatusService(). Is this an error in the javadoc, or is something wrong with our code? Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3052370
Set StatusService on Application or Component?
Hi all, According the the javadoc for StatusService, one should be able to set it on either the Application or the Component. However, in our case, only the former works. A quick peek at the restlet code shows that Resource.getStatusService() only calls Application.getStatusService(). Is this an error in the javadoc, or is something wrong with our code? We're using restlet 2.1.1. Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3052374
Re: No buffer space available (maximum connections reached?)
Many thanks. We'll be testing the new release shortly. -- Arjohn On 24/05/2012 18:00, Jerome Louvel wrote: Hi Arjohn, Thanks for reporting this issue, it should now be fixed in 2.1 RC5 and in the master branch. We now try to properly close the Pipe when an exception occurs and by default we now relay calls made on write(OutputStream) to write(WritableByteChannel) using a blocking channel, almost like you suggested. Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2965004
Re: No buffer space available (maximum connections reached?)
Hi Thierry, FYI: We've tested this solution using a custom WritableRepresentation subclass for a couple of weeks now. We haven't seen this issue anymore since then. Regards, Arjohn On 16/05/2012 16:47, Thierry Boileau wrote: Hello Arjohn, sorry for the delay, I ask Jérôme to take a closer look at your suggestion. Best regards, Thierry Boileau Hi all, me again :-) I have debugged this issue further and have probably found a simple fix. I've migrated from 2.0.x to 2.1.x in the mean time and both version are affected by this issue. The Unable to establish loopback connection problem surfaces when using resources that return WritableRepresentation objects. In the stack trace below, ChannelRepresentation.write(OutputStream) converts the writable channel to a readable one through WritableRepresentation.getChannel() and NioUtils.getReadableByteChannel(...). This last method uses a java.nio.channels.Pipe as a buffer between the writer and reader. Because this pipe isn't closed/released in time, the system will run out of available ports under high load, resulting in the shown stack trace. Making sure that the reader-side of the pipe is always closed could help to resolve this issue, but there's a more elegant solution that doesn't use ports. This solution is to override write(OutputStream) in WritableRepresentation, wrap the OutputStream in a WritableByteChannel using e.g. java.nio.channels.Channels.newChannel(...) and pass that to WritableRepresentation.write(WritableByteChannel). Gut feeling is that this might even improve the performance as it feels like a lighter weight approach than using the system's pipes. WDYT? Can we get this fix? Cheers, Arjohn On 20/04/2012 10:01, Arjohn Kampman wrote: Hi all, My restlet server is running into the error mentioned in the subject after a couple of minutes of moderate load. After this error, the server stops responding. Does anyone know what causes this error and how it can be fixed? The full stack trace looks like this: org.restlet.engine.http.adapter.ServerAdapter commit SEVERE: An exception occured writing the response entity java.io.IOException: Unable to establish loopback connection at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.ch.PipeImpl.init(PipeImpl.java:122) at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27) at java.nio.channels.Pipe.open(Pipe.java:133) at org.restlet.engine.io.NioUtils.getChannel(NioUtils.java:160) at org.restlet.representation.WritableRepresentation.getChannel(WritableRepresentation.java:65) at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:71) at org.restlet.engine.application.EncodeRepresentation.write(EncodeRepresentation.java:304) at org.restlet.engine.http.ServerCall.writeResponseBody(ServerCall.java:550) at org.restlet.engine.http.ServerCall.sendResponse(ServerCall.java:488) at org.restlet.ext.jetty.internal.JettyCall.sendResponse(JettyCall.java:327) at org.restlet.engine.http.adapter.ServerAdapter.commit(ServerAdapter.java:197) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:151) at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1042) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect at sun.nio.ch.Net.connect(Native Method) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500) at java.nio.channels.SocketChannel.open(SocketChannel.java:146) at sun.nio.ch.PipeImpl$Initializer.run
Re: Nio connector doesn't close streams/channels
Many thanks. Any ideas on my optimization suggestion in the thread No buffer space available? Cheers, Arjohn On 30/04/2012 18:03, Jerome Louvel wrote: Hi Arjohn, Thanks for reporting this issue. It is now fixed in both 2.1 and master branches. Best regards, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2956395
Re: No buffer space available (maximum connections reached?)
Hi all, me again :-) I have debugged this issue further and have probably found a simple fix. I've migrated from 2.0.x to 2.1.x in the mean time and both version are affected by this issue. The Unable to establish loopback connection problem surfaces when using resources that return WritableRepresentation objects. In the stack trace below, ChannelRepresentation.write(OutputStream) converts the writable channel to a readable one through WritableRepresentation.getChannel() and NioUtils.getReadableByteChannel(...). This last method uses a java.nio.channels.Pipe as a buffer between the writer and reader. Because this pipe isn't closed/released in time, the system will run out of available ports under high load, resulting in the shown stack trace. Making sure that the reader-side of the pipe is always closed could help to resolve this issue, but there's a more elegant solution that doesn't use ports. This solution is to override write(OutputStream) in WritableRepresentation, wrap the OutputStream in a WritableByteChannel using e.g. java.nio.channels.Channels.newChannel(...) and pass that to WritableRepresentation.write(WritableByteChannel). Gut feeling is that this might even improve the performance as it feels like a lighter weight approach than using the system's pipes. WDYT? Can we get this fix? Cheers, Arjohn On 20/04/2012 10:01, Arjohn Kampman wrote: Hi all, My restlet server is running into the error mentioned in the subject after a couple of minutes of moderate load. After this error, the server stops responding. Does anyone know what causes this error and how it can be fixed? The full stack trace looks like this: org.restlet.engine.http.adapter.ServerAdapter commit SEVERE: An exception occured writing the response entity java.io.IOException: Unable to establish loopback connection at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.ch.PipeImpl.init(PipeImpl.java:122) at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27) at java.nio.channels.Pipe.open(Pipe.java:133) at org.restlet.engine.io.NioUtils.getChannel(NioUtils.java:160) at org.restlet.representation.WritableRepresentation.getChannel(WritableRepresentation.java:65) at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:71) at org.restlet.engine.application.EncodeRepresentation.write(EncodeRepresentation.java:304) at org.restlet.engine.http.ServerCall.writeResponseBody(ServerCall.java:550) at org.restlet.engine.http.ServerCall.sendResponse(ServerCall.java:488) at org.restlet.ext.jetty.internal.JettyCall.sendResponse(JettyCall.java:327) at org.restlet.engine.http.adapter.ServerAdapter.commit(ServerAdapter.java:197) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:151) at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1042) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect at sun.nio.ch.Net.connect(Native Method) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500) at java.nio.channels.SocketChannel.open(SocketChannel.java:146) at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:78) Any help would be highly appreciated. Thanks in advance! -- Arjohn Kampman - www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2952569
Re: 204 results instead of empty strings
Hi all,
Sorry for replying to this old message, but I'm bitten by this issue
once again while migrating from 2.0.11 to 2.1-RC4. In contrast to the
previously reported issue, I'm now having trouble getting an object for
which we've written a custom ConverterHelper. The behaviour of 2.1
appears to be different than the behaviour of 2.0 in this respect.
On the server side, I've got a resource that returns Graph objects like
so:
@Get
public Graph getGraph() { ...}
On the client side, we're requesting the graph using:
clientResource.get(Graph.class)
The (de-)serialization is handled by a custom GraphConverter. The
issue that I'm running into now concerns empty graphs. GraphConverter
converts such graphs to 0-byte text documents (of type text/turtle). On
the client side, such a 0-byte text document would have been converted
to an empty Graph object, but the get(Graph.class) method call returns
null instead. The GraphConverter is never called.
The reason that GraphConverter isn't called is because of the
if-statement on line 153 in ConverterService, which bypasses the
converters for empty representations. This is where this issue relates
to the previously reported problem.
Has there been any progress on the resolution of this issue? Any chance
there'll be a fix some time soon?
Regards,
Arjohn Kampman
On 03/10/2011 15:11, Arjohn Kampman wrote:
Related to my previous question regarding empty string parameter values:
I have written a server resource that returns String values. The
DefaultConverter takes care of converting this to/from a text/plain
representation. The restlet framework does a brilliant job at taking
care of all this, except when the result is an empty string. In this
case, restlet returns a 204 no content result.
While the 204 result might look accurate, it doesn't look semantically
correct to me. There's a difference between no content and empty
content. RFC 2616 says the following about 204 codes:
... If the client is a user agent, it SHOULD NOT change its
document view from that which caused the request to be sent...
So, in a browser, you'll never see the empty result. The request appears
to be ignored instead.
On the client resource side, the 204 response is converted to a null
value, rather than an empty string. This requires me to add a null-check
in all client resources that return Strings.
Any thoughts on this?
Regards,
Arjohn Kampman
--
Arjohn Kampman - www.aduna-software.com
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2950796
No buffer space available (maximum connections reached?)
Hi all, My restlet server is running into the error mentioned in the subject after a couple of minutes of moderate load. After this error, the server stops responding. Does anyone know what causes this error and how it can be fixed? The full stack trace looks like this: org.restlet.engine.http.adapter.ServerAdapter commit SEVERE: An exception occured writing the response entity java.io.IOException: Unable to establish loopback connection at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.ch.PipeImpl.init(PipeImpl.java:122) at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27) at java.nio.channels.Pipe.open(Pipe.java:133) at org.restlet.engine.io.NioUtils.getChannel(NioUtils.java:160) at org.restlet.representation.WritableRepresentation.getChannel(WritableRepresentation.java:65) at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:71) at org.restlet.engine.application.EncodeRepresentation.write(EncodeRepresentation.java:304) at org.restlet.engine.http.ServerCall.writeResponseBody(ServerCall.java:550) at org.restlet.engine.http.ServerCall.sendResponse(ServerCall.java:488) at org.restlet.ext.jetty.internal.JettyCall.sendResponse(JettyCall.java:327) at org.restlet.engine.http.adapter.ServerAdapter.commit(ServerAdapter.java:197) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:151) at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1042) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect at sun.nio.ch.Net.connect(Native Method) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500) at java.nio.channels.SocketChannel.open(SocketChannel.java:146) at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:78) Any help would be highly appreciated. Thanks in advance! -- Arjohn Kampman - www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2950103
conditional request handling with annotated methods
Hi all, Does anyone know how to process If-Modified-Since requests in combination with annotated methods? Restlet seems to ignore the getInfo() methods and heads straight to the method that has the @Get annotation. I'm using restlet 2.0.10, in case that matters. -- Arjohn Kampman - www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2939434
Re: Serious bug in ClientResource
This looks like a related but different bug to me. ClientResource.wrap() doesn't seem to call AnnotationInfo.getRequestVariants(...) at all. -- Arjohn Kampman - www.aduna-software.com On 13/12/2011 13:42, Koen Maes wrote: I have a problem that an outbound connection sends the wrong representation, it sends the representation it received from the incoming connection (GWT serialized object) while it should send JSON. see http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2892105 Might this bug be causing this problem ? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2892924 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2892973
Re: Serious bug in ClientResource
Fix verified, it works as expected now. Thanks. On 08/12/2011 10:12, Thierry Boileau wrote: Hello Arjohn, the snapshots are refreshed three times in a day, and the maven repository once a day. I've just checked, you can test it. Best regards, Thierry Boileau -- Arjohn Kampman - www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2891840
Re: Serious bug in ClientResource
FYI: I've logged this issue earlier as: http://restlet.tigris.org/issues/show_bug.cgi?id=1356 On 07/12/2011 17:57, Thierry Boileau wrote: Thanks a lot Arjohn, I've opened an issue for this bug : http://restlet.tigris.org/issues/show_bug.cgi?id=1357 Best regards, Thierry Boileau -- Arjohn Kampman - www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2891339
Re: Serious bug in ClientResource
The fix looks fine to me. How often are the snapshot builds updated on maven.restlet.org so that I can test it? -- Arjohn Kampman - www.aduna-software.com On 07/12/2011 19:39, Thierry Boileau wrote: Hello Arjohn, thanks a lot for the issue and for reporting this bug. The fix is now available in the trunk and the 2.0 branch. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2891368
client side gzip decoding
Hi all, I'm trying to enable gzip decoding on the client using restlet 2.1-RC1 with the default http connectors. I've tried several things, but none of them worked. The javadoc suggests that the DecoderService can take care of this, but how do I use this in combination with a ClientResource? Things that I've tried so far: - Creating an Application with DecoderService enabled and setting this on the resource. This return the uncompressed data. - Creating a ClientResource -- Decoder -- Client chain. This returns a null value for Representation.getText(). - (to verify the procedure:) Wrapping the response's stream in a GZIPInputStream. This works, but I'd rather let the framework take care of this. Any suggestions? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2853899
RE: result value for Form.getFirstValue()
Hi Jerome,
Your unit test runs fine with 2.0.9 also, but I'm able to reproduce it using
the following test:
public void testQueryString() throws IOException {
String query = a=bc=;
Form form = new FormReader(query, CharacterSet.UTF_8, '').read();
assertEquals(b, form.getFirstValue(a));
assertEquals(, form.getFirstValue(c));
assertNull(form.getFirstValue(d));
}
Hope this helps,
Arjohn
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2849989
result value for Form.getFirstValue()
Hi all, I ran into an issue with Form.getFirstValue(String). This method not only returns null when the form doesn't contain the parameter, but also when there is a parameter with an empty string. The empty string is a valid input value in our application, but I can't distinguish between a missing parameter and an empty one using this method. IMHO, this method should return the empty string value in the latter case. What do you think? Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2849428
ClientInfo.getPrincipals() vs getUser()
Hi all, I'm having a hard time understanding the differences between ClientInfo.getPrincipals() and getUser() and when to use which method. I'm trying to get hold of the username in a ServerResource and figured I should use one of these methods. When using a ChallengeAuthenticator from the restlet package, the username is (only) available via getUser(). But when running inside Tomcat and relying on a servlet security-constraint, the username is only available via the getPrincipals() method. I'm using on HTTP Basic authentication in both cases. Looking through the ServerServlet's code, it seems that the user principals are copied from the incoming HttpServletRequest. HttpServletRequest.getRemoveUser() is never called though. Is this is bug in the connector? Any insights in this subject are highly appreciated! -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2435769
Re: CAS authentication in Restlet server
Rhett Sutphin wrote: Hi Arjohn, On Dec 2, 2009, at 12:34 PM, Arjohn Kampman wrote: Hi Rhett, others, Thanks for your suggestion. Since I'm fairly new to the subject, I hope you (and others) can help me a bit to get things clear. If I understand you correctly, you are suggesting to use a CAS proxy ticket as an authentication token. However, such a token can only be sent once to a CAS server for verification. This very much looks like a problem for (preemptive) authentication in consecutive requests. Or am I overlooking something? That's correct. When the client application is using proxy tickets for authentication, it needs to get a new proxy ticket from the CAS server for each request. This was intentional in the design of CAS. Hmm, that might add a bit too much overhead for my project, where proxies can send hundreds or even thousands of requests to target services in a very short time. I'd prefer an approach that allows preemptive authentication. -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426609
Re: logging framework for restlet
OK, thanks. I guess adding an initialization parameter to ServerServlet would be a possible solution. Arjohn Jerome Louvel wrote: FYI, I've just entered a related RFE: Facilitate usage of a custom LoggerFacade in Servlet mode http://restlet.tigris.org/issues/show_bug.cgi?id=962 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Thierry Boileau [mailto:thierry.boil...@noelios.com] Envoyé : vendredi 20 novembre 2009 09:25 À : discuss@restlet.tigris.org Objet : Re: logging framework for restlet Hello Arjohn, as a quick workaround, you can inherit from the ServerServlet and override the init method. Then, register your own ServerServlet class in the web.xml configuration file: servlet-classmy.package.MyServerServlet/servlet-class Best regards, Thierry Boileau Hi Jerome, Some feedback as promised: I am now setting the system property in the class that creates and starts the Component. Routing log request works like a charm in this setup. For users the prefer a simple war-file we're also offering an alternative using the ServerServlet wrapper. I don't know yet how to reroute the logging in this case. ServerServlet works on an Application so the Engine likely already has been initialized by the time the Application class is created. It's too late to set the system property then. Any suggestions? Arjohn Arjohn Kampman wrote: Hi Jerome, Many thanks. I'll have a look at this as soon as possible and let you know the results. Arjohn Jerome Louvel wrote: Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! Best regards, Jerome Louvel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24200 41 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24204 42 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426268 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426271
Re: Case-insensitive version of Series.getValuesArray(...)
FYI: I've verified the fix using the current snapshot code. Works like a charm now :-) Arjohn Thierry Boileau wrote: Hi Arjohn, Should the case-sensitive variant be modified to call this method? Sure! Best regards, Thierry Boileau Wow, that was quick! Thanks for the fix. Should the case-sensitive variant be modified to call this method? All case-sensitive methods except getValuesArray are implemented that way. Arjohn Hello Arjohn, thanks for your report, the fix is now available in the svn repository. Best regards, Thierry Boileau Hi Jerome, I've finally been able to test this new method. Unfortunately, it's implementation is broken. Calling Series.getValuesArray(String name, boolean ignoreCase) results in a ClassCastException. Looking into the code, it looks like this method is casting a array of type E (e.g. Parameter) to an array of String's. Arjohn Jerome Louvel wrote: Hi Arjohn, Good point, I've just added such method in SVN trunk! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] Envoyé : lundi 4 mai 2009 15:41 À : discuss@restlet.tigris.org Objet : Case-insensitive version of Series.getValuesArray(...) Hi all, I've just started working with the restlet framework, so please excuse me if I'm overlooking something. In Restlet 1.1.4 the Series class offers various utility methods for getting parameter values, often with a variant allowing you to control the case-sensitivity. This variant is missing for getValuesArray(), however, which is what I'd like to use. Can this method be added? Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=20565 27 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2261414 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420017 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420050 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426273
Re: CAS authentication in Restlet server
Hi Jerome, Thanks for the pointer, it was very useful. I think I'm starting to see the picture now. I'm a bit confused about the various places where a Verifier is referenced. I've seen such references in Context, ChallengeAuthenticator and Realm. I assume that the context's verifier serves as a default for the ChallengeAuthenticator in that context. The distinction betwee these two and Realm isn't very clear to me yet. What's the role of these verifiers and when should I use which option? Arjohn Jerome Louvel wrote: Hi Arjohn, That would be a nice contribution indeed! Regarding the security API, the best for now is our specification page: Security API refactoring http://wiki.restlet.org/developers/172-restlet/212-restlet.html Feel free to post questions here if needed. We'll cover this topic in the book and make sure to update the existing docs for 2.0 final. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426362
Re: CAS authentication in Restlet server
Hi Rhett, others, Thanks for your suggestion. Since I'm fairly new to the subject, I hope you (and others) can help me a bit to get things clear. If I understand you correctly, you are suggesting to use a CAS proxy ticket as an authentication token. However, such a token can only be sent once to a CAS server for verification. This very much looks like a problem for (preemptive) authentication in consecutive requests. Or am I overlooking something? Regards, Arjohn Rhett Sutphin wrote: If I were adding support for just CAS, I would define a new challenge scheme (call it something like cas_proxy_ticket) and define a Guard and AuthenticationHelper pair which handle this scheme. This would mean that a client would need to acquire a proxy ticket and then include it in the HTTP request as the Authentication header, something like Authentication: cas_proxy_ticket PT-123456789 Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426434
Re: CAS authentication in Restlet server
Hi Jerome, others, I have just started working on this. If I get it up-and-running, I can probably donate the code to the restlet project if you like. I'm currently looking at the org.restlet.security API, but I'm seeing a lot of terms/concepts that are new to me. Do you have a bit of documentation that explains the basic concepts of this API? That would be very helpful. Regards, Arjohn Kampman Jerome Louvel wrote: Hi all, In addition, we have a pending RFE: Support SSO mechanisms http://restlet.tigris.org/issues/show_bug.cgi?id=693 There is an indirect pointer there to another CAS implementation from Alex Horn. I might be a good idea to provide a dedicated Restlet extension for CAS. Anyone willing to lead this? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426075
Re: logging framework for restlet
Hi Jerome, Some feedback as promised: I am now setting the system property in the class that creates and starts the Component. Routing log request works like a charm in this setup. For users the prefer a simple war-file we're also offering an alternative using the ServerServlet wrapper. I don't know yet how to reroute the logging in this case. ServerServlet works on an Application so the Engine likely already has been initialized by the time the Application class is created. It's too late to set the system property then. Any suggestions? Arjohn Arjohn Kampman wrote: Hi Jerome, Many thanks. I'll have a look at this as soon as possible and let you know the results. Arjohn Jerome Louvel wrote: Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! Best regards, Jerome Louvel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420041
Re: Default routing mode change
Jerome Louvel wrote:
Hi Arjohn,
Good suggestion regarding the constants naming. I've just renamed routing
mode constants of Router to follow the MODE_*_MATCH pattern such as
MODE_BEST_MATCH instead of BEST. Deprecated older values.
OK, thanks.
Regarding the enums, we did consider them in several places but they prevent
addition of new constants by the framework or by the developer, especially
without breaking existing code. They also produce extra artifacts in the
Javadocs cluttering them.
Fair enough. We did a similar evaluation for our project (openrdf
sesame), where we decided to use enums where extensibility isn't an
issue and enum-like classes otherwise. The javadoc clutter isn't too
bad in our case.
For your latest question, I would recommend adding two routes: /abc and
/abc/{path}. Then, it is possible to configure the path variable to say
it should match all URI characters including slashes via the
Variable#TYPE_URI_ALL constant, setting the Template#defaultVariable#type
property or adding an entry to Template#variables maps.
Thanks for your help with this one.
I'm wondering if and how this mechanism can be simplified a bit by
making the template mechanism more powerful. One option could be to
encode the matching type in the variable string. I can imagine using a
notation like {digit:ssn} or {path:dirs} to respectively encode a
TYPE_DIGIT and a TYPE_URI_PATH variable.
Ant's notation where * matches a segment and ** matches a path could
also be a useful extension. In my case, I could then simply declare the
second route as /abc/**.
Any thoughts?
Cheers,
Arjohn
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2416507
Re: Default routing mode change
Jerome Louvel wrote: Arjohn, Thanks for the feed-back. Regarding the URI template syntax, it is tempting to extend it, but there is already work being done to define an URI Templates specification: http://code.google.com/p/uri-templates/ It seems far from stable yet and focused on the client-side though. Roy T. Fielding has been more involved lately in this topic so I expect updates soon. It definitely requires more time and thought, I guess something for Restlet 2.1. Thanks for the pointer. Unfortunately, this particular initiative seems to become more client-oriented with each update. Perhaps this isn't the best route to follow for the restlet framework? I did some googling for URI template approaches and found an interesting solution for .NET: http://hyperthink.net/blog/uritemplate-match/ http://msdn.microsoft.com/en-us/library/system.uritemplate.aspx This is also the only server-oriented implementation that I found. I had expected to find more :-( -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2416602
Re: CAS authentication in Restlet server
Hi Rhett, Many thanks for these pointers and your suggestions. The code looks nice and clean. The license for this code looks very BSD-like, is that correct? I noticed that this code is based on acegi. Is this easier/better than using the CAS client code directly? Arjohn Rhett Sutphin wrote: I have done this for my Restlet-based API. I can point you to the code[1], but since the application is a redistributable webapp which supports several authentication plugins, the implementation is probably more indirect than you need. Also, please note that my experience is with Restlet 1.1 only so far -- I haven't tried to update this application to 2.0. If I were adding support for just CAS, I would define a new challenge scheme (call it something like cas_proxy_ticket) and define a Guard and AuthenticationHelper pair which handle this scheme. This would mean that a client would need to acquire a proxy ticket and then include it in the HTTP request as the Authentication header, something like Authentication: cas_proxy_ticket PT-123456789 Rhett -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2416109
CAS authentication in Restlet server
Hi all, I'm planning to integrate CAS (proxy) authentication in my Restlet-based server. Has anyone worked on this before? Any suggestions on how to best implement this? CAS: http://www.jasig.org/cas Regards, Arjohn -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2415378
Re: Default routing mode change
Jerome Louvel wrote: Hi Arjohn, Thanks for the positive feedback on Restlet 2.0! The change on the Router was introduced to have a more predictable default setting. Currently, only the beginning of an URI has to match in order to follow the route (typically a ServerResource subclass). For example: router.attach(/abc, AbcResource.class) was matching both /abc and /abc/123 or /abcefg... This is useful for attaching Directory instances or for nested routers, but this isn't the most common case. Hi Jerome, I think I misunderstood the meaning of Router.FIRST. I thought it meant that the first route was used each time, but that wouldn't be a very useful strategy for a router :-). I now understand that it means that the first /matching/ route is chosen. Perhaps it would be a good idea to rename this (and related) constants to Router.FIRST_MATCH to clarify this? This might have been discussed before: but did you consider using enums for these kind of constants? Enums make it a bit easier to find the possible options in an IDE with auto-code-completion. I had some trouble finding the constants for Router.setDefaultMatchingMode(...) yesterday. Finally: is there an easy way to create a router that will only match complete path segments? I.e.: make /abc match /abc and /abc/123, but not /abcdefg. I assume that this is one of the most used routing option, but making it work like this is a challenge. Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2414417
Default routing mode change
Hi all, I'm currently switching from 1.1.x to 2.0-snapshot. Overall, the changes between the two versions are really good. Well done! There's one (recent) change that I was wondering about though: the change to the default routing mode from BEST to FIRST. Why this change? I also noted that the Router's javadoc hasn't been updated to reflect these changes. It still mentions best match as being the default. Regards, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2414216
logging framework for restlet
Hi all, I was wondering if you ever considered to use a logging framework such as slf4j instead of using java util logging directly. This can make integration of restlet in applications that don't use JUL a lot easier. Regards, Arjohn Kampman -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396497
Re: logging framework for restlet
Rhett Sutphin wrote: Hi Arjohn, On Sep 18, 2009, at 10:31 AM, Arjohn Kampman wrote: I was wondering if you ever considered to use a logging framework such as slf4j instead of using java util logging directly. This can make integration of restlet in applications that don't use JUL a lot easier. I'd be in favor of this, too, but the core team is dedicated zero dependencies in the core of the framework. Here's a discussion from last March: http://markmail.org/search/?q=restlet%20slf4j#query:restlet%20slf4j +page:1+mid:spk4x55pegqktg2y+state:results Guess this has had some attention before. Thanks for the pointer. Reading through Jerome's comments: There is also a bridge from JUL to sl4j (http://www.x4juli.org/) that you could leverage. x4juli actually works the other way around: it implements the slf4j APIs so you can use it as a logger in the slf4j framework. There is a jul-to-slf4j bridge available from slf4j.org, but that is said to add considerable overhead to the logging: Consequently, j.u.l. to SLF4J translation can seriously impact on the cost of disabled logging statements (60 fold increase) and a measurable impact on enabled log statements (20% overall increase). -- http://slf4j.org/legacy.html A main design constraint that we have is zero external dependency for the Restlet API/Engine beside the JRE. It is good for compactness, facility of deployment Good arguments, I would say. and also because we don't want to force our users to use one logging mechanism over another. Now here's the funny thing: based on the exact(!) same argument, we actually decided to switch from jul to slf4j. Getting jul to bridge to slf4j seems to be non-trivial task, while the reverse is as simple as adding the appropriate jar-file to your classpath. So the main question now seems to be: is this sufficient reason to add a small (30kb) external dependency to restlet? -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396548
Re: Stopping the Simple server
Hi Jerome, Niall, Thank you both for addressing this issue. Seeing Simple's performance comparison page, I may just have to consider switching back to Simple again :-) Cheers, Arjohn Jerome Louvel wrote: Hi Arjohn, I'm happy to report that the Simple connector can now be stopped cleanly by incoming requests! Niall and I have worked over the past few weeks to support this. Simple 4.1.13 is now available in Restlet's SVN trunk. Thanks for reporting this issue. I'm closing #823. Best regards, Jerome Louvel -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362689
volatile variable in Tag
Hi all, Just noticed that Tag defines its 'weak' variable to be volatile, although it is never changed. Perhaps this should be final instead? -- Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2330733
Case-insensitive version of Series.getValuesArray(...)
Hi all, I've just started working with the restlet framework, so please excuse me if I'm overlooking something. In Restlet 1.1.4 the Series class offers various utility methods for getting parameter values, often with a variant allowing you to control the case-sensitivity. This variant is missing for getValuesArray(), however, which is what I'd like to use. Can this method be added? Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2056527
