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
Hi Kyrre, I would be interested to read more about the other resource patterns that you found. We might want in the future to support some of them in Restlet directly. We packages reorganization in Restlet 1.2, we have more room for this. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Kyrre Kristiansen [mailto:kyrre_kristian...@yahoo.co.uk] Envoyé : mardi 7 avril 2009 16:28 À : discuss@restlet.tigris.org Objet : 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
Re: Resource factories
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
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596473
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
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@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
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: Resource factories
Just
to join the choir --
In
addition to Rhett's standard solution, you can also use Restlet's
application Context.getAtrributes() to set the referred type for each
resource class, which they could then read at runtime. Just an option;
I prefer Rhett's solution.
By
the way, having worked extensively with other run-time type information
(RTTI) systems, such as those in C++ and in C#, I have to say that I
really do consider Java's "type erasure" to be a feature. Sure, you
have to do the work on your own, as in this case, but the automatic
alternatives are all #$%#^$. At least you know exactly what's going in
Java.
-Tal
Rhett Sutphin wrote:
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@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 c
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
RE: Resource factories
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/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ 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=1429304
Re: Resource factories
I had almost finished drafting a response, but as usual Rob said it all better than I could. Let me emphasize that construction of short-lived objects like Resources is going to be much faster and less error-prone than managing state shared across multiple requests. Doug Lea has said that if you can avoid thread contention by allocating another object, it's almost always worth it. (For the record, I most certainly do *not* get concurrency right every time, which is why I try very hard to use immutable or thread-confined classes as much as possible.) --tim On Mon, Mar 23, 2009 at 8:29 PM, Rob Heittman rob.heitt...@solertium.comwrote: In addition to what Rhett said ... one massively huge benefit of having Resources that are created per-request is that they need not be thread safe. Very few developers (:: cough :: except Tim) can do concurrency correctly every time. But I've spent most of the afternoon noodling over this discussion and wondering why the Resource construction issue has never really bugged me like it bugs Tal. I guess I just have never written Resources that have a lot of of local configuration state. This might be because I'm not an IoC/DI guy by default -- it's a tool I use sometimes, but not a fundamental way of thinking for me. It may also help to know that I tend to like functional programming a lot, and tend to avoid static fields in general; I fear the bite of class loader hierarchies I didn't expect. For the higher-level configuration stuff, I tend to dynamically fetch it from the Application itself (which of course is wired-in and long-lived) or the Context. Really, this isn't noticeably costly. I'm not in opposition to more ways of constructing a Resource. But I also feel, somewhere in my bones, that if Resources really chafe at the existing model, they /probably/ can be refactored or redesigned to be a much smoother fit, without losing anything important ... but just thinking differently. I would be willing to have a look at a concrete case -- e.g. a resource in the scripting extension -- and try to make a proposal if one fits. Then we could talk about it in code review specifics and not in general architectural chalk talk. - R On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley bordo...@gmail.com wrote: Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1394971 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1395614
Re: Resource factories
Thanks, Tim. I intended these static non-final fields to be, by convention, only modified during the configuration mode, but in any case didn't do much because I'm still looking for a comprehension solution to the (can we call it?) constructor injection problem. Your post did come through on the code list, and I will answer you more fully there, after I slap my forehead and realize that I'm talking about a deprecated version of the Resource class. :) This project is moving quickly! For you and others interested, Restlet 1.2 will feature a major redesign of Resource: http://wiki.restlet.org/developers/172-restlet/226-restlet.html -Tal Tim Peierls wrote: [Tried sending to code list, but I'm not sure it got through.] Well, there are definitely some concurrency bugs here. Using public static non-final fields is a big no-no. Even if you made all this thread-safe, it's problematic: What if two separate Applications (in the same class loader, but from different jars, say) use completely different ScriptResource configurations? How about creating a ScriptResourceConfiguration class to encapsulate all of these static fields, stashing an instance of this in a (Restlet) Context somehow, and looking that up at ScriptResource construction time? --tim On Mon, Mar 23, 2009 at 9:18 PM, Tal Liron tal.li...@threecrickets.com wrote: ... Specifically, I would be very happy if you and others could take a look at the script extension I am working on in Restlet svn. It has two Resource-based classes that currently rely on a few static fields to configure some high-level stuff. This is not a problem as long as we are dealing with a single use of these classes, or multiple uses where we don't mind sharing the configuration details. I suspect that this is good enough for many use-cases, but I can also imagine situations where this would be a problem. (Anybody: feel free to answer on the code mailing list. I started the discussion here because I feel this issue could impacts many users of Restlet, not just this specific contribution.) -Tal
Re: Resource factories
Hi Tai,
I had a look at your classes and I agree with the others; static variables
are a bad idea.
I suggest that you turn all these static methods into properties.
Even if dependency injection is difficult (or impossible) to do with
resources in the current Restlet architecture, it is still a better design.
It offers great flexibility without tying you down to one way of doing
things.
It is then possible for a developer to trivially extend the class and
provide values in the default constructor.
public ExampleJavaScriptResource extends
org.restlet.ext.script.ScriptResource
{
public ExampleJavaScriptResource(Context context, Request request,
Response response)
{
setExtension(js);
setDefaultName(execute);
setSourceViewable(true);
// ... etc.
}
}
// Route requests to appropriate Resources
router.attach(/javascript/${scriptname},
ExampleJavaScriptResource.class);
I understand that this is not the whole answer, but it gives developers
options.
Your proposal limits developers to one way of configuring ScriptResource
classes and thats it.
Developers will find many and varied ways to configure Resources in
Restlet.
We have our own way, but I would not impose that on others. Furthermore, we
may change it in the future.
Regards
Donald.
Tal Liron
tal.li...@threec
rickets.com To
discuss@restlet.tigris.org
24/03/09 12:32 PM cc
Subject
Please respond to Re: Resource factories
discuss
disc...@restlet.
tigris.org
Small addendum:
Instead of checking out svn, I think the development documentation may be
good enough for reference:
http://www.restlet.org/documentation/snapshot/ext/index.html?org/restlet/ext/script/package-summary.html
-Tal
**
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1410856
Re: Resource factories
Thanks, Tim. This is a reasonable workaround -- creating a factory where one isn't there. And Guice adds some elegance to your solution. Another solution is simply to rewrite Finder entirely to use factories. This isn't hard. But it also goes against Restlet's current design. One of the very nice things about Restlet, which sets it apart from mere JAX-RS, is that it provides a complete container for RESTful applications. You can connect multiple Application instances to multiple Components, all running together (and possibly interacting). But, I'm wondering aloud if this particular aspect of the architecture can support this ambition or come in its way. -Tal Tim Peierls wrote: I tried to solve this problem in a limited way, using Guice, and wrote about it here: http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Maybe some of this could adapted for your purposes. --tim
Re: Resource factories
Hi Tal, On Mar 23, 2009, at 1:06 PM, Tal Liron wrote: Thanks, Tim. This is a reasonable workaround -- creating a factory where one isn't there. And Guice adds some elegance to your solution. Another solution is simply to rewrite Finder entirely to use factories. This isn't hard. But it also goes against Restlet's current design. I don't think that subclassing Finder to be more factory-like goes against Restlet's design. The default finder is a very simple sort of Resource factory -- one that is capable of instantiating objects and nothing else. Other Finders use different mechanisms -- e.g., SpringBeanFinder gets Resource instances from a Spring ApplicationContext or BeanFactory. Rhett One of the very nice things about Restlet, which sets it apart from mere JAX-RS, is that it provides a complete container for RESTful applications. You can connect multiple Application instances to multiple Components, all running together (and possibly interacting). But, I'm wondering aloud if this particular aspect of the architecture can support this ambition or come in its way. -Tal Tim Peierls wrote: I tried to solve this problem in a limited way, using Guice, and wrote about it here: http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Maybe some of this could adapted for your purposes. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1391507
Re: Resource factories
Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal Rhett Sutphin wrote: I don't think that subclassing Finder to be more factory-like goes against Restlet's design. The default finder is a very simple sort of Resource factory -- one that is capable of instantiating objects and nothing else. Other Finders use different mechanisms -- e.g., SpringBeanFinder gets Resource instances from a Spring ApplicationContext or BeanFactory. Rhett
Re: Resource factories
I'd be careful of judgement-words like bad practices since this implies some universal level of harm in all cases. I think the current Finder design is simplistic, flexible, and easy to implement. I think there is also room for a more structured base implementation that exposes some advantages for more complex resource object hierarchies. I don't think these are mutually exclusive. On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron tal.li...@threecrickets.comwrote: Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1391583
Re: Resource factories
Ah, thanks, Rob. You've captured what I think is the main problem here: it has more to do with the Resource class than the Finder class specifically. Restlet expects extensions of class Resource to have a specific constructor. Of course, you don't have to implement that specific constructor -- but then your Resource won't work with the Finder. (A related problem to this is that the Java language can't enforce this -- you need to read the documentation in English and make sure you design your classes accordingly.) "Bad practice" might sound too harsh, but I do think my efforts to follow the Restlet API, in having all my Resource classes implement that particular constructor, have caused me problems. Of course, nothing in Restlet forced me to do so. Perhaps the "encouragement" I felt was all in my head. :) I'm just asking the community to see if I'm the only one in this boat (and perhaps I am!). Let me give you an example, though, of where things can get more problematic. I'm contributing an extension to Restlet right now, and it uses Resource subclasses. For my own internal applications, of course, I can do whatever I want, include using Guice where necessary. But, I want this extension to be as minimal as possible, so I don't want to add an alternative Finder class just for this extension. I'm stuck with a basic API, that as you say is simplistic. I'm thinking out loud here -- would it make sense to have a less-simplistic version of Finder in the basic Restlet API? Or, even add functionality to the basic Finder that can allow for injection into the constructor (so that it would be less simplistic)? Having the Finder be both simple and flexible is not mutually exclusive. -Tal Rob Heittman wrote: I'd be careful of judgement-words like "bad practices" since this implies some universal level of harm in all cases. I think the current Finder design is simplistic, flexible, and easy to implement. I think there is also room for a more structured base implementation that exposes some advantages for more complex resource object hierarchies. I don't think these are mutually exclusive. On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron tal.li...@threecrickets.com wrote: Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal
Re: Resource factories
Hi Dave, On Mar 23, 2009, at 3:08 PM, David Bordoley wrote: Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. I'm not sure what the original design rationale was. Having used frameworks which use per-request request-handling objects (Restlet, Rails) and ones which use singleton request-handling objects (Spring MVC, Struts), I find that I prefer the programming model allowed by the former. In a singleton-based system, no per-request state can be stored in the object. All state has to be passed between methods using parameters. This results in either large, monolithic methods (hard to read, test, and extend) or reasonably-sized methods with a large number of parameters (hard to read and extend). In an object- per-request system, the request/response state is encapsulated in an object instance, so everything's much cleaner. (It goes without saying that you are also less likely to create hard-to-track-down shared-state-related bugs.) Rhett Thanks, Dave On Mon, Mar 23, 2009 at 11:46 AM, Rob Heittman rob.heitt...@solertium.com wrote: I'd be careful of judgement-words like bad practices since this implies some universal level of harm in all cases. I think the current Finder design is simplistic, flexible, and easy to implement. I think there is also room for a more structured base implementation that exposes some advantages for more complex resource object hierarchies. I don't think these are mutually exclusive. On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron tal.li...@threecrickets.com wrote: Good point, Rhett. Well, let me put it this way -- do you think the current Finder design encourages bad practices for Restlet users? -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1392294 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1394862
Re: Resource factories
In addition to what Rhett said ... one massively huge benefit of having Resources that are created per-request is that they need not be thread safe. Very few developers (:: cough :: except Tim) can do concurrency correctly every time. But I've spent most of the afternoon noodling over this discussion and wondering why the Resource construction issue has never really bugged me like it bugs Tal. I guess I just have never written Resources that have a lot of of local configuration state. This might be because I'm not an IoC/DI guy by default -- it's a tool I use sometimes, but not a fundamental way of thinking for me. It may also help to know that I tend to like functional programming a lot, and tend to avoid static fields in general; I fear the bite of class loader hierarchies I didn't expect. For the higher-level configuration stuff, I tend to dynamically fetch it from the Application itself (which of course is wired-in and long-lived) or the Context. Really, this isn't noticeably costly. I'm not in opposition to more ways of constructing a Resource. But I also feel, somewhere in my bones, that if Resources really chafe at the existing model, they /probably/ can be refactored or redesigned to be a much smoother fit, without losing anything important ... but just thinking differently. I would be willing to have a look at a concrete case -- e.g. a resource in the scripting extension -- and try to make a proposal if one fits. Then we could talk about it in code review specifics and not in general architectural chalk talk. - R On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley bordo...@gmail.com wrote: Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1394971
Re: Resource factories
Thanks, Rob! I value your gut instinct in this. Perhaps, then, we can indeed move this over the code review side. Specifically, I would be very happy if you and others could take a look at the script extension I am working on in Restlet svn. It has two Resource-based classes that currently rely on a few static fields to configure some high-level stuff. This is not a problem as long as we are dealing with a single use of these classes, or multiple uses where we don't mind sharing the configuration details. I suspect that this is good enough for many use-cases, but I can also imagine situations where this would be a problem. (Anybody: feel free to answer on the code mailing list. I started the discussion here because I feel this issue could impacts many users of Restlet, not just this specific contribution.) -Tal Rob Heittman wrote: In addition to what Rhett said ... one massively huge benefit of having Resources that are created per-request is that they need not be thread safe. Very few developers (:: cough :: except Tim) can do concurrency correctly every time. But I've spent most of the afternoon noodling over this discussion and wondering why the Resource construction issue has never really bugged me like it bugs Tal. I guess I just have never written Resources that have a lot of of local configuration state. This might be because I'm not an IoC/DI guy by default -- it's a tool I use sometimes, but not a fundamental way of thinking for me. It may also help to know that I tend to like functional programming a lot, and tend to avoid static fields in general; I fear the bite of class loader hierarchies I didn't expect. For the higher-level configuration stuff, I tend to dynamically fetch it from the Application itself (which of course is wired-in and long-lived) or the Context. Really, this isn't noticeably costly. I'm not in opposition to more ways of constructing a Resource. But I also feel, somewhere in my bones, that if Resources really chafe at the existing model, they /probably/ can be refactored or redesigned to be a much smoother fit, without losing anything important ... but just thinking differently. I would be willing to have a look at a concrete case -- e.g. a resource in the scripting extension -- and try to make a proposal if one fits. Then we could talk about it in code review specifics and not in general architectural chalk talk. - R On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley bordo...@gmail.com wrote: Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1394971
Resource factories
Hey Restleters, Sorry if this question has been answered before -- I'm rather new to the community, even though I've been a heavy Restlet user for a while. I understand and agree with abstract class design used by Restlet, as is detailed by the wiki: http://wiki.restlet.org/developers/179-restlet/198-restlet.html However, I wonder if this has been taken too far, as regards the Finder class. Finder uses nothing but the Java class itself, and creates instances dynamically using newInstance(). But how do we inject initialization information to these instances? One idea, following the abstract class design, can be to inherit these classes and use different ones for different purposes. However, I've come across a situation in which this is problematic. Specifically, I want to have several Application instances running on the same component. These instances all use the same set of classes inherited from Resource. In many cases this works fine, but in some cases I want these classes to work slightly different per application. Specifically, there is shared information used by instances that I store as static field within the class. The problem is that both applications share the same static scope. Using the factory design pattern, I would have a problem -- factories can be used to create instances as I please. I understand the reluctance to use this pattern in Restlet, but I wonder if anyone has another solution. Maybe I'm just really missing something obvious! -Tal
Re: Resource factories
I tried to solve this problem in a limited way, using Guice, and wrote about it here: http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Maybe some of this could adapted for your purposes. --tim On Fri, Mar 20, 2009 at 10:03 PM, Tal Liron tal.li...@threecrickets.comwrote: Hey Restleters, Sorry if this question has been answered before -- I'm rather new to the community, even though I've been a heavy Restlet user for a while. I understand and agree with abstract class design used by Restlet, as is detailed by the wiki: http://wiki.restlet.org/developers/179-restlet/198-restlet.html However, I wonder if this has been taken too far, as regards the Finder class. Finder uses nothing but the Java class itself, and creates instances dynamically using newInstance(). But how do we inject initialization information to these instances? One idea, following the abstract class design, can be to inherit these classes and use different ones for different purposes. However, I've come across a situation in which this is problematic. Specifically, I want to have several Application instances running on the same component. These instances all use the same set of classes inherited from Resource. In many cases this works fine, but in some cases I want these classes to work slightly different per application. Specifically, there is shared information used by instances that I store as static field within the class. The problem is that both applications share the same static scope. Using the factory design pattern, I would have a problem -- factories can be used to create instances as I please. I understand the reluctance to use this pattern in Restlet, but I wonder if anyone has another solution. Maybe I'm just really missing something obvious! -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1369577
