webpost | 1 Jul 20:08

RangeFilter and redirects

I ran across a problem that was causing the Daemon threads in our WadlComponent-based server to enter a busy
loop.  Essentially, if a Range header was in the HTTP GET request but the server wanted to return a
redirection (e.g. via response.redirectSeeOther()), the entity would be wrapped by a
RangeRepresentation.  Tunnel in to that, and RangeInputStream#read would loop here:

        // Reach the start index.
        while (!(position >= startIndex)) {
            position += skip(startIndex - position);
        }

Aside from the likelihood that there's also a bug in the handling/wrapping of a response entity that's too
small for the range, my first question here had to do with the status code of the response itself.  Should
responses that are not "successful" (2xx) be subject to wrapping in a RangeRepresentation?

Thanks,
David

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

Lars Heuer | 1 Jul 17:04
Favicon

Timeline for Restlet M4?

Hi Jérôme & co.,

Do you have an idea when the remaining bugs [1] are resolved? In a
project I tried to support Restlet 1.x and 2.x but recently I switched
over to Restlet 2.0M3 due to API incompatibilities.

Now I've got the request if it wouldn't be better to switch back to
Restlet 1.x. :)

I could use the 2.0 SVN snapshots, but an official release would
provide a better impression.

It would be great if you can provide a rough time line so I can
estimate if I should switch back to 1.x or support both Restlet
versions or wait for the next milestone.

[1]
<http://restlet.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=2.0+M4>

Thanks in advance,
Lars
--

-- 
http://www.semagia.com

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

Matt | 1 Jul 00:58

RE: Possible GAE Client issue.

Thanks for your response. Bug report added.

Cheers,
Matt

jlouvel wrote:
> 
> Hi guys,
> 
> By default, we leverage the HttpURLConnection class which has been
> reimplemented on top of URLFetcher so this should work.
> 
> Thierry will finish his work on automated Restlet editions next week or so
> and we'll be able to resolve such issue more quickly and precisely.
> 
> For now, I suggest to enter a bug report.
> 
> Best regards,
> Jerome 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 Philippe Marschall
> Envoyé : vendredi 26 juin 2009 07:14
> À : discuss <at> restlet.tigris.org
> Objet : Re: Possible GAE Client issue.
> 
(Continue reading)

Matt | 30 Jun 04:57

GAE + Restlet issue

Hi there,

I'm trying to use GAE and Restlet together. All works fine on the local
development server. 

The first initial deploy to the "live" server worked fine. 

1.latest.[applicationid].appspot.com ----> works as expected.

However on my subsequent deploys I keep getting: 

1001.latest.[applicationid].appspot.com ---> fails with the following error
from the logs

#

org.restlet.Restlet handle: Unable to start the Restlet
java.lang.NullPointerException
	at
org.restlet.engine.component.ComponentHelper.checkVirtualHost(ComponentHelper.java:89)
	at
org.restlet.engine.component.ComponentHelper.start(ComponentHelper.java:183)
	at org.restlet.Component.startHelper(Component.java:539)
	at org.restlet.Component.start(Component.java:513)
	at org.restlet.Restlet.handle(Restlet.java:172)
	at org.restlet.Component.handle(Component.java:394)
	at org.restlet.Server.handle(Server.java:350)
	at org.restlet.engine.ServerHelper.handle(ServerHelper.java:69)
	at
org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:149)
(Continue reading)

Alin Popa | 29 Jun 11:53
Gravatar

Re: Restlet v 1.1.5 multiple times allow method checked

Thanks Jerome,

Now's more clear.

On Mon, Jun 29, 2009 at 11:30 AM, Jerome Louvel <jerome.louvel <at> noelios.com> wrote:

Hi Alin,

 

The reason is simple: when a method is not allowed, HTTP expects the server to return the list of allowed methods, therefore the framework introspects the resource by calling allow*() methods.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6

 

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

 

 

 

 

 

De : Alin Popa [mailto:alin.popa <at> gmail.com]
Envoyé : mercredi 24 juin 2009 15:06
À : discuss <at> restlet.tigris.org
Objet : Restlet v 1.1.5 multiple times allow method checked

 

Hi,

Very soon I noticed something strange(?) when using Restlet Resources:

if a http method is not allowed, it will go and check all allow methods: e.g.

When using DELETE http method and only POST is allowed,  it will go and check
allowDelete, allowGet, allowPut.

Why is not doing just one check for allowDelete and stops ?
Is this the normal behavior ? If yes, is there a way to suppress returned message within a Resource ?


Thanks.

--
Regards,

Alin




--
Regards,

Alin

Brian Anderson | 29 Jun 16:38

Restlet trunk andd GWT issues...

Hello,

I am working with the GWT edition and trunk r5150 in order to get the recent changes that fix content
negotiation issues present in 2.0m3.

I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I notice that I cannot get my GWT app
to run in hosted mode without changing the source element in GWT.gwt.xml. The trunk version specifies:

  <source path="."/>

which causes a "Non-canonical source path: ./" in the hosted mode browser followed by numerous other
derived errors. Changing the offending source statement to:

  <source path=""/>

apparently solves the issue.

I have not been able to find RestletGWTSimpleExample in the svn sources or on the site other than through the
link provided. Obviously there have been changes made in the callback mechanism between 2.0m3 and the
trunk version. Attempting the following:

        // Add an AJAX call to the server
        final Client client = new Client(Protocol.HTTP);
        client.get(PING_URL, new Uniform() {
            public void handle(Request request, Response response, Uniform callback) {
              pingText.setText(res​ponse.getEntity().ge​tText());
            }
          });

gets me past compilation issues but results in an NPE:

[ERROR] Uncaught exception escaped
java.lang.NullPointerException: null
    at org.restlet.engine.h​ttp.HttpClientConver​ter$1.handle(HttpCl​ientConverter.java:3​84)
    at org.restlet.engine.h​ttp.GwtHttpClientCal​l$2.onResponseRecei​ved(GwtHttpClientCal​l.java:236)
    at com.google.gwt.http.​client.Request.fireO​nResponseReceivedImp​l(Request.java:264)

So, I am wondering if I have the callback pattern properly coded, or maybe this isn't yet ready for prime time?

Also, it would be helpful if the RestletGWTSimpleExample source was in the svn trunk and updated along with
the core.

Thanks for any help you can provide.

ba

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

Timothy Aanerud | 29 Jun 16:18

Re: Premature EOF / Broken Pipe

I haven't tried switching HTTP connectors. :-(

But, I did build a sanitized/stripped down example.  Unfortunately, my example does not fail like my application does.   One difference between my example is I'm only exchange data with one resource, In my actual application I'm sending two messages to two resources back-to-back before pausing.
--
Timothy Aanerud
taanerud <at> aticonsulting.com


On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel <jerome.louvel <at> noelios.com> wrote:

Hi Timothy,

 

Were you able to make progress on this front?

 

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

 

 

De : Timothy Aanerud [mailto:taanerud <at> aticonsulting.com]
Envoyé : vendredi 19 juin 2009 22:05

Objet : Re: Premature EOF / Broken Pipe

 

No, I haven't tried switching HTTP connectors. I get the same failures for both HTTP and HTTPS.
In another experiement, I changed the client message frequency to ~1 second intervals and at this rate on both
Windows XP and Fedora10/Linux show now problems with the server running on Fedora.

The various frequencies and failure rates:
1 second == no problems
1.5 seconds == ~25% failure rate
5 seconds == ~25% failure rate
10 seconds == ~3% failure rate
180 seconds == >0.5%, if any failures

I'll switch the HTTP connectors out one at a time and see what happens.
--
Timothy Aanerud

On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel <jerome.louvel <at> noelios.com> wrote:

Hi Timothy,

This looks like a bug to me. Have you tried with different Restlet HTTP
connectors (such as Jetty on the server-side and Apache HTTP client)?

If you could send us a simple standalone test case, we could easily debug
what's going bad.

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


-----Message d'origine-----
De: Timothy Aanerud [mailto:taanerud <at> aticonsulting.com]
Envoy vendredi 19 juin 2009 18:18

: discuss <at> restlet.tigris.org
Objet: RE: Premature EOF / Broken Pipe


As a test, I moved the client code to a Windows XP machine. With a five
second update rate it fails regularly too, with the same exceptions and
stack traces.

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

------------------------------------------------------

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

 


Bruce Cooper | 28 Jun 10:34

Issues loading css files (from a Directory) using Firefox

Hi guys,


I've been using a Directory object to serve up the user interface of my REST style application, and that application consists of HTML, javascript and CSS.  I've found today that Firefox 3.5 on my Mac was not reading CSS files correctly.  To be more specific, it was reading the files, but was not using the results that were returned.  

To work out what was going wrong, I wrote a simple test page, which had a single DIV with a background color set by a style in an attached style sheet.  Viewing the page directly from the disk using Safari or Firefox worked.  Viewing the Page when served by Apache worked for both Safari and Firefox.  When the files were served up by the restlet engine, it continued to work correctly in Safari, but Firefox ignored the stylesheet.  After this, I spent a bit of time in Firebug having a look in headers. The main difference I could see was that the restlet engine was reporting the content-type of the repsonse as

text/css; charset=MACROMAN

Whereas Apache was just returning the content type as text/css.

I've dug around the code and found that in org.restlet.engine.local.Entity line 252 it sets the charset of the response to the platform default if it hasn't already been set.  To test my theory, I commented out this part of the code, and Firefox started responding correctly to the CSS file again (as shown in Picture 10).

I don't know if it is Firefox not understanding the charset or whether it just doesn't like the charset at all, but either way it is a problem.  For the moment, I'll just be leaving this code commented out, but I would appreciate some advice on the best way to fix this.

Please let me know if you need any more information.

Bruce.
--
www.brucecooper.net - 0417 986 274
Schley Andrew Kutz | 25 Jun 20:08
Gravatar

bug?

I want to prevent the use of HTTP VERB annotations in order to force  
sub-classes to respond with specific class types via abstract methods  
that I prototype in a base class. I marked the isAnnotated() method as  
@Override and final and returned false. However, when it returns false  
I get the following error:

java.lang.NullPointerException
	at  
org 
.restlet 
.engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106)
	at  
org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 
649)
	at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 
329)
	at  
org 
.restlet 
.resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
	at  
org 
.restlet 
.resource.ServerResource.doConditionalHandle(ServerResource.java:260)
	at org.restlet.resource.ServerResource.handle(ServerResource.java:921)
	at  
com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 
159)
	at org.restlet.resource.Finder.handle(Finder.java:510)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Router.handle(Router.java:490)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at  
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 
153)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
	at  
org 
.restlet 
.engine.application.ApplicationHelper.handle(ApplicationHelper.java:71)
	at org.restlet.Application.handle(Application.java:396)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Router.handle(Router.java:490)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.routing.Router.handle(Router.java:490)
	at org.restlet.routing.Filter.doHandle(Filter.java:156)
	at org.restlet.routing.Filter.handle(Filter.java:201)
	at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
	at org.restlet.Component.handle(Component.java:397)
	at org.restlet.Server.handle(Server.java:350)
	at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
	at  
org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 
149)
	at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 
932)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 
487)
	at  
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
	at  
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
216)
	at  
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
	at  
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
216)
	at  
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 
405)
	at  
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at  
org 
.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 
49)
	at  
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:324)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 
505)
	at org.mortbay.jetty.HttpConnection 
$RequestHandler.headerComplete(HttpConnection.java:829)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
	at  
org 
.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 
395)
	at org.mortbay.thread.QueuedThreadPool 
$PoolThread.run(QueuedThreadPool.java:488)
--

-- 
-a

"Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts." -- L. Stein

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

webpost | 24 Jun 18:36

Hierarchical URI routing w/ Spring

I have a hierarchy of container type objects that I want to be able to use.

ex:
   /branch/{branch_id}/
   /branch/{branch_id}/branch/{branch_id}/
   /branch/{branch_id}/branch/{branch_id}/branch/{branch_id}/
etc.
This structure can be arbitrarily deep, and each branch can have other items attached.

ex:
   /branch/{branch_id}/
   /branch/{branch_id}/branch/{branch_id}/leaves/{leaf_id}/
   /branch/{branch_id}/branch/{branch_id}/buds/{bud_id}/

etc.

I want to be able to configure this using the Spring integration.  I have this:
<bean name="root" class="org.restlet.ext.spring.SpringRouter">
    <constructor-arg ref="application" />

    <property name="attachments">
        <map>
            <entry key="/branch/{branch_id}"
                value="com.example.api.resource.BranchResource"/>
            <entry key="/branch/{branch_id}/leaves/{leaf_id}/"
                value="com.example.api.resource.LeafResource"/>
            <entry key="/branch/{branch_id}/buds/{bud_id}/"
                value="com.example.api.resource.budResource"/>
        </map>
    </property>
</bean>

<!--  Spring Application -->
<bean id="application" class="org.restlet.Application">
        <property name="name" value="exampleAPI"></property>
</bean>

which handles the root cases, but does not handle nested branches.  Is there a way to construct the URI
patterns to look at this arbitrarily deep hierarchy, but still get teh correct leaf and bud resources?

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

webpost | 24 Jun 19:57

Nested resource routing

I want to be able to nest arbitrarily deep items in a hierarchical format, and route them based on URI
patterns in Spring.  For example, I can have objects nested like:

    /branches/{branch_id}/
    /branches/{branch_id}/leaves/{leaf_id}/
    /branches/{branch_id}/buds/{bud_id}/

However, the branches can alos be nested, like this:

    /branches/{branch_id}/
    /branches/{branch_id}/branches/{branch_id}/leaves/{leaf_id}/
    /branches/{branch_id}//branches/{branch_id}/branches/{branch_id}/buds/{bud_id}/
etc.

I have my Spring application context set up like this to handle the root instances of "branches":

<bean name="root" class="org.restlet.ext.spring.SpringRouter">
    <constructor-arg ref="application" />

    <property name="attachments">
        <map>
            <entry key="/branches/{branch_id}"
                value="com.example.api.resource.BranchResource"/>
            <entry key="/branches/{branch_id}/leaves/{leaf_id}/"
                value="com.example.api.resource.LeafResource"/>
            <entry key="/branches/{branch_id}/buds/{bud_id}/"
                value="com.example.api.resource.budResource"/>
        </map>
    </property>
</bean>

<!--  Spring Application -->
<bean id="application" class="org.restlet.Application">
        <property name="name" value="exampleAPI"></property>
</bean>

I would like to be able to build my URI patterns so that I can handle the cases where the branches are nested.  Is
this even possible?

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


Gmane