Lars Heuer | 1 Nov 13:51 2008

Re: Restlet 1.1.1 released

Hi Jérôme,

[...]
> Download links:
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.exe
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.zip

I wonder if it has been discussed before, but imo it would be nice if
the Restlet libs would have the version number encoded in the name,
like several extension have already (reflecting the version of the
underlying lib).

I.e.:
     org.restlet-1.1.1.jar
     com.noelios.restlet-1.1.1.jar

Best regards,
Lars
--

-- 
http://www.semagia.com

Jerome Louvel | 1 Nov 14:58 2008

RE: Restlet 1.1.1 released

Hi all,
 
The tagging of our releases is based on Debian policy (http://www.debian.org/releases/). We recommend:
 - Restlet 1.0 (stable) for production systems
 - Restlet 1.1 (testing) for new developments or people ready to upgrade frequently to get fixes
 - Restlet 1.2 (unstable) for Restlet developers or people wanting to leave on the edge with new features
 
We will only consider 1.1 'stable' when is has had a few corrective versions and when 1.2 RC1 will be released.
 
This may seem too conservative, but for example 1.1.0 contained a regression in the Servlet extension for Windows, so it wasn't really ready for production.
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 
De : Avi Flax [mailto:avif <at> arc90.com]
Envoyé : vendredi 31 octobre 2008 18:49
À : discuss <at> restlet.tigris.org
Objet : Re: Restlet 1.1.1 released

On Fri, Oct 31, 2008 at 13:08, Stephan Koops <Stephan.Koops <at> web.de> wrote:
 
one the download site Restlet 1.1.1 is marked as testing. Is this planned?

I was just wondering this myself. Shouldn't 1.0.11 be relabeled as an "archived" version at this point, and 1.1.X as "stable"?
Jerome Louvel | 1 Nov 15:00 2008

RE: Restlet 1.1.1 released


Hi Lars,

There are pros and cons. The pros is what you mentioned, the cons is that
upgrading is not just a copy/paste/replace action but might require
adjustment of classpath configuration files.

There is also the MANIFEST.MF file inside the JARs that should let you find
out exactly which version you are using.

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

-----Message d'origine-----
De : Lars Heuer [mailto:heuer <at> semagia.com] 
Envoyé : samedi 1 novembre 2008 13:52
À : Jerome Louvel
Objet : Re: Restlet 1.1.1 released

Hi Jérôme,

[...]
> Download links:
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.exe
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.zip

I wonder if it has been discussed before, but imo it would be nice if
the Restlet libs would have the version number encoded in the name,
like several extension have already (reflecting the version of the
underlying lib).

I.e.:
     org.restlet-1.1.1.jar
     com.noelios.restlet-1.1.1.jar

Best regards,
Lars
--

-- 
http://www.semagia.com

Mauro Talevi | 1 Nov 15:22 2008

Re: 1.1.0 & maven

Hello Thierry,

Thierry Boileau wrote:
> Hello Vincent,
> 
> the public maven repository is updated twice a month (see 
> http://www.restlet.org/downloads/maven).
> So, release 1.1.0 will be available on the 1st of november.

If you can't update it more frequently - e.g. day - wouldn't it more 
user friendly to update it after every release?

Say, you publish a release on the 16th of the month - it would not be 
available for 2 weeks.

BTW:  is there a technical reason why synching is not done more often? 
Also, have you considered synching your repo to the Maven Central repo 
directly?  It's surprisingly simple to do and avoids the hassle of 
having to declare an additional repo for the developers.

Cheers

Jerome Louvel | 1 Nov 15:36 2008

RE: 1.1.0 & maven


Hi Mauro,

There is no technical reason for the Maven refresh being done twice a month.
This is a policy decided to encourage users to subscribe to our support
plans:
http://www.noelios.com/products/support

However, when a major security issue is fixed, we usually push the new
version immediately in the public repository. I hope it does sound like a
reasonable balance.

We did considered Maven central repo, see previous threads in the list for
details.

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

-----Message d'origine-----
De : news [mailto:news <at> ger.gmane.org] De la part de Mauro Talevi
Envoyé : samedi 1 novembre 2008 15:23
À : discuss <at> restlet.tigris.org
Objet : Re: 1.1.0 & maven

Hello Thierry,

Thierry Boileau wrote:
> Hello Vincent,
> 
> the public maven repository is updated twice a month (see 
> http://www.restlet.org/downloads/maven).
> So, release 1.1.0 will be available on the 1st of november.

If you can't update it more frequently - e.g. day - wouldn't it more 
user friendly to update it after every release?

Say, you publish a release on the 16th of the month - it would not be 
available for 2 weeks.

BTW:  is there a technical reason why synching is not done more often? 
Also, have you considered synching your repo to the Maven Central repo 
directly?  It's surprisingly simple to do and avoids the hassle of 
having to declare an additional repo for the developers.

Cheers

Jerome Louvel | 1 Nov 16:15 2008

RE: Content negotiation with browsers - advice sought


Hi Jon,

Good suggestion! I've added a RFE for this:

"Enhance documentation on conneg"
http://restlet.tigris.org/issues/show_bug.cgi?id=641 

If you are interested in contributing some doc on this topic, we could
create a new web page in our User Guide (wiki) for this.

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

-----Message d'origine-----
De : jon.blower <at> gmail.com [mailto:jon.blower <at> gmail.com] De la part de Jon
Blower
Envoyé : jeudi 30 octobre 2008 10:06
À : discuss <at> restlet.tigris.org
Objet : Re: Content negotiation with browsers - advice sought

Thanks Stephan, this is very helpful.  I think that some documentation
on this subject would be valuable, either in the Javadoc for the
TunnelService or elsewhere on the Restlet website.  It would be useful
to clarify:

1) General background on content negotiation and how it's supposed to
work in REST - and how some web browsers break the model (perhaps
there are some external pages that can simply be referenced).
2) How Restlet handles content negotation: by default and with the use
of tunnels.
3) How to add different file extension-media type mappings and how to
find out which ones are provided by default.
4) Similarly, how to add different user agent mappings and what the
defaults are.

Best wishes,
Jon

On Tue, Oct 28, 2008 at 7:52 PM, Stephan Koops <Stephan.Koops <at> web.de> wrote:
> Hi Jon
>
>> 1) Is the TunnelService essentially a filter that can modify HTTP
>> headers (possibly other things too) before they reach my Resource
>> class?
> The Restlet Engine uses the data from the TunnelService to initialize the
TunnelFilter (part of the engine), which does the work, as you described. As
every filter, it could change everything in the request.
>
>> 2) Why do you consider the userAgentTunnel better than file
>> extensions?  Is it simply closer to the REST model?
> The user agnet filter allow the content negotiation as it is planned,
because you are not required to add extensions to your URIs. On the other
hand with the extension mapping you have the possibility to request every
media type with every client. You could also combine both possibilities.
>
> To the closeness to REST: While defining the JAX-RS-API we had a
discussion about exactly this feature. Roy Fielding pointed out (see
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1458, full
thread:
https://jsr311.dev.java.net/servlets/BrowseList?listName=dev&from=1196535&to
=1196535&count=31&by=thread&paged=false) , that he URI
http://abc.de/fgh.html is not the same resource as http://abc.de/fgh, and he
is right. These URIs describe two resources, which could (should, ...) point
to the same entity (the same business object, see
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_2_1_1 for details).
> With reading it is not a big problem, but with modifying: if you edit
...../fgh.html (e.g. PUT or DELETE), than this request (from the REST point
of view) will not change/delete ..../fgh.xml, but this is the result,
intended by the developer and the client. So the user agent filter is indeed
closer to REST. The Restlet filter will evaulate the extension only for GET
(and HEAD) requests.
> But I think, that both are useful. IMO: Use both. If the link is .../fgh
(without extension), you get, what your client like (HTML for browser etc,
XML or JSON for a web servcie etc.), and if you want a special media type,
you could explict use the URI ...../fgh.gif
>
>> 3) If I use a userAgentTunnel how can I distinguish between web page
>> requests (which probably require text/html) and requests from <img>
>> tags (which probably require image/*)?
> See above.
>
>> 4) What's the best documentation to read to learn how to use and
>> configure the TunnelService?  I can probably figure things out from
>> the javadoc, but would appreciate some other docs if they exist.
> I don't knoiw, that there is more documentation. You just need to set the
booleans to true. The Restlet Engine should do the rest. It includes a lot
of mappings for file extensions (see
org.restlet.service.MetadataService.getMetaData(), accessible via
Application.getMetadataService()). It also includes a basic configuration
for the user agent mapping. There is a propertiy file for it, but I don't
know where. Perhaps useragents.properties or something like this.
> If you have more questions, there is thsi mailing list :-) Perhaps you
give good input for more javadoc or something like this.
>
> best regards
>   Stephan
>
>> On Tue, Oct 28, 2008 at 11:51 AM, Stephan Koops <Stephan.Koops <at> web.de>
wrote:
>> > Hi Jon,
>> >
>> > in the TunnelService in Restlet 1.1 there is a solution for exactly
this problem. Try Application.getTunnelService().setUserAgentTunnel(true).
>> > Your proposed workaround with file extensions is also available: Try
Application.getTunnelService().setExtensionsTunnel(true).
>> > But the first solution is IMO better.
>> >
>> > best regards
>> >   Stephan
>> >
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: "Jon Blower" <j.d.blower <at> reading.ac.uk>
>> >> Gesendet: 28.10.08 12:34:26
>> >> An: "Restlet discussion mailing list" <discuss <at> restlet.tigris.org>
>> >> Betreff: Content negotiation with browsers - advice sought
>> >>
>> >> Hi all,
>> >>
>> >> I am using Restlet to create a simple data server.  I'm currently
>> >> wrestling with content negotiation (conneg), which is handled very
>> >> nicely by Restlet, but not by user agents, particularly web browsers.
>> >>
>> >> I'd like to be able to serve representations of my resources in a
>> >> number of formats, including HTML, Google Earth KML and a special XML
>> >> format called CSML (http://csml.badc.rl.ac.uk/).  I have set up my
>> >> Resource object to support a number of Variants:
>> >>
>> >>   getVariants().add(new Variant(MediaType.TEXT_HTML));  // for web
browsers
>> >>   getVariants().add(new Variant(CSML_MEDIA_TYPE)); // for special
>> >> clients that understand CSML
>> >>   getVariants().add(new Variant(MediaType.IMAGE_PNG)); // image
>> >> representation of the resource
>> >>   getVariants().add(new Variant(KML_MEDIA_TYPE)); // for clients that
>> >> understand KML
>> >>   getVariants().add(new Variant(MediaType.APPLICATION_XML)); // for
>> >> general clients that understand XML but not CSML
>> >>
>> >> I had naively assumed that web browsers would automatically ask for
>> >> and get the TEXT_HTML representation.  But no, I tested Firefox, IE7
>> >> and Chrome and got very different results:
>> >>
>> >> Firefox 3: Accept header is
>> >> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8".
>> >> Hence text/html is used, as expected.
>> >>
>> >> Chrome 0.2.149.30: Accept header is
>> >>
"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q
=0.8,image/png,*/*;q=0.5".
>> >>  So Chrome prefers application/xml to text/html and hence gets an XML
>> >> representation by default.  Seems odd.
>> >>
>> >> IE7: Accept header does not include text/html, image/png or
>> >> application/xml (!!) but does include "*/*" (yuck) so IE gets the
>> >> variant that happens to be first in the Resource's list.  With the
>> >> above code this just happens to be text/html.  So conneg doesn't
>> >> really happen here at all.
>> >>
>> >> I didn't test Safari, Opera or anything else.
>> >>
>> >> So the question is, how can arrange things so that web browsers get
>> >> HTML representations?  I can only see one workaround for this, which
>> >> is to use "file" extensions on my resource URLs to determine the media
>> >> type (e.g. .html, .png, .kml etc).  This is not RESTful (from my
>> >> understanding of REST) but seems to be a common workaround (e.g. in
>> >> Ruby on Rails).  Is there a way to do this easily in Restlet or is
>> >> this practice discouraged?
>> >>
>> >> Or is there a better alternative?
>> >>
>> >> Best wishes,
>> >> Jon
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
>
>

--

-- 
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower <at> reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm

Jerome Louvel | 1 Nov 16:33 2008

RE: Restlet and FF in Windows: range out of range

Hi all,
 
I've entered a bug report for this:
 
"Fix issues with content ranges"
 
Diego, could you specify which connectors you are using as this way have an impact?
 
A workaround is to turn off content ranges in your application: getRangeService().setEnabled(false);
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

De : Rob Heittman [mailto:rob.heittman <at> solertium.com]
Envoyé : vendredi 31 octobre 2008 16:28
À : discuss <at> restlet.tigris.org
Objet : Re: Restlet and FF in Windows: range out of range

This may be connected to a recent issue I've seen with Acrobat 9 not being able to serve up certain PDFs hosted by Restlet -- there are also ranged requests going on there -- Jerome and Thierry contact me direct if you want examples.

- Rob

On Fri, Oct 31, 2008 at 11:18 AM, Diego Ballve <diego.ballve <at> digital-artefacts.fi> wrote:
Hello,

Can somebody take a look at the range headers in these greps? I'm
experiencing problems in Windows when serving static files (times out
most of the times) and I believe it's due to ranged requests since it
works fine linux (1 request).

More specifically, why does Restlet answer:
 Content-Range: bytes 262144-728134/465990..
when
 Content-Length: 465990..

Jerome Louvel | 1 Nov 16:40 2008

RE: Router swallowing exceptions

Hi Cliff,
 
Do you still have the issue? If so, could you enter a bug report and attach a reproducible sample so we can figure out what is wrong?
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

De : Cliff Binstock [mailto:cliff.binstock <at> coyotereporting.com]
Envoyé : mardi 28 octobre 2008 18:56
À : discuss <at> restlet.tigris.org
Objet : RE: Router swallowing exceptions

I am using V1.1 RC2

 

Cliff Binstock

From: Thierry Boileau [mailto:thierry.boileau <at> noelios.com]
Sent: Tuesday, October 28, 2008 2:33 AM
To: discuss <at> restlet.tigris.org
Subject: Re: Router swallowing exceptions

 

Hello Cliff,

I get an Instantiation exception with a warning trace when running with the current trunk.

ATTENTION: Exception while instantiating the target handler.
java.lang.InstantiationException
    at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.restlet.Finder.createTarget(Finder.java:186)
[...]

What release of Restlet are you using?

Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~
http://www.noelios.com


I unfortunately accidentally discovered that if a “Resource” is not instantiable (e.g., the class is abstract, constructor is protected, etc.), the router—which is unable to complete its work—does “nothing” and doesn’t log anything either

It would be most appreciated if it would log a (probably SEVERE) error if it was unable to instantiate the Resource.

 

For example, if you have this:

 

        attach(router, "/not-instantiable", com.example.resource.MyAbstractResource.class);

 

and of course:

 

package com.example.resource;

public abstract class MyAbstractResource

    extends Resource {

}

 

 

Thanks much,

 

Cliff Binstock

Coyote Reporting

Robert Koberg | 1 Nov 17:20 2008

build fail (revision 3932)

Hi,

I just checked out the latest restlet distro from subversion (revision  
3932).

I am getting the following build failure on the tests:

verify-tests:
     [mkdir] Created dir: /Users/rkobergmac/Documents/workspace/ 
restlet/build/temp/test
     [junit] Running com.noelios.restlet.test.NoeliosTestSuite
     [junit] <head>
     [junit]    <title>Status page</title>
     [junit] </head>
     [junit] <body>
     [junit] <h3>The server has not found anything matching the  
request URI</h3><p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 
">here</a>.<br>
     [junit] Please continue your visit at our <a href="/">home page</ 
a>.
     [junit] </p>
     [junit] </body>
     [junit] </html>
     [junit] HTTP/1.1 404 The server has not found anything matching  
the request URI
     [junit] Content-Type: text/html; charset=ISO-8859-1
     [junit] Content-Length: 330
     [junit] Date: Sat, 01 Nov 2008 16:17:32 GMT
     [junit] Accept-Ranges: bytes
     [junit] Server: Noelios-Restlet-Engine/1.2.snapshot
     [junit]
     [junit] <html>
     [junit] <head>
     [junit]    <title>Status page</title>
     [junit] </head>
     [junit] <body>
     [junit] <h3>The server has not found anything matching the  
request URI</h3><p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 
">here</a>.<br>
     [junit] Please continue your visit at our <a href="/">home page</ 
a>.
     [junit] </p>
     [junit] </body>
     [junit] </html>
     [junit] ]>)
     [junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed:  
15.312 sec

BUILD FAILED
/Users/rkobergmac/Documents/workspace/restlet/build/build.xml:1599:  
Test com.noelios.restlet.test.NoeliosTestSuite failed

Robert Koberg | 1 Nov 17:25 2008

Re: build fail (revision 3932)

Running ant build produces the following fail:

verify-tests:
     [junit] Running com.noelios.restlet.test.NoeliosTestSuite
     [junit] Invalid memory access of location 00000000 rip=01160767
     [junit]
     [junit] Running com.noelios.restlet.test.NoeliosTestSuite
     [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec

BUILD FAILED
/Users/rkobergmac/Documents/workspace/restlet/build/build.xml:1599:  
Test com.noelios.restlet.test.NoeliosTestSuite failed (crashed)

My previous post was running the ant build default.

best,
-Rob

On Nov 1, 2008, at 12:20 PM, Robert Koberg wrote:

> Hi,
>
> I just checked out the latest restlet distro from subversion  
> (revision 3932).
>
> I am getting the following build failure on the tests:
>
> verify-tests:
>    [mkdir] Created dir: /Users/rkobergmac/Documents/workspace/ 
> restlet/build/temp/test
>    [junit] Running com.noelios.restlet.test.NoeliosTestSuite
>    [junit] <head>
>    [junit]    <title>Status page</title>
>    [junit] </head>
>    [junit] <body>
>    [junit] <h3>The server has not found anything matching the  
> request URI</h3><p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 
> ">here</a>.<br>
>    [junit] Please continue your visit at our <a href="/">home page</ 
> a>.
>    [junit] </p>
>    [junit] </body>
>    [junit] </html>
>    [junit] HTTP/1.1 404 The server has not found anything matching  
> the request URI
>    [junit] Content-Type: text/html; charset=ISO-8859-1
>    [junit] Content-Length: 330
>    [junit] Date: Sat, 01 Nov 2008 16:17:32 GMT
>    [junit] Accept-Ranges: bytes
>    [junit] Server: Noelios-Restlet-Engine/1.2.snapshot
>    [junit]
>    [junit] <html>
>    [junit] <head>
>    [junit]    <title>Status page</title>
>    [junit] </head>
>    [junit] <body>
>    [junit] <h3>The server has not found anything matching the  
> request URI</h3><p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 
> ">here</a>.<br>
>    [junit] Please continue your visit at our <a href="/">home page</ 
> a>.
>    [junit] </p>
>    [junit] </body>
>    [junit] </html>
>    [junit] ]>)
>    [junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed:  
> 15.312 sec
>
> BUILD FAILED
> /Users/rkobergmac/Documents/workspace/restlet/build/build.xml:1599:  
> Test com.noelios.restlet.test.NoeliosTestSuite failed
>


Gmane