Mike Traynor | 1 Dec 04:47 2011
Picon

Re: Re: Validating URL query parameters.

On Tue, Nov 29, 2011 at 11:55 PM, Mark Kharitonov <mark.kharitonov <at> gmail.com> wrote:

Why do you say that the POST operation applies to the Users resource? I was thinking that I do POST of a User resource, hence the POST operation applies to the User resource. But I also understand your reasoning, because one can say that POST of a User resource affects some Users resource.

However, I want to be free to decide how to treat the POST request and usually I find it more convenient to keep it bundled together with the GET, PUT and DELETE because together they form the CRUD of a single entity type - User. And here I am forced to split the CRUD into C and RUD, because of the constraints of the underlying framework. Previously, I have worked with the OpenRasta framework (.NET), which does not impose such limitations.
 
POST implies creating a new user.  This means the resource you are operating on is the **list of users**, since the resource for the new user does not exist until after the POST operation.  You can't operate on your resource until it exists :)
 
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889231

Arjohn Kampman | 1 Dec 15:15 2011

Serious bug in ClientResource

Hi all,

I think I've run into a serious bug in ClientResource. I've found this
in method handle(Method method, Object entity, Class<T> resultClass) in
restlet 2.0.10, but 2.1.x seems to be affected too.

What I think is wrong with this method is that it uses the variants for
the response to convert the request entity to a representation. Imagine
doing the following call:

    clientResource.post("1234", Integer.class)

ClientResource.handle(...) will try to convert the string "1234" to a
representation using a converter for integers. This will succeed with
the DefaultConverter as it happens to be able to encode both strings and
integers, but in other situations it will fail misserably.

I hope you can fix this soon. Are there any work-arounds that I can use
until then?

--

-- 
Arjohn Kampman - www.aduna-software.com

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889634

Tim Peierls | 1 Dec 15:56 2011
Picon

Re: Re: Restlet vs JAX-RS

On Wed, Nov 30, 2011 at 5:37 PM, Ivan <ivan.bodunov <at> gmail.com> wrote:
Say, user needs to build RESTful HTTP services. He can do it using either frameworks with proprietary API (like Restlet, Restfulie) or frameworks supporting JAX-RS API (like Jersey, Apache CXF and Restlet as well). I would agree they are incomparable things but at then end they serve the same purpose. So, selecting from your list the question is more about choosing between JAX-RS annotations and the Restlet annotations. But I think (from my limited Restlet knowledge) the difference is much more than just annotations.

Check out the Restlet wiki for an overview of the many things that Restlet provides beyond annotations for resource classes.

The two flavors of annotation are pretty similar, and, as you say, Restlet can work with either flavor, so if you're using Restlet, the decision between them comes down to personal preference. For example, I like the way the Restlet API separates the routing behavior (mapping URI to resource) from the resource behavior (methods marked <at> Get, <at> Put, etc.), allowing me to put the routing logic for an application all in one place. JAX-RS <at> Path annotations scatter the routing among many resource classes (although I wouldn't be surprised to find that it's possible to use a hybrid approach of JAX-RS annotations with Restlet routing).

--tim
Tim Peierls | 1 Dec 16:12 2011
Picon

Re: Integrating a 3rd party Dependency Injection engine with JAX-RS extension.

I wonder if addressing issue 1230 would also pave the way to a nice solution here. The common problem is the lack of pluggable resource instance creation at the application or component level.


--tim

On Wed, Nov 30, 2011 at 4:33 PM, Mark Kharitonov <mark.kharitonov <at> gmail.com> wrote:
I am using google guice and wish to integrate it with the JAX-RS extension. On the surface, everything is simple and clean:

   final JaxRsApplication application = new JaxRsApplication(component.getContext().createChildContext());
   application.setObjectFactory(new ObjectFactory() {

      <at> Override
     public <T> T getInstance(Class<T> jaxRsClass) throws InstantiateException {
       return Injector.getInstance(jaxRsClass);
     }
   });

True, when JAX-RS wishes to create an instance of a resource handler it consults the object factory first, which is excellent. But, there are certain validations that JAX-RS performs on the resource handler type and these validations totally ignore the presence of an object factory. Observer the following stack trace:

WrapperUtil.findJaxRsConstructor(Class<?>, String) line: 242
PerRequestRootResourceClass(RootResourceClass).<init>(Class<?>, ThreadLocalizedContext, JaxRsProviders, ExtensionBackwardMapping, Logger) line: 141
PerRequestRootResourceClass.<init>(Class<?>, ThreadLocalizedContext, JaxRsProviders, ExtensionBackwardMapping, Logger) line: 82
ResourceClasses.getPerRequestRootClassWrapper(Class<?>) line: 276
ResourceClasses.addRootClass(Class<?>) line: 104
JaxRsRestlet.addClass(Class<?>) line: 283
JaxRsApplication.add(Application) line: 149
Program.main(String[]) line: 60

What happens is that JAX-RS looks for the public constructors satisfying its instance creation constraints. In my case, the resource handler class has a single public non default constructor not annotated with any of the JAX-RS attributes. Indeed, this constructor is invoked by the dependency injection engine only (guice in my case) from the object factory.

I think, that JAX-RS should not fail if it does not find any suitable constructor and the object factory is registered. Seems like a bug?

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889440

Stephan Koops | 1 Dec 18:15 2011
Picon

Re: Re: Restlet vs JAX-RS

Hi,

what I forgot in my last email:
In JAX-RS you are not required to call the serialisation / deserialisation logic. You implement the
MessageBodyReader/Writer, give it to the ruintime environment, and they are called by the JAX-RS
runtime. In Restlet you have to check the media type the client sent, decide which Deserialzer you have to
use and call the deserialization. The same at the end: Check the accepted media types, decide and call the
serialization. in JAX-RS you are not required to care about that, because the runtime will do it.

best regards
   Stephan

-----Ursprüngliche Nachricht-----
Von: Ivan <ivan.bodunov <at> gmail.com>
Gesendet: 30.11.2011 23:37:44
An: discuss <at> restlet.tigris.org
Betreff: RE: Re: Restlet vs JAX-RS

>Say, user needs to build RESTful HTTP services. He can do it using either frameworks with proprietary API
(like Restlet, Restfulie) or frameworks supporting JAX-RS API (like Jersey, Apache CXF and Restlet as
well). I would agree they are incomparable things but at then end they serve the same purpose. So,
selecting from your list the question is more about choosing between JAX-RS annotations and the Restlet
annotations. But I think (from my limited Restlet knowledge) the difference is much more than just annotations.
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889676

Stephan Koops | 1 Dec 18:20 2011
Picon

Re: Re: Validating URL query parameters.

<html><head></head><body bgcolor='#FFFFFF'
style='font-size:10pt;background-color:#FFFFFF;font-family:Verdana, Arial, sans-serif;'>Hi,<br/>
<br/>
&gt; You can't operate on your resource until it exists :)<br/>
<br/>
That's not fully true: You could create it with PUT. But you have to remeber, that you have not a generated
primary key, if you need it. But maybe you could PUT to ..../users/&lt;theShortNameOfYourUser&gt; . But
then it is possible that you override an existing user with the same short name.<br/>
It is the best, to create a user via the users resource.<br/>
<br/>
best regards<br/>
&nbsp;&nbsp;&nbsp; Stephan&nbsp;&nbsp;<br><br><table cellpadding="0" cellspacing="0"
border="0"><tr><td bgcolor="#000000"><img src="https://img.ui-portal.de/p.gif" width="1"
height="1" border="0" alt="" /></td></tr><tr><td style="font-family:verdana; font-size:12px;
line-height:17px;">SMS schreiben mit WEB.DE FreeMail - einfach, schnell
und&nbsp;&nbsp;&nbsp;<br>kostenguenstig. Jetzt gleich testen! <a href="http://f.web.de/?mc=021192"><b>http://f.web.de/?mc=021192</b></a></td></tr></table>
</body></html>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889680

Stephan Koops | 1 Dec 18:25 2011
Picon

Re: Re: Wrong media type is selected for the GET request with JAX-RS

Hi Mark,

you are right. I forgot the generic providers. Then there is the bug in the runtime, which you showed. Or
there is a bug in the algorithm defined by the spec. But that's implausible ...
Feel free to fix it and post a patch for it.

best regards
    Stephan

-----Ursprüngliche Nachricht-----
Von: "Mark Kharitonov" <mark.kharitonov <at> gmail.com>
Gesendet: 30.11.2011 21:49:31
An: discuss <at> restlet.tigris.org
Betreff: RE: Re: Wrong media type is selected for the GET request with JAX-RS

>You are wrong. The framework suggests three message body writers without a single bit of help from me:
> - org.restlet.ext.jax​rs.internal.provider​.JaxbProvider
> - org.restlet.ext.jaxr​s.internal.provider.​ConverterProvider
> - org.restlet.ext.jaxr​s.internal.provider.​JsonProvider
>
>Both JaxbProvider and ​JsonProvider have no problems converting com.shunra.poc.User into the
respective XML or JSON representation.

___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889681

Stephan Koops | 1 Dec 18:27 2011
Picon

Re: Integrating a 3rd party Dependency Injection engine with JAX-RS extension.

Hi Mark,

you are right, there is room for improvement.
You could call it a bug or a feature request ...

best regards
    Stephan

-----Ursprüngliche Nachricht-----
Von: "Mark Kharitonov" <mark.kharitonov <at> gmail.com>
Gesendet: 30.11.2011 22:33:28
An: discuss <at> restlet.tigris.org
Betreff: Integrating a 3rd party Dependency Injection engine with JAX-RS extension.

>I am using google guice and wish to integrate it with the JAX-RS extension. On the surface, everything is
simple and clean:
>
> final JaxRsApplication application = new JaxRsApplication(component.getContext().createChildContext());
> application.setObjectFactory(new ObjectFactory() {
>
>  <at> Override
> public <T> T getInstance(Class<T> jaxRsClass) throws InstantiateException {
> return Injector.getInstance(jaxRsClass);
> }
> });
>
>True, when JAX-RS wishes to create an instance of a resource handler it consults the object factory first,
which is excellent. But, there are certain validations that JAX-RS performs on the resource handler type
and these validations totally ignore the presence of an object factory. Observer the following stack trace:
>
>WrapperUtil.findJaxRsConstructor(Class<?>, String) line: 242
>PerRequestRootResourceClass(RootResourceClass).<init>(Class<?>, ThreadLocalizedContext,
JaxRsProviders, ExtensionBackwardMapping, Logger) line: 141
>PerRequestRootResourceClass.<init>(Class<?>, ThreadLocalizedContext, JaxRsProviders,
ExtensionBackwardMapping, Logger) line: 82
>ResourceClasses.getPerRequestRootClassWrapper(Class<?>) line: 276
>ResourceClasses.addRootClass(Class<?>) line: 104
>JaxRsRestlet.addClass(Class<?>) line: 283
>JaxRsApplication.add(Application) line: 149
>Program.main(String[]) line: 60
>
>What happens is that JAX-RS looks for the public constructors satisfying its instance creation
constraints. In my case, the resource handler class has a single public non default constructor not
annotated with any of the JAX-RS attributes. Indeed, this constructor is invoked by the dependency
injection engine only (guice in my case) from the object factory.
>
>I think, that JAX-RS should not fail if it does not find any suitable constructor and the object factory is
registered. Seems like a bug?
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2889682

Tim Peierls | 1 Dec 19:03 2011
Picon

Re: Re: Restlet vs JAX-RS

On Thu, Dec 1, 2011 at 12:15 PM, Stephan Koops <Stephan.Koops <at> web.de> wrote:
what I forgot in my last email:
In JAX-RS you are not required to call the serialisation / deserialisation logic. You implement the MessageBodyReader/Writer, give it to the ruintime environment, and they are called by the JAX-RS runtime. In Restlet you have to check the media type the client sent, decide which Deserialzer you have to use and call the deserialization. The same at the end: Check the accepted media types, decide and call the serialization. in JAX-RS you are not required to care about that, because the runtime will do it.

Not sure what you mean. The Restlet ConverterService handles serialiation/deserialization. You can write resource handler methods like this:

    <at> Post public User addUser(User newUser) { ... }

--tim
Stephan Koops | 1 Dec 19:33 2011
Picon

Re: Restlet vs JAX-RS

Hi Tim,

ok, that I didn't know; I used Restlet before annotations come in.

best regards
    Stephan

Am 01.12.2011 19:03, schrieb Tim Peierls:
On Thu, Dec 1, 2011 at 12:15 PM, Stephan Koops <Stephan.Koops <at> web.de> wrote:
what I forgot in my last email:
In JAX-RS you are not required to call the serialisation / deserialisation logic. You implement the MessageBodyReader/Writer, give it to the ruintime environment, and they are called by the JAX-RS runtime. In Restlet you have to check the media type the client sent, decide which Deserialzer you have to use and call the deserialization. The same at the end: Check the accepted media types, decide and call the serialization. in JAX-RS you are not required to care about that, because the runtime will do it.

Not sure what you mean. The Restlet ConverterService handles serialiation/deserialization. You can write resource handler methods like this:

    <at> Post public User addUser(User newUser) { ... }

--tim

Gmane