Re: Again: gwt2.1-snapshot references java.nio.ByteBuffer (IoBuffer.java)

2011-01-24 Thread weltermann17
Hi Thierry,

a very good idea. Thanks a lot.

Guido Schmidt.
-- 
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Again-gwt2-1-snapshot-references-java-nio-ByteBuffer-IoBuffer-java-tp5946953p5954518.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


Re: NoSuchMethodException in HTTPClientConnector?

2011-01-24 Thread Alexander Kampmann
I've tried with the simple connector and got the same problem.

On 23.01.2011 21:22, Alexander Kampmann wrote:
 Hello Thierry,

 you are right about that. There was a dependency which should have 
 gone long before in my maven- pom. Thanks, removing it even solved 
 another bug ;)

 I think that solved the problem client side, but another one arises.
 On the serverside, the jetty- extension does not start. The problem is 
 a ClassNotFoundException. I think it is a moved class again. I found 
 it in the jar file, it is just in another package. But there is no 
 newer version of the jetty extension than 2.0-M6 on the public 
 repository. Is there another problem or do I have to wait until the 
 jetty extension gets released?

 Here is the exception:

 java.lang.NoClassDefFoundError: org/restlet/engine/http/HttpServerHelper
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:314)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
 at org.restlet.engine.Engine.registerHelper(Engine.java:850)
 at org.restlet.engine.Engine.registerHelpers(Engine.java:887)
 at org.restlet.engine.Engine.registerHelpers(Engine.java:927)
 at org.restlet.engine.Engine.discoverConnectors(Engine.java:625)
 at org.restlet.engine.Engine.init(Engine.java:468)
 at org.restlet.engine.Engine.register(Engine.java:346)
 at org.restlet.engine.Engine.register(Engine.java:331)
 at org.restlet.engine.Engine.getInstance(Engine.java:215)
 at org.restlet.Restlet.init(Restlet.java:99)
 at org.restlet.Restlet.init(Restlet.java:77)
 at org.restlet.Component.init(Component.java:177)
 at 
 org.restlet.ext.spring.SpringComponent.init(SpringComponent.java:83)

 Best regards,
 Alex

 On 23.01.2011 19:25, Thierry Boileau wrote:
 Hello Alex,

 the getConnection method has been renamed to 
 getSockectConnectionTimeOutMs by the release number 7068 (3 weeks 
 ago, that is to say after 2.1 M2) :
 Deprecated the Client#connectTimeout property as it is hard to find

  compared to other connector parameters. Also, it isn't available for
  all connectors so it can be confusing to expose it.
  Use the socketConnectTimeoutMs connector parameter instead or

  the maxIoIdleTimeMs parameter for internal NIO connectors.

 I wonder if you are using parts of the framework from several 
 releases which can explain the mix. Can you confirm that?

 Best regards,
 Thierry Boileau

 hi,

 something went very wrong...

 I try to connect to a restlet inside a Wicket application (if you
 don't
 know wicket: it is a web framework based on the Java Servlet
 API). I use
 HttpClientConnector to do so. There is a NoSuchMethodException
 (see below).
 To me, it seems very odd, because Method existance should be
 checked on
 compile time, shouldn't it?
 Are there any tips how to solve it? The problem appears with 2.1-M1,
 2.1-M2 and 2.1-SNAPSHOT of the ClientConnector. The other restlet
 dependencies are 2.1-SNAPSHOT. The application server (with the
 wicket
 application on it) is jetty. Server side the jetty connector is used.

 Here is the error:

 java.lang.NoSuchMethodError:
 org.restlet.ext.httpclient.HttpClientHelper.getConnectTimeout()I
 at
 
 org.restlet.ext.httpclient.HttpClientHelper.configure(HttpClientHelper.java:226)
 at
 
 org.restlet.ext.httpclient.HttpClientHelper.start(HttpClientHelper.java:453)
 at org.restlet.Client.start(Client.java:246)
 at org.restlet.Restlet.handle(Restlet.java:225)
 

Re: Inefficient parsing of date header clientresource 2.0.3

2011-01-24 Thread Tal Liron
SimpleDateFormat is not thread-safe -- you have no choice but to 1) 
re-create it per request, or 2) use thread-locals.

-Tal

On 01/24/2011 09:05 AM, Chris Davis wrote:
 Hello,

 I have been profiling my android app that uses android restlet client 
 2.0.3.
 I can see from the profile (image attached see the cornflower blue 
 section on the right hand side of the restlet thread) and subsequent 
 tracing that when DateUtils is used to parse the date header it 
 creates a new SimpleDateFormat object that then has to load all the 
 timezone names from android. This loading takes considerable time and 
 uses a lot of memory and as far as I can tell is done each time a 
 client resource is handled.

 At first I thought that the client should cache the dateformat object 
 but that too would hold onto memory (unless it held a weak reference?)
 but I also see from DateUtils that if the format is RFC 3339 then an 
 InternetDateFormat parser is used which I'm guessing wont need to load 
 the timezone names as the timezone is specified in hours

 So I am wondering that if I can configure my server resources to 
 return the date header in a format that required less processing? We 
 are using restlet 1.1.9 (I know we need to upgrade, we will get around 
 to it eventually) on the server side can I force it to use RFC 3339?

 kind regards
 Chris





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