Re: warning instantiating one of my resources
Hello Jim, there may be a problem with the web.xml configuration file. If ProcessManagerApplication is not a Restlet application, you should not have to implement such constructor, and this kind of error should not happen... Could you send us your configuration file? Best regards, Thierry Boileau Can someone pls provide some information on this exception. I am running outside the Neolios Restlet Engine. Everything works fine but wondering whether I actually need to implement this constructor and the purpose of it. 16:30:32,578 WARN [/procmgr] procmgr: [Noelios Restlet Engine] - The ServerServ let couldn't invoke the constructor of the target class. Please check this class has a constructor with a single parameter of Context. The empty constructor and the context setter wille used instead. au.com.comware.procmgr.application.Proce ssManagerApplication java.lang.NoSuchMethodException: au.com.comware.procmgr.application.ProcessManag erApplication.(org.restlet.Context) at java.lang.Class.getConstructor0(Class.java:2678) at java.lang.Class.getConstructor(Class.java:1629) cheers
RE: Problem with org.restlet.Client
Hi Jim and Adam, As the connectors in the Restlet API are protocol-neutral (HTTP-centric indeed but usable for other protocols/schemes like file:// and ftp://) and as we allow for switchable implementations of those connectors (JDK's HttpURLConnection, Apache HTTP, etc.), we don't control all the potential exceptions being thrown. The only way to expose those exceptions would be to add a "throws Exception" to the Uniform.handle() method as suggested by Adam. But, as noticed by Jim, we couldn't do anything useful with those exceptions caught beside logging them. As HTTP already has a mechanism to dealing with 'exceptions', the status, we thought that this would be better and more consistent to solely rely on those statuses to deal with all exceptions/errors/success info that could arise during the handling of a request. As Adam said, some errors are out of the traditional HTTP status scope, because the request may not have even left the client connector (bad request, invalid URI, host not found, etc.). To cover those exceptions, we have already proposed some extension statuses, specific to the connector: - CONNECTOR_ERROR_COMMUNICATION - CONNECTOR_ERROR_CONNECTION - CONNECTOR_ERROR_INTERNAL This design seems consistent and addresses all the cases uniformly, and remove the need to define try/catch blocks around the handle() method invocations. Now, there are two issues in the code pointed out in the start of this thread by Jim: - the catch block doesn't set the response status to Status.CONNECTOR_ERROR_INTERNAL - the exception described as "Only HTTP or HTTPS resource URIs are allowed here" should be caught directly in the com.noelios.restlet.ext.httpclient.HttpMethodCall constructor, by setting the response status to the standard HTTP CLIENT_ERROR_BAD_REQUEST, with an appropriate description message. The offending code has been fixed in HttpClientHelper like this: try { HttpClientCall httpCall = getConverter().toSpecific(this, request); getConverter().commit(httpCall, request, response); } catch (Exception e) { getLogger().log(Level.INFO, "Error while handling an HTTP client call", e); response.setStatus(Status.CONNECTOR_ERROR_INTERNAL, e.getMessage()); } Fix checked in SVN trunk and branch 1.0. Best regards, Jerome > -Message d'origine- > De : Jim Alateras [mailto:[EMAIL PROTECTED] > Envoyé : mardi 29 mai 2007 00:39 > À : discuss@restlet.tigris.org > Objet : Re: Problem with org.restlet.Client > > Adam Taft wrote: > > > > The biggest concern for me is that IOException is being > eaten in the > > client. So, for example, an illegal url or a host not > found error is > > being trapped, logged and then no other error is being > thrown. Yuck. > > There's no appropriate status code which can model a "host > not found" > > exception, because the status codes imply actual contact > with the server. > > > i'm starting to agree that that its hard to get an appropriate status > code particularly since the request hasn't left the client side. > > cheers >
RE: Please Don't Eat Exceptions
Hi Adam, The fix I've just checked in SVN should solve your issue. You now can check whether your request generated an error by solely looking at the response's status code. In your case, it would return a CONNECTOR_ERROR_INTERNAL because we don't fully deal with invalid URIs. In the future, we might improve the precision of the status. In your case you could also expect a CLIENT_ERROR_BAD_REQUEST because: - you provided a non HTTP URI ("a") - you didn't provide a Request's hostRef property to indicate the host to connect to I understand your preference for checked exceptions. For a Java-centric API I would design like you propose, but for a REST/HTTP API, I think it's better and more consistent to reuse and extend the HTTP status mechanism. Best regards, Jerome > -Message d'origine- > De : Adam Taft [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 1 juin 2007 06:05 > À : discuss@restlet.tigris.org > Objet : Re: Please Don't Eat Exceptions > > > I don't necessarily understand where the "first stage" and > the "second > stage" are in the code you're referring to. So, I can't guess as to > whether it's a good solution. > > Maybe think about a lower level functional class (ie. > basically what is > Client right now) throwing checked exceptions out of the > handle method. > And then, having a "convenience" class that extends Client > and wraps > the exceptions to produce an appropriate error Status code. > This would > allow the best of both worlds, by allowing the checked > exceptions to be > dealt with programatically by the end user/developer, while also > allowing a non-checked configuration for those who want it. > > A developer who wants the checked exceptions would do: > > Client client = new Client(); > > A developer who wants to do if-then-else testing on the status code > would do: > > UncheckedClient client = new UncheckedClient(); > > Where UncheckedClient extends Client. > > Regardless, down in the depths of the specification, it's in my mind > that the handle method should throw exceptions. > > Just some additional thoughts, I guess. > > Adam > > > Thierry Boileau wrote: > > Hello, > > > > we had a discussion with Jerome, and we plainly agree with the fact > > there is a problem in HttpClientHelper#handle [1] method as > pointed out > > thanksfully by Adam and Jim. > > This method first builds a call object then sends this call > and gets the > > server's response. > > The try/catch block is very problematic in the case the > build step of > > the call fails. We've decided to remove it. > > That is to say that all errors detected in this first step > will be in > > charge of the caller code which is "responsible to give > correct data". > > > > A contrario, the errors detected in the second phase should > generate a > > status code: > > - Status.CONNECTOR_ERROR_XXX (where XXX stands for CONNECTION, > > COMMUNICATION and INTERNAL) for all errors detected before > the request > > is sent. This is the current behaviour. > > - HTTP status received from the server. > > > > > > What do you think about? > > > > best regards, > > Thierry Boileau > > [1] > >public void handle(Request request, Response response) { > >try { > >HttpClientCall httpCall = > getConverter().toSpecific(this, > > request); > >getConverter().commit(httpCall, request, response); > >} catch (Exception e) { > >getLogger().log(Level.WARNING, > >"Error while handling an HTTP client call: ", > >e.getMessage()); > >getLogger().log(Level.INFO, > >"Error while handling an HTTP client call", e); > >} > >} > > > > > >> > >> I made some comments to the bug, by the way. > >> > >> One thing that came to mind, about handling different 3rd > party client > >> apis, is to deal with it like Spring deals with JDBC > exceptions. In > >> essence, they wrap and catch the various jdbc/driver > exceptions and > >> then map it to a set of common spring defined exceptions. > >> > >> In my mind, the Status code in the Response object should > be a direct > >> mapping to the HTTP status codes. This is really the > intent you guys > >> had. Of course, the status code is undefined for a request that > >> cannot establish a connection with the host, due to > various problems > >> (physical connection, dns, proxy related issues, no route > to host, etc.) > >> > >> Without the ability to "detect" these kind of connectivity > issues in > >> developer code, the Client class is pretty worthless. Having a > >> generic isError() method or a bogus status code in the response > >> doesn't give the level of detail needed. > >> > >> You're also forcing developers to use the nasty pattern of > switch or > >> if/else statements to check for the appropriate conditions in the > >> Response object. If I'm making multiple request
RE: warning instantiating one of my resources
Hi Jim, The issue might be coming from the lack of a constructor with a Context parameter in your ProcessManagerApplication class. As o.r.Application also has a default constructor, you might have missed this requirement. Best regards, Jerome > -Message d'origine- > De : Jim Alateras [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 1 juin 2007 08:39 > À : discuss@restlet.tigris.org > Objet : warning instantiating one of my resources > > Can someone pls provide some information on this exception. I > am running > outside the Neolios Restlet Engine. Everything works fine but > wondering > whether I actually need to implement this constructor and the > purpose of > it. > > 16:30:32,578 WARN [/procmgr] procmgr: [Noelios Restlet Engine] - The > ServerServ > let couldn't invoke the constructor of the target class. Please check > this class > has a constructor with a single parameter of Context. The empty > constructor and > the context setter wille used instead. > au.com.comware.procmgr.application.Proce > ssManagerApplication > java.lang.NoSuchMethodException: > au.com.comware.procmgr.application.ProcessManag > erApplication.(org.restlet.Context) > at java.lang.Class.getConstructor0(Class.java:2678) > at java.lang.Class.getConstructor(Class.java:1629) > > cheers >
Re: Please Don't Eat Exceptions
Jerome, I think I had to patch the code in two places to get it to work. There was another instance of this type of code in HttpMethodCall. You might want to look for it there (or look at my patch in the bug report, which should give you an idea of where to look). Thanks, Adam Jerome Louvel wrote: Hi Adam, The fix I've just checked in SVN should solve your issue. You now can check whether your request generated an error by solely looking at the response's status code. In your case, it would return a CONNECTOR_ERROR_INTERNAL because we don't fully deal with invalid URIs. In the future, we might improve the precision of the status. In your case you could also expect a CLIENT_ERROR_BAD_REQUEST because: - you provided a non HTTP URI ("a") - you didn't provide a Request's hostRef property to indicate the host to connect to I understand your preference for checked exceptions. For a Java-centric API I would design like you propose, but for a REST/HTTP API, I think it's better and more consistent to reuse and extend the HTTP status mechanism. Best regards, Jerome -Message d'origine- De : Adam Taft [mailto:[EMAIL PROTECTED] Envoyé : vendredi 1 juin 2007 06:05 À : discuss@restlet.tigris.org Objet : Re: Please Don't Eat Exceptions I don't necessarily understand where the "first stage" and the "second stage" are in the code you're referring to. So, I can't guess as to whether it's a good solution. Maybe think about a lower level functional class (ie. basically what is Client right now) throwing checked exceptions out of the handle method. And then, having a "convenience" class that extends Client and wraps the exceptions to produce an appropriate error Status code. This would allow the best of both worlds, by allowing the checked exceptions to be dealt with programatically by the end user/developer, while also allowing a non-checked configuration for those who want it. A developer who wants the checked exceptions would do: Client client = new Client(); A developer who wants to do if-then-else testing on the status code would do: UncheckedClient client = new UncheckedClient(); Where UncheckedClient extends Client. Regardless, down in the depths of the specification, it's in my mind that the handle method should throw exceptions. Just some additional thoughts, I guess. Adam Thierry Boileau wrote: Hello, we had a discussion with Jerome, and we plainly agree with the fact there is a problem in HttpClientHelper#handle [1] method as pointed out thanksfully by Adam and Jim. This method first builds a call object then sends this call and gets the server's response. The try/catch block is very problematic in the case the build step of the call fails. We've decided to remove it. That is to say that all errors detected in this first step will be in charge of the caller code which is "responsible to give correct data". A contrario, the errors detected in the second phase should generate a status code: - Status.CONNECTOR_ERROR_XXX (where XXX stands for CONNECTION, COMMUNICATION and INTERNAL) for all errors detected before the request is sent. This is the current behaviour. - HTTP status received from the server. What do you think about? best regards, Thierry Boileau [1] public void handle(Request request, Response response) { try { HttpClientCall httpCall = getConverter().toSpecific(this, request); getConverter().commit(httpCall, request, response); } catch (Exception e) { getLogger().log(Level.WARNING, "Error while handling an HTTP client call: ", e.getMessage()); getLogger().log(Level.INFO, "Error while handling an HTTP client call", e); } } I made some comments to the bug, by the way. One thing that came to mind, about handling different 3rd party client apis, is to deal with it like Spring deals with JDBC exceptions. In essence, they wrap and catch the various jdbc/driver exceptions and then map it to a set of common spring defined exceptions. In my mind, the Status code in the Response object should be a direct mapping to the HTTP status codes. This is really the intent you guys had. Of course, the status code is undefined for a request that cannot establish a connection with the host, due to various problems (physical connection, dns, proxy related issues, no route to host, etc.) Without the ability to "detect" these kind of connectivity issues in developer code, the Client class is pretty worthless. Having a generic isError() method or a bogus status code in the response doesn't give the level of detail needed. You're also forcing developers to use the nasty pattern of switch or if/else statements to check for the appropriate conditions in the Response object. If I'm making multiple requests to the server (which is common in a RESTful design), and th
Re: Problem with org.restlet.Client
The offending code has been fixed in HttpClientHelper like this: try { HttpClientCall httpCall = getConverter().toSpecific(this, request); getConverter().commit(httpCall, request, response); } catch (Exception e) { getLogger().log(Level.INFO, "Error while handling an HTTP client call", e); response.setStatus(Status.CONNECTOR_ERROR_INTERNAL, e.getMessage()); } Fix checked in SVN trunk and branch 1.0. Jerome, thanks for that. Any plans to update the jar(s) on http://maven.restlet.org? cheers