Jerome Louvel | 2 May 14:11 2006

Restlet 1.0 beta 10 released

Main changes:

  • Fully refactored the org.restlet.data package to reduce usage of interfaces and remove the need to use the Manager static methods whose implementation would not significantly vary from one implementation to another. When interfaces were needed, like for enumerations, the implementation class is provided with the Default* name.
  • Renamed RestletCall interface into Call and added a DefaultCall class. Also renamed RestletCallWrapper to WrapperCall.
  • Renamed Call.getRestlet*() methods to getContext*() and Call.setHandlerPath() to setContextPath().
  • Added a HostMaplet to provide an easy and flexible way to detect the URI related to a single host such as equivalent IP-based URIs. All aspects are configurable and there is choice between two attachment modes (parent Chainlet or Maplet). Suggested by Dave Pawson and John D. Mitchell.
  • The RestletContainer now also implements the Chainlet interface, in addition to the Maplet interface. If you use both attachment mechanisms at the same time, the Chainlet will have a higher priority. This is a convenient way to chain a Restlet as a root handler with having to specify a URI pattern (ex: logging, HostMaplet attachment).
  • Added support for SMTP STARTTLS and SMTPS protocols.
  • Added support for authentication in JavaMail connector. Provide login and password using the Call.getSecurity().setLogin() and setPassword() methods.
  • Fixed issues with the HTTP client connector (not sending some content metadata and not correctly reporting IO errors). This uses the new statuses:CONNECTOR_ERROR_CONNECTION, CONNECTOR_ERROR_COMMUNICATION and CONNECTOR_ERROR_INTERNAL. Reported by Dave Pawson.
  • Added "timeout" property to the Client connector interface. Default and infinite timeouts can be specified. Suggested by Dave Pawson.

Project home:
http://www.restlet.org

Direct download link:
http://www.restlet.org/downloads/restlet-1.0b10.zip

For a complete list of changes, see:
http://www.restlet.org/docs/changes

Dave Pawson | 2 May 15:53 2006
Picon

Simple GET

Based on Tutorial02b.java, I'm trying to do a GET.
The basics are below.

       String myIP = s.getmyIPaddress() ;

       // The call
       RestletCall call = Manager.createCall();
       call.setResourceRef(Manager.createReference(source.toString()));
       call.setReferrerRef(Manager.createReference(myIP));

       call.setMethod(Methods.GET);

       // Ask to the HTTP client connector to handle the call
       Client client = Manager.createClient(Protocols.HTTP, "DPTest");
       client.handle(call);

       Status st = call.getStatus();
       System.err.println("doGet: Status:  "+ st.toString());
       // Output the result representation on the JVM console
       if (!st.isError()){

         Representation output = call.getOutput();
         if (output == null) {
           System.err.println("0 length input");
           System.exit(2);

         }

The problem is that the output object is null;
Using curl I can retrieve content fine from the same url.

I don't know how to test the Representation to see if it has succeeded?

Any help appreciated.

regards DaveP

Jerome Louvel | 2 May 16:08 2006

RE: Simple GET

Hi Dave,

>        Status st = call.getStatus();
>        System.err.println("doGet: Status:  "+ st.toString());
>        // Output the result representation on the JVM console
>        if (!st.isError()){
> 
>          Representation output = call.getOutput();
>          if (output == null) {
>            System.err.println("0 length input");
>            System.exit(2);
> 
> 
>          }

Are you attempting to access to a public URI? If so, could you share it so I
can test too? If you are using Firefox, I recommand to install the
LiveHTTPHeaders extensions in order so see the flow of a request, including
any redirections, headers,etc.
http://livehttpheaders.mozdev.org/

Also, maybe the remote server is issuing redirections? Redirections are not
considered as errors.

A good test to do after a GET is to check if the status is SUCCESS_OK then
to attempt to get the output representation. As a general recommandation you
should test if the output object is not null before accessing it.

> I don't know how to test the Representation to see if it has 
> succeeded?

The indicator of success is only the status property.

Thanks,
Jerome

Dave Pawson | 2 May 16:19 2006
Picon

Re: Simple GET

Jerome Louvel wrote:
> Hi Dave,
>  
>>        Status st = call.getStatus();
>>        System.err.println("doGet: Status:  "+ st.toString());
>>        // Output the result representation on the JVM console
>>        if (!st.isError()){
>>
>>          Representation output = call.getOutput();
>>          if (output == null) {
>>            System.err.println("0 length input");
>>            System.exit(2);
>>
>>
>>          }
> 
> Are you attempting to access to a public URI? If so, could you share it so I
> can test too? If you are using Firefox, I recommand to install the
> LiveHTTPHeaders extensions in order so see the flow of a request, including
> any redirections, headers,etc.
> http://livehttpheaders.mozdev.org/

No Jerome, it is to a local network. 10.1.xxx
I can do a GET with curl OK.

> 
> Also, maybe the remote server is issuing redirections? Redirections are not
> considered as errors.
> 
> A good test to do after a GET is to check if the status is SUCCESS_OK then
> to attempt to get the output representation. As a general recommandation you
> should test if the output object is not null before accessing it.
I'm doing that ( if (!st.isError()) which is the 'same'/inverse test?)

> 
>> I don't know how to test the Representation to see if it has 
>> succeeded?
> 
> The indicator of success is only the status property.

OK, I'll change the test.
Still working with an older version, unsure how much will change
if I update to your beta Jerome?

regards DaveP

Dave Pawson | 2 May 16:28 2006
Picon

Re: Simple GET

Still the same Jerome.
the output object is null;

  Status st = call.getStatus();
       System.err.println("doGet: Status:  "+ st.toString());
       // Output the result representation on the JVM console
       if (st.isSuccess()){
         Representation output = call.getOutput();
         System.err.println("OUtput returned " + call.getResourcePath());
         if (output == null) {
           System.err.println("0 length input");
           System.exit(2);

         }

so the status is indicating success...
yet the Representation is null?

regards DaveP

Jerome Louvel | 2 May 16:51 2006

RE: Simple GET

> No Jerome, it is to a local network. 10.1.xxx
> I can do a GET with curl OK.

Could you give me the name of the status returned?
    System.out.println(call.getStatus());

Also, could you send a trace file generated by CURL using this option:
      --trace <file>

> > Also, maybe the remote server is issuing redirections?
> Redirections are not
> > considered as errors.
> >
> > A good test to do after a GET is to check if the status is
> SUCCESS_OK then
> > to attempt to get the output representation. As a general
> recommandation you
> > should test if the output object is not null before accessing it.
> I'm doing that ( if (!st.isError()) which is the 'same'/inverse test?)

Right! Another possibility is that your server is requiring certain
properties/preferences from your client, like accepted media types and
languages. 

> >> I don't know how to test the Representation to see if it has
> >> succeeded?
> >
> > The indicator of success is only the status property.
>
> OK, I'll change the test.
> Still working with an older version, unsure how much will change
> if I update to your beta Jerome?

I suggest that you check the online tutorial
(http://www.restlet.org/tutotial) to get a feel of how much changed from an
application point of view. If you have half an hour for this upgrade
process, I would recommand doing it as it includes the enhanced error
reporting that you requested for the HTTP client connector. In previous
versions, the status could stay to SUCCESS_OK even if a communication error
occured.

>  Status st = call.getStatus();
>       System.err.println("doGet: Status:  "+ st.toString());
>       // Output the result representation on the JVM console
>       if (st.isSuccess()){
>         Representation output = call.getOutput();
>         System.err.println("OUtput returned " + call.getResourcePath());
>         if (output == null) {
>           System.err.println("0 length input");
>           System.exit(2);

> so the status is indicating success...
> yet the Representation is null?

BTW, note that doing st.isSuccess() is not strictly equivalent to doing
st.equals(Statuses.SUCCESS_OK). Indeed there are multiple SUCCESS_* statuses
for other situations like creation.

Thanks,
Jerome 

> -----Message d'origine-----
> De : news [mailto:news <at> sea.gmane.org] De la part de Dave Pawson
> Envoyé : mardi 2 mai 2006 16:20
> À : discuss <at> restlet.tigris.org
> Objet : Re: Simple GET
> 
> Jerome Louvel wrote:
> > Hi Dave,
> >  
> >>        Status st = call.getStatus();
> >>        System.err.println("doGet: Status:  "+ st.toString());
> >>        // Output the result representation on the JVM console
> >>        if (!st.isError()){
> >>
> >>          Representation output = call.getOutput();
> >>          if (output == null) {
> >>            System.err.println("0 length input");
> >>            System.exit(2);
> >>
> >>
> >>          }
> > 
> > Are you attempting to access to a public URI? If so, could 
> you share it so I
> > can test too? If you are using Firefox, I recommand to install the
> > LiveHTTPHeaders extensions in order so see the flow of a 
> request, including
> > any redirections, headers,etc.
> > http://livehttpheaders.mozdev.org/
> 
> No Jerome, it is to a local network. 10.1.xxx
> I can do a GET with curl OK.
> 
> 
> 
> > 
> > Also, maybe the remote server is issuing redirections? 
> Redirections are not
> > considered as errors.
> > 
> > A good test to do after a GET is to check if the status is 
> SUCCESS_OK then
> > to attempt to get the output representation. As a general 
> recommandation you
> > should test if the output object is not null before accessing it.
> I'm doing that ( if (!st.isError()) which is the 'same'/inverse test?)
> 
> 
> 
> 
> > 
> >> I don't know how to test the Representation to see if it has 
> >> succeeded?
> > 
> > The indicator of success is only the status property.
> 
> OK, I'll change the test.
> Still working with an older version, unsure how much will change
> if I update to your beta Jerome?
> 
> regards DaveP
> 
> 
> 

Jerome Louvel | 2 May 16:50 2006

RE: get, with wait

Hi Dave,

See changes in the new beta 10. Especially have a look at the new
CONNECTOR_ERROR_* statuses just added to Statuses interface.
http://www.restlet.org/docs/api/org/restlet/data/Statuses.html

Also, check the get/setTimeout methods added to Client connectors (only
recognized by the HTTP client connector for now).
http://www.restlet.org/docs/api/org/restlet/connector/Client.html

Thx,
Jerome 

> -----Message d'origine-----
> De : news [mailto:news <at> sea.gmane.org] De la part de Dave Pawson
> Envoyé : samedi 29 avril 2006 15:21
> À : discuss <at> restlet.tigris.org
> Objet : Re: get, with wait
> 
> Jerome Louvel wrote:
> > Fortunately, "connectionTimeout" and a "readTimeout" were 
> added to the
> > UrlConnection class in JDK 5. I guess I need to expose that 
> in a standard
> > way at the Client connector level. Also, a clear call 
> status should be
> > returned.
> > 
> > Would that satisfy your need?
> 
> Yes, that would be ideal.
> GET (timeout xxx timeUnits) would be ideal.
> If the status tells me if it timed out, or if the GET succeeded.
> 
> Yes please Jerome!
> 
> 
> 
> regards
> 
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
> 

Jerome Louvel | 3 May 17:44 2006

FAQ page added

Finally we have a FAQ! 
http://www.restlet.org/faq

Thanks to Dave Pawson for pushing this. I'll try to add new questions on the
fly when they come in this list or by other means.

Best,
Jerome

Jerome Louvel | 3 May 20:31 2006

Glossary page added

Also just added a glossary that should help newcomers to get acquainted with
the usual suspects...
http://www.restlet.org/glossary

Again, thanks to Dave Pawson for proposing this. 

Jerome

Yuri de Wit | 7 May 01:00 2006
Picon

Redirecting


What is the best way to create a redirect URL when processing an HTTP
request? Is it possible to do relative redirections that are resolved
against the resource URL?
for instance: I am processing a GET request for a resource identified by
http://server/app/product/122eee, but the product 122eee does not
exist. I would like to do the following:
            call.setRedirectionRef("..");
            call.setStatus(Statuses.CLIENT_ERROR_NOT_FOUND);

because I want the client to redirect to the list of all products
identified by http://server/app/product
I am trying to stay away from hardcoding url in my resources and keep
all that centralized in the RestletContainer.
any ideas?

thanks,

-- yuri


Gmane