Re: Mystery of @Post...
Thank you for the clarification. I made the changes you suggested (totally dropping the postJava() method). I tested this with the Java client (it worked, no surprise). I then tested it using the Apigee console - and it still worked (a little surprise). Then tested it with a Javascript (using Restlet's JavaScript edition) and it still worked (even more surprise). My surprise was that I thought that the "console" client and the "javascript" client would need a postComment(String jsonString) method and wouldn't be able to use the postComment(Comment comment). But that expectation was incorrect. I guess both those clients must have Jackon and Jackson extension jars somewhere on the cp. (note: I wasn't expecting your advice to fail, I was expecting my expectations to be broken - although it may require some time in the lotus position to parse that phrase :) ). Thanks also for the getChild() suggestion, I am sure that will also come in handy. The code is now a little cleaner and if the Restlet folks want me to put back the postJava() method to help with testing the connection negotiations, I will be happy to do so. Thanks again, RB -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7376533.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2936230
Re: Mystery of @Post...
On Thu, Mar 15, 2012 at 1:00 AM, Richard Berger wrote:
> I am now only using the @Post("java") method to be able to use:
> ClientResource client4 = new ClientResource(someURL);
> CommentsResource commentsResource = client4.wrap(CommentsResource.class);
> Representation representation4 = commentsResource.postJava(comment);
>
> rather than the more generic:
> ClientResource client4 = new ClientResource(someURL);
> Representation representation4 = client4.post(comment);
>
I'm saying you don't need the postJava method at all, even to compile. If
you care and have the time, try this:
@Post("json") Representation postComment(Comment comment);
@Post("form") Representation postCommentForm(Form form);
and make sure the client side has the Jackson and Jackson extension jars on
the classpath.
Btw, I have a nifty converter for the server side that uses Jackson to
deserialize Forms into Java objects; you could use this to shrink your
CommentsResource interface down to a single postComment method. I'll blog
about it.
Side note: I know it's just test code, but if you have a family of
resources rooted at "xxx/", it can be convenient to this code to re-use a
parent client resource:
ClientResource client4 = new ClientResource("xxx/");
CommentsResource commentsResource = client4.getChild("comments/",
CommentsResource.class);
Representation representation4 = commentsResource.postComment(comment);
In any case, it is working for me (in this somewhat roundabout way) - so no
> need to spend any more time in the lotus position. Unless of course, by
> lotus position, you mean in the driver's seat of a Lotus Elise :)
>
More like the driver's seat of a Lotus spreadsheet. :-(
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2936134
Re: Mystery of @Post...
I am now only using the @Post("java") method to be able to use:
ClientResource client4 = new ClientResource(someURL);
CommentsResource commentsResource = client4.wrap(CommentsResource.class);
Representation representation4 = commentsResource.postJava(comment);
rather than the more generic:
ClientResource client4 = new ClientResource(someURL);
Representation representation4 = client4.post(commitment3);
my postJava() method doesn't do anything, it exists only to allow the code
to compile. And since this is just a test case, it was convenient to be
able to make the call with a Java object (although I guess it would be just
one line of code to create a Json string).
In any case, it is working for me (in this somewhat roundabout way) - so no
need to spend any more time in the lotus position. Unless of course, by
lotus position, you mean in the driver's seat of a Lotus Elise :)
Thanks again for your thoughts!
RB
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7374467.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2936004
Re: Mystery of @Post...
On Wed, Mar 14, 2012 at 11:22 PM, Richard Berger
wrote:
> Is it possible that when seeing the following code: (from my test case)
>
> Comment comment = new Comment("Hi there from Java", new Date());
> Representation representation4 = commentsResource.postJava(comment);
>
> the fact that I am using Jackson somehow instructs the system to convert my
> Java object (comment) into Json and since it is now in Json, the postJson
> method is called.
>
As I said, the conneg and conversion dance is delicate. I think it's a
server-side problem, not with Jackson itself, but due to the Jackson
extension jar (org.restlet.ext.jackson.jar), which registers
JacksonConverter with the Restlet Engine.
Because the order that converters are registered with the Engine is
dependent on classloader behavior and thus not predictable in general, the
decision of which converter to use has been designed to be
order-independent, using complicated scoring and client preference
adjustment logic that I can never keep in my head for more than a few
minutes at a time, and then only after sitting in a lotus position for an
hour. :-)
So ... sorry, but this is one that the Restlet guys will have to tackle for
you.
But my advice is to drop the @Post("java") option entirely. Jackson
serialization is very fast and reasonably compact, it works with objects
that don't implement java.io.Serializable, and you can exchange JSON
representations with non-Java clients. If you really want a compact binary
format that can be processed quickly, one line of code can instruct Jackson
to work in terms of the binary Smile format.
There is a learning curve to Jackson, but it has been well worth it for me:
- I've written generic implementations of equals and hashCode for my
Java representation types so I can use them in collections and maps, by
comparing and hashing serialized forms. (I can selectively override them if
I need to for speed, but I haven't needed to yet.)
- I've written generic copy and update methods similarly. (No clones
here!)
- I've implemented serializability for a data-grid library I use
(Hazelcast) in terms of Smile.
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935973
Re: Mystery of @Post...
Thank you for the suggestions (I especially liked having the annotations only
in the interface). But no difference...
After removing the annotations from the implementation, the output was:
Mar 14, 2012 8:13:44 PM com.fourspires.api.server.CommentsServerResource
postJson
INFO: In postJson
Mar 14, 2012 8:13:45 PM com.fourspires.api.server.DAO save
INFO: saving comment
Then after re-ordering the methods in both interface and server
implementation, the output was:
Mar 14, 2012 8:16:47 PM com.fourspires.api.server.CommentsServerResource
postJson
INFO: In postJson
Mar 14, 2012 8:16:49 PM com.fourspires.api.server.DAO save
INFO: saving comment
Is it possible that when seeing the following code: (from my test case)
Comment comment = new Comment("Hi there from Java", new Date());
Representation representation4 = commentsResource.postJava(comment);
the fact that I am using Jackson somehow instructs the system to convert my
Java object (comment) into Json and since it is now in Json, the postJson
method is called. Yes, it is a bit of a long shot and does introduce the
"somehow" (as if by magic) into the explanation :).
Thanks for pondering this!
RB
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7374224.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935907
Re: Mystery of @Post...
I don't think it's a Jackson bug. It might be an over-eagerness on the part
of org.restlet.ext.jackson.JacksonConverter, though. The conneg stuff can
be a bit delicate.
Try this: Remove any @Post annotations from the ServerResource
implementation (leave them on the interface) and try change the order of
method declaration (in both interface and implementation) to postJava,
postJson, postForm.
(Also, probably doesn't matter, but use (@Post("form:html") unless you
really are returning a FormRepresentation.)
--tim
On Wed, Mar 14, 2012 at 10:12 PM, Richard Berger
wrote:
> I downloaded the 3/14 snapshot of 2.2 and I don't see a change. Two
> points...
>
> 1. This may not be a bug - this may only be a conflict with my expectations
> 2. If this is a bug, is it possible that it is a Jackson problem and not a
> Restlet problem?
>
> Please let me know if I can provide additional information.
>
> Thanks!
> RB
>
> --
> View this message in context:
> http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7374095.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935803
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935849
Re: Mystery of @Post...
I downloaded the 3/14 snapshot of 2.2 and I don't see a change. Two points... 1. This may not be a bug - this may only be a conflict with my expectations 2. If this is a bug, is it possible that it is a Jackson problem and not a Restlet problem? Please let me know if I can provide additional information. Thanks! RB -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7374095.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935803
Re: Mystery of @Post...
Hello Richard,
Can you make a test with the latest snapshot? I think that the problem
is fixed now...
Tell me if it's the case. Thanks.
Thierry
> First, the good news. My code is working. But I don't understand WHY it
> works.
>
> Using Restlet and the "Annotated Interface" approach, described at
> http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/328-restlet/285-restlet.html.
> I am also running Restlet GAE (if that matters).
>
> I am using Post to add a new Comment to a collection of Comments, so my
> CommentsResource interface has the following:
>@Post("json")
>public Representation postJson(String value);
>
>@Post("java")
>public Representation postJava(Comment comment);
>
>@Post("form")
>public Representation postForm(Form form);
>
> And my CommentsServerResource class that implements this interface has three
> corresponding implementations, each of which is annotated to match the
> methods in the interface.
>
> Now I write a test case in Java. The essence is:
> ClientResource client4 = new ClientResource("xxx/comments/");
> CommentsResource commentsResource =
> client4.wrap(CommentsResource.class);
> client4.setRequestEntityBuffering(true); //
> stackoverflow.com/questions/6462142
> Comment comment = new Comment("Hi there from Java", new Date());
> Representation representation4 = commentsResource.postJava(comment);
>
> And the big mystery is that the postJava() method is NOT called, but rather
> the postJson() method IS called. And somehow my Comment object was
> magically converted to a Json string. It's kinda cool that it works this
> way, but I am sure I am missing something (in addition to my lack of IQ
> points, which must be obvious by now :) :) ).
>
> RB
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2935421
Mystery of @Post...
First, the good news. My code is working. But I don't understand WHY it
works.
Using Restlet and the "Annotated Interface" approach, described at
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/328-restlet/285-restlet.html.
I am also running Restlet GAE (if that matters).
I am using Post to add a new Comment to a collection of Comments, so my
CommentsResource interface has the following:
@Post("json")
public Representation postJson(String value);
@Post("java")
public Representation postJava(Comment comment);
@Post("form")
public Representation postForm(Form form);
And my CommentsServerResource class that implements this interface has three
corresponding implementations, each of which is annotated to match the
methods in the interface.
Now I write a test case in Java. The essence is:
ClientResource client4 = new ClientResource("xxx/comments/");
CommentsResource commentsResource =
client4.wrap(CommentsResource.class);
client4.setRequestEntityBuffering(true); //
stackoverflow.com/questions/6462142
Comment comment = new Comment("Hi there from Java", new Date());
Representation representation4 = commentsResource.postJava(comment);
And the big mystery is that the postJava() method is NOT called, but rather
the postJson() method IS called. And somehow my Comment object was
magically converted to a Json string. It's kinda cool that it works this
way, but I am sure I am missing something (in addition to my lack of IQ
points, which must be obvious by now :) :) ).
RB
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/Mystery-of-Post-tp7338202p7338202.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2928866
