Re: Prudence 1.0 RC1

[Tal Liron]

Thank you! And I agree entirely.

(I've tried to add the link myself, but it seems Daisy won't sent me a 
confirmation email for my registration...)

On 09/14/2010 05:30 PM, Jerome Louvel wrote:
> Hi Tal,
>
> Congratulations for this release! More users relying on Restlet is always a 
> positive news for our community and technology.
>
> BTW, I've added a link to Prudence here:
> http://wiki.restlet.org/community/165-restlet.html
>
> Best regards,
> Jerome
> --
> Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
> Noelios Technologies ~ http://www.noelios.com
>
>
>
> -Message d'origine-
> De : Tal Liron [mailto:tal.li...@threecrickets.com]
> Envoyé : dimanche 12 septembre 2010 02:39 À : discuss@restlet.tigris.org 
> Objet : Prudence 1.0 RC1
>
> I'm very happy to announce the first public release candidate of Prudence, an 
> open source web development platform based on Restlet 2.0.
>
> http://threecrickets.com/prudence/
>
> Prudence comes with a comprehensive 100-page manual, a complete example 
> application and an extensive online reference. It's been in development for 
> more than a year and has undergone a lot of testing in live production 
> environments.
>
> If you've depended on JEE containers such as Tomcat or JBoss to deploy your 
> Restlet apps, you might be happy to replace them with Prudence.
> Prudence acts as a Restlet-centric container, fully supporting advanced 
> Restlet features such as virtual hosts and routing, while also providing you 
> with a live administration application, pre-configured "just works"
> logging, configuration files for daemons/services, debugging information, and 
> deployment by zip file (just like WAR files in JEE).
> Furthermore, much of the Prudence documentation could be helpful to newcomers 
> to Restlet.
>
> See the special page for Restlet users:
>
> http://threecrickets.com/prudence/manual/restlet-container/
>
> Beyond functioning as a mere container, Prudence provides a JSP-like view 
> environment, with what might be the most sophisticated caching system you've 
> seen in a web platform, and allows easy prototyping of your Restlet resources 
> and filters. You can do all of this in your choice of six dynamic languages: 
> Python, Ruby, JavaScript, PHP, Clojure and Groovy. Velocity and Succinct 
> templating is also included.
>
> Enjoy! And please join the Prudence community:
>
> http://groups.google.com/group/prudence-community
>
> Special thanks go to Noelios, and especially Jérôme, for cultivating such a 
> vibrant community around Restlet. It's a solid foundation.
>
> -Tal Liron
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2657949
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2659770

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

RE: Prudence 1.0 RC1

[Jerome Louvel]

Hi Tal,

Congratulations for this release! More users relying on Restlet is always a 
positive news for our community and technology. 

BTW, I've added a link to Prudence here:
http://wiki.restlet.org/community/165-restlet.html

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com



-Message d'origine-
De : Tal Liron [mailto:tal.li...@threecrickets.com]
Envoyé : dimanche 12 septembre 2010 02:39 À : discuss@restlet.tigris.org Objet 
: Prudence 1.0 RC1

I'm very happy to announce the first public release candidate of Prudence, an 
open source web development platform based on Restlet 2.0.

http://threecrickets.com/prudence/

Prudence comes with a comprehensive 100-page manual, a complete example 
application and an extensive online reference. It's been in development for 
more than a year and has undergone a lot of testing in live production 
environments.

If you've depended on JEE containers such as Tomcat or JBoss to deploy your 
Restlet apps, you might be happy to replace them with Prudence. 
Prudence acts as a Restlet-centric container, fully supporting advanced Restlet 
features such as virtual hosts and routing, while also providing you with a 
live administration application, pre-configured "just works" 
logging, configuration files for daemons/services, debugging information, and 
deployment by zip file (just like WAR files in JEE). 
Furthermore, much of the Prudence documentation could be helpful to newcomers 
to Restlet.

See the special page for Restlet users:

http://threecrickets.com/prudence/manual/restlet-container/

Beyond functioning as a mere container, Prudence provides a JSP-like view 
environment, with what might be the most sophisticated caching system you've 
seen in a web platform, and allows easy prototyping of your Restlet resources 
and filters. You can do all of this in your choice of six dynamic languages: 
Python, Ruby, JavaScript, PHP, Clojure and Groovy. Velocity and Succinct 
templating is also included.

Enjoy! And please join the Prudence community:

http://groups.google.com/group/prudence-community

Special thanks go to Noelios, and especially Jérôme, for cultivating such a 
vibrant community around Restlet. It's a solid foundation.

-Tal Liron

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

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

Re: Using a REST layer for UI and services

[Tal Liron]

Vincent,

This is handled in Prudence using "capturing":

http://threecrickets.com/prudence/manual/routing/#toc-Subsubsection-93

Note that the "capturing" API, like all other Restlet sugar, is available in
the tiny standalone Prudence jar.

-Tal

On Fri, Sep 10, 2010 at 7:54 AM, Vincent Nonnenmacher <
vincent.nonnenmac...@telnowedge.fr> wrote:

> On 10/09/10 09:15, Marc Portier wrote:
> > you might want to give http://kauriproject.org a try
> >
> > it has restlet and all its goodies underneath, but adds
> >- a java and rest-service-wiring (based on spring and then some)
> >- some templating, routing, and client-side ajax/js support (including
> > a form-model) that helps out in this webservice to UI transition
> >
> > we're wrapping up a 0.4 release in the near future
> >
> >
> Hi mark,
>
> I admit I have looked at Kauri but some time ago and lack of documentation
> (and time to try) make me not considering it.
>
> I see that you have made lots of improvements on the doc side
> the mavenization is also nice, I will give it a try, thanks for the
> update ;-)
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2657525
>

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

Re: Prudence 1.0 RC1

[Tal Liron]

Thanks, Vincent!

I agree that Groovy is a great choice for a more Java-centric Restlet
project. I always have fun working with Groovy. (Though my personal favorite
flavor of Prudence is Clojure...)

Your suggestions for documentation are interesting, because they are so
different from what my approach was. :) I was thinking that someone with a
large Java/Restlet application would not look to rewrite things with
Prudence, but instead look to Prudence, perhaps, as a container to replace
JEE. I'm thinking, though, that you are right and it's worth looking at two
new aspects: 1) migrating parts of an existing Java/Restlet app to Prudence,
specifically component/application/routing configuration, and 2) hybrid
mixes of made-in-Java Restlet resources with Prudence resource and pages.
I've actually done both of these things with my production applications.

I've actually never tried to use the Velocity/Freemarker Restlet extensions
as a view layer, so I'm not even sure how migrating the code would work!
But, Velocity is very naturally and easily supported in Prudence, and it
even comes with example code that shows you how to share state between your
Velocity template and your other code.

-Tal

On Mon, Sep 13, 2010 at 3:44 AM, Vincent Nonnenmacher <
vincent.nonnenmac...@agentspace.com> wrote:

> On 12/09/10 02:39, Tal Liron wrote:
> > I'm very happy to announce the first public release candidate of
> > Prudence, an open source web development platform based on Restlet 2.0.
> >
> > http://threecrickets.com/prudence/
> >
> > Prudence comes with a comprehensive 100-page manual, a complete example
> > application and an extensive online reference. It's been in development
> > for more than a year and has undergone a lot of testing in live
> > production environments.
>
> Great work !
> I  tried it over this weekend and it sound like I could migrate back from
> an external ruby/sinatra for the UI computation part to prudence.
>
> Especialy the fact that with groovy support its far more easier
> to do some Restlet Ressource inner integration on the view
> side with very powerfull routings.
>
> > If you've depended on JEE containers such as Tomcat or JBoss to deploy
> > your Restlet apps, you might be happy to replace them with Prudence.
> > Prudence acts as a Restlet-centric container,
> The documentation is very nice and the tutorial a breeze to play with ;-)
>
> Perhaps one area to document would be for Reslet developers
> showing them how they can enrich there own routing/mapping of ressources
> to view delivery with prudence with a scripting level layer of their
> choice.
>
> I feel it could solve some of my problems but with contrained time it
> somewhat
> scary to adopt on a latter stage something that taken from the outside
> look like an 'other radical choice for a latter projet', when there is
> perhaps
> small steps to follow to convert let say a freemaker/velocity view kind
> of mapping
> to a Prudence app.
>
>  From that some parrallel side by side description on how to
> do things by hands with Restlet and doing the same with prudence would
> bring
> you some converts ;-)
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2658657
>

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

RE: Embedded Jetty

[webpost]

Any help on this would be appreciated.

Roy

> I'm attempting to use Jetty 7.1.5 with Restlet 1.1.10 however there's no 
> connector jar included for this version of Jetty - only Jetty 6.1.  So, I'm 
> wondering is it possible to use Jetty 7?
> 
> Also, I'm not sure where put jetty.xml so I can configure the server settings.
> 
> Thanks,
> 
> Roy

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

RE: Tutorial Service Down?

[Jerome Louvel]

Hi Soham,

Sorry but the associated Azure account has expired. I have added a note about 
it in the tutorial. Sorry for the inconvenience.

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com




-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : mardi 27 juillet 2010 22:28
À : discuss@restlet.tigris.org
Objet : Tutorial Service Down?

Is the service document from the 
http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/287-restlet/288-restlet.html
 tutorial down?

I keep getting timed-out trying to run the java -jar org.restlet.ext.odata.jar 
http://restlet.cloudapp.net/TestAssociationOneToOne.svc/ ~/workspace/testADO 
command.

Thanks,
Soham

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

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

RE: Correct way to use android ClientResource

[Jerome Louvel]

Hi Chris,

First, the current internal HTTP client in 2.0 isn't optimized to reduce thread 
usage. We are fixing this design issue in 2.1 using non-blocking NIO. For now, 
you can also leverage the Apache HTTP Client extension which is support for the 
Android edition.

Otherwise, you can reuse the same Client instance across several ClientResource 
instances. Just call 

myClientResource.setNext(myClient);

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com



-Message d'origine-
De : Chris Davis [mailto:chris.da...@hullomail.com] 
Envoyé : mardi 3 août 2010 11:15
À : discuss@restlet.tigris.org
Objet : RE: Correct way to use android ClientResource

I've traced further into the code and it seems to be the BaseHelper class that 
is creating a controller service and worker service. This happens for each new 
clientresource object. 

I currently have a clientresource object for each of my resources, is this the 
right way to go about it or should I be sharing one clientresource or maybe 
using the lower level client class??

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

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

RE: Very slow file serving

[Jerome Louvel]

Hi Richard,

Which connector are you using and version of Restlet? What is the response time 
when you don't add the ZipOutputStream wrapper?

Did you try leveraging the org.restlet.engine.application.EncodeRepresentation 
class?

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com



-Message d'origine-
De : jupiterroom [mailto:richcol...@googlemail.com] 
Envoyé : vendredi 2 juillet 2010 20:22
À : discuss@restlet.tigris.org
Objet : Very slow file serving

Hi,

I've extended OutputRepresentation and I use the OutputStream that gets passed 
to it like this:

OutputStream < ZipOutputStream < ObjectOutputStream.

Basically I'm serializing Objects that will end up being streamed to the 
client, so no Zip on the server side.  This all works, the only issue is the 
speed at which it happens.  For an 80kb zip it takes around 15-16 seconds and 
most of the time is spent on objectOutputStream.write(Object)

Any ideas what I'm doing wrong?

p.s in my unit test, I pass a FileOutputStream to the write method of my 
OutputRepresentation and it takes less that a seconds

Richard
--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Very-slow-file-serving-tp5248755p5248755.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

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

RE: Directory and FTP

[Jerome Louvel]

Hi Jean-Christophe,

 

I agree, this would be a nice enhancement and entered a RFE :

http://restlet.tigris.org/issues/show_bug.cgi?id=1183

 

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~   
http://www.restlet.o​rg
Noelios Technologies ~   http://www.noelios.com

 

 

 

De : Jean-Christophe Malapert [mailto:jcmalap...@googlemail.com] 
Envoyé : lundi 5 juillet 2010 08:37
À : Jerome Louvel
Cc : discuss
Objet : Re: Directory and FTP

 

Hi Jerome,

As you said, there are sevral ways to solve the problem with Restlet and I 
found another way to make it works (maybe not the easiest). Basically I created 
a class extending from ServerResource and an application. In the application, I 
use a certain configuration of the router : 

router.attachDefault(FtpResource.class).setMatchingMode(Template.MODE_STARTS_WITH);

In the resource, I parse the representation returned by the FTP server using a 
pattern ( private static final Pattern pattern = 
Pattern.compile("[drwxs-]{10}");). 
When my response matches with the pattern, it means that my response is a 
contain of a FTP directory otherwise the response is a file.
In the case where the response is a contain of a FTP directory, I build a 
referenceList. From this referenceList, I apply some representations (HTML, 
text/uri-list).
In the case where the response is a file, I return the file.

It will be nice that the directory class can support the browse through a FTP 
site.

Best regards,
J-Christophe

On Fri, Jul 2, 2010 at 4:06 PM, Jerome Louvel  wrote:

Hi Jean-Christophe,

 

I hope you solved this issue, sorry for the delay. In the response headers, you 
have “application/octet-stream” as content type/media type which explains the 
browser behavior.

 

The FTP client connector provided by the “org.restlet.ext.net” extension 
automatically sets the media type when the file name has extensions such as 
“.txt”. 

 

In your case, it seems that your files have no extension which leads the engine 
to call MetadataService#getDefaultMediaType() which returns 
“application/octet-stream” by default.

 

You have two solutions (at least):

· Call MetadataService#setDefaultMediaType() with a different value 
(global to your application)

· Add a filter in front of your directory that will change the media 
type appropriately

 

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

 

 

 

De : Jean-Christophe Malapert [mailto:jcmalap...@googlemail.com] 
Envoyé : vendredi 21 mai 2010 17:41
À : Jerome Louvel
Cc : discuss
Objet : Re: Directory and FTP

 

Hi Jerome,

Here is the detail : 


GET /files/test HTTP/1.1
Host: localhost:8180
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.2.3) Gecko/20100423 
Ubuntu/10.04 (lucid) Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

21 mai 2010 17:33:41 org.restlet.engine.local.DirectoryServerResource doInit
INFO: Converted target URI: ftp://193.190.231.123/
21 mai 2010 17:33:41 org.restlet.engine.local.DirectoryServerResource 
getVariants
INFO: Getting variants for : ftp://193.190.231.123/
21 mai 2010 17:33:41 org.restlet.engine.log.LogFilter afterHandle
INFO: 0:0:0:0:0:0:0:1 GET 200 /files/test AGENT:Mozilla/5.0 (X11; U; Linux 
x86_64; fr; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
REF:
HTTP/1.1 200 The request has succeeded
Transfer-Encoding: chunked
Date: Fri, 21 May 2010 15:33:41 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0rc3
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Language: fr
Content-Location: http://localhost:8180/files/test
Content-Type: application/octet-stream; charset=UTF-8

542
drwxrws---3 1001 1000 4096 May 09  2009 1993
drwxrws---3 1001 1000 4096 May 09  2009 1994
drwxrws---7 1001 1000 4096 May 09  2009 1995
drwxrws---9 1001 1000 4096 May 09  2009 1996
drwxrws---9 1001 1000 4096 May 08  2009 1997
drwxrws---9 1001 1000 4096 May 08  2009 1998
drwxrws---9 1001 1000 4096 May 08  2009 1999
drwxrws---9 1001 1000 4096 May 08  2009 2000
drwxrws---   10 1001 1000 4096 May 08  2009 2001
drwxrws---   10 1001 1000 4096 May 08  2009 2002
drwxrws---   10 1001 1000 4096 May 08  2009 2003
drwxrws---   11 1001 1000 4096 Dec 29 06:24 2004
drwxrws---   12 1001 1000 4096 Dec 29 06:24 2005
drwxrws---   11 1001 1000 4096 Dec 29 06:24 2006
drwxrws---   11 1001 1000 4096 Jan 15 06:49 2007
drwxrws---   11 1001 1000 4096

RE: ClientResource leaves inactive thread

[Jerome Louvel]

Hi Tim,

 

In the upcoming HTTP/NIO internal connectors for version 2.1, I’ve made the 
thread pool fully customizable. See the org.restlet.engine.nio. BaseHelper 
class for more details. Currently in Restlet incubator but soon to be moved to 
SVN trunk.

 

* controllerDaemon

* boolean

* true (client), false (server)

* Indicates if the controller thread should be a daemon (not blocking JVM

* exit).

 

* controllerSleepTimeMs

* int

* 50

* Time for the controller thread to sleep between each control.

 

* minThreads

* int

* 5

* Minimum number of worker threads waiting to service calls, even if they

* are idle.

 

* lowThreads

* int

* 8

* Number of worker threads determining when the connector is considered

* overloaded. This triggers some protection actions such as not accepting new

* connections.

 

* maxThreads

* int

* 10

* Maximum number of worker threads that can service calls. If this number

* is reached then additional calls are queued if the "maxQueued" value hasn't

* been reached.

 

* maxQueued

* int

* 10

* Maximum number of calls that can be queued if there aren't any worker

* thread available to service them. If the value is '0', then no queue is used

* and calls are rejected. If the value is '-1', then an unbounded queue is used

* and calls are never rejected.

 

* maxIoIdleTimeMs

* int

* 3

* Maximum time to wait on an idle IO operation.

 

* maxThreadIdleTimeMs

* int

* 6

* Time for an idle thread to wait for an operation before being 
collected.

 

* tracing

* boolean

* false

* Indicates if all messages should be printed on the standard console.

 

* workerThreads

* boolean

* true

* Indicates if the processing of calls should be done via threads provided

* by a worker service (i.e. a pool of worker threads). Note that if set to

* false, calls will be processed a single IO selector thread, which should

* never block, otherwise the other connections would hang.

 

* inboundBufferSize

* int

* 8*1024

* Size of the content buffer for receiving messages.

 

* outboundBufferSize

* int

* 32*1024

* Size of the content buffer for sending messages.

 

* directBuffers

* boolean

* true

* Indicates if direct NIO buffers should be allocated instead of regular

* buffers. See NIO's ByteBuffer Javadocs.

 

* transport

* String

* TCP

* Indicates the transport protocol such as TCP or UDP.

 

 

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~   
http://www.restlet.o​rg
Noelios Technologies ~   http://www.noelios.com

 

 

 

 

De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim Peierls
Envoyé : samedi 3 juillet 2010 19:15
À : discuss@restlet.tigris.org
Objet : Re: ClientResource leaves inactive thread

 

My earlier mail said something wrong, or at least misleading: 

...defaulting coreThreads=1 and maxThreads=255 with a SynchronousQueue seems 
like it's asking for trouble with CPU count << 255. 

 

I shouldn't have included that last italicized phrase "with CPU count << 255". 
The point was that SynchronousQueues should have unbounded pool size. 

 

Jerome's response of setting maxPoolSize to 10 by default (and still using 
SynchronousQueue) means that tasks will be rejected that much sooner, which 
will probably cause more problems for people than a value of 255.

 

The thing about a SynchronousQueue is that it isn't really a queue -- it has 
zero capacity. Putting something on a synchronous queue blocks until there's 
something (i.e., a thread) at the other end to hand it off to directly. In 
development or for small applications where you aren't too worried about 
exhausting thread resources, this is fine. In production systems, though, you 
want to be able to configure something other than direct handoff.

 

Here is the relevant section from the TPE javadoc 

 :

---

Any  
 
BlockingQueue may be used to transfer and hold submitted tasks. The use of this 
queue interacts with pool sizing:

*   If fewer than corePoolSize threads are running, the Executor always 
prefers adding a new thread rather than queuing.
*   If corePoolSize or more threads are running, the Executor always 
prefers queuing a request rather than adding a new thread.
*   If a request cannot be queued, a new thread is created unless this 
would exceed maximumPoolSize, in which case, the task will be rejected.

There are three general strategies for queuing:

1. Direct handoffs. A good default choice for a work queue is a  

 SynchronousQueue that hands off tasks to threads without otherwise holding 
them. Here, an attempt to queue a task will fail if no threads are immediately 
available to run it, so a new thread will be 

RE: Maven distribution problem

[Jerome Louvel]

Hi Karel,

Thanks for the suggestion to use classifiers, that sounds appropriate for 
Restlet editions. I entered a RFE:
http://restlet.tigris.org/issues/show_bug.cgi?id=1182

However, the current mechanisms ensures that all extensions have a separate 
artifact for each edition, based on the parent's groupID. It may not be ideal 
compared to classifiers but it does seem to work. Am I missing your point?

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com




-Message d'origine-
De : Karel Vervaeke [mailto:ka...@outerthought.org] 
Envoyé : vendredi 2 juillet 2010 22:37
À : discuss@restlet.tigris.org
Objet : Maven distribution problem

(short version)
When building the 'gae' restlet edition, you have a separate groupId for the 
restlet 'core' artifact (org.restlet.gae:org.restlet instead of 
org.restlet.jse:org.restlet), which is nice.

Unfortunately, the 'gae' edition also introduces changes in 
org.restlet:org.restlet.ext.servlet (via ifdef/ifndef instructions).
So depending on the edition, you have different 'editions' of the same maven 
artifact, which Maven doesn't like.
It might be better (though I didn't examine the details) to use maven's 
classifier mechanism for distinguishing the maven artifacts

This page does a good job at describing maven  classifiers:
http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-platform-classifier.html

Does this make sense?
Karel

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

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

Subtle hiding of allowed methods in case of a 404

[Marc Portier]

A bit of nit-picking maybe.

With the new ServerResource the updateAllowedMethods is not called if a 
isExists() returns false.

The use case is for OPTIONS on a /whatever/non-existing-yet

It used to return a 404 Not Found in combo with listing PUT as a valid 
Allow: method to invite the client to go ahead and create the resource.

I'm currently calling updateAllowedMethods in my subclass from the 
doInit() to make sure I get the same behaviour as before (admitting I 
was still using the deprecated Resource) but this feels more as a hack, no?

Haven't created a ticket or patch yet since you might want to chime in 
on how best to handle this.

regards,
-marc=

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

RE: Restlet + GAE Security Exception !!

[Jerome Louvel]

Hi Thangavel,

Since your mail the engine classloader has been reworked and doesn't rely on 
the system classloader. You shouldn't get this exception anymore.

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com




-Message d'origine-
De : SelvaGold [mailto:thangavel.loganat...@gmail.com] 
Envoyé : mercredi 30 juin 2010 18:20
À : discuss@restlet.tigris.org
Objet : Restlet + GAE Security Exception !!

Hi !!

  Am creating the simple Restlet App with Spring running in GAE, i am 
accessing the another server and wanna get response from that server. I am 
using  the below code 

try {

Client client = new 
Client(Protocol.HTTP);
Response response = 
client.get("http://staging.webservices.com";);
log.info("The Status is ::: 
"+response.getStatus());
Representation representation = 
response.getEntity();
message = representation.getText();
System.out.println("The Message is ::: 
"+message);

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}



While running in GAE am facing the below exception , ===

java.security.AccessControlException: access denied 
(java.lang.RuntimePermission getClassLoader)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:355)
at
java.security.AccessController.checkPermission(AccessController.java:567)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at
com.google.apphosting.runtime.security.CustomSecurityManager.checkPermission(CustomSecurityManager.java:45)
at java.lang.ClassLoader.getSystemClassLoader(Unknown Source)
at org.restlet.util.Engine.getInstance(Engine.java:141)
at org.restlet.Restlet.(Restlet.java:82)
at org.restlet.Connector.(Connector.java:83)
at org.restlet.Client.(Client.java:82)
at org.restlet.Client.(Client.java:101)
at org.restlet.Client.(Client.java:121)
at
com.adaptavant.restlet.webservice.RestletClientGAEServlet.handleRequest(RestletClientGAEServlet.java:32)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:824)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:769)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:613)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at
com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:97)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

==


i am having the org.restlet.jar,  org.restlet.ext.spring.jar and 
org.restlet.ext.servlet.jar for GAE 


Any  Suggestion on  this please help me on this issue

---

Thangavel

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Restlet-GAE-Security-Exception-tp5237924p5237924.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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

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

RE: [https netty]netty connector answering to only one request

[Jerome Louvel]

Hi Laurent,

Thanks for the report and the test application. I've just fixed the bug in 
Netty HTTPS connector preventing the handling of several connections, 
persistent connections and chunked encoding. Netty has also been updated to 
version 3.2.2.

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com



-Message d'origine-
De : Laurent Rustuel [mailto:laurent.rust...@genesyslab.com] 
Envoyé : vendredi 18 juin 2010 14:29
À : discuss@restlet.tigris.org
Objet : Re: [https netty]netty connector answering to only one request

Hello,
Anybody had a chance to test and confirm this ?
If it is confirmed, I can create a bug report.

Regards,
Laurent.

Le 09/06/2010 15:40, Laurent Rustuel a écrit :
> Hello,
>
> We tried, in our project, to configure https support. This part was ok 
> :) Now, we wanted to use netty with https, and I have this strange 
> behavior
> : only one request can be served.
> With jetty or simple, everything is fine, this problem occurs only 
> with netty.
> Also, this problem can be found using other client (restclient, web 
> browser, etc.)
>
> The server can answer the first request, but any other call will not 
> be handled.
>
> Trace when using jetty in the server side :
> 9 juin 2010 15:30:59 
> org.restlet.engine.http.connector.HttpClientHelper
> start
> INFO: Starting the default HTTP client returned : it worked returned : 
> it worked
>
> same code, using netty in server side :
> 9 juin 2010 15:28:50 
> org.jboss.netty.channel.socket.nio.NioProviderMetadata
> FIN: Using the autodetected NIO constraint level: 0
> 9 juin 2010 15:28:50 
> org.restlet.engine.http.connector.HttpClientHelper
> start
> INFO: Starting the default HTTP client returned : it worked
> 9 juin 2010 15:28:51 org.restlet.engine.http.connector.Connection
> readMessages
> FIN: Error while reading a message. Closing the connection.
> 9 juin 2010 15:28:51 org.restlet.engine.http.connector.Connection
> readMessages
> FIN: Error while reading a message. Closing the connection.
> java.net.SocketException: Software caused connection abort: recv failed
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.read(Unknown Source)
>   at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)
>   at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
>   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
>   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown
> Source)
>   at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
>   at java.io.BufferedInputStream.fill(Unknown Source)
>   at java.io.BufferedInputStream.read(Unknown Source)
>   at
> org.restlet.engine.http.connector.ClientConnection.readMessage(ClientConnection.java:168)
>   at
> org.restlet.engine.http.connector.Connection.readMessages(Connection.java:685)
>   at 
> org.restlet.engine.http.connector.Controller$2.run(Controller.java:94)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)
>
>
>
>
> (see attached file, an eclipse project to reproduce [2,5 Mo])
>
> Regards,
> Laurent.
>


--
Laurent Rustuel,
Alten contractor for Genesys, an Alcatel-Lucent Company


---
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential and proprietary information of Alcatel-Lucent and/or its 
affiliated entities. Access by the intended recipient only is authorized. Any 
liability arising from any party acting, or refraining from acting, on any 
information contained in this e-mail is hereby excluded. If you are not the 
intended recipient, please notify the sender immediately, destroy the original 
transmission and its attachments and do not disclose the contents to any other 
person, use it for any purpose, or store or copy the information in any medium. 
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or 
its affiliated entities.

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

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

Pls delete: Hierarchical data to URL mapping question

[Giannis Ntzegkoutanis]

Please delete my previous message "Hierarchical data to URL mapping question"

The problem was in:

remainingPart.split("?");

Changed to:

remainingPart.split("\\?");

This is what you get when you program for 10+ hours...

Sorry for the unneeded post

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

Re: Broken pipe / Unexpected end of file from server Problem

[Timothy Aanerud]

I end up switching HTTP connectors to solve my problem.   In my scenario I
have client application running on Fedora using restlet using the Apache
HTTP connector that talks to a restlet server running on Ubuntu using the
Grizzly HTTP connector.  The conditions you are describing are match what I
was experiencing.

Switching to the Apache HTTP connector on the client side solved my
problem.  I think I have since fixed a bug in my code where I wasn't
completely consuming the input stream in all cases. But, I doubt that was my
original problem.
--
Timothy


On Fri, Sep 10, 2010 at 3:28 AM, Achim W.  wrote:

> Hi!
>
> Using Restlet 1.1.10, Sun Java 6, tested on Windows XP/Debian/Ubuntu.
>
> I found a problem in NET client connector. Sometimes there is a Exception
> with messages:
> - java.io.IOException: Broken pipe (Server)
> - java.net.SocketException: Unexpected end of file from server (Client)
>
> When using the standard(?)/fall-back(?) Connector (i.e
> "com.noelios.restlet.http.StreamClientHelper", NET .jar _not_ in the
> classpath) there is no problem.
>
> When using the NET Connector (i.e.
> "com.noelios.restlet.ext.net.HttpClientHelper", NET .jar in the classpath)
> then every second request fails if there is a specific time (~2 - ~5
> seconds) between the current and the previous request. It seems the server
> closes the connection after ~2(?) seconds after the last request/response
> which answers the client with FIN. But the client does not really close the
> connection within ~5 seconds. If the next request is within those 5 seconds
> the client tries to reuse the old (already closed by server) connection.
>
> This problem exist in NET connector when using HTTP and when using HTTPS.
> Standard connector has no problem when using HTTP, HTTPS is not supported by
> standard connector.
>
> I found another post of a user with the same problem but he couldn't
> reproduce it (outside of his production environment):
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363539
>
> I have written sample programs for server/client which show the issue. When
> using 0msec and 5200msec between request there is no problem, when using
> 2000msec the exception occurs every second request.
>
> Attached are the sample programs as eclipse projects and traces of
> HTTP+standard connector, HTTP+NET connector and HTTPS+NET connector.
> To use the NET connector just remove the NET lib from the build path of the
> client project.
>
> best regards
> Achim
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2657466

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

RE: Embedded Jetty

[webpost]

Please ignore.  Sorry for the duplicate post (and html tags).

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