RE: Architecture question

2009-07-05 Thread Jerome Louvel
Hi Schley,

Good feed-back, I've just added an onError(Throwable) method on
UniformResource. It is invoked on error or exception in resource
initialization, handling or releasing.

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é : mercredi 24 juin 2009 23:00
À : discuss@restlet.tigris.org
Objet : Architecture question

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=23650
92

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


RE: Re: Mysterious message in client

2009-07-05 Thread Jerome Louvel
Hi there,

On the server-side, you need to use representations that can compute their
size in advance such as StringRepresentation and AppendableRepresentation.

Again, those messages are just informational and should be filtered out
using a proper logging.properties configuration file. 

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 : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : jeudi 25 juin 2009 21:16
À : discuss@restlet.tigris.org; Rhett Sutphin
Objet : RE: Re: Mysterious message in client

Hi,
   I do not want to change the setting in the log file. 

   How can I make sure to pass Content-Length header in the response so that
it'll not display the INFO messages?
 
   My current client code is as shown below:
[code]
Client client = new Client(Protocol.HTTP);  
Reference uri = new Reference(http://mywebsite.com/accounts/12;); 

Response response = client.get(uri);

if (response.isEntityAvailable()) {

if (null != response.getStatus()) {
if (response.getStatus().isSuccess()) {
System.out.println(Success);
} else {
System.out.println(Fail);
}
}
}

[/code]
   I'll appreciate if you can provide some sample code.

Thanks!

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

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


RE: Restlet trunk andd GWT issues...

2009-07-05 Thread Jerome Louvel
Hi Brian,

Thanks. I've just fixed both issues in SVN trunk.

Actually, we are in the middle of some deep build changes that will fully 
automate the port from the main Restlet source to various editions we now 
support (GWT, Android, GAE, etc.). I hope that the GWT API will stabilize 
around what is in SVN trunk. We hope to have this done by Restlet 2.0 M4.

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 : Brian Anderson [mailto:b...@nwlink.com] 
Envoyé : lundi 29 juin 2009 21:24
À : discuss@restlet.tigris.org
Objet : RE: Restlet trunk andd GWT issues...

FWIW, the following change in HttpClientConverter.java seems to fix the NPE:

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

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

});
}
}


 Hello,
 
 I am working with the GWT edition and trunk r5150 in order to get the recent 
 changes that fix content negotiation issues present in 2.0m3.
 
 I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I 
 notice that I cannot get my GWT app to run in hosted mode without changing 
 the source element in GWT.gwt.xml. The trunk version specifies:
 
   source path=./
 
 which causes a Non-canonical source path: ./ in the hosted mode browser 
 followed by numerous other derived errors. Changing the offending source 
 statement to:
 
   source path=/
 
 apparently solves the issue.
 
 I have not been able to find RestletGWTSimpleExample in the svn sources or on 
 the site other than through the link provided. Obviously there have been 
 changes made in the callback mechanism between 2.0m3 and the trunk version. 
 Attempting the following:
 
 // Add an AJAX call to the server
 final Client client = new Client(Protocol.HTTP);
 client.get(PING_URL, new Uniform() {
 public void handle(Request request, Response response, Uniform 
 callback) {
   pingText.setText(res​ponse.getEntity().ge​tText());
 }
   });
 
 gets me past compilation issues but results in an NPE:
 
 [ERROR] Uncaught exception escaped
 java.lang.NullPointerException: null
 at 
 org.restlet.engine.h​ttp.HttpClientConver​ter$1.handle(HttpCl​ientConverter.java:3​84)
 at 
 org.restlet.engine.h​ttp.GwtHttpClientCal​l$2.onResponseRecei​ved(GwtHttpClientCal​l.java:236)
 at 
 com.google.gwt.http.​client.Request.fireO​nResponseReceivedImp​l(Request.java:264)
 
 So, I am wondering if I have the callback pattern properly coded, or maybe 
 this isn't yet ready for prime time?
 
 Also, it would be helpful if the RestletGWTSimpleExample source was in the 
 svn trunk and updated along with the core.
 
 Thanks for any help you can provide.
 
 ba

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

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


RE: Timeline for Restlet M4?

2009-07-05 Thread Jerome Louvel
Hi Lars,

I would recommand starting with a recent 2.0 snapshot instead of 2.0 M3 if you 
plan to use the new resource API (ServerResource and ClientResource).

We hope to have 2.0 M4 out of the door pretty soon now. We are mainly 
finalizing the edition port automation and will try to squash as many bugs as 
possible (help welcome!). It's a matter of a week or two.

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é : mercredi 1 juillet 2009 17:05
À : discuss@restlet.tigris.org
Objet : Timeline for Restlet M4?

Hi Jérôme  co.,

Do you have an idea when the remaining bugs [1] are resolved? In a
project I tried to support Restlet 1.x and 2.x but recently I switched
over to Restlet 2.0M3 due to API incompatibilities.

Now I've got the request if it wouldn't be better to switch back to
Restlet 1.x. :)

I could use the 2.0 SVN snapshots, but an official release would
provide a better impression.

It would be great if you can provide a rough time line so I can
estimate if I should switch back to 1.x or support both Restlet
versions or wait for the next milestone.

[1]
http://restlet.tigris.org/issues/buglist.cgi?Submit+query=Submit+queryissue_status=NEWissue_status=STARTEDissue_status=REOPENEDtarget_milestone=2.0+M4

Thanks in advance,
Lars
-- 
http://www.semagia.com

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

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


RE: Premature EOF / Broken Pipe

2009-07-05 Thread Jerome Louvel
Hi Timothy,

 

Thanks for updating us. Let’s keep an eye on it and if you find a way to 
reproduce it, please let us know!

 

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

 

 

 

De : Timothy Aanerud [mailto:taane...@aticonsulting.com] 
Envoyé : mercredi 1 juillet 2009 20:53
À : discuss@restlet.tigris.org
Objet : Re: Premature EOF / Broken Pipe

 

I tried adding a second resource to my sample application.  But it doesn't fail.

In my actual application I have a scheduled background thread doing a POST 
transaction, immediately followed by a GET transaction. The Premature EOF 
exception has always occurred in the POST transaction.  Since order does not 
matter between these two message exchanges, I switched them around.  After 
doing this and trying several different scheduled time intervals for the 
background thread, I have yet to see it fail using the 
org.restlet.Client.Client using org.restlet.data.Protocol.HTTP or 
Protocol.HTTPS.

I can't say problem solved but this is interesting and confusing at the same 
time.
--
Timothy Aanerud

On Mon, Jun 29, 2009 at 9:18 AM, Timothy Aanerud tannerudATaticonsulting.com 
wrote:

I haven't tried switching HTTP connectors. :-(

But, I did build a sanitized/stripped down example.  Unfortunately, my example 
does not fail like my application does.   One difference between my example is 
I'm only exchange data with one resource, In my actual application I'm sending 
two messages to two resources back-to-back before pausing.
--
Timothy Aanerud
taanerudataticonsulting.com mailto:taane...@aticonsulting.com 





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

Hi Timothy,

 

Were you able to make progress on this front? 

 

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

 

 

De : Timothy Aanerud [mailto:taanerudATaticonsulting.com 
mailto:taane...@aticonsulting.com ] 
Envoyé : vendredi 19 juin 2009 22:05


À : discuss@restlet.tigris.org

Objet : Re: Premature EOF / Broken Pipe

 

No, I haven't tried switching HTTP connectors. I get the same failures for both 
HTTP and HTTPS.
In another experiment, I changed the client message frequency to ~1 second 
intervals and at this rate on both
Windows XP and Fedora10/Linux show now problems with the server running on 
Fedora.

The various frequencies and failure rates: 
1 second == no problems
1.5 seconds == ~25% failure rate
5 seconds == ~25% failure rate
10 seconds == ~3% failure rate
180 seconds == 0.5%, if any failures

I'll switch the HTTP connectors out one at a time and see what happens.
--
Timothy Aanerud

On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel jerome.lou...@noelios.com 
wrote:

Hi Timothy,

This looks like a bug to me. Have you tried with different Restlet HTTP
connectors (such as Jetty on the server-side and Apache HTTP client)?

If you could send us a simple standalone test case, we could easily debug
what's going bad.

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


-Message d'origine-
De: Timothy Aanerud [mailto:taanerudATaticonsulting.com 
mailto:taane...@aticonsulting.com ]

Envoy頺 vendredi 19 juin 2009 18:18


: discuss@restlet.tigris.org
Objet: RE: Premature EOF / Broken Pipe


As a test, I moved the client code to a Windows XP machine. With a five
second update rate it fails regularly too, with the same exceptions and
stack traces.

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

--

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

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

RE: Re: Multiple content types

2009-07-05 Thread Jerome Louvel
Hi Sherif,

Could you send us the trace of your HTTP request/response exchange including 
HTTP headers? I suscept that you Accept header might not be correct.

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 : Sherif Ahmed [mailto:sherifah...@hotmail.com] 
Envoyé : mercredi 1 juillet 2009 20:00
À : discuss@restlet.tigris.org
Objet : RE: Re: Multiple content types

Okay..
I had to add an XLS Representation for a resource and I wan to support a suffix 
of .json for JSON and .XLS for Excel , but using the code below (and rest of 
the code in the previous thread).

no matter what extension I use (even other than XLS OR JSON). the 
Variant.Representation in my represent(Variant variant) method in the resource 
class always picks up JSON as the type..

Thanks

public HelloWorldResource(Context context, Request request, Response response) {

 super(context, request, response);
getVariants().add(new Variant(MediaType.APPLICATION_EXCEL));
getVariants().add(new Variant(MediaType.APPLICATION_JSON));

}


 Hi Sherif,
 
 .js is javascript
 .json is json :0)
 
 There is no need to add js or json to the MetadataService as it comes 
 with a bunch of common ones already.
 Remove that line, and try
 
 http://localhost:8080/firstStepsServlet/Hello.json (Notice the JSON)
 
 
 Jon
 
 Sherif wrote:
 
  Thanks Jonathan..
 
  1. Here’s what I did to support lets say “.js” as an extension to 
  indicate JSON as the content type
 
  *public* *class* FirstStepsApplication *extends* Application {
 
  /**
 
  * Creates a root Restlet that will receive all incoming calls.
 
  */
 
  @Override
 
  *public* Restlet createRoot() {
 
  // Create a router Restlet that routes each call to a
 
  // new instance of HelloWorldResource.
 
  Router router = *new* Router(getContext());
 
  // Defines only one route
 
  router.attachDefault(HelloWorldResource.*class*);
 
  *this*.getTunnelService().setExtensionsTunnel(*true*);
 
  *this*.getTunnelService().setEncodingParameter(output);
 
  *this*.getMetadataService().addExtension(js, *new* 
  Metadata(MediaType./APPLICATION_JSON/.getName(), 
  MediaType./APPLICATION_JSON/.getDescription()), *true* );
 
  *return* router;
 
  }
 
  }
 
  *public* *class* HelloWorldResource *extends* Resource {
 
  *public* HelloWorldResource(Context context, Request request, Response 
  response) {
 
  *super*(context, request, response);
 
  // This representation has only one type of representation.
 
  getVariants().add(*new* Variant(MediaType./TEXT_PLAIN/));
 
  getVariants().add(*new* Variant(MediaType./APPLICATION_JSON/));
 
  }
 
  /**
 
  * Returns a full representation for a given variant.
 
  */
 
  @Override
 
  *public* Representation represent(Variant variant) *throws* 
  ResourceException {
 
  Representation representation = *null*;
 
  *if*(variant.getMediaType() == MediaType./APPLICATION_JSON/){
 
  representation = *new* JsonRepresentation(Hello World);
 
  }*else* *if* ( variant.getMediaType() == MediaType./TEXT_PLAIN/){
 
  representation = *new* StringRepresentation(
 
  hello, world, MediaType./TEXT_PLAIN/);
 
  }
 
  *return* representation;
 
  }
 
  }
 
  However when I call the service using the following URL 
  http://localhost:8080/firstStepsServlet/Hello.js the Variant type in 
  the HelloWorldResource is of MediaType.TEXT_PLAIN
 
  Thanks for Your help
 
  *From:* Jonathan Hall (via Nabble) 
  [mailto:ml-user+125526-1692215...@... 
  http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=3043073i=0]
  *Sent:* Friday, June 05, 2009 1:29 PM
  *To:* Sherif
  *Subject:* Re: Multiple content types
 
  Have a look at
  http://www.restlet.org/documentation/2.0/api/org/restlet/service/TunnelService.html
 
  getTunnelService().setExtensionsTunnel(true);
 
  Jon
 
  Sherif wrote:
   I realize RESTLet supports multiple encodings based on the Accept 
  Encoding
   headers. Does Restlet also have a way to allow encodings based on 
  URI patter
   e.g. http://mystores/items/1000.json or something like that ?
  
 
  --
  http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2359775
   
  http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2359775
 
  
 
  This email is a reply to your post @ 
  http://n2.nabble.com/Multiple-content-types-tp3031817p3031841.html
  You can reply by email or by visting the link above.
 
 
  
  View this message in context: RE: Multiple content types 
  http://n2.nabble.com/Multiple-content-types-tp3031817p3043073.html
  Sent from the Restlet Discuss mailing list archive 
  http://n2.nabble.com/Restlet-Discuss-f1400322.html at Nabble.com.


RE: RangeFilter and redirects

2009-07-05 Thread Jerome Louvel
Hi David,

Thanks for the report. I've fixed the redirection conflict in SVN trunk and
1.1 branch. Let us know if it works better now.

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 : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : mercredi 1 juillet 2009 20:09
À : discuss@restlet.tigris.org
Objet : RangeFilter and redirects

I ran across a problem that was causing the Daemon threads in our
WadlComponent-based server to enter a busy loop.  Essentially, if a Range
header was in the HTTP GET request but the server wanted to return a
redirection (e.g. via response.redirectSeeOther()), the entity would be
wrapped by a RangeRepresentation.  Tunnel in to that, and
RangeInputStream#read would loop here:

// Reach the start index.
while (!(position = startIndex)) {
position += skip(startIndex - position);
}

Aside from the likelihood that there's also a bug in the handling/wrapping
of a response entity that's too small for the range, my first question here
had to do with the status code of the response itself.  Should responses
that are not successful (2xx) be subject to wrapping in a
RangeRepresentation?

Thanks,
David

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

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


RE: Passing a serialized Java object

2009-07-05 Thread Jerome Louvel
Hi Alfredo,

If you have the exact same version of your TimelineDataForUpdate class
available of both client and server sides, it should work. Could you send us
a reproducible sample and the stack trace?

BTW, if you can use the Restlet 2.0 in development, you will see
ClientResource and ServerResource classes that can transparently handle
serialization via annotated methods. Internally, it produces something
similar to what you have though.

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 : AJ [mailto:alfredo.benc...@nasa.gov] 
Envoyé : vendredi 3 juillet 2009 21:39
À : discuss@restlet.tigris.org
Objet : Passing a serialized Java object

Hi,

I trying to pass a java object from client to the serve, as shown below:

# CLIENT
public Response setData(String resourceSegment, String queryString,
Serializable object) throws Exception {
Reference reference = new Reference(Protocol.HTTP, host, port);
reference.addSegment(resourceSegment);
if (queryString != null)
reference.setQuery(Reference.encode(queryString));

Response response = client.post(reference.toString(), new
ObjectRepresentationSerializable(object));
...
..
}


 SERVER 
public void handlePost() {
try {
if
(MediaType.APPLICATION_JAVA_OBJECT.equals(getRequest().getEntity().getMediaT
ype())) {   
ObjectRepresentationTimelineDataForUpdate rep =
new ObjectRepresentationTimelineDataForUpdate(getRequest().getEntity());
TimelineDataForUpdate tml = rep.getObject();
}
} catch (IOException ioe) {
trace.error(ioe);
getResponse().setStatus(Status.SERVER_ERROR_INTERNAL);
} catch (ClassNotFoundException cnfe) {
trace.error(cnfe);
getResponse().setStatus(Status.SERVER_ERROR_INTERNAL);
}
}
###

Unfortunately, I am getting a ClassNotFoundException at server.  Please let
me know if I am doing something wrong.

Thanks in advance!

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

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


RE: Issues loading css files (from a Directory) using Firefox

2009-07-05 Thread Jerome Louvel
Hi Bruce,

 

That’s rather unexpected indeed. I’ve checked the text/css media type and it
does support the charset parameter:

http://tools.ietf.org/html/rfc2318

 

What seems wrong is the name of the character set. Looking at IANA registry,
the proper name is either “macintosh” or “mac”, but not “MACROMAN”:

http://en.wikipedia.org/wiki/Mac_OS_Roman

http://www.iana.org/assignments/character-sets 

 

A test that would be interesting to do is to change the default character
set to something like UTF-8 to see if this is the value of the character set
that annoys FireFox. One way to do this is:

 

myApp.getMetadataService().setDefaultCharacterSet(CharacterSet.UTF_8);

 

BTW, I’ve also added CharacterSet.MACINTOSH constant and default extension
mappings for character sets in MetadataService (“ascii”, “utf8”, “utf16”,
“mac”, “win”).

 

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

 

 

 

De : Bruce Cooper [mailto:br...@brucecooper.net] 
Envoyé : dimanche 28 juin 2009 10:38
À : discuss@restlet.tigris.org
Objet : Issues loading css files (from a Directory) using Firefox

 

Hi guys,

 

I've been using a Directory object to serve up the user interface of my REST
style application, and that application consists of HTML, javascript and
CSS.  I've found today that Firefox 3.5 on my Mac was not reading CSS files
correctly.  To be more specific, it was reading the files, but was not using
the results that were returned.  

 

To work out what was going wrong, I wrote a simple test page, which had a
single DIV with a background color set by a style in an attached style
sheet.  Viewing the page directly from the disk using Safari or Firefox
worked.  Viewing the Page when served by Apache worked for both Safari and
Firefox.  When the files were served up by the restlet engine, it continued
to work correctly in Safari, but Firefox ignored the stylesheet.  After
this, I spent a bit of time in Firebug having a look in headers. The main
difference I could see was that the restlet engine was reporting the
content-type of the repsonse as

 

text/css; charset=MACROMAN

 

Whereas Apache was just returning the content type as text/css.

 

I've dug around the code and found that in org.restlet.engine.local.Entity
line 252 it sets the charset of the response to the platform default if it
hasn't already been set.  To test my theory, I commented out this part of
the code, and Firefox started responding correctly to the CSS file again (as
shown in Picture 10).

 

I don't know if it is Firefox not understanding the charset or whether it
just doesn't like the charset at all, but either way it is a problem.  For
the moment, I'll just be leaving this code commented out, but I would
appreciate some advice on the best way to fix this.

 

Please let me know if you need any more information.

 

Bruce.

--
www.brucecooper.net - 0417 986 274

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

Re: bug?

2009-07-05 Thread Jerome Louvel
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: 
 395)
   at org.mortbay.thread.QueuedThreadPool 
 $PoolThread.run(QueuedThreadPool.java:488)

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


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: