RE: Client Custom Header
Hi Jean-Philippe,
Both Client and Filter classes extend the base Restlet class and implement the
Uniform interface, so you should be able to expose the same API to your
application.
Filters can be chained together, chained with Router and all sorts of Restlet
handlers that materialize the call process flow. This diagram illustrates the
intended design: http://www.restlet.org/documentation/2.0/tutorial#part11
In your case, I would recommend to use the higher-level ClientResource class
instead of the Client one to prepare your client-side calls, unless you are
implementing a reverse proxy or something especially intensive. The
ClientResource has a “next” property that can be used to point to a Filter or a
Client to effectively process the client calls.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : Jean-Philippe Steinmetz [mailto:caskate...@gmail.com]
Envoyé : mercredi 5 mai 2010 18:07
À : discuss@restlet.tigris.org
Objet : Re: Client Custom Header
Hi Jerome,
As I said the server side isn't an option and I need to do this systematically.
The Filter seems like the way to go. You're right that I was sending through
the client instead of the filter. However my aplication expects a Client object
and the Filter does not have the same API. Do I need to instead extend Client
instead of filter?
You may want to reconsider how Filter hooks in. It's inappropriate for it to
change the API. A Filter should really attach to an object, not wrap it.
Jean-Philippe
On May 5, 2010, at 4:36 AM, Jerome Louvel jerome.lou...@noelios.com wrote:
Hi Jean-Philippe,
If your goal is to systematically add cookies to your client requests, you
should definitely use the Restlet API (Request#cookies property) instead of
setting a custom header. To set the cookies on the server-side, you need
instead to use the Response#cookieSettings property. For complete mapping
between Restlet API and HTTP headers, check this page:
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restlet.html
The Client class is a stateless connector that is not appropriate for cookie
management. It was designed to be shared by several threads/applications. Even
though it is possible to instantiate several of them in the same JVM, it is
recommended to share them (of course based on the protocol they support,
HTTP(S) in your case).
I would instead suggest using a CookieFilter in front of the Client to
systematically add the cookies (maybe based on the target URI…). I don’t see
why this wouldn’t work as you say in your previous email. Note that your
“clientHelper” bean doesn’t seem used nor useful.
Are you sure that you send outgoing requests to the “myFilter” bean and not
just to the “client” one? In order for filtering to happen, you need to
explicitly call it. It will then forward the call to the ‘next’ Restlet
attached, the “client” one in your case.
Also, note that we have a RFE to provide a cookie manager filter, able to store
cookie settings and to send them again based on target URI and other criteria:
http://restlet.tigris.org/issues/show_bug.cgi?id=42
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : Jean-Philippe Steinmetz [mailto:caskate...@gmail.com]
Envoyé : mercredi 5 mai 2010 04:38
À : discuss@restlet.tigris.org
Objet : Re: Client Custom Header
Since no one seems to have responded to this problem I was hoping someone could
shed some light on cookie setting. Similarly to adding my own header to all
outgoing client requests I could instead set a cookie. My one requirement here
is that I don't want to modify every outgoing request individually. In other
words, the following code won't work...
request.getCookies().add(myCookie, value);
Instead I need a solution where I set the cookie for the Client instance once
and it is respected across all future connections and requests. Is this
possible? Or am I really stuck having to add it to every outgoing request? Also
please note it is not possible to set the cookie on the server side.
On Mon, May 3, 2010 at 5:24 PM, Jean-Philippe Steinmetz caskate...@gmail.com
wrote:
Hi Stephan,
Thank you for the response. I've implemented a filter and created one while
setting the next property to be my client but I am not getting any calls to
the beforeHandle function. My code looks like the following.
class MyFilter extends Filter
{
public MyFilter() { this(null);
public MyFilter(Context context) { this(context, null); }
public MyFilter(Context context, Restlet next) { super(context, next); }
public int beforeHandle(Request request, Response response)
{
Re: 304 responses cause WARN logging
Is anyone else getting these spurious warnings logged during 304s? Is anyone else using EmptyRepresentation? -Dave On Mon, May 3, 2010 at 6:43 PM, David Fogel carrotsa...@gmail.com wrote: We recently updated to the newest RC (actually to revision 6570 of trunk), and now every single 304 response our server returns causes a WARN-level message to appear in the logs, like this: WARNING: Responses with a 304 (Not modified) status can't have an entity. Only adding entity headers for resource http://localhost:8080/some/path/here/;. This doesn't seem desirable. ... -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604244
SSL issue with Jetty, Simple
Hi all- We're having a problem with serving our restlet web application over SSL. It's very possible that we're doing something wrong with how we're setting up the keystore and cert. We had previously set up SSL with a self-signed cert, generated using java keytool. This worked fine on Jetty and, until recently, with the Simple connector, which had some hanging issues a few revisions ago (but which may have been fixed, we're not sure. overall we'd prefer to get back to using the simple connector). Our configuration involved something like this: SeriesParameter params = s.getServers().add(Protocol.HTTPS, 8443) .getContext().getParameters(); params.add(keystorePath, path/to/keystore.jks); params.add(keystorePassword, secret); params.add(keyPassword, secret); So, like I said, this worked fine with a self-signed cert, although obviously browsers complain at first. We recently decided to acquire a real CA-signed cert, which we got from StartSSL.com. I built up a keystore which imports their root certs and the cert they signed for us. Doing a keytool -list command shows something like this: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries startcom.ca.sub, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 30:B0:5A:F7:B2:F4:BE:0C:28:67:15:EA:CC:5B:24:20 startcom.ca, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 startcom pfx certificate, Apr 26, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): 15:F4:A5:34:C6:B1:DE:BE:BF:4E:5D:83:BA:97:89:1E Here is what we experience now: With Jetty: - everything seems to work great in our Safari, Chrome, and IE browsers, in that HTTPS works and the browser doesn't complain. - Firefox complains that the cert is Untrusted With Simple extension, and using the same configuration: - no access at all via HTTPS. no response or log message at all on the server at startup or on request Anyone else successfully serving up CA-signed HTTPS using Jetty or Simple? And why doesn't the default connector do HTTPS? Also, I've never been clear on what the org.restlet.ext.ssl module is for- will it add HTTPS support to the default restlet connector? Thanks, -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604257
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 15:16, David Fogel wrote: We had previously set up SSL with a self-signed cert, generated using java keytool. This worked fine on Jetty and, until recently, with the Simple connector, which had some hanging issues a few revisions ago (but which may have been fixed, we're not sure. overall we'd prefer to get back to using the simple connector). Have you tried the Simple connector since 2.0-RC2? It should incorporate the fix discussed in the thread you started at the end of March http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621 (a newer release of the Simple library). Our configuration involved something like this: SeriesParameter params = s.getServers().add(Protocol.HTTPS, 8443) .getContext().getParameters(); params.add(keystorePath, path/to/keystore.jks); params.add(keystorePassword, secret); params.add(keyPassword, secret); This looks correct (although you might need to configure a truststore too if you're using the Simple connector, see below). We recently decided to acquire a real CA-signed cert, which we got from StartSSL.com. I built up a keystore which imports their root certs and the cert they signed for us. Doing a keytool -list command shows something like this: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries startcom.ca.sub, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 30:B0:5A:F7:B2:F4:BE:0C:28:67:15:EA:CC:5B:24:20 startcom.ca, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 startcom pfx certificate, Apr 26, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): 15:F4:A5:34:C6:B1:DE:BE:BF:4E:5D:83:BA:97:89:1E Here is what we experience now: With Jetty: - everything seems to work great in our Safari, Chrome, and IE browsers, in that HTTPS works and the browser doesn't complain. - Firefox complains that the cert is Untrusted What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. With Simple extension, and using the same configuration: - no access at all via HTTPS. no response or log message at all on the server at startup or on request Perhaps try setting the truststore to use the keystore too? params.add(truststorePath, path/to/keystore.jks); params.add(truststorePassword, secret); Otherwise, you might run into a similar problem as in this thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599797 (This is due to the fact that Simple always ask for a client-certificate at the moment). Anyone else successfully serving up CA-signed HTTPS using Jetty or Simple? And why doesn't the default connector do HTTPS? I have. Admittedly, mostly with the UK e-Science CA: its certificates aren't bundled by default with browsers, but that's an admin/trust problem, not a technical one. Also, I've never been clear on what the org.restlet.ext.ssl module is for- will it add HTTPS support to the default restlet connector? The SSL extension is mostly useful if you want advanced SSLContext settings (e.g. specific client certificate settings or non-default trust models such as those used with FOAF+SSL or grid computing). You probably don't need it if you're not using client certificates at all. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604285
Annotated Get method and Content Negotiation procude undesired result
Hi, using Content Negotiation together with annotated get methods produce an undesired behaviour in our case. We have a ServerResource with some annotated get methods and content negotiation enabled. In case that the client calls with Accept: application/pdf (which is allowed in other parts of the app) the get method for xml is called. This also happens in the attached testcase. We are using Restlet 2.0rc3. Thanks for your help, Hanno -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604231 TestContentNegotiation.java Description: Binary data
NullPointerException from converter when passing empty form in 2.0 RC3
Hi,
Since Restlet 2.0RC3, ConverterService throws a nullPointerException when
attempting to resolve an empty form.
Here is a short code exemple :
ClientResource resource = new ClientResource(uri);
resource.post(new Form());
From the server side, the post handle looks like this :
@Post create(Form form) {
// do stuff
}
And finally, the stack trace we got :
java.lang.NullPointerException
at
org.restlet.engine.util.FormReader.readNextParameter(FormReader.java:221)
at org.restlet.engine.util.FormReader.addParameters(FormReader.java:132)
at org.restlet.engine.util.FormUtils.parse(FormUtils.java:266)
at org.restlet.data.Form.init(Form.java:82)
at
org.restlet.engine.converter.DefaultConverter.toObject(DefaultConverter.java:253)
at
org.restlet.service.ConverterService.toObject(ConverterService.java:156)
at org.restlet.resource.ServerResource.doHandle(ServerResource.java:402)
at org.restlet.resource.ServerResource.post(ServerResource.java:1047)
The question is, okay we really want a well formed form here, but it seems to
us that throwing a nullpointer when receiving en empty form is a bit to
excessive :)
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604056
Josaphat
Just wanted to say hello Caron is just as excited about getting her MSA registration doing her first training days italy I like this site. http://leadsuppsi.anyhow5.com/2010/05/01/cruise-to-hawaii-i-recommend-to-visit-trip-to-gkarfagen-sidi-bou-said-worth-a-try-magnificent/airfare marriott mark, http://holdtenthfib.anyhow5.com/2010/05/01/last-minute-airline-fares-to-las-vegas-norway-the-country-of-fairy-tales-legends-trolls/airfare park leave a lot to be desired, http://diagewidthnet.blogit.fi/kenai-alaska-lodgings-do-not-have-100-rubles-approximately-so-i-thought-on-the-way-in-limburg-on/airfare short, kiss -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602496
Serving Static Files with RC3
Hello,
I setup this little test case as described in the Restlet 2.0 tutorial. I'm
using RC3.
When I run it and try to access just one file several times the Restlet server
'hangs',
that means I don't get a response. Any ideas? Can you reproduce this?
package de.klaq.test;
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.Protocol;
import org.restlet.resource.Directory;
public class RestletStaticTest {
public static final String ROOT_URI = file:/Users/klaas/_temp/;
public static void main(String[] args) {
// Create a component
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
component.getClients().add(Protocol.FILE);
// Create an application
Application application = new Application() {
@Override
public Restlet createInboundRoot() {
final Directory directory = new
Directory(getContext(), ROOT_URI);
directory.setListingAllowed(true);
return directory;
}
};
// Attach the application to the component and start it
component.getDefaultHost().attach(application);
try {
component.start();
} catch (Exception e) {
System.out.println(RestletStaticTest.main: + e);
}
}
}
I thought this issue would be related to the 304 warning discussed earlier, but
it isn't.
Best regards, Klaas.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603505
Re: 304 responses cause WARN logging
Any news on this?
I'm serving a static directory with this code:
component.getDefaultHost().attach(/s/, new Application() {
@Override
public Restlet createInboundRoot() {
final String basedirPath = /directory/;
final Directory directory = new
Directory(getContext(), LocalReference.createFileReference(basedirPath));
return directory;
}
});
And I get the error as well:
WARN Server - Responses with a 304 (Not modified) status can't have an entity.
Only adding entity headers for resource
http://xxx.com/s/includes/mootools-1.2.4.2-more.js'
But it gets worse. if I use my application with Safari, Safari hangs and can
not download the file at all.
I'm using the current RC3.
Best Regards, Klaas.
On 03.05.2010, at 18:43, David Fogel wrote:
We recently updated to the newest RC (actually to revision 6570 of
trunk), and now every single 304 response our server returns causes a
WARN-level message to appear in the logs, like this:
WARNING: Responses with a 304 (Not modified) status can't have an
entity. Only adding entity headers for resource
http://localhost:8080/some/path/here/;.
This doesn't seem desirable.
This message is generated in the ServerAdapter.commit() method, if the
status us 304 and isEntityAvailable() returns true. This implies it
is incorrect for an representation at this stage (having gone through
condition request handling) to be available.
One change from 3 weeks ago that I found looking at SVN commits was a
change to EmptyRepresentation.java which makes it available, instead
of unavailable. (It now passes 'true' instead of 'false' to
setAvailable() in its constructor). This seems like a pretty
significant change, especially given that there isn't much
documentation for how the EmptyRepresenation is supposed to behave.
In fact, it was our impression that the only way for us to return any
entity metadata during a 304 was in fact to use a subclass of
EmptyRepresentation. (Although I also noticed a current restlet issue
which claims that this metadata is not, in fact, being actually sent!)
So now, since an EmptyRepresentation is available, the ServerAdapter
is WARNing about a 304 with a, entity.
However, I don't think the problem is just with EmptyRepresentation,
something else must have changed, maybe in the conditional request
handling, because we have other resources which have no special code
in them at all, but which happen to publish an eTag in the
representation subclass, and which therefor sometimes cause a 304 when
requested, and we also see this warning showing up now for these
requests.
1) what should the state of a representation be after conditional
request handling?
2) how is the EmptyRepresentation supposed to be used?
3) Why is there a warning during a 304 response with an entity?
thanks,
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602172
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603129
getting DOM from Response
Greetings! I am new to using restlets and have the 2.0 version of the GWT release for the client and the 2.0 version of the J2EE for the server. I am getting a Response back from the server and would like to get the information without parsing raw XML. I have seen many ways to do this, like using the representation in the constructor to DomRepresentation, but it seems things have been shuffled around in 2.0 as compared to previous versions. I cannot find an example of how to do this in 2.0. Does anyone have any pointers? I did see some use of wrappers and annotations in one example on the wiki. Is this preferred? Many Thanks! Allan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602987
Multipart form post from android client
Hi, I was wondering if you guys had implemented the multi-part form request in the android client lib yet? If not I understand I can use the apache httpclient? could anyone point me at a good example of how to do this? thanks in advance Chris D -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602795
Android OutOfMemory
Hi, I try to send a file this way, from Android, with Restlet 2.0RC3 *** ClientResource clientResource = new ClientResource(URL); FileResource filesResources = clientResource.wrap(FileResource.class); FileRepresentation fileEntity = new FileRepresentation(file, MediaType.APPLICATION_ZIP); filesResources.upload(fileEntity); *** It works fine, I sent some 3Mo files without any error. But I always have an OutOfMemory error on a 7Mo file, which is not so big. Any idea ? Thanks in advance, Pierre 05-04 11:21:41.320: ERROR/dalvikvm-heap(29653): Out of memory on a 7199005-byte allocation. 05-04 11:21:41.330: INFO/dalvikvm(29653): AsyncTask #2 prio=5 tid=23 RUNNABLE 05-04 11:21:41.330: INFO/dalvikvm(29653): | group=main sCount=0 dsCount=0 s=N obj=0x437c8118 self=0x22c728 05-04 11:21:41.330: INFO/dalvikvm(29653): | sysTid=29932 nice=10 sched=0/0 handle=2726392 05-04 11:21:41.330: INFO/dalvikvm(29653): at java.io.ByteArrayOutputStream.init(ByteArrayOutputStream.java:~74) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection$HttpOutputStream.init(HttpURLConnection.java:518) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1147) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.ext.net.internal.HttpUrlConnectionCall.getRequestStream(HttpUrlConnectionCall.java:208) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.ext.net.internal.HttpUrlConnectionCall.getRequestEntityStream(HttpUrlConnectionCall.java:193) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.engine.http.ClientCall.sendRequest(ClientCall.java:314) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.ext.net.internal.HttpUrlConnectionCall.sendRequest(HttpUrlConnectionCall.java:350) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.engine.http.adapter.ClientAdapter.commit(ClientAdapter.java:112) 05-04 11:21:41.350: INFO/dalvikvm(29653): at org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:110) 05-04 11:21:41.360: INFO/dalvikvm(29653): at org.restlet.Client.handle(Client.java:177) 05-04 11:21:41.360: INFO/dalvikvm(29653): at org.restlet.resource.ClientResource.handle(ClientResource.java:838) 05-04 11:21:41.360: INFO/dalvikvm(29653): at org.restlet.resource.ClientResource.handle(ClientResource.java:806) 05-04 11:21:41.360: INFO/dalvikvm(29653): at org.restlet.resource.ClientResource.access$000(ClientResource.java:77) 05-04 11:21:41.360: INFO/dalvikvm(29653): at org.restlet.resource.ClientResource$1.invoke(ClientResource.java:1599) 05-04 11:21:41.360: INFO/dalvikvm(29653): at $Proxy5.upload(Native Method) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602545
RE: Re: Android and WCF DataService
Matthew, Your log looks very similar to mine, only I never see the log entries my code should write when the data actually comes back from the service. Does it just take a long time? Do you know if navigation properties on the Entity Model impacts performance? Mine are lazy loaded, so they shouldn't be an issue at this point, as I'm just querying a single entity. I'm well versed in C#/.NET, but just getting into Android/Java development. I read the Restlet oData tutorial (http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/287-restlet/288-restlet.html) and thought it sounded perfect for what I want to do. Unfortunately, I haven't been able to get it working despite several late nights messing with it. Thanks in advance for any help you or anyone else can provide! Andy Thierry- I have been working on my android app...but noticed some strange behaviors in the android logs that I wanted to pass your way. Here is a cut of sample code I am using in my app. String remoteServiceEndPoint = http://blah.blah.blah/iMMeta/webdataservice.svc;; Service myService = new Service(remoteServiceEndPoint); SysShoot ActiveShoot= new SysShoot(); ShootProviderHelper myHelper = new ShootProviderHelper(); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot iShoot= theShootQuery.iterator(); Below is a snipit of log from my app that spits out for the above code. I wanted to check with you on a few things. 04-30 11:15:32.625: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.115: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.575: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:34.034: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:34.055: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:45.764: INFO/org.restlet(518): Get the metadata for http://digital-furnace.com/iMMeta/webdataservice.svc/ at http://digital-furnace.com/iMMeta/webdataservice.svc/$metadata 04-30 11:15:45.945: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.485: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.965: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:47.275: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:47.295: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:53.944: DEBUG/dalvikvm(518): GC freed 12463 objects / 646712 bytes in 109ms 04-30 11:16:01.104: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:01.725: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:02.234: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:16:02.555: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:02.574: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:06.775: DEBUG/dalvikvm(518): GC freed 14622 objects / 764968 bytes in 98ms 04-30 11:16:11.654: DEBUG/dalvikvm(518): GC freed 13481 objects / 835208 bytes in 107ms 04-30 11:16:16.834: DEBUG/dalvikvm(518): GC freed 13575 objects / 809480 bytes in 92ms 04-30 11:16:22.145: DEBUG/dalvikvm(518): GC freed 13529 objects / 808816 bytes in 111ms 04-30 11:16:27.974: DEBUG/dalvikvm(518): GC freed 14672 objects / 874640 bytes in 113ms 04-30 11:16:33.394: DEBUG/dalvikvm(518): GC freed 13786 objects / 820520 bytes in 99ms 04-30 11:16:38.265: DEBUG/dalvikvm(518): GC freed 13235 objects / 822288 bytes in 101ms So for Service myService = new Service(remoteServiceEndPoint); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot
Re: SSL issue with Jetty, Simple
Hi Bruno- Thanks for responding about this, comments inline.. On Thu, May 6, 2010 at 11:18 AM, Bruno Harbulot bruno.harbu...@manchester.ac.uk wrote: Have you tried the Simple connector since 2.0-RC2? It should incorporate the fix discussed in the thread you started at the end of March http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621 (a newer release of the Simple library). Our current issue with Simple is based on the most recent released simple jar and the restlet trunk for org.restlet.ext.simple. However, I have not yet retried simple with the self-signed cert, so it's possible it will work with that. This looks correct (although you might need to configure a truststore too if you're using the Simple connector, see below). I will try simple with the truststore configured. What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). firefox is saying: local.mydomain.org:8083 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. Looking at firefox's list of certificate authorities, I see the various startcom certs. So as far as I understand it, it should work. From what I've heard elsewhere, firefox differs from other browsers in part by using it's own list of trusted root certs, instead of the host system's built-in list. But either way, the certs seem to be there. I'm pretty sure that the startcom/startssl certs are widely enough used that they're trusted by all browsers and operating systems. They also specifically claim this on their site. So I feel it is more likely that I've misconfigured the keystore or misconfigured restlet/jetty/etc. -Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604309
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 17:07, David Fogel wrote: What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). firefox is saying: local.mydomain.org:8083 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. Looking at firefox's list of certificate authorities, I see the various startcom certs. So as far as I understand it, it should work. From what I've heard elsewhere, firefox differs from other browsers in part by using it's own list of trusted root certs, instead of the host system's built-in list. But either way, the certs seem to be there. I'm pretty sure that the startcom/startssl certs are widely enough used that they're trusted by all browsers and operating systems. They also specifically claim this on their site. So I feel it is more likely that I've misconfigured the keystore or misconfigured restlet/jetty/etc. One way to diagnose what certificates are configured is to use OpenSSL (often pre-installed on Linux/OSX): echo | openssl s_client -showcerts -connect local.mydomain.org:8083 The command above isn't configured with any trusted certificate, so it will most likely say verify error:num=19:self signed certificate in certificate chain, which you can ignore. The important part is that it should show the certificate chain after: Certificate chain 0 s:/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... i:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA -BEGIN CERTIFICATE- ... XxdhCHujMWxwSLQq -END CERTIFICATE- 1 s:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root -BEGIN CERTIFICATE- ... dZwURrmRAbx676x3Ef2po8s= -END CERTIFICATE- 2 s:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root -BEGIN CERTIFICATE- ... -END CERTIFICATE- --- Server certificate subject=/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... issuer=/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA Here, cert 0 (the server's) was issued by 1, which was issued by 2. I didn't have anything explicit to do to get the server to serve the full chain. I'm only using a keystore that contains these certs + the private key for the server's cert, with extra config. (My keystore is in PKCS#12 format, but that really shouldn't make any difference, your JKS seemed fine, provided it contains the right intermediate certs.) What you should have is a chain that's not broken and that builds up to at least something that's in Firefox's trusted CA certificates. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604404
Directory and FTP
Hello, I would like to use Directory class with FTP. I wrote the following code Router router = new Router(); Directory dir = new Directory(getContext(), ftp://193.190.231.123 ); dir.setNegotiatingContent(true); dir.setListingAllowed(true); dir.setDeeplyAccessible(true); router.attachDefault(dir); return router; I expected a result as FILE protocole, I mean a HTML representation if I use my browser. But, instead of a HTML representation, I have something else : a popup appears to me for asking to save a file. How can I have a HTML representation using directory with FTP ? Thanks a lot, J-Christophe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604427
