Re: bug? - AccessControlException on Restlet GAE module

restlet.org/> > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > <http://www.noelios.com/> > > > *De :* keke [mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>] > *Envoyé :* samedi 18 avril 2009 16:57 > *À :* discuss@res

Re: bug? - AccessControlException on Restlet GAE module

vril 2009 16:57 > *À :* discuss@restlet.tigris.org > *Objet :* Re: bug? - AccessControlException on Restlet GAE module > > Can I simply return null in ServletCall.getSubject, because in GAE > application usually relies on GAE's authentication. > > Cheers, > Keke >

RE: bug? - AccessControlException on Restlet GAE module

<http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : keke [mailto:iamk...@gmail.com] Envoyé : samedi 18 avril 2009 16:57 À : discuss@restlet.tigris.org Objet : Re: bug? - AccessControlException on R

RE: Bug in HttpAmazonS3Helper class

Hi Jerome, No problems at all. Thanks for fixing it so quickly. Kind regards, Matt Hi Matt, Thanks for reporting this. I've fixed the bug (due to an evolution in S3) in both 1.1 branch and SVN trunk. I've also added proper unit test cases to make sure there is no regression. Be

Re: bug? - AccessControlException on Restlet GAE module

Can I simply return null in ServletCall.getSubject, because in GAE application usually relies on GAE's authentication. Cheers, Keke - We paranoid love life On Sat, Apr 18, 2009 at 10:25 PM, keke wrote: > Hi, > > Does anybody else get AccessControlException when using restlet-ga

bug? - AccessControlException on Restlet GAE module

Hi, Does anybody else get AccessControlException when using restlet-gae? Everything goes well, unless I need to use GAE's authentication feature. After a successful login (on development env), I got following exception: java.security.AccessControlException: access denied (javax.security.auth.Auth

RE: Bug in HttpAmazonS3Helper class

Hi Matt, Thanks for reporting this. I've fixed the bug (due to an evolution in S3) in both 1.1 branch and SVN trunk. I've also added proper unit test cases to make sure there is no regression. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.o

Bug in HttpAmazonS3Helper class

, 27 Mar 2007 19:36:42 +\n /_bucketname_/photos/puppy.jpg Matt. -- View this message in context: http://n2.nabble.com/Bug-in-HttpAmazonS3Helper-class-tp2614094p2614094.html Sent from the Restlet Discuss mailing list archive at Nabble.com. --

RE: ApplicationStatusFilter - bug ???

s.com -Message d'origine- De : Thierry Boileau [mailto:thierry.boil...@noelios.com] Envoyé : jeudi 11 décembre 2008 17:30 À : discuss@restlet.tigris.org Objet : Re: ApplicationStatusFilter - bug ??? Hello Rémi, your suggestion looks really reasonnable. As I'm not fully aware of the

Re: ApplicationStatusFilter - bug ???

nologies ~ Co-founder ~ http://www.noelios.com > Hello, > > I just wonder if it is a bug having in ApplicationStatusFilter : > public ApplicationStatusFilter(Application application) { > super(application.getContext(), application.getStatusService() >

ApplicationStatusFilter - bug ???

Hello, I just wonder if it is a bug having in ApplicationStatusFilter : public ApplicationStatusFilter(Application application) { super(application.getContext(), application.getStatusService() .isOverwrite(), application.getStatusService() .getContactEmail

Re: (Bug?) entity for "" receives null mediaType when deployed on Tomcat

Thanks ... Tomcat trunk didn't seem to have the same issue when I quick compiled it -- I'll start looking at 5.5.27 tag. If you have counter evidence that shows trunk or 6.x with the same issue, let me know. On Mon, Nov 17, 2008 at 8:10 AM, Richard Hoberman < [EMAIL PROTECTED]> wrote: > Hi Rob

Re: (Bug?) entity for "" receives null mediaType when deployed on Tomcat

Hi Rob I tested this against Tomcat-5.5.27. The problem is also affecting code running on 5.5.25. Cheers Richard Rob Heittman wrote: > Thanks, Richard! Can you share a Tomcat version number? This sounds > like the same issue we've been seeing in GWT hosted mode, and I've > been trying to fig

Re: (Bug?) entity for "" receives null mediaType when deployed on Tomcat

Thanks, Richard! Can you share a Tomcat version number? This sounds like the same issue we've been seeing in GWT hosted mode, and I've been trying to figure out where this is triggered in the Tomcat codebase so maybe we can work around it better. GWT's embedded version is special enough and old

RE: (BUG) restlet-ext-jaxrs depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT).

-Message d'origine- De : Hendy Irawan [mailto:[EMAIL PROTECTED] Envoyé : samedi 8 novembre 2008 06:46 À : discuss@restlet.tigris.org Objet : (BUG) restlet-ext-jaxrs depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT). Restlet-ext-JAXRS depends on a snapshot j

(BUG) restlet-ext-jaxrs depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT).

=jsr311-api -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) * 2) org.restlet:org.restlet.ext.jaxrs:jar:1.1.1 3) javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT I've reported this as bug in http://restlet.tigri

Re: Form Processing bug?

Hi Cliff, the cause of your bad experience is described here: http://www.restlet.org/documentation/1.1/api/org/restlet/service/TunnelService.html The TunnelService which is attached to an application is able to preprocess incoming requests, especially it allows to workaround some browser's l

Form Processing bug?

I believe there is something wrong, or at least unpleasant in the Restlet Engine (V1.1 RC2). I am using the "language" as a form input. I have a simple test case (below) which mimics the form input. Input of this: http://localhost:8080/test?lang=all

RE: Possible bug in DateUtils.ImmutableDate

Hi Mike, Thanks for following up on this issue. We'll look at it for 1.1 RC. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Mike Brzozowski Envoye : mardi 17 juin 2008 23:45 A : discuss@restlet.tigris.org Objet : Re: Possi

Re: Possible bug in DateUtils.ImmutableDate

Jerome Louvel noelios.com> writes: > JUnit tests are very easy to write. Look at the simple example attached. Done. Sorry it took so long... http://restlet.tigris.org/issues/show_bug.cgi?id=516 ... I see you committed some changes to DateUtils that may render it obsolete. But you should be able

RE: Possible bug in DateUtils.ImmutableDate

Mike Brzozowski Envoye : mercredi 28 mai 2008 20:41 A : discuss@restlet.tigris.org Objet : Re: Possible bug in DateUtils.ImmutableDate > Regarding the conditional GET support, is there any reason why you don't > rely on the built-in support that we provide for Resource subclasses? I w

Re: Possible bug in DateUtils.ImmutableDate

Hi Mike, Could you write a simple unit test illustrating the issue and attach it to a new bug report? I've never written a unit test, but it's probably high time I learned. Do you use JUnit? Yes, the Restlet project uses JUnit best regards Stephan

Re: Possible bug in DateUtils.ImmutableDate

e > same delegate Date instance... I believe from tracing into the code that java.util.Date.after() doesn't call any methods on the target Date, it just reaches directly into its instance fields. > Could you write a simple unit test illustrating the issue and attach it to a > new bu

RE: Possible bug in DateUtils.ImmutableDate

ng is processed by the same delegate Date instance... Could you write a simple unit test illustrating the issue and attach it to a new bug report? Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Mike Brzozowski Envoye : mardi 27 mai 2008 21:03 A

Possible bug in DateUtils.ImmutableDate

Hi, In trying to implement support for HTTP conditional GET I ran across a bizarre bug which seems to be somehow related to the implementation of ImmutableDate. The scene: lastModified is a java.util.Date (also works if it's a java.sql.Timestamp) corresponding to the last modified date for

Restlet Application throws 405 HTTP error when not accessing root (bug #500) help request

Complete report is available here: http://restlet.tigris.org/issues/show_bug.cgi?id=500 Hopefully someone can tell me what's wrong... Thank you. -- Best regards, Hendy Irawan

Re: Interesting behaviour of restlet maven repo -- probably a bug

Hello Tamás, thanks for reporting this bug. It is now fixed. best regards, Thierry Boileau Hi there, i noticed an interesting behaviour of the restlet powered maven repository on http://maven.restlet.org/ Since it is powered by latest 1.1M3 (according to response headers), it seems it is a

Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

On Tue, Apr 15, 2008 at 11:38 AM, Stephan Koops <[EMAIL PROTECTED]> wrote: > I'm using JDJ 1.5, because 1.6 causes trouble eith JAXB. or do you updated > this, so that both JDKs are possible? Java 1.6>= update 4 has better JAXB support, though the whole idea of bundling something as unstable as JA

RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

gt; Cc : [EMAIL PROTECTED] > Objet : Re: [BUG] OSGi manifest, please don't use > Require-Bundle, re: com.noelios.restle > > I'm using JDJ 1.5, because 1.6 causes trouble eith JAXB. or do you > updated this, so that both JDKs are possible? > > best reg

RE: Interesting behaviour of restlet maven repo -- probably a bug

09:36 > À : discuss@restlet.tigris.org > Objet : Re: Interesting behaviour of restlet maven repo -- > probably a bug > > What do you and the others think? > > best regards > Stephan > > Stephan Koops schrieb: > > Hi Thierry > > > > The behaviour of now

Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

ok at this issue? Hendy maybe? Best regards, Jerome -Message d'origine- De : Thierry Boileau [mailto:[EMAIL PROTECTED] Envoyé : mardi 15 avril 2008 11:53 À : discuss@restlet.tigris.org Objet : Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.re

RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

vril 2008 11:53 > À : discuss@restlet.tigris.org > Objet : Re: [BUG] OSGi manifest, please don't use > Require-Bundle, re: com.noelios.restle > > Hi all, > > I've problems with com.noelios.restlet.ext.httpclient_3.1 (import not > found) and com.noelios.

Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

: Hendy Irawan [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 avril 2008 23:01 À : discuss@restlet.tigris.org Objet : [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet Regarding com.noelios.restlet.ext.servlet JAR in 1.1 M3 Please don't use Requi

Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle

have converted all manifests in SVN trunk. -Message d'origine- De : Hendy Irawan [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 avril 2008 23:01 À : discuss@restlet.tigris.org Objet : [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.serv

Re: Interesting behaviour of restlet maven repo -- probably a bug

What do you and the others think? best regards Stephan Stephan Koops schrieb: Hi Thierry The behaviour of now results in the requirement for JAX-RS. JAX-RS requires to map abc.def.en.ghi.html to abc.def.ghi, Accept: text/html, and Accept-Language: en. At the beginning I also think that th

Re: Interesting behaviour of restlet maven repo -- probably a bug

Hi Thierry The behaviour of now results in the requirement for JAX-RS. JAX-RS requires to map abc.def.en.ghi.html to abc.def.ghi, Accept: text/html, and Accept-Language: en. At the beginning I also think that this idea was good, but now I think it is useful to try to change this behavior in JA

RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet

> À : discuss@restlet.tigris.org > Objet : [BUG] OSGi manifest, please don't use Require-Bundle, > re: com.noelios.restlet.ext.servlet > > Regarding com.noelios.restlet.ext.servlet JAR in 1.1 M3 > > Please don't use Require-Bundle manifest header. Please use > > Impor

Re: Interesting behaviour of restlet maven repo -- probably a bug

Hi all, I think it is due to the fact that the "sha1" extension is not known by the metadataService. best regards, Thierry Boileau This confuses browsers (FFox, Epiphany tested, i believe all Mozilla based ones) and also wget. True, the response header shows the correct served resource (the

Re: Interesting behaviour of restlet maven repo -- probably a bug

Hi Rob and Tamás, >Thierry, any ideas? not yet... I will have a look after my current task. best regards, Thierry Boileau I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thier

Re: Interesting behaviour of restlet maven repo -- probably a bug

This confuses browsers (FFox, Epiphany tested, i believe all Mozilla based ones) and also wget. True, the response header shows the correct served resource (the JAR, not the SHA1), but even then, clients are saving/consuming the response as SHA1 response. ~t~ On Mon, Apr 14, 2008 at 4:07 PM, Ro

Re: Interesting behaviour of restlet maven repo -- probably a bug

I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thierry, any ideas? On Mon, Apr 14, 2008 at 10:01 AM, Tamás Cservenák <[EMAIL PROTECTED]> wrote: > Do in a browser/wget/whatever t

Interesting behaviour of restlet maven repo -- probably a bug

Hi there, i noticed an interesting behaviour of the restlet powered maven repository on http://maven.restlet.org/ Since it is powered by latest 1.1M3 (according to response headers), it seems it is a bug in restlet.org framework. To reproduce: Do in a browser/wget/whatever the following request

[BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet

Regarding com.noelios.restlet.ext.servlet JAR in 1.1 M3 Please don't use Require-Bundle manifest header. Please use Import-Package: javax.servlet,javax.servlet.http or others as needed. Require-Bundle hardcodes the bundle name. In my case, I use pax-web, which provides the package javax.servl

Re: bug in the spring SpringBeanRouter

> I haven't tried using *. SpringBeanRouter is taking the bean name and > passing it directly to attach. I'm not aware of anything Spring does > specially with *, but there could be. Can you provide a reproduceable > test case? I don't have my test-setup anymore, but while debugging I fou

Re: bug in the spring SpringBeanRouter

On Apr 1, 2008, at 3:20 PM, Michael Böckling wrote: After lots of debugging, it seems wildcards don't work in the SpringBeanRouter, since the * is improperly escaped. I haven't tried using *. SpringBeanRouter is taking the bean name and passing it directly to attach. I'm not aware of anyt

bug in the spring SpringBeanRouter

After lots of debugging, it seems wildcards don't work in the SpringBeanRouter, since the * is improperly escaped. The SpringBeanRouter also does not work when placed in the [servlet-name]-servlet.xml, it must be placed in the main applicationContext.xml. Can you confirm this?

RE: There's a bug with follow ups on this site

Hi there, That is weird, GMane works fine for me. Which email client are you using? Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de TA > Envoyé : vendredi 29 février 2008 16:30 > À : discuss@restlet.tigris.org > O

There's a bug with follow ups on this site

I try and do a follow up and keep getting blocked because the site thinks I 'm doing top posting. The way I got around it was to take the follow up and remove all ">" characters from the message chain and that seemed to work.

RE: Possible bug?

Hi Matt, Thanks for the bug report. The fix (similar to your workaround) has been checked in SVN trunk and 1.0 branch. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Matt Allen > Envoyé : mardi 20 novembre 2007 22:13

Re: Possible bug?

Matt Allen mathworks.com> writes: I have temporarily solved this by changing the code in SimpleProtocolHandler to look like this: // Once the request is handled, the request input stream must be // entirely consumed. Not doing so blocks invariably the transaction //

Possible bug?

uld potentially have been related, but they alluded to a fix that was implemented. Is this the same bug? Can I solve it (correctly) by simply removing the call to close in SimpleProtocolHandler? Any feedback would be appreciated. Thank you, Matt

Re: TransformRepresentation URIResolver Out of order bug

Hi all, There is a follow-up RFE entered here: http://restlet.tigris.org/issues/show_bug.cgi?id=377 Best regards, Jerome Jerome Louvel wrote : Hi all, I've fixed the bugs reported by Joe in SVN. He also suggested a couple of enhancements that we'll discuss here or via the bug trac

Re: TransformRepresentation URIResolver Out of order bug

Jerome Louvel wrote : Hi all, I've fixed the bugs reported by Joe in SVN. He also suggested a couple of enhancements that we'll discuss here or via the bug tracker. Best regards, Jerome

RE: TransformRepresentation URIResolver Out of order bug

Hi all, I've fixed the bugs reported by Joe in SVN. He also suggested a couple of enhancements that we'll discuss here or via the bug tracker. Best regards, Jerome > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part > de Jerome

Re: Bug in SpringFinder?

Hello Florian, I think that you need to override the init method in order to intialize properly your resource instance (such as getting from the model all data needed by this resource, check if this resource exists, setting the supported variants, etc). best regards, Thierry Boileau Hi fol

Bug in SpringFinder?

Hi folks, I think SpringFinder.createResource(...) should be changed from: public Resource createResource(Request request, Response response) { Resource result = createResource(); if (result != null) { result.init(getContext(), request, response); } return result; } } to:

Re: TransformRepresentation URIResolver Out of order bug

the build process :) Best regards, Jerome 2007/10/24, Joe Nellis <[EMAIL PROTECTED]>: > Greetings again, > > There is a bug in the TransformRepresentation.getTransformer() method > involving the wrong setURIResolver method being called. The method in > question: >

TransformRepresentation URIResolver Out of order bug

Greetings again, There is a bug in the TransformRepresentation.getTransformer() method involving the wrong setURIResolver method being called. The method in question: public Transformer getTransformer() throws IOException { if (this.transformer == null) { try

RE: Bug: DirectoryResource is broken if used with relative paths

i 24 septembre 2007 01:44 > À : discuss@restlet.tigris.org > Objet : Re: Bug: DirectoryResource is broken if used with > relative paths > > > I'm getting a test failure building trunk 2181, probably this > change is the culprit?!? > > [junit] java.lang.

Re: Bug: DirectoryResource is broken if used with relative paths

From: "Jerome Louvel" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Sunday, September 23, 2007 3:35:55 PM (GMT-0500) America/New_York Subject: RE: Bug: DirectoryResource is broken if used with relative paths Hi all, The Directory constructors now automatically no

RE: Bug: DirectoryResource is broken if used with relative paths

ntRef() methods now return a LocalReference instance. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Joel Nelson > Envoyé : mercredi 19 septembre 2007 17:44 > À : discuss@restlet.tigris.org > Objet : Re: Bug: DirectoryResour

Re: Bug: DirectoryResource is broken if used with relative paths

Marc, I agree there needs to be more research into this around symlinks and the canonicalization of "../" However for this bug I've found, the issue is not how to correctly canonicalize paths. Instead, the issue is that we need to pick one approach within the code I've cited,

Re: Bug: DirectoryResource is broken if used with relative paths

I have done a little more debugging and I think the offender is Reference.normalize(). FileClientHelper calls this to normalize file:///foo/./ to file:///foo. This is fine, but DirectoryResource has fields "targetUri" and "directoryUri" which are NOT normalized. If we can normalize these things, t

Re: Bug: DirectoryResource is broken if used with relative paths

it of a nuisance? regards, -marc= - Original Message - From: "Marc Portier" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Wednesday, September 19, 2007 7:52:26 AM (GMT-0500) America/New_York Subject: Re: Bug: DirectoryResource is broken if used with relative

Re: Bug: DirectoryResource is broken if used with relative paths

Learn something new every day! Makes sense. Just resolve the relativisms then? - Original Message - From: "Marc Portier" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Wednesday, September 19, 2007 7:52:26 AM (GMT-0500) America/New_York Subject: Re: Bug: D

Re: Bug: DirectoryResource is broken if used with relative paths

en symbolic links are in use) regards, -marc= - Original Message - From: "Jerome Louvel" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Tuesday, September 18, 2007 5:13:35 PM (GMT-0500) America/New_York Subject: RE: Bug: DirectoryResource is broken if used wi

Re: Bug: DirectoryResource is broken if used with relative paths

org Sent: Tuesday, September 18, 2007 5:13:35 PM (GMT-0500) America/New_York Subject: RE: Bug: DirectoryResource is broken if used with relative paths Hi all, This bug lied in the File connector in is now fixed in SVN. Thanks for testing it. Best regards, Jerome > -Message d'o

RE: Bug: DirectoryResource is broken if used with relative paths

Hi all, This bug lied in the File connector in is now fixed in SVN. Thanks for testing it. Best regards, Jerome > -Message d'origine- > De : Rob Heittman [mailto:[EMAIL PROTECTED] > Envoyé : mardi 18 septembre 2007 15:48 > À : discuss@restlet.tigris.org

Re: Bug: DirectoryResource is broken if used with relative paths

s, Jerome, Thierry? Also, I think LocalReference.getTargetRef() oughta return a LocalReference (you'd have to cast it, but this should work). - Rob - Original Message - From: "Joel Nelson" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Monday, September 17, 2007

Re: Bug: DirectoryResource is broken if used with relative paths

On Mon, 17 Sep 2007 11:26:08 -0400, Rob Heittman wrote: > 1) > // Create a directory able to expose a hierarchy of files > Directory directory = new Directory(getContext(), > LocalReference.createFileReference(new File("./").getPath())); > This one is equally broken > 2) > // Create a dire

Re: Bug: DirectoryResource is broken if used with relative paths

There is a bug with file: scheme references with no host dropping 2 characters, http://restlet.tigris.org/issues/show_bug.cgi?id=352 but I cant tell if that's manifested here. Can you check to see if either or both of these behaves as expected? 1) // Create a directory able to exp

Bug: DirectoryResource is broken if used with relative paths

I'm still very extremely new to Restlet, but I hope the information I have here will be enough to find this bug: In trying the sample code in the Restlet tutorial, I think I've found a problem with using local paths, e.g. // Create a directory able to expose a hierarchy of files

RE: ServerServlet bug?

Hi Richard, I've just fixed this bug in SVN (1.0 branch): - Reverted changes to the ServerServlet back to the 1.0.2 behavior (application context set after construction via setContext() method). The new behavior requires NRE API changes and will only be available in the Restle

RE: Routing bug?

Hi Alex, [...] > Does the restlet engine attach a log handler? No it doesn't, it just provides some support classes for the applications' access logging service (similar to Apache or IIS logging). There are some more explanations in the tutorial: http://www.restlet.org/documentation/1.0/tuto

Re: ServerServlet bug?

learning a project I'm never sure if something I find is actually a bug or if I'm just doing something wrong and not looking at the backing code properly. In the future I'll post to the tracker. Rich

Re: ServerServlet bug?

Hi Richard, Hmmm, this seems like a regression introduced in 1.0.3. Thierry or myself will definitely have a closer look at this later today and release an update soon to fix this if needeed. I also recommend the usage of the Restlet issue tracker on Tigris.org to report those type of bugs/

ServerServlet bug?

Hello all, I'm trying to use Restlet 1.0.3 in a servlet environment. But I'm getting the following NPE when the application is starting up: 2007-07-18 20:20:04.701::WARN: Nested in javax.servlet.ServletException: java.lang.NullPointerException: java.lang.NullPointerException at com.noel

Re: Routing bug?

On 7/17/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi Alex, Thanks for the progress reports :) I'm glad to see how useful turning the fine logging can be for debugging Restlet routing. There's still some magic there for logging that I don't quite understand. Does the restlet engine attach

RE: Routing bug?

ds, Jerome > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Alex Milowski > Envoyé : mardi 17 juillet 2007 19:56 > À : discuss@restlet.tigris.org > Objet : Re: Routing bug? > > *sigh* > > My bug. I take the remaining part a

Re: Routing bug?

*sigh* My bug. I take the remaining part and create a new Reference() instance along the way. That explains everything. At least I got to dig into the code and understand it a bit better. :) --Alex Milowski

Re: Routing bug?

Turning on fine logging I get the following. It looks the route handling is correct. Is it possible that the Reference class is doing something bad ? Jul 17, 2007 10:49:01 AM com.noelios.restlet.component.HostRoute beforeHandle FINE: New base URI: https://localhost:8080 Jul 17, 2007 10:49:01 AM

Routing bug?

In atomojo, I allow this kind of URI: http://localhost:8080/T/http://www.atomojo.com/O/myterm That allows me to embed a term URI into the URI path. According to the URI RFC, the colon character ':' is allowed in segments: segment = *pchar *( ";" param ) param = *pchar pchar

Re: Entity validation always true. Bug?

sage d'origine- De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] Envoyé : vendredi 13 juillet 2007 20:51 À : discuss@restlet.tigris.org Objet : Re: Entity validation always true. Bug? I submitted an issue regarding this: http://restlet.tigris.org/issues/show_bug.cgi?id=330 Basically, the pro

Re: Entity validation always true. Bug?

egards, Jerome -Message d'origine- De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] Envoyé : vendredi 13 juillet 2007 20:51 À : discuss@restlet.tigris.org Objet : Re: Entity validation always true. Bug? I submitted an issue regarding this: http://restlet.tigris.org/issues/show_b

Re: Entity validation always true. Bug?

ou mind completing the necessary paperwork for the patches (JCA)? http://www.restlet.org/community/contribute Best regards, Jerome -Message d'origine- De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] Envoyé : vendredi 13 juillet 2007 20:51 À : discuss@restlet.tigris.org Objet :

RE: Entity validation always true. Bug?

r the patches (JCA)? http://www.restlet.org/community/contribute Best regards, Jerome > -Message d'origine- > De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 13 juillet 2007 20:51 > À : discuss@restlet.tigris.org > Objet : Re: Entity validation

Re: Entity validation always true. Bug?

ot; headers. See the list of unsupported HTTP headers here: http://restlet.tigris.org/issues/show_bug.cgi?id=282 Best regards, Jerome -Message d'origine- De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] Envoyé : jeudi 12 juillet 2007 00:54 À : discuss@restlet.tigris.org Objet : R

Re: Entity validation always true. Bug?

s/show_bug.cgi?id=282 Best regards, Jerome -Message d'origine- De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] Envoyé : jeudi 12 juillet 2007 00:54 À : discuss@restlet.tigris.org Objet : Re: Entity validation always true. Bug? Peter, can you please tell me what caused this error i

Re: Entity validation always true. Bug?

-Modified and/or Etag values are not being computed or validated correctly. Perhaps the bug is because Vladimir is only sending an ETag out from the server to the client? Perhaps he should be sending both an ETag and a Last-Modified header. I.e. Perhaps the bug is in Restlet's handling o

RE: Entity validation always true. Bug?

] > Envoyé : jeudi 12 juillet 2007 00:54 > À : discuss@restlet.tigris.org > Objet : Re: Entity validation always true. Bug? > > Peter, > > can you please tell me what caused this error in your case? > I'm having similar problem, and can't find the solution. &

Re: Context bug

e context attributes JobProcessor processor = ConcurrentJobProcessor.getInstance(); getContext().getAttributes().put("processor", processor); } In this case, when any resource tries to obtain a reference to my singleton, it always comes back null. I'm not sure if this is relate

Context bug

processor); } In this case, when any resource tries to obtain a reference to my singleton, it always comes back null. I'm not sure if this is related to the bug Tammy just found a bit earlier, or if it's a new bug, or if I'm just doing something wrong. Thanks! Jason

Re: Entity validation always true. Bug?

Peter, can you please tell me what caused this error in your case? I'm having similar problem, and can't find the solution. This is my case: 1. I use GET to generate an entity from an URL, and set maxAge and Etag headers in response. The first time I request this URI, I get 200 status, along wi

Re: Entity validation always true. Bug?

Sorry to keep responding to my own posts, but it turns out that the problem existed between chair and keyboard. Restlet's working dandy. Pete Peter Lacey wrote: All, I have a resource for which I'm generating a strong ETag and a Last-Modified header. I first GET the resource without any co

Entity validation always true. Bug?

All, I have a resource for which I'm generating a strong ETag and a Last-Modified header. I first GET the resource without any conditions (no If-None-Match and no If-Modified-Since). I next GET it again supplying the ETag and get a 304 response as appropriate. I then update the resource an

RE: StatusService Question / Potential Bug

Hi Adam, This was a bug, which is now fixed in SVN (1.0 and trunk). Best regards, Jerome > -Message d'origine- > De : Adam Taft [mailto:[EMAIL PROTECTED] > Envoyé : lundi 21 mai 2007 22:56 > À : discuss@restlet.tigris.org > Objet : StatusService Question / P

StatusService Question / Potential Bug

etc. based on the Throwable. I'm under the impression that these two cases should work identically. So, I'm guessing that this is a bug? Or, is there something in my implementation that I'm doing wrong? Thanks in advance, Adam

Re: Bug: Oversized messages cause erroneous behavior

parameter and thus breaks the communication with the client. This cannot be trapped by the Restlet framework. On the client side, there was a bug with the Net client extension that detected correctly the end of the communication, but returned a -1 status code. Now, the generic status code 1001

Re: Bug: Oversized messages cause erroneous behavior

The way I got the bug was as follows: String request = "http://localhost:1234/";; for(int i=0;i<5*1024;i++) request += "a"; Component component = new Component(); Server server = component.getServers().add(Protocol.HTTP, 1234); component.start(); Client client = n

Re: Bug: Oversized messages cause erroneous behavior

Hello Alex, Could you precise your environment? I've tested with the Simple connector, and I get back 404 status which is not so bad but may be improved. Best regards, Thierry Boileau If you do a GET on a URI that is too big (4k by default), the response status will be 'null (-1)'. A quick

<    1   2   3   >