RE: Re: Using Tunneling Service and tunneling filter
Shoukry, If you are building with OpenLaszlo, then that is correct, it will only send the query string as values in the request body. There are two solutions: Either set a request header and build your own HTTP Header Tunnel Filter and look for a specific method. You can look at the base Tunnel class to see how to actually reset the method. or Put a value in the request body (query string) that you inspect and set the method on the request. However, this means that you will have to parse the data in your filter. Hope that helps, Mitch From: shoukri kattan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 9:08 AM To: discuss@restlet.tigris.org Subject: Re: Using Tunneling Service and tunneling filter Hi Thierry I have discovered why tunneling does not work for me. I am using a client that does not support passing a query string with POSTS , instead every parameter i specify in the query string is sent in the request body. I dont think the restlet supports that right ? Thanks Shoukry - Original Message - From: Thierry Boileau [EMAIL PROTECTED] To: discuss@restlet.tigris.org Sent: Tuesday, July 22, 2008 3:29:17 PM (GMT+0200) Auto-Detected Subject: Re: Using Tunneling Service and tunneling filter Hello shoukri kattan, trying to send method=PUT doesnt invoke handlePut but handleGet The tunnelFilter relies only on query parameters not on the entity sent via the POST request. That is to say, the requested resource URI should be more or less: http://myserver/path/to/my/resource?method=put This point is written in the javadocs of the TunnelService class, but should be clearly precised. best regards, Thierry Boileau [1] http://www.restlet.org/documentation/1.0/faq#19 [2] http://www.restlet.org/documentation/1.0/api/org/restlet/service/TunnelS ervice.html Hi, I have been trying to get the HTTP method tunneling in restlet 1.0 running but i havent been able to do this. The Restlet is configured as follows : Restlet running from Tomcat Servlet container : a Server Servlet mapped to /rest/* An Application defined in web.xml which servers as the root application. Create root method of the application creates a router and attaches a number of resources to it. trying to send method=PUT doesnt invoke handlePut but handleGet Trying to call setTunnelService(new TunnelService(true,true,true)); in the application constructor after calling super constructor has no effect . What am i doing wrong, and how to get tunneling working ? Thank you very much Shoukry Kattan
RE: Send and Parse Attachment using Restlet
Surjendu,
By default, Restlet does not handle the multi-part form request, so you
will need to use some form of multi-part form handling library to do
this. The file upload library that is most commonly used, and the one
used by RestletFileUpload, is the Apache commons-fileupload library.
Make sure the commons-fileupload-1.2.jar file is in your classpath when
you run your application, and Restlet should be able to pick it up.
The RestletFileUpload is just an example of how to do it, you can take a
look at the code and break it down as you see fit.
Mitch
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Surjendu
Sent: Wednesday, April 30, 2008 12:53 AM
To: discuss@restlet.tigris.org
Subject: Send and Parse Attachment using Restlet
Please help me regarding sending a file as an attachment
using Restlet.
I have
written my client code. Please let me know if it's correct.
Client:
FileRepresentation rep = new
FileRepresentation(c:\\input.text,MediaType.TEXT_ALL, 0);
Client client = new Client(Protocol.HTTP); Response response
= client.put(http://localhost:19090/cm/;, rep);
Server:
What would i code in Server. I saw in the forum one
implementation of RestletFileUpload. Do I have to use
RestletFileUpload?
Aren't there any other way?
DiskFileItemFactory factory = new DiskFileItemFactory();
RestletFileUpload upload = new RestletFileUpload(factory); try {
List items = upload.parseRequest(getRequest());
int i = 0;
for (final Iterator it = items.iterator(); it.hasNext(); )
{
FileItem fi = (FileItem)it.next();
File saveTo = new File(c:\\temp\\FileReqReceived + i
+ .txt);
fi.write(saveTo);
i++;
}
}catch(Exception e)
{
e.printstackTrace();
}
I have also seen that I receive a multi-part error.
How to solve this?
Regards
Surjendu
RE: Re: re servlet mapping question
Ted, You do not want to duplicate the servlet mappings with Router URL attachments, as that will only work with double URLs. So in your example your URL would have to be: http://localhost/testServlet/dog/testServlet/dog This is assuming that you are installing your webapp under /ROOT (for Tomcat) or /root (for jetty) There is a level of routing that happens in the servlet container outside of the Restlet engine, and it is determined by either the name of the WAR file or directory in the /webapps directory (again, assuming Tomcat/Jetty). For instance, if your directory structure looks like this: /ServletContainer /webapps /testServlet ... Files for webapp Then your url, with this given web.xml, should REALLY be: http://localhost/testServlet/testServlet/dog/testServlet/dog Because the first /testServlet tells the servlet container to route it to the /testServlet webapp in the /webapps directory. The next /testServlet/dog is your mapping within the web.xml file. The last /testServlet/dog is the Router attachment. A more appropriate mapping would be this: !-- Catch all requests -- servlet-mapping servlet-nameRestletServlet/servlet-name url-pattern/*/url-pattern /servlet-mapping Then you would be able to get to your page using: http://localhost/testServlet/testServlet/dog But, if you just want dog, then you should attach the Router like this: router.attach(/dog,HelloWorldResource.class); Then you could go to: http://localhost/testServlet/dog Again, this is because the servlet container will do an initial routing of the context name based on the webapps you have installed. The Restlet engine works within this context, so Router does not use the initial context (which is testServlet) to map its URLs. As for worries about other servlets, because the Servlet container is routing initially based on context, all other webapps will take precedence. But, this is only a consideration if you install your servlet into the ROOT context. However, the servlet container will still look for installed contexts first before routing the request to the ROOT context. Hope that helps. Also, you may want to check to see if you are getting into the Restlet engine itself. Are you getting a 404 error from your servlet engine, or from the Restlet engine. They will produce different looking pages (unless you are using IE7, in which case the page will be hidden and you will see a generic 404 error displayed by IE itself). Mitch -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of TA Sent: Friday, February 29, 2008 10:28 AM To: discuss@restlet.tigris.org Subject: Re: re servlet mapping question Apologies for starting a new post on an existing thread but everytime I try and follow up I get a top posting error. Here is the thread on the issue Rhett, Thanks for the reply. I tried mapping to something specific and it still does not work, 404 error. I set up a route like so router.attach(/testServlet/dog,HelloWorldResource.class); and set up a mapping in the web.xml like so servlet-mapping servlet-nameRestletServlet/servlet-name url-pattern/testServlet/dog/url-pattern /servlet-mapping I tried the URLs /testServlet/dog and also /testServlet/testServlet/dog and no luck. The only way it appears to work is if attachDefault is used with a url-pattern of /* Does anyone have an example of a route and url-pattern that they know works on their setup? Ted Hi Ted, What Stephan was pointing out is that that _won't_ happen because the container will continue to route requests to the other servlets -- even if your restlet servlet wanted to handle the other requests, it won't ever see them. I'm not sure, but if I had to guess I'd suggest that your problem is that your servlet was mapped to /testServlet/* and you were trying to request /testServlet. The containers I've used (okay, just Tomcat) are very literal minded. Try requesting /testServlet/ or /testServlet/ somethingElse. Rhett Helo TA, try to request /testServlet/testServlet/*, because you give the testServlet double: one times in the web.xml and one times while attaching to the router. I think, you should remove the testServlet from the attach method. best regards Stephan New user and I'm playing around with the firstStepsApplication using it in a tomcat web container. I'm trying to play with the routing. Instead of Router router = new Router(getContext()); router.attachDefault(HelloWorldResource.class); I'm trying to do router.attach(/testServlet,HelloWorldResource.class); and correspondingly, I've changed the entry in web.xml from servlet-mapping servlet-nameRestletServlet/servlet-name url-pattern/*/url-pattern /servlet-mapping to url-pattern/testServlet/*/url-pattern and I can't get it to work, keep getting
RE: Problems extracting a POST request's entity
If you read the stream from the representation, or call getText(), then the stream will be consumed and there will be no more data to read. This is also true if you debug a POST on the server side, and call getText(). Your debugger will consume the stream and no more data will be available to the handlePost() method. Only grab the data from the Representation once. If you need to debug, then read it into a temporary variable prior to parsing it, then you can inspect the temp variable without losing the data. Mitch -Original Message- From: Sergio Saugar [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 2:30 PM To: discuss@restlet.tigris.org Subject: Problems extracting a POST request's entity Hi all, I'm developing a web-based middleware (the software of my PhD) and I'm trying to use RESTLET. I create a server (and a client) and some restlets to implement the execution dynamics of my software. I'm using XML for the representation of the resources (using JAXB). Well, I tried to implement a GET method and it works, it returns a response with a XML entity on it. But now I'm programming a POST method and I have a problem. I create a request with a XML string as an entity and it seems to be ok (I'm using a StringRepresentation) for this purpose. The code that I use is one of the following: Representation rep = new StringRepresentation(xmlString, MediaType.TEXT_XML); I debug the request and it seems to be well formed. But, when I try to get back the XML string on the handlePost method, I allways obtain a null value. How could I extract the XML String from a request's entity??? (i try to do it using an InputStreamReader but the result is the same) I would appreciate some help regarding this, it takes me two days!! :-) P.D.- Please forgive my poor english :-) -- Sergio Saugar García Área de Ciencias de la Computación e Inteligencia Artificial Departamento de Ciencias de la Computación Edificio Departamental II - Despacho 053 Escuela Técnica Superior de Ingeniería Informática Universidad Rey Juan Carlos Móstoles (MADRID) Clave PGP: http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xADFA3433
RE: Re: How to get request running realpath just like what does in servlet api?
With that being said, there is a way to get to it but it makes your application have a hard dependency on the Servlet adapter provided by Restlet. final Context context = ...; final ServletContextAdapter servletContextAdapter = (ServletContextAdapter) context; final ServletContext servletContext = servletContextAdapter.getServletContext(); final String realPath = servletContext.getRealPath(realPath); But, I agree with Rob, this makes the application less flexible with your deployment options. Mitch From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 8:12 AM To: discuss@restlet.tigris.org Subject: Re: How to get request running realpath just like what does in servlet api? I don't think there can be a Restlet equivalent, since there is no single filesystem root corresponding to a Servlet WAR's deployment directory. In the Servlet world the use of getRealPath() is frequently bad practice anyway, because many containers don't have to extract WARs. On 2/13/08, cleverpig [EMAIL PROTECTED] wrote: How to get request running realpath just like what does in servlet api? In Servlet api,there is a method:request.getRealPath().it can return request's realpath. How to do that in restlet in order to access LocalFile?
Re: Restful Login/Identifier
Thanks Rob for the clarification, it seems the URL/query parameters are
encrypted before any data is sent.
Mitch
-Original Message-
From: Peter Lacey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 3:13 PM
To: discuss@restlet.tigris.org
Subject: Re: Restful Login/Identifier
Googling... Googling... Rob's right. The URL will not be
visible if SSL is in use. His latter point is valid though.
So my second suggestion is currently feeling better.
Pete
Rob Heittman wrote:
No, SSL operates at the transport layer. It is not
sniffable in transit.
One highly undesirable feature, though, is that it will be
recorded in
logfiles, which are generally not treated with care.
- Original Message -
From: Mitch Stewart [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Tuesday, October 2, 2007 3:02:49 PM (GMT-0500)
America/New_York
Subject: RE: Re: Restful Login/Identifier
If you place the password inside the URL as a parameter,
won't that be
sniffable because the URL contents are not encrypted via
SSL, only
the payload of the request? I think that's why Basic Authentication
sends the data inside the body of the POST as opposed to parameters
within a URL.
Mitch
-Original Message-
From: Peter Lacey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 2:55 PM
To: discuss@restlet.tigris.org
Subject: Re: Restful Login/Identifier
I have only just started mussing over the very same idea. In my
thinking the URLs would be much more readable. The core user
resource would be something like
http://example.com/users/{uname}
To use this for authentication purposes, an application would
receive credentials from the user, and GET a URL like the
following
from the RESTful authentication service:
https://example.com/users/{uname},{passwd} (note the use
of SSL).
That could return the same resource as the previous URL, but more
usefully could return, say, a SAML token appropriate for
the asking
application.
Of course, one should not just assume that the proposed
URI scheme
will last forever, so a better solution is for a client to first
request a form (from a cool URL), e.g.,
http://example.com/authentication_form.
That form will contain the necessary fields to populate and
(assuming it's an HTML form) will allow you to construct a URL.
However, in this case the URL would end up looking something like
this:
https://example.com/users?uname=placeypasswd=sekrit.
Which isn't
as pretty as the other version, but serves the same
purpose and uses
a standard recipe for link construction.
Pete
JC wrote:
I am trying to develop a Restful login system. Using a web
service I
want to identify a user based on their user name and
password, but I
am not sure the best (Restful) approach.
I would like to avoid the RPC approach of calling an
authenticate
method, passing in a user name and password.
The best (Restful) solution I have come up w/ so far is to have
the URL HTTPS://www.example.com/user/{user}. The {user}
placeholder would
be the MD5 value of the concatenated string of user
name + password.
Ex.
User name: MyName
Password: MyPassword
{user} = MD5(MyName+MyPassword)
If the user is found return a XML representation of the
user, if not
return a
404 error.
Thoughts, comments, suggestions?
RE: Xeerkat XMPP Restlet
Alex, I found your site from the restlet.org site and I am definitely interested in this API. Does your implementation support XMPP over HTTP? We have considered using XMPP for getting access to behind the firewall services as well...but there are cases where even normal outbound ports besides port 80 or 443 are blocked. Mitch -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Milowski Sent: Saturday, August 25, 2007 10:39 AM To: discuss@restlet.tigris.org Subject: Xeerkat XMPP Restlet I've finished integrating restlet XMPP for my P2P computing work. You can now access restlets through XMPP. That means you can just write normal REST-style applications and access them over XMPP. My current motivation for this (besides grid computing) is to access services that are behind firewalls. The service can make a outbound connection to its XMPP server and that you can communicate with it over XMPP. The project alpha release is at: http://code.google.com/p/xeerkat/ Also, if you just want to use the XMPP transport, you can use the the xeerkat and sxeerkat protocols in your own application. The restlet-xmpp.jar file from the restlet-xmpp subproject provides client and server connectors. You'll need several support jar files for the XMPP client code and XML support. Anyway, having the restlet API has greatly simplified this P2P computing framework in that all you have to do is write a restlet Application instance and you can write simple edge services. If you want to coordinate between peers, you need to do a little more work inside that application but it isn't rocket science like it was before. --Alex Milowski
RE: RE: Xeerkat XMPP Restlet
I'm going to answer my own question after fully reading your website. It DOES support XMPP over HTTP. :) This looks great, I'll have to play with it. Thanks! Mitch -Original Message- From: Mitch Stewart [mailto:[EMAIL PROTECTED] Sent: Saturday, August 25, 2007 2:30 PM To: discuss@restlet.tigris.org Subject: RE: Xeerkat XMPP Restlet Alex, I found your site from the restlet.org site and I am definitely interested in this API. Does your implementation support XMPP over HTTP? We have considered using XMPP for getting access to behind the firewall services as well...but there are cases where even normal outbound ports besides port 80 or 443 are blocked. Mitch -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Milowski Sent: Saturday, August 25, 2007 10:39 AM To: discuss@restlet.tigris.org Subject: Xeerkat XMPP Restlet I've finished integrating restlet XMPP for my P2P computing work. You can now access restlets through XMPP. That means you can just write normal REST-style applications and access them over XMPP. My current motivation for this (besides grid computing) is to access services that are behind firewalls. The service can make a outbound connection to its XMPP server and that you can communicate with it over XMPP. The project alpha release is at: http://code.google.com/p/xeerkat/ Also, if you just want to use the XMPP transport, you can use the the xeerkat and sxeerkat protocols in your own application. The restlet-xmpp.jar file from the restlet-xmpp subproject provides client and server connectors. You'll need several support jar files for the XMPP client code and XML support. Anyway, having the restlet API has greatly simplified this P2P computing framework in that all you have to do is write a restlet Application instance and you can write simple edge services. If you want to coordinate between peers, you need to do a little more work inside that application but it isn't rocket science like it was before. --Alex Milowski
RE: Re: get and send Cookie not working....
Regis,
We've used the cookie feature in both Jetty and Tomcat (version 5.5.23).
While testing, we found that if the cookie information was not set
correctly, then the cookies would not be sent back to the server because
of browser security implementations. Here are some things which
prevented us from getting cookies...and we subsequently had to set them
when we created the cookie:
1. The cookie Path attribute wasn't set correctly, or wasn't set at all.
If this is not set, then the cookie will not be returned on subsequent
requests because the paths do not match. When we created client-side
cookies with javascript, we noticed that no Path attribute was set. Once
we did that it worked. You can set it to a specific relative path within
your URL structure..or you can set it to / for all URLs going to your
restlet code.
2. The cookie Domain attribute wasn't set correctly, or wasn't set at
all. This might not be the problem you are encountering, but if you try
to access data across subdomains from your browser it won't pass the
cookies around unless the domain is set to .mydomain.com where
mydomain.com is your base domain. Notice the dot . in front of the
domain name.
Also...have you tried to debug your restlet app and inspect the Request
object coming in? You can drill down into the actual headers that are
coming from your client to see if the Cookie header is even set with the
appropriate values..
Mitch
From: Regis Leray [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 3:34 PM
To: discuss@restlet.tigris.org
Subject: Re: get and send Cookie not working
I did what you said i download the extensions for firefox, so it seems
the restlet filter send back a cookie to my browser. I m not at my
office desk so i cannot show you the message, but i will on monday, but
the cookie it is send.
Could you tell me if some issue exist with firefox or IE ??
I said a mistake, i can't get any cookie from the request
(request.getCookies()) but the function doesn't return a null list but a
empty list, even i have some cookies which exists
I will post the reponse on monday the reponse i get with http header
extension...
Somebody test the cookie feature in a tomcat container ??? (developper ,
user )
Thanks for the reply.
Regis
2007/8/17, Alex Milowski [EMAIL PROTECTED]:
On 8/17/07, Regis Leray [EMAIL PROTECTED] wrote:
private Cookie hasCookie(Request request) {
ListCookie cookies = request.getCookies (); //always
NULL
The getCookies() call should not return a null value.
snip/
About my environment all of this it is run in a tomcat
container, and i use
the restlet version 1.0.4.
There could be an environment issue. Have you tried running
your application
outside of Tomcat using the Simple or Jetty connectors?
Have you checked the return headers using the LiveHttpHeaders
[1] or
my Poster [2]
extension for Firefox to see if the Set-Cookie header is there?
[1] https://addons.mozilla.org/en-US/firefox/addon/3829
[2] https://addons.mozilla.org/en-US/firefox/addon/2691
--Alex Milowski
--
Regis LERAY
1214, rue Bishop
Canada, Montreal (Qc) H3G 2E3
Cel: (514) 699 1000
RE: Re: Re: get and send Cookie not working....
You have it now, the browser will only send cookies back that match the domain you are requesting. You will not need to set domain/path if you are creating cookies in the restlet code as long as you hit the right domain in the browser. Mitch but if you try with http://127.0.0.1:8080/restlet/test (you can get the cookie) or with a default domain name define in you WINDOWS/system32/drivers/etc/host ( test.domain.com) http://test.domain.com:8080/restlet/test You can get the cookie in your browser. And the second time when i hit my application, i can get the cookie in my filter ! I said another mistake, i thought i will get all my cookies of my browser. But NOT, it is a security issue, so it was normal, i didn't get the others cookies. Now when i get my cookie, i just have in the object the name the value, not the domain and the path (but i think that is a default behavior). Tell me if it is not true. Thanks a lot. Bye regis.
JSON jar and Maven POM
I just wanted to clarify something with the new Maven POM files. In the org.restlet.ext.json_2.0.pom file, there are no dependencies, but it looks like it should include the org.json.jar file. If you intend on using JSON + Restlet + Maven2 you will probably have to install the org.json.jar file into a local repository and add a dependency to the org.restlet.ext.json_2.0.pom file before you load it into your local repository. I don't know if this should be documented anywhere...maybe a comment in the pom file itself? Thank you to the Restlet team for providing these files! Mitch
RE: Restlet 1.0 RC2 released
Hi Ryan, I think this was attempted awhile ago, Jerome actually tried to move the entire build process to Maven2 but I don't think it fit well and he ended up reverting back to Ant. I use Maven2 myself, so whenever a new release comes out I just have a series of basic poms that I edit and deploy using a simple script. It's hacky but it works. I'm sure at some point in the future when the dust settles a bit (and 1.0 is finally released) then maybe we can get restlet uploaded to the various Maven2 repositories out there. However, I think it might be worthwhile to post some POMs to the mailing list...even if the project isn't built using Maven2, then maybe the POMs can be included in the source distribution and modified as part of the release process to include the appropriate version numbers. That way the POMs are standard... Mitch From: Ryan Daum [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 10:38 AM To: discuss@restlet.tigris.org Subject: Re: Restlet 1.0 RC2 released Hey, great, new release (downloading)! I'm sure I'm not the first to mention it, but have you considered either switching your build to use Maven 2 or else at least providing Maven 2 friendly jars and POMs? I ask this because I had to generate my own (not very good ones) in our local repository, and now I'm going to have to update again... It might be something to consider for the full 1.0 release, to encourage wider adoption... BTW, are there any pieces of documentation on the representation resource portions of the library? All the tutorials I saw got as far as the registration of handlers, but didn't really describe common RESTy-patterns for the representation of resources using the library. Anyways, great work, looking forward to trying RC2. Ryan On 1/9/07, Jerome Louvel [EMAIL PROTECTED] wrote: Hi all, Here is the second release candidate! Compared to RC1, it has many API refinements but no major breaking change, which is a good sign :-) Everyone is encouraged to upgrade and test as much as possible. Summary of main changes: - New Windows installer (contributed by Thierry Boileau) - Added XmlRepresentation class providing XPath support for DOM and SAX representations - Added Message.getEntityAsSax() and getEntityAsDom() methods - Extracted Variant super class from Representation, with metadata properties only - Added Resource.getRepresentation(Variant) method - Updated Jetty connector to use final 6.1 release Thank to the direct contributors: - Chris Battey - Dave Pawson - Randy Layman - Ryan Daum - Sean Landis - Sumit Lohia - Thierry Boileau Changes log: http://www.restlet.org/docs/changes Download links: http://www.restlet.org/downloads/restlet-1.0rc2.exe (NEW!) http://www.restlet.org/downloads/restlet-1.0rc2.zip Best regards, Jerome Louvel -- http://www.restlet.org
RE: RE: POSTing dynamic Representations
Jerome,
I downloaded the latest from Subversion after seeing that you made the fix and
it all works.
Thanks for the quick response!
Mitch
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Friday, November 24, 2006 1:50 AM
To: discuss@restlet.tigris.org
Subject: RE: RE: POSTing dynamic Representations
Hi Mitch,
My turn to have a Aha! moment ;-) It's a rather major bug that you found here.
I will fix it today and release a new snapshot.
Best regards,
Jerome
-Message d'origine-
De : Mitch Stewart [mailto:[EMAIL PROTECTED] Envoyé : vendredi
24 novembre 2006 03:44 À : discuss@restlet.tigris.org Objet : RE: RE:
POSTing dynamic Representations
Jerome,
Thank you for the response...I thought I had an Aha! moment there. :)
I've changed my Representation to set the size to
Representation.UNKNOWN_SIZE, however, I still think I am having a
problem. I think the problem lies in the
Message.isEntityAvailable() method, shown here:
public boolean isEntityAvailable()
{
return (getEntity() != null) (getEntity().getSize() 0)
getEntity().isAvailable();
}
The entity is my Representation class which returns a -1 size, however
it is still checking to see if the size of the entity is greater than
0, not != to 0. This then returns false, and the calling method,
which is
HttpClientCall.sendRequest() still determines that the Representation
entity is null and doesn't send the data.
Thanks,
Mitch
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Thu 11/23/2006 3:32 AM
To: discuss@restlet.tigris.org
Subject: RE: POSTing dynamic Representations
Hi Mitch,
You got nearly everything right. The only thing that you missed is
that when the size of a Representation is unknown, you need to set it
to -1 (using the Representation.UNKNOWN_SIZE constant). Setting the
size to 0 means that there is no content in the representation which
is not true in your case.
Best regards,
Jerome
-Message d'origine-
De : Mitch Stewart [mailto:[EMAIL PROTECTED] Envoyé :
mercredi 22 novembre 2006 22:19 À : discuss@restlet.tigris.org Objet
: POSTing dynamic Representations
I'm using the Restlet HTTP client implementation to post a dynamic
Representation to my Restlet server implementation, however it
doesn't look like my data is getting written to the HTTP stream. I
might be missing something critical, but I've been able to
understand the API so far. :) My Representation class resembles the
ObjectRepresentation that already exists, except instead of
serializing a Java object to an ObjectOutputStream, it serializes a
Java object to an XML stream. But, testing with the
ObjectRepresentation produces the same result.
Here's the basics of what I am trying to do:
Client client = new Client(Protocol.HTTP);
Response response =
client.post(http://somehost.com/someurl;, new
ObjectRepresentation(TestData));
The response variable is not filled with any status or response.
Drilling down through the code I think I found the culprit:
in com.noelios.restlet.http.HttpClientCall.sendRequest()
there's a check to see if an entity exists:
Representation entity = request.isEntityAvailable() ?
request.getEntity() : null;
if(entity != null)
{
//The code to write the representation to the output stream.
}
The call to request.isEntityAvailable() goes back to the
org.restlet.data.Message class which checks that the entity is not
null and that the size of the entity is greater than 0. This is
where I'm having difficulty. In my Representation, I do not know the
size of the resulting data prior to it being written to the output
stream, so my size is 0. However, if you look at the
com.noelios.restlet.ext.net.HttpUrlConnectionCall.sendRequest(
) method, you see this:
// Adjust the streaming mode
if (entity.getSize() 0)
{
// The size of the entity is known in advance
getConnection().setFixedLengthStreamingMode((int)
entity.getSize());
}
else
{
// The size of the entity is not known in advance
if (this.clientHelper.getChunkLength() = 0)
{
// Use chunked encoding
getConnection().setChunkedStreamingMode(
this.clientHelper.getChunkLength());
}
else
{
// Use entity buffering to determine the content length
}
}
This suggests that the data I am sending can have a size of 0, but
when it does it is never sent. And I can't guess a size, because
if I guess wrong then the setFixedLengthStreamingMode will cause the
HTTP Post to fail when more bytes are written than expected.
I guess my question is: When we subclass Representation
RE: RE: POSTing dynamic Representations
Jerome,
Thank you for the response...I thought I had an Aha! moment there. :)
I've changed my Representation to set the size to Representation.UNKNOWN_SIZE,
however, I still think I am having a problem. I think the problem lies in the
Message.isEntityAvailable() method, shown here:
public boolean isEntityAvailable()
{
return (getEntity() != null) (getEntity().getSize() 0)
getEntity().isAvailable();
}
The entity is my Representation class which returns a -1 size, however it is
still checking to see if the size of the entity is greater than 0, not != to
0. This then returns false, and the calling method, which is
HttpClientCall.sendRequest() still determines that the Representation entity is
null and doesn't send the data.
Thanks,
Mitch
-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED]
Sent: Thu 11/23/2006 3:32 AM
To: discuss@restlet.tigris.org
Subject: RE: POSTing dynamic Representations
Hi Mitch,
You got nearly everything right. The only thing that you missed is that when
the size of a Representation is unknown, you need to set it to -1 (using the
Representation.UNKNOWN_SIZE constant). Setting the size to 0 means that
there is no content in the representation which is not true in your case.
Best regards,
Jerome
-Message d'origine-
De : Mitch Stewart [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 22 novembre 2006 22:19
À : discuss@restlet.tigris.org
Objet : POSTing dynamic Representations
I'm using the Restlet HTTP client implementation to post a
dynamic Representation to my Restlet server implementation,
however it doesn't look like my data is getting written to
the HTTP stream. I might be missing something critical, but
I've been able to understand the API so far. :) My
Representation class resembles the ObjectRepresentation that
already exists, except instead of serializing a Java object
to an ObjectOutputStream, it serializes a Java object to an
XML stream. But, testing with the ObjectRepresentation
produces the same result.
Here's the basics of what I am trying to do:
Client client = new Client(Protocol.HTTP);
Response response =
client.post(http://somehost.com/someurl;, new
ObjectRepresentation(TestData));
The response variable is not filled with any status or response.
Drilling down through the code I think I found the culprit:
in com.noelios.restlet.http.HttpClientCall.sendRequest()
there's a check to see if an entity exists:
Representation entity = request.isEntityAvailable() ?
request.getEntity() : null;
if(entity != null)
{
//The code to write the representation to the output stream.
}
The call to request.isEntityAvailable() goes back to the
org.restlet.data.Message class which checks that the entity
is not null and that the size of the entity is greater than
0. This is where I'm having difficulty. In my Representation,
I do not know the size of the resulting data prior to it
being written to the output stream, so my size is 0. However,
if you look at the
com.noelios.restlet.ext.net.HttpUrlConnectionCall.sendRequest(
) method, you see this:
// Adjust the streaming mode
if (entity.getSize() 0)
{
// The size of the entity is known in advance
getConnection().setFixedLengthStreamingMode((int)
entity.getSize());
}
else
{
// The size of the entity is not known in advance
if (this.clientHelper.getChunkLength() = 0)
{
// Use chunked encoding
getConnection().setChunkedStreamingMode(
this.clientHelper.getChunkLength());
}
else
{
// Use entity buffering to determine the content length
}
}
This suggests that the data I am sending can have a size of
0, but when it does it is never sent. And I can't guess a
size, because if I guess wrong then the
setFixedLengthStreamingMode will cause the HTTP Post to fail
when more bytes are written than expected.
I guess my question is: When we subclass Representation, do
we have to calculate the getSize() value or can we allow it
to be 0? In my case, I don't really want to serialize my Java
object until absolutely necessary, and I also don't want to
hold the serialized form of the object in memory prior to POSTing it.
Am I missing something? Maybe it's not supposed to work this way.
Mitch
winmail.dat
POSTing dynamic Representations
I'm using the Restlet HTTP client implementation to post a dynamic
Representation to my Restlet server implementation, however it doesn't look
like my data is getting written to the HTTP stream. I might be missing
something critical, but I've been able to understand the API so far. :) My
Representation class resembles the ObjectRepresentation that already exists,
except instead of serializing a Java object to an ObjectOutputStream, it
serializes a Java object to an XML stream. But, testing with the
ObjectRepresentation produces the same result.
Here's the basics of what I am trying to do:
Client client = new Client(Protocol.HTTP);
Response response = client.post(http://somehost.com/someurl;, new
ObjectRepresentation(TestData));
The response variable is not filled with any status or response.
Drilling down through the code I think I found the culprit:
in com.noelios.restlet.http.HttpClientCall.sendRequest() there's a check to see
if an entity exists:
Representation entity = request.isEntityAvailable() ? request.getEntity() :
null;
if(entity != null)
{
//The code to write the representation to the output stream.
}
The call to request.isEntityAvailable() goes back to the
org.restlet.data.Message class which checks that the entity is not null and
that the size of the entity is greater than 0. This is where I'm having
difficulty. In my Representation, I do not know the size of the resulting data
prior to it being written to the output stream, so my size is 0. However, if
you look at the com.noelios.restlet.ext.net.HttpUrlConnectionCall.sendRequest()
method, you see this:
// Adjust the streaming mode
if (entity.getSize() 0)
{
// The size of the entity is known in advance
getConnection().setFixedLengthStreamingMode((int) entity.getSize());
}
else
{
// The size of the entity is not known in advance
if (this.clientHelper.getChunkLength() = 0)
{
// Use chunked encoding
getConnection().setChunkedStreamingMode(
this.clientHelper.getChunkLength());
}
else
{
// Use entity buffering to determine the content length
}
}
This suggests that the data I am sending can have a size of 0, but when it does
it is never sent. And I can't guess a size, because if I guess wrong then the
setFixedLengthStreamingMode will cause the HTTP Post to fail when more bytes
are written than expected.
I guess my question is: When we subclass Representation, do we have to
calculate the getSize() value or can we allow it to be 0? In my case, I don't
really want to serialize my Java object until absolutely necessary, and I also
don't want to hold the serialized form of the object in memory prior to POSTing
it.
Am I missing something? Maybe it's not supposed to work this way.
Mitch
