RE: Premature EOF / Broken Pipe

2009-06-29 Thread Jerome Louvel
Hi Timothy,

 

Were you able to make progress on this front? 

 

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

 

 

De : Timothy Aanerud [mailto:taane...@aticonsulting.com] 
Envoyé : vendredi 19 juin 2009 22:05
À : discuss@restlet.tigris.org
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.lou...@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:taane...@aticonsulting.com]
Envoy頺 vendredi 19 juin 2009 18:18
: discuss@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 
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23635 
dsMessageId=23635
62

--

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

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

RE: Problem Using proxy server for Restlet service

2009-06-29 Thread Jerome Louvel
Hi Albert, 

As a workaround, if you use the HTTP client connector based on
HttpURLConnection (org.restlet.ext.net), then you can use the proxy
parameters via JVM system properties.

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 : Albert Newton [mailto:myname.wha...@gmail.com] 
Envoyé : lundi 22 juin 2009 04:12
À : discuss@restlet.tigris.org
Objet : Problem Using proxy server for Restlet service

Browsing through the forum and googling around, it seems like currently
there is no way to make a client
request through the proxy server for Restlets. Seems like according to the
RFE submitted at this link:
http://restlet.tigris.org/issues/show_bug.cgi?id=317, this issue is not
expected to be solved until 2.0 5. Am i correct? Does that mean is there no
way right now to use a proxy server for Restlets?

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

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


RE: Restlet v 1.1.5 multiple times allow method checked

2009-06-29 Thread Jerome Louvel
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/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  http://www.noelios.com/
http://www.noelios.com

 

 

 

 

 

De : Alin Popa [mailto:alin.p...@gmail.com] 
Envoyé : mercredi 24 juin 2009 15:06
À : discuss@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

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

RE: Content Negotiation for Safari 4. Any way to override?

2009-06-29 Thread Jerome Louvel
Hi all,

I don't think that keeping the equalsIgnoreCase() method call do any harm. I 
suggest to keep it for flexibility purpose.

I've checked the HTTP spec, but nothing is said about case sensitivity for 
product tokens:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8

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 : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : vendredi 26 juin 2009 07:54
À : discuss@restlet.tigris.org
Objet : Re: Content Negotiation for Safari 4. Any way to override?

Hello,

well, I'm afraid that I'm the author of the change...
Let's see with Jérôme if we keep the equalsIgnorCase test or not.

best regards,
Thierry Boileau

 Hello Bruno, Bruce,

 well that's weird, the current 2.0 release (in the svn repository) uses 
 equalsIgnoreCase not equals. And I was not aware this had changed.


 best regards,
 Thierry Boileau
   
 Hi Bruce/Thierry,

 It seems that the code has changed between version 1.1 and 2.0.

 In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 
 'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), 
 org.restlet.engine.application.TunnelFilter uses 'equals' (line 528).

 I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' 
 (although I'm not sure which one is best), but the accept.properties 
 files should probably be updated to reflect this change (the version in 
 the trunk still uses lower case for all agent names).

 Best wishes,

 Bruno.

 Bruce Cooper wrote:
   
 
 Hi guys,

 I have found that the agentName is reporting as Safari with a capitol S 
 whereas the standard file has it listed with a lowercase s, so I've 
 needed to add a separate rule in accept.properties.  Because I want to 
 only override the default Accept that is being sent through (and so that 
 I can put in other accepts in XMLHttpRequest requests and not have them 
 overridden)//, I think it is best to include the acceptOld as shown below://

 #Safari
 agentName: Safari
 acceptOld: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

 This appears to work for me, so I'm happy.  Let me know if you think it 
 is a good solution.

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


 

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



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

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


RE: Possible GAE Client issue.

2009-06-29 Thread Jerome Louvel
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:n...@ger.gmane.org] De la part de Philippe Marschall
Envoyé : vendredi 26 juin 2009 07:14
À : discuss@restlet.tigris.org
Objet : Re: Possible GAE Client issue.

Matt wrote:
 Hi there,
 
 I'm getting the following error whenever I attempt to use the client class
 from within the GAE.
 
 Client client = new Client(Protocol.HTTP);
 Response response = client.get(http://www.google.com;);
 
 Internal Connector Error (1002) - access denied (java.net.SocketPermission
 www.google.com resolve)
 
 NB: I'm not using anything other than the default provided by restlet i.e.
 I'm not using apache's HttpClient.
 
 I've updated the gae jar to be the latest snapshot as of yesterday but I'm
 still getting this problem.
 
 Any suggestions? Or is it a potential bug? 

You're not allowed to open sockets on GAE/J.

Cheers
Philippe

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

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


Re: Premature EOF / Broken Pipe

2009-06-29 Thread Timothy Aanerud
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
taane...@aticonsulting.com


On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel jerome.lou...@noelios.comwrote:

  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:taane...@aticonsulting.com]
 *Envoyé :* vendredi 19 juin 2009 22:05
 *À :* discuss@restlet.tigris.org
 *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.lou...@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:taane...@aticonsulting.com]
 Envoy頺 vendredi 19 juin 2009 18:18
 : discuss@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=4447dsMessageId=23635
 62

 --


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




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

Restlet trunk andd GWT issues...

2009-06-29 Thread Brian Anderson
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=4447dsMessageId=2366391


Re: Restlet v 1.1.5 multiple times allow method checked

2009-06-29 Thread Alin Popa
Thanks Jerome,

Now's more clear.

On Mon, Jun 29, 2009 at 11:30 AM, Jerome Louvel
jerome.lou...@noelios.comwrote:

  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.p...@gmail.com]
 *Envoyé :* mercredi 24 juin 2009 15:06
 *À :* discuss@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

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

RE: Restlet trunk andd GWT issues...

2009-06-29 Thread Brian Anderson
FWIW, the following change in HttpClientConverter.java seems to fix the NPE:

public void commit(final HttpClientCall httpCall, Request request,
Response response, final Uniform userCallback) throws Exception {
if (httpCall != null) {
// Send the request to the client
httpCall.sendRequest(request, response, new Uniform() {

public void handle(Request request, Response response,
Uniform callback) {
updateResponse(response, httpCall);
userCallback.handle(request, response, null);
}

});
}
}


 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=4447dsMessageId=2366513


GAE + Restlet issue

2009-06-29 Thread Matt
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)
at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:932)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:237)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at
com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:125)
at
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:235)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4755)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4753)
at
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:359)
at com.google.net.rpc.impl.Server$2.run(Server.java:800)
at
com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56)
at
com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:510)
at com.google.net.rpc.impl.Server.startRpc(Server.java:756)
at com.google.net.rpc.impl.Server.processRequest(Server.java:348)
at
com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:459)
at
com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319)
at
com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290)
at com.google.net.async.Connection.handleReadEvent(Connection.java:419)
at
com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:762)
at
com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:207)
at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101)
at
com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251)
at
com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:373)
at java.lang.Thread.run(Unknown Source)

#
W 06-29 07:44PM 54.635

org.restlet.Restlet handle: Unable to start the Restlet

#
E 06-29 07:44PM 54.635

org.restlet.engine.ChainHelper handle: The org.restlet.Component class has
no Restlet defined to process calls. Maybe it wasn't properly