Re: problems using gzip encoding
Okay this is my problem. I was assuming that i would get the wrapped representation once it hits my resource by i get the DecodeRepresentation instance instead. Can I configure my Application so that the wrapped representation is sent to my resource class rather than the DecodeRepresentation? cheers /jima Jim Alateras wrote: I am trying use gzip for all my representations and use the tunnel filter, on the application, to automatically decode the body before passing it to the router. This how i encode the rep new EncodeRepresentation(Encoding.GZIP, new StringRepresentation(getXStream().toXML(records), MediaType.APPLICATION_XML)); but i end up getting the following error on the server. java.io.IOException: Not in GZIP format at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:132) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:58) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:68) at com.noelios.restlet.application.DecodeRepresentation.getDecodedStream(DecodeRepresentation.java:138) at com.noelios.restlet.application.DecodeRepresentation.getStream(DecodeRepresentation.java:115) at com.noelios.restlet.application.DecodeRepresentation.getText(DecodeRepresentation.java:189) at au.com.observant.ringocore.resource.syslog.SyslogsResource.post(SyslogsResource.java:103) at org.restlet.resource.Resource.handlePost(Resource.java:479) at org.restlet.Finder.handle(Finder.java:296) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Router.handle(Router.java:444) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:87) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:96) at org.restlet.Application.handle(Application.java:293) at org.restlet.Uniform.handle(Uniform.java:97) at cheers /jima
Re: problems using gzip encoding
Hi Jim, The Application.decoderService is already able to automatically decode incoming compressed representations. If you prefer to disable this behavior, just do: myApp.getDecoderService().setEnabled(false); before starting the application. Best, Jerome 2007/10/9, Jim Alateras [EMAIL PROTECTED]: Okay this is my problem. I was assuming that i would get the wrapped representation once it hits my resource by i get the DecodeRepresentation instance instead. Can I configure my Application so that the wrapped representation is sent to my resource class rather than the DecodeRepresentation? cheers /jima Jim Alateras wrote: I am trying use gzip for all my representations and use the tunnel filter, on the application, to automatically decode the body before passing it to the router. This how i encode the rep new EncodeRepresentation(Encoding.GZIP, new StringRepresentation(getXStream().toXML(records), MediaType.APPLICATION_XML)); but i end up getting the following error on the server. java.io.IOException: Not in GZIP format at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:132) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:58) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:68) at com.noelios.restlet.application.DecodeRepresentation.getDecodedStream(DecodeRepresentation.java:138) at com.noelios.restlet.application.DecodeRepresentation.getStream(DecodeRepresentation.java:115) at com.noelios.restlet.application.DecodeRepresentation.getText(DecodeRepresentation.java:189) at au.com.observant.ringocore.resource.syslog.SyslogsResource.post(SyslogsResource.java:103) at org.restlet.resource.Resource.handlePost(Resource.java:479) at org.restlet.Finder.handle(Finder.java:296) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Router.handle(Router.java:444) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:87) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:96) at org.restlet.Application.handle(Application.java:293) at org.restlet.Uniform.handle(Uniform.java:97) at cheers /jima
Issue when using Guard for POST and GET requests
Hi all. I have started using restlet since last month and am impressed with the
simplicity it offers.
However, I bumped into a problem with using Guards earlier and could not figure
out a good way to get around it.
Basically I have one Restlet TestRestlet that handles both GET and POST
requests. However, they have different URI patterns.
For example, GET request would have pattern of /testGet/user/{userId}
and POST request would have pattern of /testPost
Hence if I type http://localhost:8080/testGet/user/ABC, the request would be
mapped to the GET handling of the TestRestlet and it would return, say a form in
html format and the use can click submit on that form which points to
http://localhost:8080/testPost
I have one single Guard:
Guard testGuard= new TestGuard(getContext()
, ChallengeScheme.HTTP_BASIC
, test Access Control; //my TestGuard class, same as Guard...
Restlet testRestlet = new TestRestlet(getContext());
testGuard.setNext(testRestlet);
router.attach(/testGet/user/{userId}, testGuard);
router.attach(/testPost, testGuard);
Now, if I access /testGet/user/ABC, it would ask me for authentication (401
response), which is fine. After I input the user name and password, it would
then return the html form which points to /testPost (which is fine too). Now, if
I submit that form, I would get 401 response again...and the web browser
obviously was confused (keep saying loading) and its stuck.
My expectation is that the server should not give 401 status code the 2nd time
(since it has already authenticated on the GET request and they are sharing the
same Guard). The funny part is that if I change the pattern
/testGet/user/{userId} into just /testGet then all goes fine...
I am not sure if its a bug or if its some stupid problem that I made...can
anyone plz gimme some pointers plz?
The Restlet jar I am using is the version 3.1 one. The server is the Simple
server and Simple Framework.
Many thanks in advance!!!
Re: HEAD not well supported?
At Mon, 8 Oct 2007 17:35:00 + (UTC), Sean Landis [EMAIL PROTECTED] wrote: Regarding my previous comments regarding a test using curl; it appears curl is hung up on the fact that content length has a value and there is no entity. I did determine that Restlet does remove the content. Sorry for being misleading on that point. It does appear that curl is wrong here. I have filed a bug report at http://sourceforge.net/tracker/index.php?func=detailaid=1810273group_id=976atid=100976 You can obtain correct behavior by using the -I/--head option instead of -X HEAD, which is good to know. I'd say that Restlet meets the requirements of the spec and that's good. Although I still think it would be better to leverage Uniform entirely and it seems awkward to me that HEAD is an exception. My understanding of REST is that HEAD is part of the uniform interface and therefore should be supported in the same way, and to the same extent as the rest of the HTTP methods. I was very surprised when HEAD did not conform to the programming model in place for the uniform interface and I suspect others would be too. I don’t understand what you mean here by uniform interface. Uniform interface in REST refer to inter-application semantics, not intra-application. And it doesn’t, to my understanding, mean that HEAD GET must have identical semantics, rather that the semantics of a GET or HEAD request be the same for all resources. Am I misunderstanding you here? best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpa7495zhgap.pgp Description: PGP signature
Re: Thread-safety in Guard
On 10/9/07, Jerome Louvel [EMAIL PROTECTED] wrote: Good idea, I've entered a RFE for this documentation task: http://restlet.tigris.org/issues/show_bug.cgi?id=369 What's the best way for me (or anyone else) to report other concurrency and documentation issues that I encounter? In this discussion group? This thread? Or somewhere else? Here's my understanding of the basic concurrency requirements of the Restlet framework: Restlets of all flavors must be @ThreadSafe because they will in general be accessed concurrently by many threads. Requests and Responses are @NotThreadSafe; their handling is confined to a single thread. Representations might or might not be thread-safe, depending on whether they will be re-used in subsequent request handling. Does that sound right? I posted some basic rules for writing @ThreadSafe classeshttp://tembrel.blogspot.com/2007/10/basic-rules-for-threadsafe-classes.htmlon my blog. I hope they're helpful. --tim
Re: Index files don't work with Directory and clap://
Nope, this doesn't work: Directory d = new Directory(getContext(), clap: //thread/client-bin); d.setNegotiateContent(false); d.setIndexName(index.html); guard1.setNext(d); Though this does: Directory d = new Directory(getContext(), file: //home/imaginary/build/dir/client-bin); d.setNegotiateContent(false); d.setIndexName(index.html); guard1.setNext(d); - Rob - Original Message - From: Jerome Louvel [EMAIL PROTECTED] To: discuss@restlet.tigris.org Sent: Tuesday, October 9, 2007 3:41:05 PM (GMT-0500) America/New_York Subject: RE: Index files don't work with Directory and clap:// Rob, Yes. I think simply being able to specify index.html instead of index and turn off content negotiation is what I want here. So, if I set negotiateContent to false and indexName to index.html, that should do the trick already, or do I need to do some surgery first? My guess is that should work directly. Otherwise we'll make it work this way :) Best regards, Jerome
Re: Slow to retrieve Request Entity?
Rob, great call, switching to Jetty did the trick. Thanks!
On 10/8/07, Rob Heittman [EMAIL PROTECTED] wrote:
Simple has given me some indigestion on OS X 10.4. Any chance you can try it
with the regular java.net HTTP connector and/or Jetty and see if you get the
same result? That would help isolate it.
- Original Message -
From: Avi Flax [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Monday, October 8, 2007 11:09:30 PM (GMT-0500) America/New_York
Subject: Slow to retrieve Request Entity?
I seem to be having some kind of performance problem trying to
retrieve the request entity.
I've tried a few different approaches, and I can't figure it out.
I'm using Restlet 1.0.5 with the bundled Simple server, Intel Core
Duo, Mac OS X 10.4.10, Java 5.0, Eclipse.
I've tried reducing my test case down to the bare bones.
At this point my test App looks like this:
import org.restlet.Restlet;
import org.restlet.Server;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class TestApp {
public static void main(String[] args) throws Exception {
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
try {
response.setEntity(request.getEntity().getText(), MediaType.TEXT_PLAIN);
System.exit(1);
} catch (Exception e) {
e.printStackTrace();
}
}
};
new Server(Protocol.HTTP, 3000, restlet).start();
}
}
and these are the only JAR files in my build path:
com.noelios.restlet.ext.simple_3.1.jar
com.noelios.restlet.jar
org.restlet.jar
org.simpleframework.jar
My JVM args are: -server -Xprof
My test script:
time curl -X POST -d @post.xml -H Content-Type:application/xml
http://localhost:3000/
post.xml is a 2.5K xml file.
No matter what I do, request.getEntity().getText() seems to take about
2 seconds. This seems way too slow.
Looking through the profiling results I found:
Flat profile of 4.02 secs (390 total ticks): Thread-17
Interpreted + native Method
97.3% 0 + 183 java.net.SocketInputStream.socketRead0
1.1% 2 + 0 java.lang.AbstractStringBuilder.init
0.5% 1 + 0 java.lang.ClassLoader.loadClassInternal
0.5% 1 + 0 java.util.Arrays.copyOf
0.5% 1 + 0 sun.misc.Resource.getBytes
100.0% 5 + 183 Total interpreted
So it looks as though java.net.SocketInputStream.socketRead0 is taking
a lot of time - I think. I'm still new to Java, so not exactly sure
how to read this.
Could this be something wrong with my system configuration? Am I
missing something?
Thanks for any help!!!
--
Avi Flax
Lead Technologist
arc90 | http://arc90.com
--
Avi Flax
Lead Technologist
arc90 | http://arc90.com
Re: Issue when using Guard for POST and GET requests
Patson patson.luk at timesearchinc.com writes:
Hi all. I have started using restlet since last month and am impressed with
the
simplicity it offers.
However, I bumped into a problem with using Guards earlier and could not
figure
out a good way to get around it.
Basically I have one Restlet TestRestlet that handles both GET and POST
requests. However, they have different URI patterns.
For example, GET request would have pattern of /testGet/user/{userId}
and POST request would have pattern of /testPost
Hence if I type http://localhost:8080/testGet/user/ABC, the request would be
mapped to the GET handling of the TestRestlet and it would return, say a
form in
html format and the use can click submit on that form which points to
http://localhost:8080/testPost
I have one single Guard:
Guard testGuard= new TestGuard(getContext()
, ChallengeScheme.HTTP_BASIC
, test Access Control; //my TestGuard class, same as
Guard...
Restlet testRestlet = new TestRestlet(getContext());
testGuard.setNext(testRestlet);
router.attach(/testGet/user/{userId}, testGuard);
router.attach(/testPost, testGuard);
Now, if I access /testGet/user/ABC, it would ask me for authentication (401
response), which is fine. After I input the user name and password, it would
then return the html form which points to /testPost (which is fine too).
Now, if
I submit that form, I would get 401 response again...and the web browser
obviously was confused (keep saying loading) and its stuck.
My expectation is that the server should not give 401 status code the 2nd
time
(since it has already authenticated on the GET request and they are sharing
the
same Guard). The funny part is that if I change the pattern
/testGet/user/{userId} into just /testGet then all goes fine...
I am not sure if its a bug or if its some stupid problem that I made...can
anyone plz gimme some pointers plz?
The Restlet jar I am using is the version 3.1 one. The server is the Simple
server and Simple Framework.
Many thanks in advance!!!
Hi Jerome,
Many thanks for the reply! I have tried to removed the spaces in the
authentication realm name but still no luck. Anyway, I sent you the zipped
project in an e-mail. In order to test it:
1. Unzip and import the project (I am using eclipse)
2. Run the main class RestServer that starts the server
3. Open your browser, key in url http://localhost:8080/testGet/user/123
4. It would prompt u for authentication, simply enter something (doesnt check
anything)
5. enter something in the box and click submit Query
6. you will see in ur console log that another 401 response was issued by the
server, however, the broswer is unable to handle it (keeps loading)
Again, Many thanks for your help!!
Re: problems using gzip encoding
Jerome, Ignore this last questionbasically i has an invalid test case. cheers /jima Jerome Louvel wrote: Hi Jim, I'm not 100% sure I understand what you exactly want to do: * For the encoding/client side, your approach is OK. * For the decoding/server side, you can directly use the request's entity as a APPLICATION_XML representation, for example using req.getEntity().toString(). There is no need to wrap the request entity into a DecodeRepresentation or even an EncodeRepresentation as this is already done by the decoderService. If you want to encoded representation (GZIP), you have to turn off the decoderService on your application. * Note that in the future, we'd like to add a encoderService: http://restlet.tigris.org/issues/show_bug.cgi?id=208 Best regards, Jerome -Message d'origine- De : Jim Alateras [mailto:[EMAIL PROTECTED] Envoyé : mardi 9 octobre 2007 14:51 À : discuss@restlet.tigris.org Objet : Re: problems using gzip encoding Hey Jerome, I want the decoder service enabled. I guess my question is whether i am doing something wrong. On the client I do something like this Representation rep = new EncodeRepresentation(Encoding.GZIP, new StringRepresentation(getXStream().toXML(records), MediaType.APPLICATION_XML)); and on the server side i need to do something like this to retrieve the original StringRepresentation. (EncodeRepresentation)((DecodeRepresentation)entity).getWrappe dRepresentation()).getWrappedRepresentation(); So the StringRepresentation is wrapped inside the EncodeRepresentation which is subsequently wrapped inside a DecodeRepresentation. Can you confirm cheers /jima Jerome Louvel wrote: Hi Jim, The Application.decoderService is already able to automatically decode incoming compressed representations. If you prefer to disable this behavior, just do: myApp.getDecoderService().setEnabled(false); before starting the application. Best, Jerome 2007/10/9, Jim Alateras [EMAIL PROTECTED]: Okay this is my problem. I was assuming that i would get the wrapped representation once it hits my resource by i get the DecodeRepresentation instance instead. Can I configure my Application so that the wrapped representation is sent to my resource class rather than the DecodeRepresentation? cheers /jima Jim Alateras wrote: I am trying use gzip for all my representations and use the tunnel filter, on the application, to automatically decode the body before passing it to the router. This how i encode the rep new EncodeRepresentation(Encoding.GZIP, new StringRepresentation(getXStream().toXML(records), MediaType.APPLICATION_XML)); but i end up getting the following error on the server. java.io.IOException: Not in GZIP format at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:132) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:58) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:68) at com.noelios.restlet.application.DecodeRepresentation.getDecode dStream(DecodeRepresentation.java:138) at com.noelios.restlet.application.DecodeRepresentation.getStream (DecodeRepresentation.java:115) at com.noelios.restlet.application.DecodeRepresentation.getText(D ecodeRepresentation.java:189) at au.com.observant.ringocore.resource.syslog.SyslogsResource.pos t(SyslogsResource.java:103) at org.restlet.resource.Resource.handlePost(Resource.java:479) at org.restlet.Finder.handle(Finder.java:296) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Router.handle(Router.java:444) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:87) at org.restlet.Filter.handle(Filter.java:134) at org.restlet.Filter.doHandle(Filter.java:105) at org.restlet.Filter.handle(Filter.java:134) at com.noelios.restlet.application.ApplicationHelper.handle(Appli cationHelper.java:96) at org.restlet.Application.handle(Application.java:293) at org.restlet.Uniform.handle(Uniform.java:97) at cheers /jima
