Restlet 1.2 -- Filter

[Lars Heuer]

Hi all,

I ran against a problem with the 1.2 Filter. The filter does not let
me specify that 'next' is a ServerResource.

I propose to change Filter as follows:

- Add method "setNext(Class targetClass)"
  or "setNext(Class targetClass)"
- Remove "setNext(Class targetClass)"
- Add a constructor that takes either Class or Classhttp://www.semagia.com

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

Re: Google AppEngine and Restlet

[Lars Heuer]

[...]
> Just out of curiosity: Has someone tried Google AppEngine [1] together
> with Restlet (Servlet connector)?

I ran a few toy applications against the Google AppEngine SDK and
discovered no problems so far.

Best regards,
Lars
-- 
http://www.semagia.com

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

RE: Google AppEngine and Restlet

[Jerome Louvel]

Hi all,

When using third-party libraries with GAE SDK, you have to be careful
because those libraries are not verified against the available Java classes
(white list). Therefore, it will work locally but break at deployment time!

Hint: an adaptation of Restlet for GAE is underway. Stay tuned ;)
 
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 : Lars Heuer [mailto:he...@semagia.com] 
Envoyé : vendredi 10 avril 2009 12:32
À : discuss@restlet.tigris.org
Objet : Re: Google AppEngine and Restlet

[...]
> Just out of curiosity: Has someone tried Google AppEngine [1] together 
> with Restlet (Servlet connector)?

I ran a few toy applications against the Google AppEngine SDK and discovered
no problems so far.

Best regards,
Lars
--
http://www.semagia.com

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

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

Re: Google AppEngine and Restlet

[Lars Heuer]

Hi Jérôme,

> When using third-party libraries with GAE SDK, you have to be
> careful because those libraries are not verified against the
> available Java classes (white list). Therefore, it will work locally
> but break at deployment time!

Are you sure? I understood the purpose of the SDK that it emulates the
Google service completely. So, if a lib uses classes not available at
the Google server, your application won't work (locally).

Best regards,
Lars
-- 
http://www.semagia.com

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

RE: Google AppEngine and Restlet

[Jerome Louvel]

Hi Lars,

For the JRE classes, I'm pretty sure (based on feed-back from Groovy
developers who did a port to GAE). For other dependencies, you are probably
right.

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 : Lars Heuer [mailto:he...@semagia.com] 
Envoyé : vendredi 10 avril 2009 16:00
À : discuss@restlet.tigris.org
Objet : Re: Google AppEngine and Restlet

Hi Jérôme,

> When using third-party libraries with GAE SDK, you have to be careful 
> because those libraries are not verified against the available Java 
> classes (white list). Therefore, it will work locally but break at 
> deployment time!

Are you sure? I understood the purpose of the SDK that it emulates the
Google service completely. So, if a lib uses classes not available at the
Google server, your application won't work (locally).

Best regards,
Lars
--
http://www.semagia.com

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

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

RE: DirectoryResource throws/logs useless exceptions for CLAP protocol

[Jerome Louvel]

Tal,
 
My view is that Directory is such a critical piece of Restlet that if we
find serious performance issues with it, we should fix them as soon as
possible rather than spending time working around. If somebody would have
time to do serious comparisons, that would help us realize how far behind
alternatives we are.
 
>From a high level design, there is nothing I see that creates a bottleneck.
Used in combination with the Grizzly connector, you can even achieve direct
disk to socket transfer using NIO. All extra features that could slow down
the serving should have a flag.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : mercredi 8 avril 2009 19:36
À : discuss@restlet.tigris.org
Objet : Re: DirectoryResource throws/logs useless exceptions for CLAP
protocol


This is something that concerns me, too, as I'd much rather have my
applications purely in the Restlet API without reverting specifically to the
connector. I've been using Directory, too, in production and without any
issue except my uneasiness about performance. I have not dared use it (yet)
in performance-intensive situation.

I'm wondering if it's worth, in addition to Restlet's Directory, to support
a simple connector-agnostic wrapper that would use the underlying
DefaultServlet or whatever. The Grizzly and Jetty projects already are doing
superb work on optimization of serving static files, and we might as well
wrap it! I see it as a lowest-common-denominator kind of API, which just
sets up a filesystem-to-HTTP server and offers minimal fiddling.

Of course, I'm not expecting such a wrapper to return nice Restlet
representations which we can Filter. It would be a "black box" as far as the
Restlet API is concerned. Still, I think this would be very useful. Many
users (myself included) turn to Restlet in order to create performative
applications. Serving static files should be part and parcel of this.

-Tal

Jerome Louvel wrote: 

Dave,
 
Thanks for looking at the details on Directory implementation. This are
certainly opportunities to refactor and optimize this class. As you found
out, it is handling pretty complex stuff. We would welcome some
contributions in this area. 
 
We have also received a report regarding performance issue of Directory used
with the WAR client that we need to inspect. This might be due to the same
reason:
 
"Improve performance of WAR client"
http://restlet.tigris.org/issues/show_bug.cgi?id=736
 
Regarding the production ready status, we have been using this class on all
our Web sites with no trouble so far.
 
Would you mind creating a bug report for what you found?

 

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

  _  

De : Rob Heittman [mailto:rob.heitt...@solertium.com] 
Envoyé : mardi 7 avril 2009 14:26
À : discuss@restlet.tigris.org
Objet : Re: DirectoryResource throws/logs useless exceptions for CLAP
protocol


I also wish it were a bit faster. We do serve several hundred thousand
impressions out of Directory every month, but we serve several million using
thinner Resources not wrapped in Directory -- not sure what would happen if
we wrapped those in Directory.


On Tue, Apr 7, 2009 at 1:58 AM, David Fogel  wrote:


The Directory class is the only built-in way for plain, non-servlet,
Restlet apps to serve static content. Should we consider it
"production"-ready w.r.t. performance under load? Another way of
asking this: is the Directory class a reasonable substitute for, e.g.
Jetty's DefaultServlet?

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

RE: ServerResource conditional mode

[Jerome Louvel]

Tal,
 
My understanding is that conditional POST/PUT require the presence of an
existing resource/state to check the conditions on.
 
The latest behavior in SVN trunk should NOT trigger a GET if you do a POST
or a PUT *without* any condition specified. If this still doesn't work then
it is a bug.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : mercredi 8 avril 2009 23:55
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome,




I understand If-Match, but I'm still confused by ServerResource's support of
it in conditional mode. Logically, POST and PUT should work even if there is
no entity, right?





Right now, my GET returns an error status because there is no entity, but
then I can't get POST/PUT to work while in conditional mode because of that.
No entity, no possibility of checking conditions... which doesn't make sense
to me.





It seems to me that if GET doesn't return a value, then POST and PUT should
continue as normal in conditional mode. Could the problem be that I'm
setting an error status? But, then, I do need to set an error status for
true failures of GET...




I'm still confused!





-Tal



Jerome Louvel wrote:


Hi Tal,
 
The conditional mode is here to support HTTP conditional methods as
explained for the "If-Match" header:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24
 
The idea is that before executing some methods (PUT, POST, etc.), it is
possible to check whether the resource state has changed (tag or date
comparison). This check has to be done on the entity that would have been
returned by an equivalent GET. So we have to simulate a GET in order to
check conditions, whatever is the actual method handled.
 
Now, there is no reason to simulate the GET if the client hasn't expressed
any condition. I have fixed ServerResource#doConditionalHandle() so it will
work fine in your cases. 
 
Just note that if your client do express some conditions, the ServerResource
will expect your subclasses to provide support for GET or else it will
result in an error. I think this is reasonable and you can always turn off
conditional processing if you really don't want to provide GET
implementation.
 
Hope this clarifies.

 

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

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 2 avril 2009 23:20
À : discuss@restlet.tigris.org
Objet : ServerResource conditional mode



Hi,




Does someone have a grasp on what conditional mode is for and how it used?




It's enabled by default, but I had to disable it for one of my resources to
work with PUT and POST. The issue is that it always calls doGetInfo first,
which for my particular resource will fail, and so calls to PUT and POST
also fail.


Also, it seems to me that calling doGetInfo for every request, even for
methods that are not GET, is wasteful. In short, I simply don't understand
why this check happens, and subsequently what exactly conditional mode is
doing. :)

-Tal

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

RE: ServerResource conditional mode

[Jerome Louvel]

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to rethrow checked exceptions of
annotated method as ResourceExceptions. This result in a 500 (Internal
server error) status being set by the ServerResource#handle() method.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome, regarding exceptions caught --




You've implemented this only for when users override methods in
non-annotated mode. In annotated mode, exceptions are still not allowed.
This leads to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions across
the board would result in better user code.




If you decide that you do want to handle exceptions for annotated handlers,
see doHandle(AnnotationInfo): you would need to get the reflected exception
via InvocationTargetException.getTargetException().




Whatever you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.





-Tal



Jerome Louvel wrote:


2) Exceptions caught
 
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example. 
 
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).

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

Re: ServerResource conditional mode

[Tal Liron]

Pretty good... except what if the user throws a
ResourceException with a specific status code? I suggest something like
this instead:

catch(InvocationTargetException e) {
    Throwable te = e.getTargetException();
    if (te instanceof ResourceException) {
       throw (ResourceException) te;
    } else {
       throw new ResourceException(te);
    }
}


Jerome Louvel wrote:

  
  
  Tal,
   
  Thanks for this issue report.
   
  I've changed the ServerResource behavior to
rethrow checked exceptions of annotated method as ResourceExceptions.
This result in a 500 (Internal server error) status being set by the
ServerResource#handle() method.
  
  
   
  
  
  Best regards,
Jerome Louvel
--
  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
  
  
   
  
  
  De : Tal Liron
[mailto:tal.li...@threecrickets.com] 
  Envoyé : jeudi 9 avril 2009 00:06
  À : discuss@restlet.tigris.org
  Objet : Re: ServerResource conditional mode
  
  
  Jerome,
regarding exceptions caught --
  
  
  You've
implemented this only for when users override methods in non-annotated
mode. In annotated mode, exceptions are still not allowed. This leads
to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions
across the board would result in better user code.
  
  
  If
you decide that you do want to handle exceptions for annotated
handlers, see doHandle(AnnotationInfo): you would need to get the
reflected exception via InvocationTargetException.getTargetException().
  
  
  Whatever
you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.
  
  
  
  -Tal
  
  
Jerome Louvel wrote:
  
  

2) Exceptions caught
 
Currently (SVN trunk at least), the
ResourceExceptions are caught and the response status is updated
accordingly. This is done in the ServerResource#handle() method. Other
exceptions will be caught upper in the processing chain, by the
StatusService for example. 
 
We do have some plans to extend the
ConverterService in order to automatically convert common exceptions
into matching statuses, but I'm not clear yet whether this is such a
good idea (JAX-RS has this).
  

RE: Annotations and Restlet's future

[Jerome Louvel]

Hi all,
 
I haven't fully digested all this feed-back, but it helps tremendously! Just
to clarify a few points:

*   

Rob correctly guessed my thoughts, annotations should be a fully
optional feature
*   

I like to have this feature turned on by default because it lowers
the barrier of entry for new users. For experienced Restlet developers, it's
easy enough to override the "doInit()" method and call
"setAnnotated(false)".
*   Non-annotated resources shouldn't impose any significant performance
hit, even if the "annotated" flag is turned on (annotation detection is done
only once)

*   

No additional annotation is expected in Restlet 1.2, we should stick
with the current 5 public annotations
*   

Exceptions are no rethrown for annotated methods

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

 
  _  

De : Rémi Dewitte [mailto:remidewi...@gmail.com] 
Envoyé : vendredi 10 avril 2009 08:58
À : discuss@restlet.tigris.org
Objet : Re: Annotations and Restlet's future


Hello,

I thank you all to clear my mind about annotations.
Annotations are probably good to get started with a hello world or minimize
the amount of code you would write. But you lose some compilation checks and
moreover developing further more complex resources will require to
understand how it works (routing/switch logic) and which methods will not be
called because of the use of annotations. If I want to search for resources
class will I have to search for @Resource as well ? How far are we from
annotated Restlets ?

Would it be possible to have ServerResource free of annotation logic and an
AnnotatedServerResource subclass removing the need for isAnnotated ?

Cheers,
Rémi



On Thu, Apr 9, 2009 at 17:47, Rob Heittman 
wrote:


GWT 1.5/1.6 is happy with annotations at compile time ... but if the
implementation needs to examine them at runtime via reflection, GWT doesn't
have that capability.  GWT getClass() emulation doesn't have
getAnnotations() ... or much of anything else.  There's no reflection in the
Javascript room.

Restlet 1.2's current incarnation is fine with me ... annotations optional.
But I agree that the non-annotation and annotation approach should use the
same vowels and consonants in the same order whenever possible  :-)  This
helps us bears of very little brain. 


On Thu, Apr 9, 2009 at 7:06 AM, Tim Peierls  wrote:


On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman 
wrote:


...my only *strong* requirement, that the annotation based solution must
remain a voluntary choice and not the only way to get things done.  It
should remain possible to achieve whatever annotations can achieve in a
non-annotation way.  This allows the basic API outline to work in places
where annotations are not available or work differently enough to cause
friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala
...)  It is OK with me if the non-annotation approach requires verbosity or
heavy lifting, it just needs to exist.


Isn't that currently the case with the 1.2 branch? (Does GWT not support
annotations yet? I thought it did.)

It would be best if the non-annotation approach used the same terminology as
the annotations, and I think that's not the case right now.


--tim

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

RE: ServerResource conditional mode

[Jerome Louvel]

I had the same thought and updated SVN trunk a couple of minutes ago with
the exact same code ;)
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 
  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : vendredi 10 avril 2009 20:09
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode


Pretty good... except what if the user throws a ResourceException with a
specific status code? I suggest something like this instead:

catch(InvocationTargetException e) {
Throwable te = e.getTargetException();
if (te instanceof ResourceException) {
   throw (ResourceException) te;
} else {
   throw new ResourceException(te);
}
}


Jerome Louvel wrote: 

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to rethrow checked exceptions of
annotated method as ResourceExceptions. This result in a 500 (Internal
server error) status being set by the ServerResource#handle() method.

 

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

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome, regarding exceptions caught --




You've implemented this only for when users override methods in
non-annotated mode. In annotated mode, exceptions are still not allowed.
This leads to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions across
the board would result in better user code.




If you decide that you do want to handle exceptions for annotated handlers,
see doHandle(AnnotationInfo): you would need to get the reflected exception
via InvocationTargetException.getTargetException().




Whatever you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.





-Tal



Jerome Louvel wrote:


2) Exceptions caught
 
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example. 
 
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).

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

Re: ServerResource conditional mode

[Tal Liron]

Supple,
ingenious, creative, compassionate, endlessly-open minds think alike!

Jerome Louvel wrote:


  
  
  
  I had the same thought and updated SVN trunk a
couple of minutes ago with the exact same code ;)
  
  
   
  
  
  Best regards,
Jerome Louvel
--
  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
  
  
   
  
  De : Tal Liron
[mailto:tal.li...@threecrickets.com] 
  Envoyé : vendredi 10 avril 2009 20:09
  À : discuss@restlet.tigris.org
  Objet : Re: ServerResource conditional mode
  
  
  Pretty good... except what if the user throws a
ResourceException with a specific status code? I suggest something like
this instead:
  
  catch(InvocationTargetException e) {
    Throwable te = e.getTargetException();
    if (te instanceof ResourceException) {
       throw (ResourceException) te;
    } else {
       throw new ResourceException(te);
    }
}
  
  
Jerome Louvel wrote:
  

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to
rethrow checked exceptions of annotated method as ResourceExceptions.
This result in a 500 (Internal server error) status being set by the
ServerResource#handle() method.


 


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


 


 De : Tal
Liron [mailto:tal.li...@threecrickets.com]

Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode


Jerome,
regarding exceptions caught --


You've
implemented this only for when users override methods in non-annotated
mode. In annotated mode, exceptions are still not allowed. This leads
to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions
across the board would result in better user code.


If
you decide that you do want to handle exceptions for annotated
handlers, see doHandle(AnnotationInfo): you would need to get the
reflected exception via InvocationTargetException.getTargetException().


Whatever
you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.



-Tal


Jerome Louvel wrote:


  
  2) Exceptions caught
   
  Currently (SVN trunk at least), the
ResourceExceptions are caught and the response status is updated
accordingly. This is done in the ServerResource#handle() method. Other
exceptions will be caught upper in the processing chain, by the
StatusService for example. 
   
  We do have some plans to extend the
ConverterService in order to automatically convert common exceptions
into matching statuses, but I'm not clear yet whether this is such a
good idea (JAX-RS has this).

  

Re: ServerResource conditional mode

[David Bordoley]

Have you considered that having a generic server resource might be a
bit to simplistic or not granular enough? I guess from my point of
view the resource class is really the implementation of the gritty
protocol details of your application. I'm wondering if at least in
addition to ServerResource, if resources such as
AtomPubCollectionResource and AtomPubEntryResource would be useful to
implementors who want to use standard RESTful protocols without
needing to dig into the details.

thanks,

Dave

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

Re: ServerResource conditional mode

[David Fogel]

That's a funny coincidence- I was just looking at Restlet's Atom
extension and wondering why there weren't any Resource implementations
there.  Unless I'm missing something, it looks like the ext.atom
package is a set of java objects modeling the data in APP xml, that
know how to serialize/deserialize themselves to/from xml...

-Dave

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

Re: Google AppEngine and Restlet

[Jonathan Hall]

This came up today on the GAE list, you may want to chime in when the 
adapation is done so people get the latest information:

http://groups.google.com/group/google-appengine-java/browse_thread/thread/f601350cd8f4d385/c8dc407d77e5562d?lnk=gst&q=rest#c8dc407d77e5562d

...

You can also run Restlets on GAE with a little workaround:

Replace initialization of ServletLogger instance with java.util.Logger

in these 2 source files:
   - com.noelios.restlet.ext.servlet.ServletContextAdapter
   - com.noelios.restlet.ext.servlet.ServletConverter

Now add the Restlet servlet to your deployment descriptor and you
should be good to go.
 
  
RestletServlet
com.noelios.restlet.ext.servlet.ServerServlet
  

  
RestletServlet
/store/feeds/*
  :

-Anirudh



Jerome Louvel wrote:
> Hi all,
>
> When using third-party libraries with GAE SDK, you have to be careful
> because those libraries are not verified against the available Java classes
> (white list). Therefore, it will work locally but break at deployment time!
>
> Hint: an adaptation of Restlet for GAE is underway. Stay tuned ;)
>  
> 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 : Lars Heuer [mailto:he...@semagia.com] 
> Envoyé : vendredi 10 avril 2009 12:32
> À : discuss@restlet.tigris.org
> Objet : Re: Google AppEngine and Restlet
>
> [...]
>   
>> Just out of curiosity: Has someone tried Google AppEngine [1] together 
>> with Restlet (Servlet connector)?
>> 
>
> I ran a few toy applications against the Google AppEngine SDK and discovered
> no problems so far.
>
> Best regards,
> Lars
> --
> http://www.semagia.com
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=16283
> 83
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1630425
>
>

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

YAJSW as a replacement for Tanuki's Java Service Wrapper

[Tal Liron]

If,
like me, you have been disappointed by Tanuki's moving from LGPL to
GPL, coupled with their charging very, very high prices for commercial
licenses, then I strongly recommend you look at YAJSW:


http://yajsw.sourceforge.net/


The
product is still in alpha, but it's very promising, and I'm currently
using it successfully with my Restlet applications. I'm particularly
fond of its built-in support for JMX, which lets me start and stop my
Restlet applications using jconsole. Outside of its uses for Restlet,
it offers comfortable support for running all kinds of Java, Groovy and
arbitrary command tasks with cron-like abilities. It also support's Mac
OS X's launchd.



I'm
particularly fond of how the controller is implemented -- with JNA,
rather than separate binaries per platform, as in Tanuki's wrapper.
This allows the controller to be written in pure Java, which guarantees
consistency across platforms, and generally makes it easier to maintain
and manage. (Personally, I wish JNA were included in the Java platform
as part of JNI -- it offers something similar to ctypes in Python,
making it almost trivial to call native C libraries from Java.)


I'd
be happy to hear about your experiences with YAJSW. And please send the
developer comments and suggestions! They seem eager to listen. This can
be become a very important companion project to Restlet!



-Tal