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:
snip
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();
}
/snip
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.init(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.init(Server.java:171) [java] at org.restlet.Server.init(Server.java:154) [java] at org.restlet.Server.init(Server.java:129) [java] at org.restlet.Server.init(Server.java:71)
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:
snip
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();
}
/snip
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: 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: 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
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 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
