Re: Resource factories
Hello, again.
Tim, thanks for the guice-restlet link, I will for sure check it out.
As for Jerome's question, I'd like to elaborate a bit.
I'm using Restlet mostly to set up quick examples and proof-of-concept
solutions. I'm trying to convince a few people in the company I work that doing
web systems more RESTfull will make the system simpler, and much easier to
integrate with than a lot of the traditional systems, where the
RPC/SOAP/CORBA train of thought seems to dominate. I have made the decision to
try to keep the number of dependencies for my apps as small as possible,
everything I'm using is supplied in the restlet distribution. I know that's not
the real goal of restlet, but it is truly a testament to the power of the
framework.
As the codebase has grown, I've realized that I'm making the following
classes of resources:
- Single - describing one, single instance of a simple object (everything can
be represented in one web page or XML document, or whatever representation)
- List - describing a list of resources, represented as a single web page or
XML document with links to each child resource.
- Hierarchical - describing a resource that is a child of a given resource.
This is usually mapped in a router as parents/{parentId}/children/{childId}
where you can replace parent and child with the name of your resources. You
can, of course, have several levels of parent/child relationships, and my hope
is that this could be chained in some way.
What lead me down the way of using generics was that I felt that I kept
repeating myself, creating resources that were the same except from the type of
objects I was representing. As I mentioned earlier, I've had limited success
with the single and list resources, but never really got anywhere with the
hierarchical resources, especially in the case where you need more than two
levels. Just for the record, using generics is not an absolute must. Maybe an
annotations-based system would be more suitable, but I haven't got around to
trying any of that out.
What I think would be extremely useful is to be able to create the most common
resources easily using some handy classes and a few lines of code, and still be
able to fall back on raw resources when I need to.
If I get the time (which there always seems to little of), I'll try to work my
code into something more suitable for the general audience and post it
somewhere so that people can have a look and maybe come with some ideas of how
to make it better.
Regards,
Kyrre
Kyrre Kristiansen
--- On Wed, 8/4/09, Tim Peierls t...@peierls.net wrote:
From: Tim Peierls t...@peierls.net
Subject: Re: Resource factories
To: discuss@restlet.tigris.org
Date: Wednesday, 8 April, 2009, 3:26 PM
On Tue, Apr 7,
2009 at 10:28 AM, Kyrre Kristiansen kyrre_kristian...@yahoo.co.uk
wrote:
This resulted in using Generics on my resources, where I
created a class, ListResourceT extends Referrable
(where Referrable is an interface, with one method, getId()
). ... a concrete class that relies solely on one object,
the config, and that works with any resource that represents
a Referrable subtype and is a top-level list
resource.
This, however, is where my trouble starts. Because at
run-time, the system cannot differentiate between a
ListResourceFoo.class and a
ListResourceBar.class due to type erasure. At the
moment I have to subclass ListResource for each type I am
using it for, but hopefully making a parametrized Finder
class that can then be attached to a Router, will solve my
troubles. Has anyone tried this?
You can get this for free with the Guice-Restlet
integration work described here:
http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html
You'd write something like this in your
Restlet wiring code:
router.attach(/foo/{id},
finderFor(new
TypeLiteralListResourceFoo(){})); // curly
braces required!
router.attach(/bar/{id},
finderFor(new
TypeLiteralListResourceBar(){}));
router.attach(/baz/{id}, finderFor(new
TypeLiteralListResourceBaz(){}));
where finderFor would be defined
like this:
private T Finder
finderFor(TypeLiteralT typeLiteral) {
return
finderFactory.finderFor(Key.get(typeLiteral));
}
Then in your binding code, you'd create a
binding for each ListResourceX that you wanted to
support. You'd even be able to provide custom
implementations for certain types. For example, if you
needed a special subclass of ListResourceBaz to
handle /baz/{id} -- while Foo and Bar just needed the
standard ListResource -- you could bind it differently in
your binding code, and the
router.attach(/baz/{id}, ...) line would remain
the same.
Of course, this approach assumes Guice, which
might not be an option for you. But the same technique could
eventually be supported directly by Restlet.
--tim
RE: Resource factories
Hello, all. *rant alert* I came over this discussion, and wanted to share my experiences with creating resources. I started playing around with restlet before it became 1.0, and am generally very, very pleased with it. One of the things I use it for is my own prototype environment, where I can throw together some quite impressive applications in a matter of hours.. After creating a whole host of different resource types, I started seeing some quite distinct patterns in my resources, at least the simplest ones. This resulted in using Generics on my resources, where I created a class, ListResourceT extends Referrable (where Referrable is an interface, with one method, getId() ). I already have a generic DAO implementation based on the Referrable interface. In addition, I created a ResourceConfigT extends Referrable that I could pull off all the things I need for the ListResource (including the DAO, that's why it's parametrized), as well as a FormBuilderT extends BaseObject interface for building my objects based on a Form. All this leads to ListResource being a concrete class that relies solely on one object, the config, and that works with any resource that represents a Referrable subtype and is a top-level list resource. This, however, is where my trouble starts. Because at run-time, the system cannot differentiate between a ListResourceFoo.class and a ListResourceBar.class due to type erasure. At the moment I have to subclass ListResource for each type I am using it for, but hopefully making a parametrized Finder class that can then be attached to a Router, will solve my troubles. Has anyonw tried this? I have, BTW, also a solution for SingleResourceT extends Referrable, but this is not used as much as my ListResource, so I didn't describe this. The big, unsolved task is to make the resources and interfaces available for more complex resource hierarchies where you have to check for the existence of a parent resource before you allow creation and modification of a child resource. Twenty or so more resource types under the belt, and I might get there ;-) *end rant* Kyrre Kristiansen --- On Thu, 26/3/09, Jerome Louvel jerome.lou...@noelios.com wrote: From: Jerome Louvel jerome.lou...@noelios.com Subject: RE: Resource factories To: discuss@restlet.tigris.org Date: Thursday, 26 March, 2009, 1:20 PM Hi all, I've just found time to read this thread and enjoyed it very much. It's hard to find the best balance between so much points of views and ways to deal with instantiations, wiring of objects, etc. so it's nice to hear that the current design has more advantages than drawbacks. As Tal mentioned, we are redesigning the Resource API to support client-side resources and focused use of annotations. I didn't intend to change the way resources are instantiated though. But, if we can adjust the new design to accommodate more use cases, I would be interested to explore. Currently, we are working on Restlet 1.2 M2 which will give you a chance to play with the new resource API and provide feed-back. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : jeudi 26 mars 2009 08:49 À : discuss@restlet.tigris.org Objet : Re: Resource factories Thanks to all who replied on this. After a discussion on the code list, it became clear that the Restlety solution to configuring resources is to use the Context. The Context has a ConcurrentMap of attributes, described as so: This is a convenient mean[s] to provide common objects to all the Restlets and Resources composing an Application. So, that's it! The nice thing about contexts, too, is that they pass through restlets along the way. So, even if you configure your Application context in a certain way, you can apply filters or whatnot along the way to adapt the configuration. For example, a DebuggingFilter might enable all the configuration aspects that have to do with debugging. It's then easy to add/remove such a filter, even on-the-fly, without reconfiguring the whole application. -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1577974
Re: Resource factories
Hello Rhett,
That's not at all a bad idea! I keep forgetting about the fact that classes
themselves are generic. I'd still have to make a subclass of finder to add the
extra class parameter to my resource (I really like the idea of creating a
resource per request, mostly for the reasons stated in this thread already).
That, however is not a big deal.
Kyrre Kristiansen
--- On Tue, 7/4/09, Rhett Sutphin rh...@detailedbalance.net wrote:
From: Rhett Sutphin rh...@detailedbalance.net
Subject: Re: Resource factories
To: discuss@restlet.tigris.org
Date: Tuesday, 7 April, 2009, 5:49 PM
Hi Kyrre,
On Apr 7, 2009, at 9:28 AM, Kyrre Kristiansen wrote:
Hello, all.
*rant alert*
I came over this discussion, and wanted to share my
experiences with
creating resources. I started playing around with
restlet before it
became 1.0, and am generally very, very pleased with
it. One of the
things I use it for is my own prototype environment,
where I can
throw together some quite impressive applications in a
matter of
hours..
After creating a whole host of different resource
types, I started
seeing some quite distinct patterns in my resources,
at least the
simplest ones.
This resulted in using Generics on my resources, where
I created a
class, ListResourceT extends Referrable (where
Referrable is an
interface, with one method, getId() ). I already have
a generic DAO
implementation based on the Referrable interface. In
addition, I
created a ResourceConfigT extends Referrable
that I could pull off
all the things I need for the ListResource (including
the DAO,
that's why it's parametrized), as well as a
FormBuilderT extends
BaseObject interface for building my objects based
on a Form. All
this leads to ListResource being a concrete class that
relies solely
on one object, the config, and that works with any
resource that
represents a Referrable subtype and is a top-level
list resource.
This, however, is where my trouble starts. Because at
run-time, the
system cannot differentiate between a
ListResourceFoo.class and a
ListResourceBar.class due to type erasure. At
the moment I have to
subclass ListResource for each type I am using it for,
but hopefully
making a parametrized Finder class that can then be
attached to a
Router, will solve my troubles. Has anyonw tried
this?
This isn't specific to Restlet, but the way I handle this
feature of
generics is to define a method like this:
public abstract class ListResourceT extends
Referrable extends
Resource {
// ...
public abstract ClassT
referrableType();
// ...
}
If you wanted to do it in a way that doesn't require
subclassing, you
could do
public class ListResourceT extends Referrable
extends Resource {
public ListResource(/* whatever
parameters */, ClassT type) {
// ...
this.type = type;
}
public ClassT referrableType() {
return this.type; }
}
Rhett
I have, BTW, also a solution for SingleResourceT
extends
Referrable, but this is not used as much as my
ListResource, so I
didn't describe this.
The big, unsolved task is to make the resources and
interfaces
available for more complex resource hierarchies where
you have to
check for the existence of a parent resource before
you allow
creation and modification of a child resource. Twenty
or so more
resource types under the belt, and I might get there
;-)
*end rant*
Kyrre Kristiansen
--- On Thu, 26/3/09, Jerome Louvel jerome.lou...@noelios.com
wrote:
From: Jerome Louvel jerome.lou...@noelios.com
Subject: RE: Resource factories
To: discuss@restlet.tigris.org
Date: Thursday, 26 March, 2009, 1:20 PM
Hi all,
I've just found time to read this thread and
enjoyed it very much. It's
hard to find the best balance between so much
points of
views and ways to deal
with instantiations, wiring of objects, etc. so
it's nice to hear that
the current
design has more advantages than
drawbacks.
As Tal mentioned, we are redesigning the Resource
API to support
client-side resources and focused use of
annotations. I
didn't intend to change
the way resources are instantiated though. But,
if
we can adjust the new design
to accommodate more use cases, I would be
interested to
explore.
Currently, we are working on Restlet 1.2 M2 which
will give you a chance
to play with the new resource API and provide
feed-back.
Best
regards,
Jerome
Louvel
--
Restlet ~ Founder and Lead developer ~
http://www.restlet.org
Noelios Technologies ~ Co-founder ~
http://www.noelios.com
De : Tal Liron
[mailto:tal.li...@threecrickets.com]
Envoyé : jeudi 26 mars 2009
08:49
À : discuss
Re: Evaluating Restlet
Hello, everyone. I know this is probably the best place for this, but am I the only one that thinks Comet is pushing the limits of HTTP too far (no pun intended)? As far as I can read from the RFC, a client may create a long-lived connection, issue several requests, but the server MUST respond to these requests in the order they're sendt. I'm not trying to give the Comet crew (that's a cool name, btw) a bad name, but I get the feeling that doing this type of things in HTTP/1.1 is against the constraints imposed on the protocol. I'd absolutely love to get callback-type functionality in HTTP, but I'm just bothered by the nagging feeling that it should be done either as a different protocol or a new version of the HTTP protocol, since this type of protocol leverage gives a new set of challenges that should be seriously looked into. After all, a lot of the success of HTTP is in its ability to be simple, but extremely powerful. Just some thoughts I had to get out somewhere... Regards, Kyrre --- Rob Heittman [EMAIL PROTECTED] wrote: The thing I'm working on simply involves an alternative to handle(request,response) that allows the response to be delivered to a callback object, possibly and probably in another thread. This is principally valuable for AJAX style code and critical path for the GWT support I'm working on. To a certain degree, we actually want a model here that looks and feels very familiar to GWT users who have worked with GWT-RPC and would like to try a RESTful alternative. The idea of being able to pin a thread is probably more applicable to the issue of a long-lived request/response cycle (e.g. Comet style), and probably more valuable across the board, but less critical path to what I'm doing. Both of these asynchronous needs are under active research and development, and the implementation is probably interrelated (synchronous processing can probably be expressed in terms of a single callback which can probably be expressed in terms of chunked asynchronous processing) ... the RFE gives some code examples for how this might be true. Right now I am looking at the penalties and costs of thread-safe Request and Response objects across the board, a need which must be sorted out before any of the other async stuff can be safely investigated. On 2/6/08, António Mota [EMAIL PROTECTED] wrote: Hmm, let me try to understand, is there a effort going on to include in Restlet some kind of notification to asynchronous clients based on xmlhhttprequest callbacks and/or Comet-style push techniques? On 06/02/2008, jbarciela jbarciela [EMAIL PROTECTED] wrote: Have a look at this RFE and its references: http://restlet.tigris.org/issues/show_bug.cgi?id=143 ... Ah, that's a wonderful wonderful compilation of articles, so far I've only read about Jetty's continuations, thanks for the link you guessed right I have my moments Cheers Jaime -- -- Melhores cumprimentos / Beir beannacht / Best regards António Manuel dos Santos Mota mobile: +353(0)877718363 mail: [EMAIL PROTECTED] skype: amsmota msn: [EMAIL PROTECTED] linkedin: www.linkedin.com/in/amsmota Kyrre Kristiansen ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
RE: Testing strategies
A strategy I've seen that's worked great is a mix between interfaces and private implementations. This would require an associated Factory to look up the actual implementation. This gives you the choice of stubbing out the interface if it's needed, or creating mock objects for the different private implementations. Maybe this would be a choice for when the project becomes more stable on the external inteface side? Kyrre --- Jerome Louvel [EMAIL PROTECTED] wrote: Agreed, I've entered a design task for 2.0 M1 to remember this point: http://restlet.tigris.org/issues/show_bug.cgi?id=384 Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tim Peierls Envoyé : mardi 20 novembre 2007 20:33 À : discuss@restlet.tigris.org Objet : Re: Testing strategies On Nov 20, 2007 1:55 PM, Sean Landis [EMAIL PROTECTED] wrote: Stated differently, maybe when the convergence is over, it will be much safer to move to interfaces. The nearly immutable nature of interfaces won't be such an issue since the API questions will have mostly been answered. And presumably a compatibility layer could be maintained, at least through 2.x, to help 1.x clients migrate at their own speed. --tim Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: HEAD not well supported?
I have always been a bit unsure of which methods to override for the different verbs/methods, always considering it a bit of a nuisance and a potential put-off for new adopters (I'm carrying on about the potential problems to new restlet implementors, but it's only because I believe it's one of the factors needed to become a successful framework). But looking at this discussion, I've started wondering if this isn't a problem in the design of Resources. I have found myself having to look at the code several times when implementing a new Resource, just to make sure I know what the class I'm extending (usually Resources, although I sometimes make my own base resources for applications and inherit from them) is actually doing. According to Java Practices web site, this is one of the points for considering composition instead of subclassing [1]. I still don't know if this explicitly relates to this problem, but it definetly seems like we have a case of coupling of the implementation of Resource and its subclasses. I don't know if I'm off the map here, but just had a thought and wanted to share with the people with the know-how. Regards, Kyrre [1]http://www.javapractices.com/Topic72.cjp --- Tim Peierls [EMAIL PROTECTED] wrote: On 10/11/07, Chuck Hinson [EMAIL PROTECTED] wrote: allowPut(), allowPost(), allowDelete(), allowGet() handlePut(), handlePost(), handleDelete(), handleGet() put(), post(), delete(), getRepresentation() - eh? what? The lack of symmetry there is jarring - it leads people to go looking for the get() method and when they can't find it, they're confused. It depends on how they approach the documentation. The javadoc class comment for Resource presents these in the reverse order; it isn't jarring if you first encounter getVariants, getRepresentation, put, post, and delete, *then* find out that there is a lower level of handle* methods (that you might not have to deal with at all, if you're lucky). It *is* slightly awkward that you have to use the lower level allow* methods to control whether your higher-level overrides will be used. Maybe the constructor could take an argument to handle some common cases with, say, an EnumSet? I think two things need to happen. First, the documentation for handlePut(), handlePost(), handleDelete() and handleGet() needs a whole lot more detail making it plain what exactly they do. More precisely, what they do by default (i.e., implement the higher-level API of getVariants, getRepresentation, post, put, delete) *and* what they should do if overridden, e.g., a warning that overriding handleGet without calling super.handleGet can cause any overridden getRepresentation and getVariants methods to be ignored (unless your handleGet calls getPreferredRepresentation, say). And second, yes, I think put(), post() and delete() and getRepresentation() need to be renamed. While doPut(), doPost(), doDelete() and doGet() are OK, I think I'd prefer processPut(), processPost(), processDelete() and processGet() - but anything that makes it clear that they are at the same level of processing is fine. There's a false parallel here that I don't think should be encouraged by providing parallel names. getRepresentation takes a Variant argument, handleGet does not; post takes a Representation argument, handlePost does not. If anything, I'd argue for names that were *less* parallel, e.g., add instead of post, and remove instead of delete. Resource is the place where the uniform interface hits the rich interface of your domain objects. It's entirely appropriate (and convenient!) to have an intermediate API (getVariant, getRepresentation, put, post, and delete) to help ease the transition between them. --tim Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: Restlet site code
Is this an answer to a different post? --- Patson [EMAIL PROTECTED] wrote: Yes, tried on both IE and netscape...both had the same issue. The problem is the localhost server should not send the 401 response again after its authenticated at the first GET Kyrre Kristiansen ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: Restlet site code
yep, that's the one. I just couldn't locate it from the site. Thanks a lot, Jerome! --- Thierry Boileau [EMAIL PROTECTED] wrote: yes I think so. Is this what you are talking about : http://www.restlet.org/documentation/1.0/examples/self; ? best regards, Thierry Boileau On 10/11/07, Kyrre Kristiansen [EMAIL PROTECTED] wrote: Is this an answer to a different post? --- Patson [EMAIL PROTECTED] wrote: Yes, tried on both IE and netscape...both had the same issue. The problem is the localhost server should not send the 401 response again after its authenticated at the first GET Kyrre Kristiansen ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: Restlet site code
Oops! That should have been thanks, Thierry! --- Kyrre Kristiansen [EMAIL PROTECTED] wrote: yep, that's the one. I just couldn't locate it from the site. Thanks a lot, Jerome! --- Thierry Boileau [EMAIL PROTECTED] wrote: yes I think so. Is this what you are talking about : http://www.restlet.org/documentation/1.0/examples/self; ? best regards, Thierry Boileau On 10/11/07, Kyrre Kristiansen [EMAIL PROTECTED] wrote: Is this an answer to a different post? --- Patson [EMAIL PROTECTED] wrote: Yes, tried on both IE and netscape...both had the same issue. The problem is the localhost server should not send the 401 response again after its authenticated at the first GET Kyrre Kristiansen ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Restlet site code
Hello. Just an unimportant question... I seem to remember the code for the restlet site being available in the documentation, but now I can't find it. Has it been removed? Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: sessions debate (was Re: some benchmarking)
Adam, My rant about load balancing and cookies was intended to be a point in the case against session state on the server. I just got carried away, and din't get my point across very well :-) I've never used Terracotta, but have heard of one project using it, and they're quite happy with it. Probably about time to kill off this thread now? Kyrre --- Adam Taft [EMAIL PROTECTED] wrote: You should check out Terracotta. http://www.terracotta.org/ It does shared cross-JVM memory management pretty seamlessly. It's open source. Being the good REST programmer that I am :), I don't keep session state on the server. But, if I had to do it, they have a really slick way to manage shared memory across JVMs. I saw a demo of their stuff at a JUG meeting once. They demoed a shared Swing TableModel. Very interesting and exciting stuff. Adam Kyrre Kristiansen wrote: Yes, you are right. You really have two options for this, 1. Use the database. This might not be a good solution for short-length, time-based session data. 2. Use some sort of cluster-sharing, eg memcached (which is C++, but I believe there's a Java-version for it as well), or other solutions. 3. Don't share sessions in the cluster, which means that you have to route the same client to the same server throughtout the session. This is usually done by cookies from the load-balancer (yet more cookies). There's a second way to make sure that the same requests come to the same server, but it's based on IP. Most large cooperations use NAT-style routing out, so that the load-balancer will only see one IP for up to thousands of users, which will give uneven load on the servers. Avoid this balancing scheme like the plague. Regards, Kyrre --- Marc Portier [EMAIL PROTECTED] wrote: Kyrre Kristiansen wrote: simple round-robin of a cookie-less system. And, if you want to make quick, highly reliable services, load balancing is almost as king as cache... Kyrre, thx for pointing me to this, I read this as the intrinsic point that 'resource-state' should be shared in the server-cluster in some way... Anyway, thx all for your comments on the thread, sorry for not finding the time earlier to participate after starting it... have to give it some time to sip through, now... regards, -marc= Kyrre Kristiansen ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html Kyrre Kristiansen ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
RE: Re: JDBCClient
Hi. Just some thoughts around JDBCClient. I have to say that I was a bit surprised when I saw the implementation of JDBCClient as it is. What I had envisioned was an implementations that used a basic mapping from methods to SQL keywords, eg SELECT, INSERT, UPDATE and DELETE (CRUD, remember?), with the rest of the information in the input representation. I think that returning the entire result set in XML will limit the size of the result returned from the database, although it probably would suffice for most database queries used in real-life applications. As network access is horrendously expensive compared to doing something locally (memory/disk), it is usually better to pin down the result as much as possible in the database before returning it to the application. At least that was what my database lecturer told me back in the happy student days. Regards, Kyrre --- Jerome Louvel [EMAIL PROTECTED] wrote: 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 Kyrre Kristiansen ___ Try the all-new Yahoo! Mail. The New Version is radically easier to use The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html
RE: Re: JDBCClient
Jerome, I saw that you had checked in a fix in SVN for the issue I reported. The fix does not fix my problem, however. I believe that the finally-block should be removed completely, and the connection closed elsewhere. It seems to me that the pooling mechanism should keep a lifetime of the connection (eg number of times used), and close the connection and remove from the pool after a certain amount of time. This raises the question on what to do in the case when connections aren't pooled, however. I'm quite busy with work at the moment, but I'll look into setting up my environment for development against the restlet source, so I can submit a fix rather than just ranting on the mailing list :-) BTW, I'm using the JavaDB (derby) as the database to test for, in case that makes any difference. Regards, Kyrre --- Jerome Louvel [EMAIL PROTECTED] wrote: Hi Kyrre, Thanks for sharing your thoughts: I fully agree with you. We need a higher level of mapping between JDBC database and Restlet Resources. The JDBC connector is a first step at a lower-level. In 1.1 we will focus on providing this higher-level of mapping where people can manipulation table rows/columns/cells directly as resources with URIs and using GET/POST/PUT/DELETE methods (internally mapped to corresponding SQL verbs). This will be a major effort in order to get this mapping right and will bring us closer to other frameworks like Rails which introduced a similar feature in their 1.2 RC1 release: http://weblog.rubyonrails.com/2006/11/23/rails-1-2-release-candidate-1 I've also just added an XSLT Filter (called org.restlet.Transformer) that will facilitate the task of transforming the JDBC XML resultsets (or any XML document) into a representation (XML, HTML, etc.) suitable for the clients. Stay tuned! Jerome -Message d'origine- De : Kyrre Kristiansen [mailto:[EMAIL PROTECTED] Envoyé : vendredi 24 novembre 2006 10:24 À : discuss@restlet.tigris.org Objet : RE: Re: JDBCClient Hi. Just some thoughts around JDBCClient. I have to say that I was a bit surprised when I saw the implementation of JDBCClient as it is. What I had envisioned was an implementations that used a basic mapping from methods to SQL keywords, eg SELECT, INSERT, UPDATE and DELETE (CRUD, remember?), with the rest of the information in the input representation. I think that returning the entire result set in XML will limit the size of the result returned from the database, although it probably would suffice for most database queries used in real-life applications. As network access is horrendously expensive compared to doing something locally (memory/disk), it is usually better to pin down the result as much as possible in the database before returning it to the application. At least that was what my database lecturer told me back in the happy student days. Regards, Kyrre --- Jerome Louvel [EMAIL PROTECTED] wrote: 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/WebRo wSet.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
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
Handling PUT, POST and DELETE
Hello. I've been trying to make a small test application using restlets. First of all I'd like to say good work on bringing a framework for developing REST applications to Java, that was sorely needed! Anyway. I've looked at the sample code, and there the domain classes are subclasses of Resource. Looking at the Handler code in eg handleDelete, the Resource is found, and the delete() method is called on the resource. If we use the domain class as a subclass of Resource, this would mean that the object will have to delete itself... Isn't that a bit strange? Is it better to make the Resource classes refer to the real domain objects, and thereby deleting the referred domain object? How have others separated the domain objects and the Resources? I'm desperatly seeking some documentation that goes a bit beyond setting up a server and plain Javadoc, as well as a more complete example with all CRUD methods implemented. Regards, Kyrre Kyrre Kristiansen ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
RE: Handling PUT, POST and DELETE
Hi again, Jerome. Thanks for your prompt reply. Fist of all, I'm very unsure of the correctness of my suggestions, I'm in a very early stage of looking at this framework. My implementation is basically a reimplementation of the Sample application, with all objects stored in-memory and lost upon restart. This means that I haven't really thought through the implications of using it with containers, databases, etc. Thanks for giving me an opportunity to discuss this important point. The idea of having a Resource.delete() method was a deliberate design choice on my behalf. I assumed that in most cases, the Resource instance would know how to delete itself: The point that confuses me a bit is that locating an object is done through findTarget in Handler (or Finder), but changing, deleting and constructing objects is meant to be done through the Resource. I'm at a bit of a crossroad whether I should override the Handler methods for PUT, POST and DELETE, or have a base class (Domain) inherit from AbstractResource and keeping a static reference to my datasource. Being able to do both is IMHO not a problem, just a result of a flexible API. I have planned to add some docs on this point for 1.0 release. Meanwhile, you can refer to this FAQ entry: How do I implement the traditional MVC pattern? http://www.restlet.org/faq#15 Thanks for your pointers! Kyrre ___ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
