RE: Architecture question
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: Restlet trunk andd GWT issues...
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(response.getEntity().getText());
}
});
gets me past compilation issues but results in an NPE:
[ERROR] Uncaught exception escaped
java.lang.NullPointerException: null
at
org.restlet.engine.http.HttpClientConverter$1.handle(HttpClientConverter.java:384)
at
org.restlet.engine.http.GwtHttpClientCall$2.onResponseReceived(GwtHttpClientCall.java:236)
at
com.google.gwt.http.client.Request.fireOnResponseReceivedImpl(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?
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
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
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
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
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
Hi Bruce, Thats rather unexpected indeed. Ive 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, Ive 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?
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?
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:
