Entity not set when setting it from storeRepresentation
Hi everybody,
I'm trying to figure out how to handle a PUT on a resource. I have overriden
storeRepresentation method, so that it creates a new entity, and replies with
the passed entity. Here is the code :
@Override
public void storeRepresentation(Representation r) throws ResourceException {
try {
/* Create and store new resource */
getResponse().setStatus(Status.SUCCESS_CREATED);
getResponse().setEntity(r);
} catch (Exception e) {
throw new ResourceException(e);
}
}
@Override
public boolean allowPut() {
return true;
}
My problem is, if I build a client to put an entity on this resource, the
response contains an empty entity. Here is my test code :
Client client = new Client(Protocol.HTTP);
Request request = new Request(Method.PUT, URL for the resource);
request.setEntity(new StringRepresentation(some data));
Response response = client.handle(request);
System.out.println(response.getEntity());
This gives me org.restlet.resource.representation$emptyrepresentat...@87e704.
Can someone explain me what I did wrong?
Thank you much,
Mathieu
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1652124
RE: Re: Google AppEngine and Restlet
After a bit of experimentation I have managed to get a Restlet/Freemarker stack running on GAE. The basic steps I took were : 1. Modify ServletConverter and ServletContextAdapter as detailed below. Basically this means replacing the calls to new ServletLogger with Logger.getLogger e.g. in the ServletConverter constructor do something like... super(new Context(Logger.getLogger(ServletConverter.class.getName(; 2. Add org.freemarker.jar, org.restlet.jar, org.restlet.ext.servlet.jar and org.restlet.ext.freemarker.jar to the WEB-INF/lib of your google app project and add to the build path. 3. Follow usual setup for getting Restlet working in a Servlet environment. Folow the HelloWorld tutorial in the getting started docs - it should work fine locally (even without doing step 1. However, you'll need to replace these calls in order to get it to run in the real GAE) 4. Freemarker was a little more tricky, but not much. Create a freemarker configuration that uses the class template loader and put this in the Restlet Application context attributes. 5. Make sure your templates are somewhere on the class path. 6. Use the TemplateRepresentation along with your freemarker config from the context attributes 7. Make sure it works locally and upload to the app engine. Hopefully I'll get a chance to write this up properly over easter, but it wasn't too bad and looks promising so far. Cheers, Richy http://wiredupandfiredup.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1648597
Re: firstResource example problem
Dear all, I just starting to learn restlet, and found this problem. I'm following firstResource tutorial with eclipse and glassfish integrated to eclipse. After write all the code,and importing : - org.restlet.jar - com.noelios.restlet.jar - com.noelios.restlet.ext.servlet_2.5.jar and run the servlet, I got the following error : javax.servlet.ServletException: PWC1397: Wrapper cannot find servlet class com.noelios.restlet.ext.servlet.ServerServlet or a class it depends on root cause java.lang.ClassNotFoundException: com.noelios.restlet.ext.servlet.ServerServlet note The full stack traces of the exception and its root causes are available in the Sun GlassFish Enterprise Server v2.1 logs. But when I was deploying .war example downloaded from the site, it was deployed successfully. Does anybody know what cause this problem? THanks Dear hudarsono, You'll need to copy the three jar files into /WEB-INF/lib inside your deployment (I use Tomcat + IntelliJ) - I struggled with this as well, and the error message provided didn't exactly point me in the right direction, but I did this and it worked. Surely, the tutorial you're reading could contain this information more explicitly. Hope this helps. Best regards, hnilsen -- View this message in context: http://n2.nabble.com/firstResource-example-problem-tp2538870p2619243.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1639583
resource scheme
Hi, i need suggestion. I have to implement a multi-side RESTlet architecture to exchange message/resource between pharmacies and suppliers, and between suppliers and agents. It implicates thet in the suppliers side, there are resources POSTed or PUTted by booth pharmacies and agents and some resources destined to different pharmacies (fiscal invoices and similar) and other destined to different agents (order sheet and similar). It implicates thet each side cannot know the resources map and their structure in the other side (and cannot know the specific URI's). I think it's necessary to provide, before different clients GET, POST or PUT resources, an XML resource thet maps the structure of resources and over this map the client can generate the right URI's for the HTTP packets (WADL like). I'm aware this approach gets further from restlet architecture, but i don't succeed in imagining other solutions. It's all right or i'm crazy? If it's all right can you recommend me a particular structure for resources that is easier to manipulate? I can create a directory for each client and in each directory a tree of other directory for different resources using the name of directories as identifier... or there are other easier way to implement an manipulate better resource structure and map? Thanks in advance!! Illuminate me!! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1626522
Bug in HttpAmazonS3Helper class
Ok. I think I've figured out my the problem with the HttpAmazonS3Helper class. The code in the method getCanonicalizedResourceName(Reference resourceRef) isn't quite correct as It needs to incorporate the _bucketname_ into the path. Presently its just getting the resource path. From the S3 developer guide examples: GET /photos/puppy.jpg HTTP/1.1 Host: _bucketname_.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 + Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA= Which should translate into the following string to sign: GET\n \n \n Tue, 27 Mar 2007 19:36:42 +\n /_bucketname_/photos/puppy.jpg Matt. -- View this message in context: http://n2.nabble.com/Bug-in-HttpAmazonS3Helper-class-tp2614094p2614094.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1620518
Re: Restlet and maven
Hello, There is an issue with the maven build. Resources files (not java files) in src/ are not in the final jar. Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hi ! Thanks all for your answers. I was not really worried about building the project with ant or maven. I use maven to build most of my projects and I want to test them with last updates. As maven.restlet.org is not being updated everyday ;). Cheers, Rémi On Tue, Apr 7, 2009 at 17:02, Davide Angelocola davide.angeloc...@gmail.com wrote: Hi Rémi, assuming you've installed maven in the PATH you must run the following command in trunk/modules: mvn install using netbeans is even easier, just install the maven plugin and open the modules project. Then build the project. Best Regards, Davide Angelocola 2009/4/7 Rémi Dewitte r...@gide.net Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Thanks, Rémi -- -- Davide Angelocola -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1620322
Re: ServerResource is currently incompatible with OSGi
I wouldn't recommend RRWL for this.
Since it's harmless to recompute the AnnotationInfos, I think just having an
AnnotationUtils.clearCache method would work well. Call it whenever an
Application stops, say. It's worth a little redundant computation to avoid
having to deal with shared locks and liveness.
--tim
On Thu, Apr 9, 2009 at 2:22 PM, Tal Liron tal.li...@threecrickets.comwrote:
Oh, I didn't mean synchronizing the whole map. I actually didn't mean
much beyond suggesting that we brainstorm a way to use WeakReferences as
keys in this particular case. I still don't have a complete solution in
mind.
Another idea: Perhaps we can use a ReentrantReadWrite lock around a simple
WeakHashMap? Since this is a 99% read situation, most requests won't need
to acquire locks.
(ConcurrentHashMap is actually a very complicated and delicately tuned
class, and it would be anything but trivial for us to try to re-implement it
using WeakReferences.)
I know there are generic 3rd party solutions to this, but I know we'd all
prefer to use what Java 5 offers us right now. I'm sure we can cobble
together something that performs well!
-Tal
Tim Peierls wrote:
Did you read my subsequent e-mail that talked about opening an issue to
make this more robust?
There is currently no standard concurrent map with weak keys, although
MapMaker in Google Collections provides this and much more. An effort to put
something like this into Java 7 is under way, but there's no telling whether
it will actually happen.
Wrapping a WeakHashMap with synchronization is likely to be a performance
bottleneck: every request has to grab a global lock.
--tim
On Wed, Apr 8, 2009 at 2:06 PM, Tal Liron tal.li...@threecrickets.comwrote:
Hmm. I disagree that this has *nothing* to do with the Application. For
example, if an Application is unloaded, this cached information will remain
in the static field. In fact, there is no mechanism in place right now clean
this cache, and in dynamic environments (possibly OSGi) it may accumulate
cruft. Not a huge problem, but this is the stuff memory leaks are made
of...
Here's a thought: can we use a synchronized WeakHashMap here? That way,
the AnnotationInfo would be discarded when the class is unloaded.
-Tal
Jerome Louvel wrote:
Hi all,
Beautiful! This new solution is available in SVN trunk.
Thanks Dave for the report and Tim for the clever fix!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
*De :* tpeie...@gmail.com [mailto:tpeie...@gmail.com tpeie...@gmail.com]
*De la part de* Tim Peierls
*Envoyé :* mercredi 8 avril 2009 00:23
*À :* discuss@restlet.tigris.org
*Objet :* Re: ServerResource is currently incompatible with OSGi
Why involve Context at all? The AnnotationInfo associated with a Class?
extends UniformResource does not depend on Context. You could just add a
method to AnnotationUtils:
public static AnnotationInfo getAnnotationDescriptor(Class? extends
UniformResource resourceClass) {
AnnotationInfo result = cache.get(resourceClass);
if (result == null) {
result = computeAnnotationDescriptor(resourceClass); // use code from
existing getAnnotationDescriptors for this
AnnotationInfo prev = cache.putIfAbsent(resourceClass, result);
if (prev != null) result = prev;
}
return result;
}
private static final ConcurrentMapClass? extends Resource,
AnnotationInfo cache =
new ConcurrentHashMapClass? extends Resource, AnnotationInfo();
Then you don't need getAnnotationDescriptors. You probably want a way to
clear cache entries if a class is reloaded, say.
You could get more fancy, with Futures and such, but I think that would
be wasted effort.
--tim
On Tue, Apr 7, 2009 at 1:20 PM, Tal Liron tal.li...@threecrickets.comwrote:
Ah, I can see your point now.
I would recommend, then, that a Context would have two separate
ConcurrentHashMaps, something like this:
1. Context.getConfiguration() -- this would be for the user
2. Context.getImplementationCache() -- this would be for things like
AnnotationUtils, and the user should not normally look at this, except
perhaps for debugging
-Tal
David Fogel wrote:
Hi Tal-
I think what you suggested about appending a classloader id (perhaps
System.identityHashCode(cl) ?) would work.
Regarding the Restlet Context and this cache being cruft: You say
the Context is a reasonable place for information that applies to the
Application, but this doesn't have annotation cache doesn't have
anything to do with my Application, it's related to a hidden
_implementation_ detail. As an end-user, we're not meant to be using
this annotion info cache directly. Yet the Context, as a very
prominent and unavoidable part of the Restlet public API is meant to
be used and understood. That's why I think it isn't a good place to
stash
Re: ServerResource is currently incompatible with OSGi
Tim... you seem to be agreeing with me, then, that
this does have something to do with the Application, and you are also
allowing for some redundancy in calculation and memory use, so, again,
why not just store it in the Application's Context, where all this is
taken care of automatically? I think Jerome's first instinct here may
have been the most straightforward.
Barring that, how about calling the clearCache in the Application's
release(), rather than stop()?
-Tal
Tim Peierls wrote:
I wouldn't recommend RRWL for this.
Since it's harmless to recompute the AnnotationInfos, I think
just having an AnnotationUtils.clearCache method would work well. Call
it whenever an Application stops, say. It's worth a little redundant
computation to avoid having to deal with shared locks and liveness.
--tim
On Thu, Apr 9, 2009 at 2:22 PM, Tal Liron tal.li...@threecrickets.com
wrote:
Oh, I didn't mean synchronizing the whole map.
I
actually didn't mean much beyond suggesting that we brainstorm a way to
use WeakReferences as keys in this particular case. I still don't have
a complete solution in mind.
Another idea: Perhaps we can use a ReentrantReadWrite lock around a
simple WeakHashMap? Since this is a "99% read" situation, most requests
won't need to acquire locks.
(ConcurrentHashMap is actually a very
complicated and delicately tuned class, and it would be anything but
trivial for us to try to re-implement it using WeakReferences.)
I know there are generic 3rd party solutions to this, but I know we'd
all prefer to use what Java 5 offers us right now. I'm sure we can
cobble together something that performs well!
-Tal
Tim Peierls wrote:
Did you read my subsequent e-mail that
talked about
opening an issue to make this more robust?
There is currently no standard concurrent map with weak
keys,
although MapMaker in Google Collections provides this and much more. An
effort to put something like this into Java 7 is under way, but there's
no telling whether it will actually happen.
Wrapping a WeakHashMap with synchronization is likely to be
a
performance bottleneck: every request has to grab a global lock.
--tim
On Wed, Apr 8, 2009 at 2:06 PM, Tal
Liron tal.li...@threecrickets.com
wrote:
Hmm.
I disagree that this has nothing to do with the Application.
For example, if an Application is unloaded, this cached information
will remain in the static field. In fact, there is no mechanism in
place right now clean this cache, and in dynamic environments (possibly
OSGi) it may accumulate "cruft." Not a huge problem, but this is the
stuff memory leaks are made of...
Here's
a thought: can we use a synchronized WeakHashMap here? That way, the
AnnotationInfo would be discarded when the class is unloaded.
-Tal
Jerome Louvel wrote:
Hi
all,
Beautiful!
This new solution is available in SVN
trunk.
Thanks Dave for
the report and Tim for the clever fix!
Best
regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~
Co-founder~ http://www.noelios.com
De: tpeie...@gmail.com
[mailto:tpeie...@gmail.com] De la part de
Tim Peierls
Envoy: mercredi 8 avril 2009 00:23
: discuss@restlet.tigris.org
Objet: Re: ServerResource is currently incompatible
with
OSGi
Why involve Context at all? The AnnotationInfo associated with a
Class? extends UniformResource does not depend on Context. You
could just add a method to AnnotationUtils:
public static AnnotationInfo
getAnnotationDescriptor(Class?
extends UniformResource resourceClass) {
AnnotationInfo result = cache.get(resourceClass);
if (result == null) {
result = computeAnnotationDescriptor(resourceClass); //
use
code
from existing getAnnotationDescriptors for this
AnnotationInfo prev = cache.putIfAbsent(resourceClass,
result);
if (prev != null) result = prev;
}
return result;
}
private static final ConcurrentMapClass? extends
Resource, AnnotationInfo cache =
new ConcurrentHashMapClass? extends
Resource,
AnnotationInfo();
Then you don't need getAnnotationDescriptors. You
probably
want
a way to clear cache entries if a class is reloaded, say.
You could get more fancy, with Futures and such, but I
think
that would be wasted effort.
--tim
On Tue, Apr 7, 2009 at 1:20 PM, Tal
Liron
Re: Annotations and Restlet's future
Hi
Jerome,
How
about instead of calling setAnnotated(false), there would be an
annotation to turn annotation on? Since this doesn't seem like behavior
you'd want to turn on or off during the life of the resource instance,
it seems like it should be defined at the class level, not in the
instance. Makes sense?
Maybe
something like this:
@Resource
class
ArticleResource extends ServerResource {
@Get("txt")
...
}
The
@Resource tag could also support parameters defining general
characteristics of the resource. Perhaps enabling conditional mode,
etc. Maybe it can even be a separate tag, such as @ConditionalResource.
What
I'm hoping is that if this tag is not present, annotated mode would be
off, which is what I think should be the default.
-Tal
Jerome Louvel wrote:
Hi all,
I haven't fully digested all this feed-back, but
it helps tremendously! Just to clarify a few points:
Rob correctly guessed my thoughts, annotations
should be a fullyoptional feature
I like to have this feature turned on by default
because it lowers the barrier of entry for new users. For experienced
Restlet developers, it's easy enough to override the "doInit()" method
and call "setAnnotated(false)".
Non-annotated
resources shouldn't impose any significant performance hit, even if the
"annotated" flag is turned on (annotation detection is done only once)
No additional annotation is expected in Restlet
1.2, we should stick with the current 5 public annotations
Exceptions are no rethrown for annotated methods
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder~ http://www.noelios.com
De: Rmi
Dewitte [mailto:remidewi...@gmail.com]
Envoy: vendredi 10 avril 2009 08:58
: discuss@restlet.tigris.org
Objet: Re: Annotations and Restlet's future
Hello,
I thank you all to clear my mind about annotations.
Annotations are probably good to get started with a hello world or
minimize the amount of code you would write. But you lose some
compilation checks and moreover developing further more complex
resources will require to understand how it works (routing/switch
logic) and which methods will not be called because of the use of
annotations. If I want to search for resources class will I have to
search for @Resource as well ? How far are we from annotated Restlets ?
Would it be possible to have ServerResource free of annotation logic
and an AnnotatedServerResource subclass removing the need for
isAnnotated ?
Cheers,
Rmi
On Thu, Apr 9, 2009 at 17:47, Rob Heittman rob.heitt...@solertium.com
wrote:
GWT
1.5/1.6 is happy with annotations at compile time ... but if the
implementation needs to examine them at runtime via reflection, GWT
doesn't have that capability. GWT getClass() emulation doesn't have
getAnnotations() ... or much of anything else. There's no reflection
in the _javascript_ room.
Restlet 1.2's current incarnation is fine with me ... annotations
optional. But I agree that the non-annotation and annotation approach
should use the same vowels and consonants in the same order whenever
possible :-) This helps us bears of very little brain.
On Thu, Apr 9, 2009 at 7:06 AM, Tim
Peierls t...@peierls.net
wrote:
On Thu, Apr 9, 2009 at 4:57 AM, Rob
Heittman rob.heitt...@solertium.com
wrote:
...my only *strong* requirement, that the annotation based
solution must remain a voluntary choice and not the only way to get
things done. It should remain possible to achieve whatever annotations
can achieve in a non-annotation way. This allows the basic API outline
to work in places where annotations are not available or work
differently enough to cause friction (pre-1.5 JVM backports, GWT, API
ports to other languages, Scala ...) It is OK with me if the
non-annotation approach requires verbosity or heavy lifting, it just
needs to exist.
Isn't that currently the case with the 1.2 branch? (Does GWT
not support annotations yet? I thought it did.)
It would be best if the non-annotation approach used the
same terminology as the annotations, and I think that's not the case
right now.
--tim
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
