RE: Annotations and Restlet's future
Hi Tal,
Again, if there is no annotation declared on a ServerResource subclass,
there is nearly no cost for testing for the presence of those annotations.
Hence, it is not really necessary to call setAnnotated(false).
I don't want to add a new annotation for this. The fact that a class is a
resource is based on the class hierarchy (extending ServerResource), no need
to mark it with an additional annotation IMO.
Regarding other annotations, I don't want to go further on the JAX-RS road.
I really don't see the issue of calling a setter method to turn off
conditional processing, otherwise we risk using annotations as the
programming language.
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é : dimanche 12 avril 2009 22:08
À : discuss@restlet.tigris.org
Objet : 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 fully
optional 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/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com
_
De : Rémi 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,
Rémi
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
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: Annotations and Restlet's future
Hi Daid, (It turns out the JAX-RS spec is unusually short and comprehensible, which is unusual for these enterprisey specs. The downside is that it's short partly because they left out a little too much, and JAX-RS is essentially not a stand-alone technology, you pretty much need some sort of injection container around it, which the spec ignores, BTW: that's the same in Restlet: you need a container, that calls the Filters, the Resources and so on. Here it is the Restlet Engine and so on, and there it is a JAX-RS container. What's the difference? and therefore there's effectively no way to write portable jax-rs code for any application that does anything interesting, like accessing stored data, for instance.) Why you can't write portable applications? You could e.g. use JDBC or Hibernate. That's portable, or why not? And one problem for people trying to automate the mapping of requests onto java methods is that, until recently, java methods didn't provide much in the way of places to stick data about themselves. That's annotations are made for. But I think, you know it :-), and I miss or missunderstand something. I did a number of experiments comparing how to implement the same resources in Restlet and in Jax-RS, and for the most part the only difference was the presence of this routing code in the Restlet version, which got replaced by a couple of easy-to-understand annotations. Right, IMO (also as member of the JAX-RS expert group and developer of the JAX-RS extension). The routing code is boilerplate code. It is needed, if you don't use something like annotations. And because boilerplate code induces bugs, so avoid the need for it. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1648220
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, Rémi On Thu, Apr 9, 2009 at 17:47, Rob Heittman rob.heitt...@solertium.comwrote: 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.comwrote: ...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 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1625766
RE: Annotations and Restlet's future
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 fully optional 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/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com _ De : Rémi 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, Rémi 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 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1633999
Re: Annotations and Restlet's future
Good treatment, Dave, not too long :-) I do agree with your thoughts generally ... except to harp on 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. I can indeed see the benefit of writing many Resources more economically and intelligently with the right annotations ... and I also think, used consistently, this could help with my little dream of producing a machine and human readable REST interface specification that gives a large chunk of the enterprise value of WADL and WSDL without any of the associated misery. So, to sum up what has been a much-too-long post, I'm convinced that it's desireable to attempt to replace the unavoidable writing of routing code with annotations on target methods, as long as the annotations are clear, self-explanatory, and don't try to hide too much magic. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1611242
Re: Annotations and Restlet's future
On Wed, Apr 8, 2009 at 8:15 PM, Rob Heittman rob.heitt...@solertium.comwrote: Or, to solve the confusion, it may be as simple as modulating the annotation names. I don't know: @ResourceGets(form) instead of @Get(form) or such. This would make clear that it's a Restlet thing and not an abstract standards-driven RESTful markup thing. Or @Accepts, @Stores, and friends, from the 1.1 method names. I could go either way. The risk that @Get will be confused with @GET is there, but I'd hate to be bullied out of the space. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1607097
Re: Annotations and Restlet's future
On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman rob.heitt...@solertium.comwrote: ...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 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1612961
Re: Annotations and Restlet's future
It seems like I'm the only one here working with non-annotated ServerResources right now, so I'd chime in and add that you actually need to override more than method for each REST method as it stands. There's get(), get(variant), post(entity), post(entity, variant), put(entity), put(entity, variant), delete(), delete(variant). Also, all these methods are allowed to throw ResourceExceptions, but annotated handlers cannot. So, it at stands, non-annotated and annotated mode are currently very different. Also, it seems that annotated mode is turned on by default, and that you have to explicitly turn it off in doInit(). I'm sure some of us would prefer this to be the other way around! Or perhaps automatic detection of some sort? -Tal Tim Peierls 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: Annotations and Restlet's future
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.comwrote: ...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 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1618441
Re: Annotations and Restlet's future
I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596551
Re: Annotations and Restlet's future
Hi Rémi, Will annotations in restlet the advertised way of creating restlet application ? I moved to Restlet 1.2 M2/snapshot without using annotations. I found no reason why these annotations will help me. Everything works fine without annotations and I think/hope Restlet won't force us to use them in the near future. Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1600565
Re: Annotations and Restlet's future
I would agree with that as a guide (and I think it is what Jerome has in mind) ... the annotations are nice for people who like them. It seems Jerome is striving for something very terse that supplants boilerplate in a number of common cases, which I can see is a nice goal. But if annotations were ever *required* to get things done, it would cause some real problems for me. On Wed, Apr 8, 2009 at 2:58 PM, Lars Heuer he...@semagia.com wrote: I moved to Restlet 1.2 M2/snapshot without using annotations. I found no reason why these annotations will help me. Everything works fine without annotations and I think/hope Restlet won't force us to use them in the near future. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1601018
Re: Annotations and Restlet's future
Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1604346
Re: Annotations and Restlet's future
JAX-RS = JSR 311. JAX-RS is available as a Restlet extension. I'll point out one elephant in the room, though: the JAX-RS extension has not yet received the same level of attention as other Restlet extensions that were developed by the core Noelios team. Even the Restlet-GWT extension I lead was mainly ported by Jerome ... I just helped over implementation hurdles and provided concrete use cases and documentation. Anyway. The JAX-RS extension doesn't feel as finished as the core of the project, because it's not. This probably ain't right. Also: JAX-RS feels a lot to me like JPA. I can mark up any old POJO with annotations that brilliantly, even miraculously generate glue for a particular paradigm (REST or relational persistence). But, to me, either one still amounts to a very lovely, silver filigreed, impeccably wrought glue gun. If I'm writing RESTful web services, I want a thoroughly RESTful architecture surrounding me, dammit ... which is what Restlet provides. I want my Resources to know all about it and leverage it to the hilt. They are where the rubber meets the road; where the underlying system is modeled in a RESTful way. So I'm kind of like Lars here, a conscientious annotation objector :-) But I also think I see what Jerome is doing too -- providing annotations that aren't meant to be a generalized glue gun, but a way to straightforwardly tell Restlet things that might take a lot of boilerplate to do otherwise. This is a neat idea. It seems like it's not meant to be a generic RESTify your POJO mechanism -- which JAX-RS already is -- but a way to author Restlet Resources with less effort and perhaps even less pratfalls. I haven't played with it enough to know whether it fills that role effectively ... I may not get a chance before it's too late to really comment. The broader concern I have ... well, I vainly think I see the point of the new Resource annotations because I have become a hard core Restlet developer. Still, what does a newbie think? It's confusing to have two slightly different annotation systems in play at once. It looks like Restlet is taking on JAX-RS with an alternative, and the user must choose one. The message traffic seems to reflect this confusion is already happening. I think having a Restlet @Get(form) and a JAX-RS @GET is probably more confusion than a lot of folks can swallow. Hibernate seems to have played it well by heavily internalizing the JPA spec, using JPA where it fits, and providing custom annotations where it doesn't. Maybe wrapping JAX-RS in a tighter embrace and making it more core to Restlet is part of the solution. Or, to solve the confusion, it may be as simple as modulating the annotation names. I don't know: @ResourceGets(form) instead of @Get(form) or such. This would make clear that it's a Restlet thing and not an abstract standards-driven RESTful markup thing. Anyway ... my personal preference is to leave the darned things out entirely, so perhaps I oughtn't to be operating my keyboard to comment on this. I only like to use annotations for purely compile-time code management purposes (@ThreadSafe, @SuppressWarnings) and not really ever for functional purposes. Pass the boilerplate and a side of fries. - Rob On Wed, Apr 8, 2009 at 7:35 PM, Erik Beeson erik.bee...@gmail.com wrote: Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1604945
Re: Annotations and Restlet's future
+1 I.e., what Rob said. Take care, John On Apr 8, 2009, at 17:15 , Rob Heittman wrote: JAX-RS = JSR 311. JAX-RS is available as a Restlet extension. I'll point out one elephant in the room, though: the JAX-RS extension has not yet received the same level of attention as other Restlet extensions that were developed by the core Noelios team. Even the Restlet-GWT extension I lead was mainly ported by Jerome ... I just helped over implementation hurdles and provided concrete use cases and documentation. Anyway. The JAX-RS extension doesn't feel as finished as the core of the project, because it's not. This probably ain't right. Also: JAX-RS feels a lot to me like JPA. I can mark up any old POJO with annotations that brilliantly, even miraculously generate glue for a particular paradigm (REST or relational persistence). But, to me, either one still amounts to a very lovely, silver filigreed, impeccably wrought glue gun. If I'm writing RESTful web services, I want a thoroughly RESTful architecture surrounding me, dammit ... which is what Restlet provides. I want my Resources to know all about it and leverage it to the hilt. They are where the rubber meets the road; where the underlying system is modeled in a RESTful way. So I'm kind of like Lars here, a conscientious annotation objector :-) But I also think I see what Jerome is doing too -- providing annotations that aren't meant to be a generalized glue gun, but a way to straightforwardly tell Restlet things that might take a lot of boilerplate to do otherwise. This is a neat idea. It seems like it's not meant to be a generic RESTify your POJO mechanism -- which JAX-RS already is -- but a way to author Restlet Resources with less effort and perhaps even less pratfalls. I haven't played with it enough to know whether it fills that role effectively ... I may not get a chance before it's too late to really comment. The broader concern I have ... well, I vainly think I see the point of the new Resource annotations because I have become a hard core Restlet developer. Still, what does a newbie think? It's confusing to have two slightly different annotation systems in play at once. It looks like Restlet is taking on JAX-RS with an alternative, and the user must choose one. The message traffic seems to reflect this confusion is already happening. I think having a Restlet @Get(form) and a JAX-RS @GET is probably more confusion than a lot of folks can swallow. Hibernate seems to have played it well by heavily internalizing the JPA spec, using JPA where it fits, and providing custom annotations where it doesn't. Maybe wrapping JAX-RS in a tighter embrace and making it more core to Restlet is part of the solution. Or, to solve the confusion, it may be as simple as modulating the annotation names. I don't know: @ResourceGets(form) instead of @Get(form) or such. This would make clear that it's a Restlet thing and not an abstract standards-driven RESTful markup thing. Anyway ... my personal preference is to leave the darned things out entirely, so perhaps I oughtn't to be operating my keyboard to comment on this. I only like to use annotations for purely compile- time code management purposes (@ThreadSafe, @SuppressWarnings) and not really ever for functional purposes. Pass the boilerplate and a side of fries. - Rob On Wed, Apr 8, 2009 at 7:35 PM, Erik Beeson erik.bee...@gmail.com wrote: Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1606738
Re: Annotations and Restlet's future
Nicely
put, Rob.
I
have to agree in the general sense. I'd even add that annotations are
one of the most abused features in Java, and I often regret their
introduction into the language. For every problem solved elegantly with
an annotation, you'd find ten solutions made worse. Sometimes, I even
miss the days where everything was turned into an XML configuration.
I've seen JEE projects mixing JSF, Spring and other annotation-based
data frameworks until methods accumulated ten different annotations!
How does that help anyone?
Part
of why I prefer Java, as a language, to other languages in the C family
is that it doesn't have things like operator overriding or hidden
finalizers or magic run-time type information handling. In Java, you
always can tell immediately what methods are being called in a section
of code. Compare with C++ or C# where a section of code might have
hidden method calls that aren't apparent without a very smartly
colorizing IDE. C++ is probably the most easy-to-abuse language for
this reason.
But
let's focus on the very specific use for annotations in the case of
ServerResource: they save you from writing your own switching method.
Without annotations, you would have to override a method (actually,
you'd need to override several at the moment -- the non-annotated
ServerResource is still a bit of a mess right now), do your own
checking of variants or whatever, and from there call the appropriate
method. The annotations handle that boilerplate code for you.
The
rule of thumb for good annotations, as far as I'm concerned, is that
you can look at the annotation and still in your mind clearly see what
the boilerplate code would look like. The moment you get into magical
"it just works" mechanisms, I turn into Rob. :) POJOs magically
serializing themselves into databases or flying about as part of EJB
transactions sounds nice until the first bug appears. And then you
would give your left leg for regular, non-generic, procedural code you
can look at with your own two eyes.
As
it stands, ServerResource annotations are just at about the tipping
point for me. There are two different modes supported in the background
(negotiated and conditional) in addition to annotated vs.
non-annotated, and I honestly have no clue what goes on unless I step
slowly with the debugger.
Jerome,
I'm sure things will get a lot clearer as we reach the 1.2 release.
But, you did ask for feedback, so here it is. Java developers are a
skeptical bunch. If we believed in magic, we'd be programming in Ruby.
;)
-Tal
Rob Heittman wrote:
JAX-RS = JSR 311. JAX-RS is available as a Restlet
extension.
I'll point out one elephant in the room, though: the JAX-RS
extension has not yet received the same level of attention as other
Restlet extensions that were developed by the core Noelios team. Even
the Restlet-GWT extension I lead was mainly ported by Jerome ... I just
helped over implementation hurdles and provided concrete use cases and
documentation. Anyway. The JAX-RS extension doesn't feel as
"finished" as the core of the project, because it's not. This probably
ain't right.
Also: JAX-RS feels a lot to me like JPA. I can mark up any old
POJO with annotations that brilliantly, even miraculously generate glue
for a particular paradigm (REST or relational persistence). But, to
me, either one still amounts to a very lovely, silver filigreed,
impeccably wrought glue gun.
If I'm writing RESTful web services, I want a thoroughly RESTful
architecture surrounding me, dammit ... which is what Restlet provides.
I want my Resources to know all about it and leverage it to the hilt.
They are where the rubber meets the road; where the underlying system
is modeled in a RESTful way.
So I'm kind of like Lars here, a conscientious annotation
objector :-) But I also think I see what Jerome is doing too --
providing annotations that aren't meant to be a generalized glue gun,
but a way to straightforwardly tell Restlet things that might take a
lot of boilerplate to do otherwise. This is a neat idea. It seems
like it's not meant to be a generic "RESTify your POJO" mechanism --
which JAX-RS already is -- but a way to author Restlet Resources with
less effort and perhaps even less pratfalls. I haven't played with it
enough to know whether it fills that role effectively ... I may not get
a chance before it's too late to really comment.
The broader concern I have ... well, I vainly think I see the
point of the new Resource annotations because I have become a hard core
Restlet developer. Still, what does a newbie think? It's confusing to
have two slightly different annotation systems in play at once. It
looks like Restlet is taking on JAX-RS with an alternative, and the
user must choose one. The message traffic seems to reflect this
confusion is already happening. I think having a Restlet @Get("form")
and a JAX-RS @GET is probably more confusion than a lot of folks can
swallow.
Re: Annotations and Restlet's future
Hi All- Well, I almost can't believe I'm saying this, but I'd like to weigh in on the side of considering Annotation-based approaches to writing resources in Restlet. (Although I'm not so sure about Jerome's current plan.) I've mostly disliked, and sometimes despised, the use of Annotations in most of the places I've encountered them, for many of the same reasons some of you have mentioned. I don't like the way they're used in hibernate and JPA (predicting what will happen with those annotated classes is difficult), I was initially excited by the idea of all-java config in google's Guice framework until I realized what my classes would look like with all the annotations. And I don't even really like the simple @Override convention for labeling methods (I figure the tools could probably figure it out without the annotation). But a few months ago I forced myself to read through the JX-RS spec in a fit of due-diligence, while at the same time going through the process of re-familiarizing myself with the state of the Restlet project, which I hadn't looked at since before 1.1. And it modified my thoughts on annotations. (It turns out the JAX-RS spec is unusually short and comprehensible, which is unusual for these enterprisey specs. The downside is that it's short partly because they left out a little too much, and JAX-RS is essentially not a stand-alone technology, you pretty much need some sort of injection container around it, which the spec ignores, and therefore there's effectively no way to write portable jax-rs code for any application that does anything interesting, like accessing stored data, for instance.) Both Restlet and Jax-RS provide a framework for implementing conceptual resources as sets of handler methods on a java class. From the perspective of the resource class author, these handler methods are the main public api of your class- routing happens somewhere else in the container. Additionally, both Restlet and JAX-RS recommend that these Resource instances be per-request in scope, so they really don't have much of a lifecycle, or many reciprocal interactions with other parts of the application. By the time any of the custom handler methods get called, all the routing and much of the details of the HTTP protocol have been taken care of by the container. The main difference between JAX-RS and Restlet is that JAX-RS puts as much of the code to handle the content negotiation and other protocol issues into the container (and so alllows its Resource classes to be superclass-less POJOs), while Restlet puts this code into the mandated Resource (now ServerResource) base-classes, where it is more accessible and allows greater customization. Anyhow, my point is that the main challenge seems to me to be in sorting out which of the handler methods should get called. And this ends up being all about metadata- the metadata of the conceptual Resource combining with the metadata attached to the HTTP requests. And one problem for people trying to automate the mapping of requests onto java methods is that, until recently, java methods didn't provide much in the way of places to stick data about themselves. I am personally guilty of having written frameworks that resorted to method naming patterns as a way around this, and it's, well, not elegant. But if there's one appropriate use of Annotations it might be to add data _about_ methods, specifically _public_ methods. (The reason I don't like seeing annotations used to decorate private member fields is that these fields are supposed to be private, hidden implementation details, not something for outside things to mess around with.) There's really no way of getting around the need to associate some data (like text/html) with some handler method. And if you don't use annotations to do this, then you have to capture that association in what becomes effectively routing code. I did a number of experiments comparing how to implement the same resources in Restlet and in Jax-RS, and for the most part the only difference was the presence of this routing code in the Restlet version, which got replaced by a couple of easy-to-understand annotations. So, to sum up what has been a much-too-long post, I'm convinced that it's desireable to attempt to replace the unavoidable writing of routing code with annotations on target methods, as long as the annotations are clear, self-explanatory, and don't try to hide too much magic. -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1609318
