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
