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, do
> > we have to calculate the getSize() value or can we allow it
> > to be 0? In my
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
>
>
<>
RE: Re: JDBCClient
Hi John, > I have some concerns about the proposed approach... > > (A) What about results that are quite large? I.e. that take up a lot > of memory or won't fit into memory? One major use case I see for this JDBC connector is to fetch a reasonable amount of data in order to assemble a representation for a client of a Restlet application. This representation might be in XML, HTML, PDF, RTF, ... or any other format that can be generated from an XML source. As for memory, we will rely on streams. When the representation is fully consumed, the stream or channel should be closed, which will transparently release the JDBC connection. The result XML format will use the WebRowSet implementation for now: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/rowset/WebRowSet.html A useful piece, will be the addition of an XsltFilter later in 1.1: http://restlet.tigris.org/issues/show_bug.cgi?id=112 > (B) What about performance? Doing that extra transformation > is costly. There is always the option to use JDBC APIs directly. If you need to built business object from this JDBC data, obviously using a solution like EJB or JPA/Hibernate seems even better. > (C) What about those of use who really don't want to have to bother > with yet still more XML in the system? If people want to keep the current approach (XML request and JdbcResult response) we will preserve it and provide an option to switch between the two types of results (XML or JdbcResult wrapper). > > The main reason of this refactoring is that keeping an open > connection does > > not really comply with a REST approach. > > Yes and no. The purpose, IMHO, is for the service to bridge from a > purely REST to the messiness of things like databases. I think we all agree that this is a bridge more than a pure connector (JDBC doesn't define a standard protocol anyway). Hopefully the approach proposed above will coverage most use cases for this connector. Another road we could explore is the SQL/XML standardization efforts that allow an RDBMS to directly return results as an XML stream, without any intermediary transformation. See: http://restlet.tigris.org/issues/show_bug.cgi?id=7 Also, I'd like to explore the usage of XQuery to access databases in the future: http://restlet.tigris.org/issues/show_bug.cgi?id=8 Finally, we should also investigate the idea of a DatabaseHandler/Connector that will attempt to map as well as possible table rows and columns to a set of resources/representations, using a flexible URI namespace. It would support GET/PUT/DELETE/POST. See initial thoughts here: http://restlet.tigris.org/issues/show_bug.cgi?id=6 Best regards, Jerome
Re: Re: JDBCClient
On 11/23/06, thierry boileau <[EMAIL PROTECTED]> wrote: [...] Good morning, you're right : the current behaviour is bugged. If you want to use the resultSet, the connection need to stay open. This connector has been released a long time ago and has probably been updated without tests. As Jerome said, we are working on some refactorings to the JDBC Client in order to return XML result sets. That is to say, the jdbcHelper will get the resultSet, generate an XML Representation of the resultSet then release the connection, and return the new representation. I have some concerns about the proposed approach... (A) What about results that are quite large? I.e. that take up a lot of memory or won't fit into memory? (B) What about performance? Doing that extra transformation is costly. (C) What about those of use who really don't want to have to bother with yet still more XML in the system? The main reason of this refactoring is that keeping an open connection does not really comply with a REST approach. Yes and no. The purpose, IMHO, is for the service to bridge from a purely REST to the messiness of things like databases. Thanks, John
Re: JDBCClient
Hello Kyrre,
you're right : the current behaviour is bugged. If you want to use the
resultSet, the connection need to stay open.
This connector has been released a long time ago and has probably been
updated without tests.
As Jerome said, we are working on some refactorings to the JDBC Client in
order to return XML result sets.
That is to say, the jdbcHelper will get the resultSet, generate an XML
Representation of the resultSet
then release the connection, and return the new representation.
The main reason of this refactoring is that keeping an open connection does
not really comply with a REST approach.
This refactoring will be done in a few days. So, you can wait for this or
ask for a patch of the current behaviour.
Feel free to tell us your needs.
Best regards,
Thierry Boileau
On 11/23/06, Kyrre Kristiansen <[EMAIL PROTECTED]> wrote:
Hello, again.
I think I might have found the problem. I might have
misread the code completely, but here's what I think
is the case.
In JDBCHelper.handle(), the connection is closed in a
finally-block, before we get a chance to get a hold of
the ResultSet, and hence we get the exception I
mentioned in my previous mail.
Closing the connection for each request seems a bit
strange to me, since it never checks to see if the
connection is pooled. As far as I can see, this will
give you a pool of closed connections, not what we
want.
I think the finally-block should be removed completely
from the handle code, and replaced by some way of
telling the client(helper) that we're done with the
connection, and it can be returned to the pool or
closed.
If you want, I can create a bug report on this.
Regards,
Kyrre
--- Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Kyrre,
>
> You shouldn't directly use the JdbcClientHelper
> class. You should instead
> create a new org.restlet.Client for the protocol
> Protocol.JDBC.
>
> As for the error message, I'm not sure why you are
> getting this. Please try
> to update to beta 20 and create a new bug report if
> this still doesn't work.
>
> BTW, we are working on some refactorings to the JDBC
> Client in order to
> return XML result sets (via WebRowSet):
> http://restlet.tigris.org/issues/show_bug.cgi?id=104
> It should be done in
> the beta 21 release.
>
> Best regards,
> Jerome
>
> > -Message d'origine-
> > De : Kyrre Kristiansen
> [mailto:[EMAIL PROTECTED]
> > Envoyé : lundi 20 novembre 2006 15:46
> > À : discuss@restlet.tigris.org
> > Objet : JDBCClient
> >
> > Hello, all.
> >
> > I'm trying to use the JDBCClient to connect to a
> > database in one of my handlers. I use the
> > JDBCClientHelper to do this, but when I try to get
> the
> > ResultSet from the response, I get an SQL
> exception:
> > "java.sql.SQLException:
> > org.apache.commons.dbcp.DelegatingStatement is
> > closed."
> >
> > Note that I'm still on beta19, I've not had the
> time
> > to upgrade yet, but as far as I can see, nothing
> has
> > been done to the jdbclient stuff since beta19.
> >
> > Here's a snippet of code I'm using:
> >
> >
> > String query = "SELECT id, url from
> feeddescriptions
> > where id = " + id + "";
> > Request request =
> >
>
JdbcClientHelper.create(connectionString,generateRepresentatio
> > n(query));
> > Response respone = new Response(request);
> > helper.handle(request,respone);
> > ObjectRepresentation output =
> > (ObjectRepresentation)respone.getEntity();
> >
> > try {
> > //JdbcResult jdbcResult = getJdbcResult(query);
> > JdbcResult jdbcResult =
> > (JdbcResult)output.getObject();
> > ResultSet result = jdbcResult.getResultSet();
> > if (result.next()) {
> > int dbid = result.getInt("id");
> > String url = result.getString("url");
> > feed = new FeedDescription(dbid,url);
> > }
> > } catch (IOException e) {
> > e.printStackTrace();
> > } catch (SQLException e) {
> > e.printStackTrace();
> > }
> >
> >
> >
> > Can anyone see anything wrong here, or is this a
> bug?
> > Maybe I have to upgrade to get the bug fix?
> >
> > Regards,
> > Kyrre.
> >
> >
> >
> >
>
> > Kyrre Kristiansen
> >
> >
> >
> >
> >
> >
>
___
>
> > All new Yahoo! Mail "The new Interface is stunning
> in its
> > simplicity and ease of use." - PC Magazine
> > http://uk.docs.yahoo.com/nowyoucan.html
>
Kyrre Kristiansen
___
All new Yahoo! Mail "The new Interface is stunning in its simplicity and
ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
Re: Newbie Question
Thanks - all fixed and working ok. Thanks again for your help. Ed. On 21/11/06, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi Ed, Please check the "/lib/README.txt" file in the distribution, it lists all the dependencies. In your case, I forgot to mention that you also need the Simple JAR in the "org.simpleframework_3.1" directory. Best regards, Jerome > -Message d'origine- > De : Ed Sweet [mailto:[EMAIL PROTECTED] > Envoyé : lundi 20 novembre 2006 22:17 > À : discuss@restlet.tigris.org > Objet : Re: Newbie Question > > Hi Jerome, > > Thanks for the reply. > > > Note that you don't need all JARs to run your example, > those should be enough: > > - org.restlet.jar > > - com.noelios.restlet.jar > > - com.noelios.restlet.ext.simple_3.1.jar > > ok, I have these in my classpath and I can compile the code. Now when > I run it I get a NoClassDefFoundError: simple/http/ProtocolHandler > (stack trace below). > > So, I checked the com.noelios.restlet.ext.simple_3.1.jar (where I > assume it should be), and it's not in there. It's not in any of the > other two jar files either. > > Again, this should be a simple problem to fix, right? > > Thanks again, > > Ed. > > [java] Exception in thread "main" java.lang.NoClassDefFoundError: > simple/http/ProtocolHandler > [java] at java.lang.ClassLoader.defineClass1(Native Method) > [java] at > java.lang.ClassLoader.defineClass(ClassLoader.java:620) > [java] at > java.security.SecureClassLoader.defineClass(SecureClassLoader. > java:124) > [java] at > java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > [java] at > java.net.URLClassLoader.access$100(URLClassLoader.java:56) > [java] at > java.net.URLClassLoader$1.run(URLClassLoader.java:195) > [java] at > java.security.AccessController.doPrivileged(Native Method) > [java] at > java.net.URLClassLoader.findClass(URLClassLoader.java:188) > [java] at > java.lang.ClassLoader.loadClass(ClassLoader.java:306) > [java] at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) > [java] at > java.lang.ClassLoader.loadClass(ClassLoader.java:251) > [java] at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > [java] at java.lang.ClassLoader.defineClass1(Native Method) > [java] at > java.lang.ClassLoader.defineClass(ClassLoader.java:620) > [java] at > java.security.SecureClassLoader.defineClass(SecureClassLoader. > java:124) > [java] at > java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > [java] at > java.net.URLClassLoader.access$100(URLClassLoader.java:56) > [java] at > java.net.URLClassLoader$1.run(URLClassLoader.java:195) > [java] at > java.security.AccessController.doPrivileged(Native Method) > [java] at > java.net.URLClassLoader.findClass(URLClassLoader.java:188) > [java] at > java.lang.ClassLoader.loadClass(ClassLoader.java:306) > [java] at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) > [java] at > java.lang.ClassLoader.loadClass(ClassLoader.java:251) > [java] at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > [java] at java.lang.Class.forName0(Native Method) > [java] at java.lang.Class.forName(Class.java:164) > [java] at > com.noelios.restlet.Factory.(Factory.java:189) > [java] at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > [java] at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeCo > nstructorAccessorImpl.java:39) > [java] at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Dele > gatingConstructorAccessorImpl.java:27) > [java] at > java.lang.reflect.Constructor.newInstance(Constructor.java:494) > [java] at java.lang.Class.newInstance0(Class.java:350) > [java] at java.lang.Class.newInstance(Class.java:303) > [java] at > org.restlet.util.Factory.getInstance(Factory.java:152) > [java] at org.restlet.Server.(Server.java:171) > [java] at org.restlet.Server.(Server.java:154) > [java] at org.restlet.Server.(Server.java:129) > [java] at org.restlet.Server.(Server.java:71)
RE: JDBCClient
Hello, again.
I think I might have found the problem. I might have
misread the code completely, but here's what I think
is the case.
In JDBCHelper.handle(), the connection is closed in a
finally-block, before we get a chance to get a hold of
the ResultSet, and hence we get the exception I
mentioned in my previous mail.
Closing the connection for each request seems a bit
strange to me, since it never checks to see if the
connection is pooled. As far as I can see, this will
give you a pool of closed connections, not what we
want.
I think the finally-block should be removed completely
from the handle code, and replaced by some way of
telling the client(helper) that we're done with the
connection, and it can be returned to the pool or
closed.
If you want, I can create a bug report on this.
Regards,
Kyrre
--- Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Kyrre,
>
> You shouldn't directly use the JdbcClientHelper
> class. You should instead
> create a new org.restlet.Client for the protocol
> Protocol.JDBC.
>
> As for the error message, I'm not sure why you are
> getting this. Please try
> to update to beta 20 and create a new bug report if
> this still doesn't work.
>
> BTW, we are working on some refactorings to the JDBC
> Client in order to
> return XML result sets (via WebRowSet):
> http://restlet.tigris.org/issues/show_bug.cgi?id=104
> It should be done in
> the beta 21 release.
>
> Best regards,
> Jerome
>
> > -Message d'origine-
> > De : Kyrre Kristiansen
> [mailto:[EMAIL PROTECTED]
> > Envoyé : lundi 20 novembre 2006 15:46
> > À : discuss@restlet.tigris.org
> > Objet : JDBCClient
> >
> > Hello, all.
> >
> > I'm trying to use the JDBCClient to connect to a
> > database in one of my handlers. I use the
> > JDBCClientHelper to do this, but when I try to get
> the
> > ResultSet from the response, I get an SQL
> exception:
> > "java.sql.SQLException:
> > org.apache.commons.dbcp.DelegatingStatement is
> > closed."
> >
> > Note that I'm still on beta19, I've not had the
> time
> > to upgrade yet, but as far as I can see, nothing
> has
> > been done to the jdbclient stuff since beta19.
> >
> > Here's a snippet of code I'm using:
> >
> >
> > String query = "SELECT id, url from
> feeddescriptions
> > where id = " + id + "";
> > Request request =
> >
>
JdbcClientHelper.create(connectionString,generateRepresentatio
> > n(query));
> > Response respone = new Response(request);
> > helper.handle(request,respone);
> > ObjectRepresentation output =
> > (ObjectRepresentation)respone.getEntity();
> >
> > try {
> > //JdbcResult jdbcResult = getJdbcResult(query);
> > JdbcResult jdbcResult =
> > (JdbcResult)output.getObject();
> > ResultSet result = jdbcResult.getResultSet();
> > if (result.next()) {
> > int dbid = result.getInt("id");
> > String url = result.getString("url");
> > feed = new FeedDescription(dbid,url);
> > }
> > } catch (IOException e) {
> > e.printStackTrace();
> > } catch (SQLException e) {
> > e.printStackTrace();
> > }
> >
> >
> >
> > Can anyone see anything wrong here, or is this a
> bug?
> > Maybe I have to upgrade to get the bug fix?
> >
> > Regards,
> > Kyrre.
> >
> >
> >
> >
>
> > Kyrre Kristiansen
> >
> >
> >
> >
> >
> >
>
___
>
> > All new Yahoo! Mail "The new Interface is stunning
> in its
> > simplicity and ease of use." - PC Magazine
> > http://uk.docs.yahoo.com/nowyoucan.html
>
Kyrre Kristiansen
___
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease
of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
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
>
>
