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

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

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.
> 

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)

Re: Restlet v 1.1.5 multiple times allow method checked

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

Re: Premature EOF / Broken Pipe

Issues loading css files (from a Directory) using Firefox

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

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

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