Re: GET and POST - Semantics vs. Function

2009-09-14 Thread Schley Andrew Kutz
Dave,

Thank you for your input; it is much appreciated. I'm just bothered by  
the fact that GET and POST have a data delivery mechanism tied to them  
in addition to their semantic purpose of immutable and modifiable  
actions. It would seem to me that the method by which you send data to  
the server should not dictate what the server does to that data.

-- 
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.  --Einstein

On Sep 14, 2009, at 3:22 AM, David Bordoley wrote:

 Hi Andrew,

 It might be more useful if you could supply a more detailed example
 that is causing you headaches. Really the difference between POST and
 GET is idempotence. GET operations must be idempotent, not having side
 effects, while POST operations may have side effects as defined by the
 server.  A good rule of thumb is that if a request returns data but
 doesn't change the state of the server, than GET should be used as it
 allows for sane client/intermediary caching.

 On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz  
 sak...@gmail.com wrote:
 I'm faced with a dilemma. I'm trying to be a good RFC consumer and
 stick with the true purpose of GET and POST (see 
 http://www.cs.tut.fi/~jkorpela/forms/methods.html
  for a good discussion on the history of these two HTTP verbs).
 Plainly put, GET is for retrieving data and POST is for creating  
 data.
 However, the problem lies in the fact that their purpose and their
 data encoding mechanism are mutually exclusive. GET requests encode
 data in the URL and POST requests encode data into the form. However,
 it is not always desirable to issue a GET request with URL-encoded
 data (login information for example), not is it always desirable to
 POST data with a form (sometimes a query string will do).

 I actually disagree with this statement. Using GET to pass login
 parameters is fine, and in some cases preferable (particularly as it
 relates to client caching). If you're concerned about security, you
 should encrypt such requests using SSL (you really should do this
 regardless of the method used in this case).

 Also the URI RFC doesn't require that URI parameters be form encoded.
 You could as easily pass JSON, XML, etc. in the query string as long
 as it is properly escaped. Form encoding for these parameters is
 typically chosen as a pragmatic decision due to HTML.

 Dave

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

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


Re: GET and POST - Semantics vs. Function

2009-09-14 Thread Schley Andrew Kutz
I see where you are coming from. Thank you for your advice.

--  
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.  --Einstein

On Sep 14, 2009, at 9:41 AM, Stephen Groucutt wrote:

 I'm not sure I get where you're coming from exactly.  It matters  
 very much how data is sent to the server, as part of the uniform  
 interface is the expected server behavior for each HTTP verb.

 If I issue:

   GET /my/resource/12345
   Accept: text/html
   ...

 Then I expect to receive resource 12345 in HTML format (or some HTTP  
 error code that explains why I cannot).

 If I issue:

   POST /my/resource
   

 with some entity body of a type described by the Content-Type  
 header, I expect a Created response with a Location field pointing  
 to the new resource (or some HTTP error code that explains why the  
 resource could not be created).  I would not expect a GET issued  
 with an entity body to do anything useful with that entity body, nor  
 would I expect a POST issued with no body to create anything useful,  
 unless the resource was of a certain type that required no input  
 data to be created.  These assumptions allow me, as a consumer of  
 that RESTful resource, to interact with that resource without having  
 to do anything special.

 You can, of course, define a resource that ignores these conventions  
 and does its own thing.  You'll just lose the benefit of offering a  
 uniform interface to consumers of that resource - and when you start  
 needing clients to do custom, non-standard things, you're one step  
 closer to the old WSDL/SOAP thing.

 On Mon, Sep 14, 2009 at 9:44 AM, Schley Andrew Kutz  
 sak...@gmail.com wrote:
 Dave,

 Thank you for your input; it is much appreciated. I'm just bothered by
 the fact that GET and POST have a data delivery mechanism tied to them
 in addition to their semantic purpose of immutable and modifiable
 actions. It would seem to me that the method by which you send data to
 the server should not dictate what the server does to that data.

 --
 -a

 Only two things are infinite, the universe and human stupidity, and
 I'm not sure about the former.  --Einstein

 On Sep 14, 2009, at 3:22 AM, David Bordoley wrote:

  Hi Andrew,
 
  It might be more useful if you could supply a more detailed example
  that is causing you headaches. Really the difference between POST  
 and
  GET is idempotence. GET operations must be idempotent, not having  
 side
  effects, while POST operations may have side effects as defined by  
 the
  server.  A good rule of thumb is that if a request returns data but
  doesn't change the state of the server, than GET should be used as  
 it
  allows for sane client/intermediary caching.
 
  On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz
  sak...@gmail.com wrote:
  I'm faced with a dilemma. I'm trying to be a good RFC consumer and
  stick with the true purpose of GET and POST (see 
  http://www.cs.tut.fi/~jkorpela/forms/methods.html
   for a good discussion on the history of these two HTTP verbs).
  Plainly put, GET is for retrieving data and POST is for creating
  data.
  However, the problem lies in the fact that their purpose and their
  data encoding mechanism are mutually exclusive. GET requests encode
  data in the URL and POST requests encode data into the form.  
 However,
  it is not always desirable to issue a GET request with URL-encoded
  data (login information for example), not is it always desirable to
  POST data with a form (sometimes a query string will do).
 
  I actually disagree with this statement. Using GET to pass login
  parameters is fine, and in some cases preferable (particularly as it
  relates to client caching). If you're concerned about security, you
  should encrypt such requests using SSL (you really should do this
  regardless of the method used in this case).
 
  Also the URI RFC doesn't require that URI parameters be form  
 encoded.
  You could as easily pass JSON, XML, etc. in the query string as long
  as it is properly escaped. Form encoding for these parameters is
  typically chosen as a pragmatic decision due to HTML.
 
  Dave
 
  --
  http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2394479

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


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


Re: GET and POST - Semantics vs. Function

2009-09-14 Thread Schley Andrew Kutz
I concur.

--  
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.  --Einstein

On Sep 14, 2009, at 11:41 AM, Rob Heittman wrote:

 Quick pragmatic security note on this:

 I actually disagree with this statement. Using GET to pass login
 parameters is fine, and in some cases preferable (particularly as it
 relates to client caching). If you're concerned about security, you
 should encrypt such requests using SSL (you really should do this
 regardless of the method used in this case).

 Most web servers include the full URL of each request in their  
 server logs.  These logs are not always automatically treated with  
 the privacy accorded to the password database.  This is one reason  
 that many prefer to send such data via POST, since entity bodies are  
 not typically recorded except in debugging situations.

 - Rob


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


REST and Authentication

2009-09-14 Thread Schley Andrew Kutz
Not to start a fire, but I was curious what people thought about my  
approach to authentication with my RESTful application. I am currently  
using a Restlet authenticator (was using a Servlet filter) to  
authenticate incoming requests. Once authenticated the request and  
response have a cookie added to their cookie collection. This cookie  
is also stored in an authentication tokens table the REST application  
has access to. The benefit of this is that it allows for a login  
once architecture without having to deal with the hazards of BASIC  
auth (never expiring for example). However, I am pretty sure I am  
violating the spirit of REST by maintaining a form of state.

What do you think?

-- 
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.  --Einstein

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


GET and POST - Semantics vs. Function

2009-09-13 Thread Schley Andrew Kutz
I'm faced with a dilemma. I'm trying to be a good RFC consumer and  
stick with the true purpose of GET and POST (see 
http://www.cs.tut.fi/~jkorpela/forms/methods.html 
  for a good discussion on the history of these two HTTP verbs).  
Plainly put, GET is for retrieving data and POST is for creating data.  
However, the problem lies in the fact that their purpose and their  
data encoding mechanism are mutually exclusive. GET requests encode  
data in the URL and POST requests encode data into the form. However,  
it is not always desirable to issue a GET request with URL-encoded  
data (login information for example), not is it always desirable to  
POST data with a form (sometimes a query string will do).

I'm curious what others think of the differences between GET and POST  
and whether it is still desirable to think of them as separate verbs  
or rather just two means to accomplish the same thing with different  
encoding techniques.

Thanks!

-- 
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.  --Einstein

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


Questions about Security Model

2009-09-11 Thread Schley Andrew Kutz
I was hoping someone could provide me a little more insight into the
workings of the Restlet security model. I'm currently using M4 and
have created my own Authenticator filter that uses JAAS to do
authentication. I notice that there is also a class called Verifier
(which JaasVerifier appears to be a sub-class of), as well as
Enrollers, Subjects, Principals, etc. However, the flow chart at 
http://www.restlet.org/documentation/2.0/tutorial
  (see attached image) explains how Filters are used (and I deduced
how to use them from the guard example -- very nice routing mechanism
-- similar to how IIS handles requests -- I like how it isolates  
logical steps -- authenticate, authorize, process, post, etc.), but it
makes no mention of Verifiers or the other classes in the security
namespace. I would love it if I could get a crash course in how to
properly handle security within the Restlet API. Thanks!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2393515inline: restlets.pngI was hoping someone could provide me a little more insight into the
workings of the Restlet security model. I'm currently using M4 and
have created my own Authenticator filter that uses JAAS to do
authentication. I notice that there is also a class called Verifier
(which JaasVerifier appears to be a sub-class of), as well as
Enrollers, Subjects, Principals, etc. However, the flow chart at 
http://www.restlet.org/documentation/2.0/tutorial
  (see attached image) explains how Filters are used (and I deduced
how to use them from the guard example -- very nice routing mechanism
-- similar to how IIS handles requests -- I like how it isolates  
logical steps -- authenticate, authorize, process, post, etc.), but it
makes no mention of Verifiers or the other classes in the security
namespace. I would love it if I could get a crash course in how to
properly handle security within the Restlet API. Thanks!

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

Re: Help! -- Error handler isn't working

2009-07-25 Thread Schley Andrew Kutz
I changed the package name last night :(

http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/hyper9/vangaea/server/rest/BaseResource.java?view=markup

Here is the updated link. Thanks!

--  
-a

Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former. -- Einstein

On Jul 25, 2009, at 6:01 AM, Jerome Louvel wrote:

 Hi Schley,

 I could open your link (404). By default, the exception doesn't  
 appear in the browser to not expose too much internal details. You  
 can customize the StatusService if needed.

 I agree it would be nice to have such an option available so I've  
 updated this RFE:

 Return clear status description when exception caught
 http://restlet.tigris.org/issues/show_bug.cgi?id=852

 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
 Envoyé : jeudi 23 juillet 2009 01:07
 À : discuss@restlet.tigris.org
 Objet : Re: Help! -- Error handler isn't working

 Jerome,

 Sorry about that (updated). Here is the ViewVC link to the file  - 
 http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/h9labs/vangaea/server/rest/BaseResource.java?view=markup
 .

 I've updated the code to take advantage of M4's doCatch handler.
 However, when I throw a ResourceException in the doInit() method, or
 any method, the ResourceException is not being displayed in the
 browser, and I was under the impression that it should.

 Thanks!

 -- 
 -a

 Only two things are infinite, the universe and human stupidity, and
 I'm not sure about the former. -- Einstein

 On Jul 21, 2009, at 2:53 AM, Jerome Louvel wrote:

 Hi Schley,

 Could you send us your project (or a snippet reproducing the issue)
 and
 Restlet environment details (version, OS, etc.)? It should
 definitely work.

 BTW, I suggest that you use more meaningful email title when you  
 post,
 easier for tracking and searching in the archives.

 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
 Envoyé : mardi 14 juillet 2009 21:52
 À : discuss@restlet.tigris.org
 Objet : Help!

 The StringRepresentation returned by 'public Representation handle()'
 is no longer appearing in the browser when I access my server.

 Here is an example:

 @Override
public Representation handle()
{
if (true) return new StringRepresentation(Hello, world.);
...

 That should ALWAYS trump any other logic and show Hell, world. in the
 browser. Was a bug introduced to the Maven snapshot? Or do you  
 think I
 could have farked myself somehow.

 -- 
 -a

 Ideally, a code library must be immediately usable by naive
 developers, easily customized by more sophisticated developers, and
 readily extensible by experts. -- L. Stein

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

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

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

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

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


Re: bug?

2009-07-15 Thread Schley Andrew Kutz
Gotcha. Thanks.

--  
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

On Jul 15, 2009, at 12:43 PM, Jerome Louvel wrote:

 Hi Schley,

 For Maven refresh policy, please check:
 http://www.restlet.org/downloads/maven

 For Restlet 2.0 M4, I'd like to push it out by the end of the month.

 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
 Envoyé : vendredi 10 juillet 2009 20:41
 À : discuss@restlet.tigris.org
 Objet : Re: bug?

 Jerome,

 Do you know when this will make it into the Maven snapshot? Thanks!

 --  
 -a

 Ideally, a code library must be immediately usable by naive
 developers, easily customized by more sophisticated developers, and
 readily extensible by experts. -- L. Stein

 On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote:

 Actually, I've just renamed the method to doCatch as the error
 term was ambiguous regarding Java terminology (ie. errors vs
 exceptions). Same logic.

 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
 Envoyé : dimanche 5 juillet 2009 15:45
 À : discuss@restlet.tigris.org
 Objet : Re: bug?

 Great! I'm really looking forward to this and the OnError bit making
 it into a release. :)

 -- 
 -a

 Ideally, a code library must be immediately usable by naive
 developers, easily customized by more sophisticated developers, and
 readily extensible by experts. -- L. Stein

 On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote:

 Hi Schley,

 FYI, this has been fixed in SVN trunk.

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


 Schley Andrew Kutz a écrit :
 I want to prevent the use of HTTP VERB annotations in order to  
 force
 sub-classes to respond with specific class types via abstract
 methods
 that I prototype in a base class. I marked the isAnnotated() method
 as
 @Override and final and returned false. However, when it returns
 false
 I get the following error:

 java.lang.NullPointerException
at
 org
 .restlet
 .engine 
 .resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:
 106)
at
 org
 .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
 649)
at
 org.restlet.resource.ServerResource.doHandle(ServerResource.java:
 329)
at
 org
 .restlet
 .resource.ServerResource.doNegotiatedHandle(ServerResource.java: 
 592)
at
 org
 .restlet
 .resource.ServerResource.doConditionalHandle(ServerResource.java:
 260)
at org.restlet.resource.ServerResource.handle(ServerResource.java:
 921)
at
 com
 .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
 159)
at org.restlet.resource.Finder.handle(Finder.java:510)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at
 org
 .restlet 
 .engine.application.StatusFilter.doHandle(StatusFilter.java:
 153)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
at
 org
 .restlet
 .engine 
 .application.ApplicationHelper.handle(ApplicationHelper.java:
 71)
at org.restlet.Application.handle(Application.java:396)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
at org.restlet.Component.handle(Component.java:397)
at org.restlet.Server.handle(Server.java:350)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
at
 org
 .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:
 149)
at
 org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java

Help!

2009-07-14 Thread Schley Andrew Kutz
The StringRepresentation returned by 'public Representation handle()'  
is no longer appearing in the browser when I access my server.

Here is an example:

@Override
 public Representation handle()
 {
 if (true) return new StringRepresentation(Hello, world.);
 ...

That should ALWAYS trump any other logic and show Hell, world. in the  
browser. Was a bug introduced to the Maven snapshot? Or do you think I  
could have farked myself somehow.

-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

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


Re: bug?

2009-07-10 Thread Schley Andrew Kutz
Jerome,

Do you know when this will make it into the Maven snapshot? Thanks!

--  
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote:

 Actually, I've just renamed the method to doCatch as the error  
 term was ambiguous regarding Java terminology (ie. errors vs  
 exceptions). Same logic.

 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
 Envoyé : dimanche 5 juillet 2009 15:45
 À : discuss@restlet.tigris.org
 Objet : Re: bug?

 Great! I'm really looking forward to this and the OnError bit making
 it into a release. :)

 -- 
 -a

 Ideally, a code library must be immediately usable by naive
 developers, easily customized by more sophisticated developers, and
 readily extensible by experts. -- L. Stein

 On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote:

 Hi Schley,

 FYI, this has been fixed in SVN trunk.

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


 Schley Andrew Kutz a écrit :
 I want to prevent the use of HTTP VERB annotations in order to force
 sub-classes to respond with specific class types via abstract  
 methods
 that I prototype in a base class. I marked the isAnnotated() method
 as
 @Override and final and returned false. However, when it returns
 false
 I get the following error:

 java.lang.NullPointerException
 at
 org
 .restlet
 .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:
 106)
 at
 org
 .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
 649)
 at  
 org.restlet.resource.ServerResource.doHandle(ServerResource.java:
 329)
 at
 org
 .restlet
 .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
 at
 org
 .restlet
 .resource.ServerResource.doConditionalHandle(ServerResource.java: 
 260)
 at org.restlet.resource.ServerResource.handle(ServerResource.java:
 921)
 at
 com 
 .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
 159)
 at org.restlet.resource.Finder.handle(Finder.java:510)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Router.handle(Router.java:490)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at
 org
 .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:
 153)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
 at
 org
 .restlet
 .engine.application.ApplicationHelper.handle(ApplicationHelper.java:
 71)
 at org.restlet.Application.handle(Application.java:396)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Router.handle(Router.java:490)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.routing.Router.handle(Router.java:490)
 at org.restlet.routing.Filter.doHandle(Filter.java:156)
 at org.restlet.routing.Filter.handle(Filter.java:201)
 at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
 at org.restlet.Component.handle(Component.java:397)
 at org.restlet.Server.handle(Server.java:350)
 at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
 at
 org
 .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:
 149)
 at  
 org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:
 932)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
 487)
 at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
 362)
 at
 org
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
 at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
 181)
 at
 org
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
 at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
 729)
 at  
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
 405

Re: bug?

2009-07-05 Thread Schley Andrew Kutz
Great! I'm really looking forward to this and the OnError bit making  
it into a release. :)

-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote:

 Hi Schley,

 FYI, this has been fixed in SVN trunk.

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


 Schley Andrew Kutz a écrit :
 I want to prevent the use of HTTP VERB annotations in order to force
 sub-classes to respond with specific class types via abstract methods
 that I prototype in a base class. I marked the isAnnotated() method  
 as
 @Override and final and returned false. However, when it returns  
 false
 I get the following error:

 java.lang.NullPointerException
  at
 org
 .restlet
 .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: 
 106)
  at
 org 
 .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
 649)
  at org.restlet.resource.ServerResource.doHandle(ServerResource.java:
 329)
  at
 org
 .restlet
 .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
  at
 org
 .restlet
 .resource.ServerResource.doConditionalHandle(ServerResource.java:260)
  at org.restlet.resource.ServerResource.handle(ServerResource.java: 
 921)
  at
 com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
 159)
  at org.restlet.resource.Finder.handle(Finder.java:510)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at
 org 
 .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:
 153)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
  at
 org
 .restlet
 .engine.application.ApplicationHelper.handle(ApplicationHelper.java: 
 71)
  at org.restlet.Application.handle(Application.java:396)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
  at org.restlet.Component.handle(Component.java:397)
  at org.restlet.Server.handle(Server.java:350)
  at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
  at
 org 
 .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:
 149)
  at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:
 932)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  at  
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
 487)
  at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 
 362)
  at
 org 
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
  at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 
 181)
  at
 org 
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
  at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 
 729)
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
 405)
  at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
 152)
  at
 org
 .mortbay 
 .jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:
 49)
  at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
 152)
  at org.mortbay.jetty.Server.handle(Server.java:324)
  at  
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
 505)
  at org.mortbay.jetty.HttpConnection
 $RequestHandler.headerComplete(HttpConnection.java:829)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
  at
 org
 .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java

bug?

2009-06-25 Thread Schley Andrew Kutz
I want to prevent the use of HTTP VERB annotations in order to force  
sub-classes to respond with specific class types via abstract methods  
that I prototype in a base class. I marked the isAnnotated() method as  
@Override and final and returned false. However, when it returns false  
I get the following error:

java.lang.NullPointerException
at  
org 
.restlet 
.engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106)
at  
org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 
649)
at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 
329)
at  
org 
.restlet 
.resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
at  
org 
.restlet 
.resource.ServerResource.doConditionalHandle(ServerResource.java:260)
at org.restlet.resource.ServerResource.handle(ServerResource.java:921)
at  
com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 
159)
at org.restlet.resource.Finder.handle(Finder.java:510)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at  
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 
153)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
at  
org 
.restlet 
.engine.application.ApplicationHelper.handle(ApplicationHelper.java:71)
at org.restlet.Application.handle(Application.java:396)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.routing.Router.handle(Router.java:490)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:201)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
at org.restlet.Component.handle(Component.java:397)
at org.restlet.Server.handle(Server.java:350)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
at  
org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 
149)
at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 
932)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 
487)
at  
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at  
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
216)
at  
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at  
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
216)
at  
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 
405)
at  
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at  
org 
.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 
49)
at  
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 
505)
at org.mortbay.jetty.HttpConnection 
$RequestHandler.headerComplete(HttpConnection.java:829)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at  
org 
.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 
395)
at org.mortbay.thread.QueuedThreadPool 
$PoolThread.run(QueuedThreadPool.java:488)
-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

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


Architecture question

2009-06-24 Thread Schley Andrew Kutz
I have moved my application from sub-classing Restlets to sub-classing  
Resources and am now relying on annotations to process incoming  
requests (@Get for ex.). However, one of the nice side-effects of  
processing requests with the catch-all handle method is that it allows  
me to have one place to catch exceptions. My question is this: Is  
there a way to catch all exceptions with one method (an onError event  
handler for ex.) so that I can decide what to do with them there?  
Thanks!

-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

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


Re: How do I get the contents of POST variables?

2009-06-19 Thread Schley Andrew Kutz
I thought that the entity is what I should be looking at, thanks!

I know that they are different, but some frameworks already provide a  
single call to fetch the data, and I have found it useful in the past.

-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

On Jun 19, 2009, at 5:08 AM, Thierry Boileau wrote:

 Hello,

 if entity is the Representation sent via the POST request, you can
 parse it with a Form as follow:
 Form form = new Form(entity);

 If you want to get the cookies values, just call request#getCookies.

 For sure, there is a real distinction between the query part of an URI
 and the content of POSTed entity.
 The query is part of the identifier of the resource. An entity sent  
 via
 a POST is a set of data that the resource is asked to take into  
 account
 in order to act on its current state.
 It seems preferable keep this distinction.

 best regards,
 Thierry Boileau
 I can get GET variables via the getQueryAsForm method for a resource
 reference, but how do I get POST variables? Also, it would be nice to
 have a getVariable() method that returned a series comprised of GET,
 POST, and COOKIE keys and values.

 Thanks!



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

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