Re: bug with SpringFinder?
ok, thanks Sean. I close the issue. Best regards, Thierry Boileau 2013/11/15 Sean Hogan > Never mind. Like an idiot I had two beans named "metadataResource". I > thought Spring would whine about that, but apparently not. :-( > > (There may still be an issue with SpringFinder, but not from my flawed > analysis.) > > Thanks, > Sean > > > On 13-11-15 01:31 PM, Sean Hogan wrote: > > Hi, > > I believe I may have found a bug with the way SpringFinder works in > Restlet 2.1.4. > > I have two Application subclasses, each with one Router. Call them app1 > and app2, mapped in my servlet-based web app to "/app1" and "/app2". Both > apps define a template "/metadata" mapped to their own private Resource > subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be > initialized after app1. > > I find that invoking /app*1*/metadata instantiates a Metadata*2*Resource. > Looking into how this happens, I believe the problem is that SpringFinder > is a singleton, and therefore gets attached to both Routers in order of > initialization. Since app2 was initialized later, it wins, and the > /metadata is looked up relative to that Router. > > The bit of Spring context for app1 looks like this: > > > > > > > bean="metadataResource" /> > > > ... > > > scope="prototype" /> > > and similarly for app2. Both apps are loaded into the same Spring context. > > If I'm understanding things correctly, this is a fundamental issue in > using SpringFinder with multiple Routers. Can anyone give me workaround? > I absolutely need my Resource instances to be created by Spring so they get > autowired. > > Thanks, > Sean > > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3068572
Re: bug with SpringFinder?
Never mind. Like an idiot I had two beans named "metadataResource". I thought Spring would whine about that, but apparently not. :-( (There may still be an issue with SpringFinder, but not from my flawed analysis.) Thanks, Sean On 13-11-15 01:31 PM, Sean Hogan wrote: > Hi, > > I believe I may have found a bug with the way SpringFinder works in > Restlet 2.1.4. > > I have two Application subclasses, each with one Router. Call them > app1 and app2, mapped in my servlet-based web app to "/app1" and > "/app2". Both apps define a template "/metadata" mapped to their own > private Resource subclasses (Metadata1Resource and > Metadata2Resource). app2 happens to be initialized after app1. > > I find that invoking /app_1_/metadata instantiates a > Metadata_2_Resource. Looking into how this happens, I believe the > problem is that SpringFinder is a singleton, and therefore gets > attached to both Routers in order of initialization. Since app2 was > initialized later, it wins, and the /metadata is looked up relative to > that Router. > > The bit of Spring context for app1 looks like this: > > > > > > > bean="metadataResource" /> > > > ... > > > scope="prototype" /> > > and similarly for app2. Both apps are loaded into the same Spring > context. > > If I'm understanding things correctly, this is a fundamental issue in > using SpringFinder with multiple Routers. Can anyone give me > workaround? I absolutely need my Resource instances to be created by > Spring so they get autowired. > > Thanks, > Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3068571
Re: bug with SpringFinder?
Hi Sean, thanks for submitting this question: I've entered an issue for that point: https://github.com/restlet/restlet-framework-java/issues/797 best regards, Thierry Boileau 2013/11/15 Sean Hogan > Hi, > > I believe I may have found a bug with the way SpringFinder works in > Restlet 2.1.4. > > I have two Application subclasses, each with one Router. Call them app1 > and app2, mapped in my servlet-based web app to "/app1" and "/app2". Both > apps define a template "/metadata" mapped to their own private Resource > subclasses (Metadata1Resource and Metadata2Resource). app2 happens to be > initialized after app1. > > I find that invoking /app*1*/metadata instantiates a Metadata*2*Resource. > Looking into how this happens, I believe the problem is that SpringFinder > is a singleton, and therefore gets attached to both Routers in order of > initialization. Since app2 was initialized later, it wins, and the > /metadata is looked up relative to that Router. > > The bit of Spring context for app1 looks like this: > > > > > > > bean="metadataResource" /> > > > ... > > > scope="prototype" /> > > and similarly for app2. Both apps are loaded into the same Spring context. > > If I'm understanding things correctly, this is a fundamental issue in > using SpringFinder with multiple Routers. Can anyone give me workaround? > I absolutely need my Resource instances to be created by Spring so they get > autowired. > > Thanks, > Sean > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3068569
Re: Bug in DefaultConverter in 2.0.8?
Hello Glenn, thanks a lot for reporting this bug and for your analysis. The fix is available in the svn repository for both 2.0 branch and trunk (future 2.1). Best regards, Thierry Boileau > 2. shouldn't the test on line 237 of toObject be the > > test used on line 179 of the score method? > > The test on line 179 of the score method, for > > example, will be true if target has > > class DomRepresentation, regardless of the source object. > > Oops -- I meant to say that the test used in > the score method should be replaced with the > test used in the toObject method. The test used > in the score method seems patently wrong, since > among other things it never looks at the source. > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2815760 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2817066
RE: Bug in DefaultConverter in 2.0.8?
> 2. shouldn't the test on line 237 of toObject be the > test used on line 179 of the score method? > The test on line 179 of the score method, for > example, will be true if target has > class DomRepresentation, regardless of the source object. Oops -- I meant to say that the test used in the score method should be replaced with the test used in the toObject method. The test used in the score method seems patently wrong, since among other things it never looks at the source. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2815760
RE: BUG: restlet client ignores SSL parameters
Thierry, hello: do you think you could take a look on this? thank you; Andrei. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2723440
RE: BUG: restlet client ignores SSL parameters
this is tested with restlet version 2.0.5 with 2.1-SNAPSHOT the server code http://code.google.com/p/carrotgarden/source/browse/trunk/test-restlet/src/main/java/restlet_01/MainServerSSL.java just hangs -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2712183
RE: BUG: restlet client ignores SSL parameters
FYI: 1) script to generate keys & stores: http://code.google.com/p/carrotgarden/source/browse/trunk/test-restlet/src/main/resources/developer-keytool.sh 2) location of generated key stores used in test: http://code.google.com/p/carrotgarden/source/browse/#svn%2Ftrunk%2Ftest-restlet%2Fssl 3) reading and setting ssl restlet parameters: http://code.google.com/p/carrotgarden/source/browse/trunk/test-restlet/src/main/java/restlet_01/RESTLET.java -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2712171
RE: Bug when serializing sub-class to GWT?
Hello Fred, could you precise the version of Restlet are you using (on client side, and if applicable on server side)? I've made a test with a project with the current snapshots of the gwt and jee editions. I get the right values on client side. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2623779
RE: Bug in Atom extension Readers
Hi Martin,
Thanks for the report, this is fixed in SVN trunk.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
-Message d'origine-
De : Martin Svensson [mailto:msv...@gmail.com]
Envoyé : jeudi 13 mai 2010 18:36
À : discuss@restlet.tigris.org
Objet : Bug in Atom extension Readers
Hi, I am using both the FeedContentReader and EntryContentReader. When
inline content is detected the type will never be set, hence setting it to
text.
Code snippet
..
else if (localName.equalsIgnoreCase("content")) {
if (this.state == State.FEED_ENTRY_CONTENT) {
if (!this.currentEntry.getContent().isExternal()) {
String content =
this.currentContentWriter.getWriter()
.toString().trim();
contentDepth = -1;
if ("".equals(content)) {
this.currentEntry.setContent(null);
} else {
currentContent
.setInlineContent(new
StringRepresentation(
content));
}
}
this.state = State.FEED_ENTRY;
}
I guess the SringRepresentation needs to be set with correct content type as
well.
Thanks,
martin
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=26087
25
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2617646
RE: Bug in ServerResource.handle() when using annotated methods?
Hi Dave and Tim,
This is an edge case, but I think we can safely check if there is already an
available response entity before replacing it with the result. Ive changed
the test to this in SVN trunk and added a note in the Javadocs:
if (!getResponse().isEntityAvailable()) {
// If the user manually set the entity, keep it
getResponse().setEntity(result);
}
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com
De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim
Peierls
Envoyé : mercredi 12 mai 2010 14:36
À : discuss@restlet.tigris.org
Objet : Re: Bug in ServerResource.handle() when using annotated methods?
On Tue, May 11, 2010 at 5:06 PM, David Fogel wrote:
The other way I can see to make it consistent it to force annotated
methods to _always_ provide a return-type, in which case I suppose it
should always be fine to use that returned value to override anything
else.
Or (did you suggest this already?) just carve out an exception for annotated
void methods?
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2617644
RE: Re: Bug in ServerResource.handle() when using annotated methods?
While newcomer to Restlet, I was first quite confused after reading the Tutorial and the Java Docs how the ServerResouce class was expected to be extended. Now I understand clearly the several approaches, from very low level (extending doHandle) to nice high level annotations. Of course, I could just copy & paste the Tutorial example, but I prefer understanding how stuff works. Therefore I agree to David that ServerResouce should consistently allow combinations of higher/lower level API to be called, whichever fits a particular situation. I also would prefer the annotations as a tool to easy the ServerResource implementation, but not replacing lower level API. The annotation framework does not impose any pattern for return value nor parameters. Neither does is it hide lower level API. I think it is fine getting the request manually if one decided not to declare parameters. Or setting the response manually if the method is declared void. These are usages that seem reasonable to me. One might want to use annotations to ease content negotiation, but handle the remaing manually. Best regards, Daniel Ferber -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2610395
Re: Bug in ServerResource.handle() when using annotated methods?
On Tue, May 11, 2010 at 5:06 PM, David Fogel wrote: > The other way I can see to make it consistent it to force annotated > methods to _always_ provide a return-type, in which case I suppose it > should always be fine to use that returned value to override anything > else. > Or (did you suggest this already?) just carve out an exception for annotated void methods? --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2608130
Re: Bug in ServerResource.handle() when using annotated methods?
Hi Tim- Well, like I said, these methods have typical behavior that involves not returning an entity (for redirection and no-content handling). So we felt like part of having that code "read" better would involve it not being littered with "return null" statements, which, in other code, often suggest a failure condition. It's definitely not a huge deal, but there didn't seem to be any _logical_ reason to expect the resource-handling code to ignore our setEntity() calls. If this is indeed a case of higher-level API versus lower-level API, then if a higher-level API is going to change the semantics of using the lower-level API, shouldn't it prevent such mis-use of the lower-level API? Perhaps there is a fundamental flaw in how the ServerResource class offers annotation-based configuration on top of it's own lower-level API (because it has no way to control or even suggest how the two should be used together). But I think in this case it really would be sufficient to simply make the behavior consistent between the two by respecting any calls to setEntity() during request handling. The other way I can see to make it consistent it to force annotated methods to _always_ provide a return-type, in which case I suppose it should always be fine to use that returned value to override anything else. -Dave On Tue, May 11, 2010 at 4:56 PM, Tim Peierls wrote: > It doesn't sound like a bug to me, but I agree that the ServerResource > documentation should be clearer about this. > I think of getResponse().setEntity(new SomeRepresentation()) as an appeal to > a lower-level API. Is there some reason you don't want to return "new > SomeRepresentation()" directly from the annotated method? > --tim > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2607811
Re: Bug in ServerResource.handle() when using annotated methods?
It doesn't sound like a bug to me, but I agree that the ServerResource
documentation should be clearer about this.
I think of getResponse().setEntity(new SomeRepresentation()) as an appeal to
a lower-level API. Is there some reason you don't want to return "new
SomeRepresentation()" directly from the annotated method?
--tim
On Tue, May 11, 2010 at 4:31 PM, David Fogel wrote:
> Hi all-
>
> Our resources tend to subclass ServerResource and then use @Get,
> @Post, etc annotated methods for their functionality. Since there
> isn't very much documentation on the ServerResource class, we don't
> really know whether this is a bug, or if it reflects us violating some
> contract to do with the annotation processing, but we've noticed the
> following undesirable behavior:
>
> If we
> 1) annotate a method which has a return-type of "void", and
> 2) within that method call getResponse().setEntity(new
> SomeRepresentation()),
>
> then, ServerResource.handl() will, after calling some form of
> doHandle(), replace this existing entity with "null" in the response.
>
> Here is the relevant excerpt in ServerResource.handle():
>
>
> if (isConditional()) {
>result = doConditionalHandle();
> } else if (isNegotiated()) {
>result = doNegotiatedHandle();
> } else {
>result = doHandle();
> }
>
> if (getResponse() != null) {
>getResponse().setEntity(result);
> }
>
>
> In the above code, "result" is the (possibly converted) value returned
> from the annotated method. For "void" methods, this value is null.
> In our case, sometimes the method has set the entity separately using
> getResponse().setEntity(..)
>
> Is it possible that this line is meant to be something like:
> if (getResponse() != null && result != null)
> getResponse().setEntity(result);
>
> I think it's fine for the method return value to override what's
> already in the response, unless the result is null and the response
> already has an entity set.
>
> (Incdentally, our reason for using methods that have a "void" return
> type is that these methods will usually be doing redirects or
> "Success-No-Content" type response, but occasionally need to return
> something with an entity, for instance during an error.)
>
> Is this a bug?
>
> thanks,
> -Dave Fogel
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2607795
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2607808
RE: Bug in MediaType Parameter handling
Hi guys,
After double checking, there was a bug. Parameters are actually part of the
media type name, so toString() shouldnt add those parameters again.
Ive fixed the issue in SVN trunk and also improved the behavior of
getParent() to return an instance of MediaType without parameters if
possible first. See test case added:
MediaType mediaType = MediaType.valueOf("application/atom+xml;
name=value");
assertEquals("application/atom+xml; name=value",
mediaType.toString());
assertEquals(MediaType.APPLICATION_ATOM, mediaType.getParent());
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com
De : Thierry Boileau [mailto:thierry.boil...@noelios.com]
Envoyé : lundi 25 janvier 2010 12:02
À : discuss@restlet.tigris.org
Objet : Re: Bug in MediaType Parameter handling
Hello Carsten,
the current contract of the valueOf method is to use a "name" such as
"application/atom+xml" instead of a complete string with the parameters.
In your case, you can use the ContentType constructor with the String
parameter.
Best regards,
Thierry Boileau
Hi,
when I do the following:
---
MediaType mediaType = MediaType.valueOf("application/atom+xml;
charset=UTF-8");
System.out.println(mediaType.toString());
---
I get this output (with 2.0M6):
application/atom+xml; charset=UTF-8; charset=UTF-8
Seems to be a bug in the handling of parameters.
Cheers,
Carsten
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441
619> &dsMessageId=2441619
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2449981
Re: Bug in OAuthHelper?
Hello Yu,
Thanks for your report. I've entered an issue for that:
http://restlet.tigris.org/issues/show_bug.cgi?id=1034
Best regards,
Thierry Boileau
> Hi,
>
> When I use Restlet (Acutally Noelios) OAuth together with OAuth lib from
> Netflix, there's inconsistent in handling OAuth and non-oauth parameters and
> causes invalid signature exception later on in
>
> Noelios OAuthHelper saves all parameters (OAuth and Query parameters, for
> example) into its OAuthMessage's arrtibutes.
> see the code snippet from OAuthHelper.java:
>
> // Query parameters.
> for (final org.restlet.data.Parameter p : request.getResourceRef()
> .getQueryAsForm()) {
> parameters.add(new OAuth.Parameter(p.getName(), p.getValue()));
> }
>
> However, in Netflix's OAuthSignatureMethod class, the function "validate"
> where the signature of the base string is calculated from both the
> OAuthMessage arrtibutes PLUS the request parameters. See the code snippets in
> the function "getBaseString(OAuthMessage message)"
>
> parameters = new ArrayList>();
> parameters.addAll(OAuth.decodeForm(message.URL.substring(q +
> 1))); //!!! here we got duplicated query parameters !!!
> parameters.addAll(message.getParameters());
>
> --
> So My fix to this problem in OAuthGuard is to use my own "genMessage"
> function to replace the one at:
> // old
> final OAuthMessage requestMessage = OAuthHelper.getMessage(request);
>
> // mine
> final OAuthMessage requestMessage = _getMessage(request); // my
> implementation, basically I just commented out few lines of code where query
> parameters are involved.
>
> I am not 100% sure my hack is correct or will cause any other side-effect to
> the Restlet 1.* OAuth extension.
>
> BRs,
> Yu
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2444857
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446747
Re: Bug in MediaType Parameter handling
Hello Carsten,
the current contract of the valueOf method is to use a "name" such as
"application/atom+xml" instead of a complete string with the parameters.
In your case, you can use the ContentType constructor with the String
parameter.
Best regards,
Thierry Boileau
> Hi,
>
> when I do the following:
> ---
> MediaType mediaType = MediaType.valueOf("application/atom+xml;
> charset=UTF-8");
> System.out.println(mediaType.toString());
> ---
> I get this output (with 2.0M6):
> application/atom+xml; charset=UTF-8; charset=UTF-8
>
> Seems to be a bug in the handling of parameters.
>
> Cheers,
> Carsten
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441619
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441712
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
In the case of the wrapped jsonRepresentation object it might be sufficient to pass the call to getSize through to jsonRepresentation.getSize without doing the full calculation. In this case you gain the benefit of knowing the size when the wrapped representation knows its own size but don't suffer the penalty of repeated calculation if it does not. On Tue, Dec 8, 2009 at 12:50 AM, Thierry Boileau wrote: > Hi Ben, > > thanks a lot, I'm now awaken. > I've added an implementation of the getSize method that checked if the > wrapped representation is available of not. We may rely on the > getJsonText, however this could have an impact on large objects since > the each call to getJsonText compute a new value. > > Best regards, > Thierry Boileau >> I'm not sure I'm convinced. When using the constructor that takes >> (String jsonString) the passed arg is put into a StringRepresentation >> which is then stored in this.jsonRepresentation of the >> JsonRepresentation object. The private getJsonText method then will >> not use the first if case (because this.jsonObject is still null) and >> it will fall into the else if case (as this.jsonRepresentation is not >> null). This case is very simple as it directly takes >> StringRepresentation.getText() and returns that as the result (in the >> case where the String based constructor was used, in the case where >> the Representation based constructor was used the behavior may be a >> bit more ambiguous). >> >> >> >>> If the wrapped representation is not aimed to be parsed (in order to get >>> a JsonObject, JsonArray, etc) and is only aimed to be written, the >>> JsonRepresentation is useless. >>> >> >> >> The JsonRepresentation is not useless in this case. All the helpers >> can still be used to get formal json objects out of the representation >> using the toJson() methods (which will parse the underlying string >> rep but will still never set the internal jsonObject var). Also, the >> data still represents json formatted data conceptually. I still prefer >> the string constructor on the JsonRepresentation because it gives much >> greater control over the json formatting. One can also rely on >> Restlet's built in handling of media type and any other functionality >> that might be added or triggered by the variant system. >> >> When constructed through String or Representation the >> JsonRepresentation never changes its nature (it always knows it was >> not constructed with a json object and never forgets this fact no >> matter what methods you call on it). In these cases it is very >> possible to know the size (and even guaranteed to know the size in the >> String case). This makes the use of the "chunked" header quite >> unnecessary in these cases, and it breaks and slows down some proxy >> configurations which then have to do extra work to reassemble the >> response before passing it on. >> >> I have fallen back to using StringRepresentation to overcome this. In >> addition to needing to add extra json code (where I used to be able to >> pull the json right out of the representation) it also means I have to >> jump through more hoops to get a "application-json" header back >> through manual configuration of something that is supposed to be one >> of the nice things that Restlet does for you without making you jump >> through a bunch of hoops. >> >> It really does feel like a loophole. If you don't want to allow >> JsonRepresentation to be used as a convenience wrapper around a String >> then why provide a constructor that causes it to behave as one? >> >> -- >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428093 >> >> > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428111 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428114
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
Hi Ben, thanks a lot, I'm now awaken. I've added an implementation of the getSize method that checked if the wrapped representation is available of not. We may rely on the getJsonText, however this could have an impact on large objects since the each call to getJsonText compute a new value. Best regards, Thierry Boileau > I'm not sure I'm convinced. When using the constructor that takes > (String jsonString) the passed arg is put into a StringRepresentation > which is then stored in this.jsonRepresentation of the > JsonRepresentation object. The private getJsonText method then will > not use the first if case (because this.jsonObject is still null) and > it will fall into the else if case (as this.jsonRepresentation is not > null). This case is very simple as it directly takes > StringRepresentation.getText() and returns that as the result (in the > case where the String based constructor was used, in the case where > the Representation based constructor was used the behavior may be a > bit more ambiguous). > > > >> If the wrapped representation is not aimed to be parsed (in order to get >> a JsonObject, JsonArray, etc) and is only aimed to be written, the >> JsonRepresentation is useless. >> > > > The JsonRepresentation is not useless in this case. All the helpers > can still be used to get formal json objects out of the representation > using the toJson() methods (which will parse the underlying string > rep but will still never set the internal jsonObject var). Also, the > data still represents json formatted data conceptually. I still prefer > the string constructor on the JsonRepresentation because it gives much > greater control over the json formatting. One can also rely on > Restlet's built in handling of media type and any other functionality > that might be added or triggered by the variant system. > > When constructed through String or Representation the > JsonRepresentation never changes its nature (it always knows it was > not constructed with a json object and never forgets this fact no > matter what methods you call on it). In these cases it is very > possible to know the size (and even guaranteed to know the size in the > String case). This makes the use of the "chunked" header quite > unnecessary in these cases, and it breaks and slows down some proxy > configurations which then have to do extra work to reassemble the > response before passing it on. > > I have fallen back to using StringRepresentation to overcome this. In > addition to needing to add extra json code (where I used to be able to > pull the json right out of the representation) it also means I have to > jump through more hoops to get a "application-json" header back > through manual configuration of something that is supposed to be one > of the nice things that Restlet does for you without making you jump > through a bunch of hoops. > > It really does feel like a loophole. If you don't want to allow > JsonRepresentation to be used as a convenience wrapper around a String > then why provide a constructor that causes it to behave as one? > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428093 > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428111
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
I'm not sure I'm convinced. When using the constructor that takes (String jsonString) the passed arg is put into a StringRepresentation which is then stored in this.jsonRepresentation of the JsonRepresentation object. The private getJsonText method then will not use the first if case (because this.jsonObject is still null) and it will fall into the else if case (as this.jsonRepresentation is not null). This case is very simple as it directly takes StringRepresentation.getText() and returns that as the result (in the case where the String based constructor was used, in the case where the Representation based constructor was used the behavior may be a bit more ambiguous). > If the wrapped representation is not aimed to be parsed (in order to get > a JsonObject, JsonArray, etc) and is only aimed to be written, the > JsonRepresentation is useless. The JsonRepresentation is not useless in this case. All the helpers can still be used to get formal json objects out of the representation using the toJson() methods (which will parse the underlying string rep but will still never set the internal jsonObject var). Also, the data still represents json formatted data conceptually. I still prefer the string constructor on the JsonRepresentation because it gives much greater control over the json formatting. One can also rely on Restlet's built in handling of media type and any other functionality that might be added or triggered by the variant system. When constructed through String or Representation the JsonRepresentation never changes its nature (it always knows it was not constructed with a json object and never forgets this fact no matter what methods you call on it). In these cases it is very possible to know the size (and even guaranteed to know the size in the String case). This makes the use of the "chunked" header quite unnecessary in these cases, and it breaks and slows down some proxy configurations which then have to do extra work to reassemble the response before passing it on. I have fallen back to using StringRepresentation to overcome this. In addition to needing to add extra json code (where I used to be able to pull the json right out of the representation) it also means I have to jump through more hoops to get a "application-json" header back through manual configuration of something that is supposed to be one of the nice things that Restlet does for you without making you jump through a bunch of hoops. It really does feel like a loophole. If you don't want to allow JsonRepresentation to be used as a convenience wrapper around a String then why provide a constructor that causes it to behave as one? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428093
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
Hello Ben, your first post has been moderated, but was lost in the list of posts... sorry. Actually, the wrapped Representation is first parsed (in the private "getJsonText()" method) as JsonObject, even when the "write" method is called. Thus, it is difficult to know by advance the size of the text representation generated by the org.json library. If the wrapped representation is not aimed to be parsed (in order to get a JsonObject, JsonArray, etc) and is only aimed to be written, the JsonRepresentation is useless. Best regards, Thierry Boileau > JsonRepresentation has the member variable jsonRepresentation for > using a wrapped Representation object in some cases. The bug I'm > seeing is that getSize() on the JsonRepresentation object always > returns -1 in those cases where it is backed by this other underlying > representation. I believe a better behavior would be for > JsonRepresntation to over getSize() to return > jsonRepresentation.getSize() in those cases. > > I'm using 2.0-M5 (until M6 hits the public maven repo) but the problem > looks like it is also in M6. > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2427907 > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428085
RE: Bug with getClientInfo().getPreferredVariant()
Hi Dave, The experience so far has led us to be more flexible than the HTTP specification, if I remember correctly to be work around misconfigured user agent preferences. I'm open to revise this for stricter compliance and entered an issue: "Content negotiation isn't strict enough" http://restlet.tigris.org/issues/show_bug.cgi?id=964 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 : David Bordoley [mailto:bordo...@gmail.com] Envoyé : lundi 23 novembre 2009 05:42 À : discuss@restlet.tigris.org Objet : Bug with getClientInfo().getPreferredVariant() The HTTP spec section 14.1 states: "If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response." So I'm wondering if from within the handle() method in a Restlet if the following code should return null: request.getClientInfo().getPreferredVariant(variants, this.getApplication().getMetadataService()); if a client's request does not include one of the variants in the variants List, so that a server can detect the situation and return 406. Right now it seems to return the first variant in the variant list. Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24231 88 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2426287
RE: BUG??: Internal Connector Error (1002) - allowUserInteraction is not supported. - GAE
Hi there, Could you try again with Restlet 2.0 M4 and the GAE edition? The "org.restlet.ext.net" extension has been adapted and should work fine 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é : mardi 4 août 2009 16:43 À : discuss@restlet.tigris.org Objet : BUG??: Internal Connector Error (1002) - allowUserInteraction is not supported. - GAE Hi, I'm facing the same problem when using a Restlet client on GAE. I'm using the internal client implementation for GAE (org.restlet.gae.jar) since the others don't work at all and give me a more drastic exception. This is the exception Im getting using the restlet internal client: Caused by: java.lang.IllegalArgumentException: allowUserInteraction is not supported. at com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler$C onnection.setAllowUserInteraction(URLFetchServiceStreamHandler.java:346) at org.restlet.ext.net.HttpUrlConnectionCall.(HttpUrlConnectionCall.java:135) at org.restlet.ext.net.HttpClientHelper.create(HttpClientHelper.java:129) at org.restlet.engine.http.HttpClientAdapter.toSpecific(HttpClientAdapter.java: 505) at org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:106) at org.restlet.Client.handle(Client.java:164) at org.restlet.Uniform.handle(Uniform.java:118) at org.restlet.Uniform.post(Uniform.java:217) at com.eris4.warp4.callfriends.server.restlet.UsersManagerRemoteApplication.cre ateUser(UsersManagerRemoteApplication.java:41) ... 28 more Just for your curiosity this what I get using Apache HttpClient: Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityMan ager.checkPermission(DevAppServerFactory.java:128) at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityMan ager.checkAccess(DevAppServerFactory.java:155) at java.lang.ThreadGroup.checkAccess(Unknown Source) at java.lang.Thread.init(Unknown Source) at java.lang.Thread.(Unknown Source) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQu eueThread.(MultiThreadedHttpConnectionManager.java:1068) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.storeRefere nceToConnection(MultiThreadedHttpConnectionManager.java:173) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.access$900( MultiThreadedHttpConnectionManager.java:65) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionP ool.createConnection(MultiThreadedHttpConnectionManager.java:771) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnec tion(MultiThreadedHttpConnectionManager.java:476) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnecti onWithTimeout(MultiThreadedHttpConnectionManager.java:416) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDir ector.java:153) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.restlet.ext.httpclient.HttpMethodCall.sendRequest(HttpMethodCall.java:31 6) at org.restlet.engine.http.HttpClientAdapter.commit(HttpClientAdapter.java:430) at org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:108) at org.restlet.Client.handle(Client.java:164) at org.restlet.Uniform.handle(Uniform.java:118) at org.restlet.Uniform.post(Uniform.java:217) at com.eris4.warp4.callfriends.server.restlet.UsersManagerRemoteApplication.cre ateUser(UsersManagerRemoteApplication.java:41) ... 28 more --- I think this is a bug.. Anyone can help me?? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23800 36 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2384328
Re: bug?
Gotcha. Thanks. -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 15, 2009, at 12:43 PM, Jerome Louvel wrote: > Hi Schley, > > For Maven refresh policy, please check: > http://www.restlet.org/downloads/maven > > For Restlet 2.0 M4, I'd like to push it out by the end of the month. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : vendredi 10 juillet 2009 20:41 > À : discuss@restlet.tigris.org > Objet : Re: bug? > > Jerome, > > Do you know when this will make it into the Maven snapshot? Thanks! > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote: > >> Actually, I've just renamed the method to "doCatch" as the "error" >> term was ambiguous regarding Java terminology (ie. errors vs >> exceptions). Same logic. >> >> Best regards, >> Jerome Louvel >> -- >> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >> >> >> >> -Message d'origine- >> De : Schley Andrew Kutz [mailto:sak...@gmail.com] >> Envoyé : dimanche 5 juillet 2009 15:45 >> À : discuss@restlet.tigris.org >> Objet : Re: bug? >> >> Great! I'm really looking forward to this and the OnError bit making >> it into a release. :) >> >> -- >> -a >> >> "Ideally, a code library must be immediately usable by naive >> developers, easily customized by more sophisticated developers, and >> readily extensible by experts." -- L. Stein >> >> On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: >> >>> Hi Schley, >>> >>> FYI, this has been fixed in SVN trunk. >>> >>> Best regards, >>> Jerome Louvel >>> -- >>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >>> >>> >>> Schley Andrew Kutz a écrit : >>>> I want to prevent the use of HTTP VERB annotations in order to >>>> force >>>> sub-classes to respond with specific class types via abstract >>>> methods >>>> that I prototype in a base class. I marked the isAnnotated() method >>>> as >>>> @Override and final and returned false. However, when it returns >>>> false >>>> I get the following error: >>>> >>>> java.lang.NullPointerException >>>>at >>>> org >>>> .restlet >>>> .engine >>>> .resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >>>> 106) >>>>at >>>> org >>>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >>>> 649) >>>>at >>>> org.restlet.resource.ServerResource.doHandle(ServerResource.java: >>>> 329) >>>>at >>>> org >>>> .restlet >>>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java: >>>> 592) >>>>at >>>> org >>>> .restlet >>>> .resource.ServerResource.doConditionalHandle(ServerResource.java: >>>> 260) >>>>at org.restlet.resource.ServerResource.handle(ServerResource.java: >>>> 921) >>>>at >>>> com >>>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >>>> 159) >>>>at org.restlet.resource.Finder.handle(Finder.java:510) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet.routing.Router.handle(Router.java:490) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet
RE: bug?
Hi Schley, For Maven refresh policy, please check: http://www.restlet.org/downloads/maven For Restlet 2.0 M4, I'd like to push it out by the end of the month. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Schley Andrew Kutz [mailto:sak...@gmail.com] Envoyé : vendredi 10 juillet 2009 20:41 À : discuss@restlet.tigris.org Objet : Re: bug? Jerome, Do you know when this will make it into the Maven snapshot? Thanks! -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote: > Actually, I've just renamed the method to "doCatch" as the "error" > term was ambiguous regarding Java terminology (ie. errors vs > exceptions). Same logic. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > > -Message d'origine- > De : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : dimanche 5 juillet 2009 15:45 > À : discuss@restlet.tigris.org > Objet : Re: bug? > > Great! I'm really looking forward to this and the OnError bit making > it into a release. :) > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: > >> Hi Schley, >> >> FYI, this has been fixed in SVN trunk. >> >> Best regards, >> Jerome Louvel >> -- >> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >> >> >> Schley Andrew Kutz a écrit : >>> I want to prevent the use of HTTP VERB annotations in order to force >>> sub-classes to respond with specific class types via abstract >>> methods >>> that I prototype in a base class. I marked the isAnnotated() method >>> as >>> @Override and final and returned false. However, when it returns >>> false >>> I get the following error: >>> >>> java.lang.NullPointerException >>> at >>> org >>> .restlet >>> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >>> 106) >>> at >>> org >>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >>> 649) >>> at >>> org.restlet.resource.ServerResource.doHandle(ServerResource.java: >>> 329) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doConditionalHandle(ServerResource.java: >>> 260) >>> at org.restlet.resource.ServerResource.handle(ServerResource.java: >>> 921) >>> at >>> com >>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >>> 159) >>> at org.restlet.resource.Finder.handle(Finder.java:510) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at >>> org >>> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: >>> 153) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >>> at >>> org >>> .restlet >>> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: >>> 71) >>> at org.restlet.Application.handle(Application.java:396) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restl
Re: bug?
Jerome, Do you know when this will make it into the Maven snapshot? Thanks! -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote: > Actually, I've just renamed the method to "doCatch" as the "error" > term was ambiguous regarding Java terminology (ie. errors vs > exceptions). Same logic. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > > -Message d'origine- > De : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : dimanche 5 juillet 2009 15:45 > À : discuss@restlet.tigris.org > Objet : Re: bug? > > Great! I'm really looking forward to this and the OnError bit making > it into a release. :) > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: > >> Hi Schley, >> >> FYI, this has been fixed in SVN trunk. >> >> Best regards, >> Jerome Louvel >> -- >> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >> >> >> Schley Andrew Kutz a écrit : >>> I want to prevent the use of HTTP VERB annotations in order to force >>> sub-classes to respond with specific class types via abstract >>> methods >>> that I prototype in a base class. I marked the isAnnotated() method >>> as >>> @Override and final and returned false. However, when it returns >>> false >>> I get the following error: >>> >>> java.lang.NullPointerException >>> at >>> org >>> .restlet >>> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >>> 106) >>> at >>> org >>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >>> 649) >>> at >>> org.restlet.resource.ServerResource.doHandle(ServerResource.java: >>> 329) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doConditionalHandle(ServerResource.java: >>> 260) >>> at org.restlet.resource.ServerResource.handle(ServerResource.java: >>> 921) >>> at >>> com >>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >>> 159) >>> at org.restlet.resource.Finder.handle(Finder.java:510) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at >>> org >>> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: >>> 153) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >>> at >>> org >>> .restlet >>> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: >>> 71) >>> at org.restlet.Application.handle(Application.java:396) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.engine.
RE: bug?
Actually, I've just renamed the method to "doCatch" as the "error" term was ambiguous regarding Java terminology (ie. errors vs exceptions). Same logic. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Schley Andrew Kutz [mailto:sak...@gmail.com] Envoyé : dimanche 5 juillet 2009 15:45 À : discuss@restlet.tigris.org Objet : Re: bug? Great! I'm really looking forward to this and the OnError bit making it into a release. :) -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: > Hi Schley, > > FYI, this has been fixed in SVN trunk. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > Schley Andrew Kutz a écrit : >> I want to prevent the use of HTTP VERB annotations in order to force >> sub-classes to respond with specific class types via abstract methods >> that I prototype in a base class. I marked the isAnnotated() method >> as >> @Override and final and returned false. However, when it returns >> false >> I get the following error: >> >> java.lang.NullPointerException >> at >> org >> .restlet >> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >> 106) >> at >> org >> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >> 649) >> at org.restlet.resource.ServerResource.doHandle(ServerResource.java: >> 329) >> at >> org >> .restlet >> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) >> at >> org >> .restlet >> .resource.ServerResource.doConditionalHandle(ServerResource.java:260) >> at org.restlet.resource.ServerResource.handle(ServerResource.java: >> 921) >> at >> com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >> 159) >> at org.restlet.resource.Finder.handle(Finder.java:510) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at >> org >> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: >> 153) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >> at >> org >> .restlet >> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: >> 71) >> at org.restlet.Application.handle(Application.java:396) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >> at org.restlet.Component.handle(Component.java:397) >> at org.restlet.Server.handle(Server.java:350) >> at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) >> at >> org >> .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: >> 149) >> at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: >> 932) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: >> 487) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: >> 362) >> at >
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.j
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://restl
RE: bug?
Hi Schley, I've just fixed this bug in SVN trunk. Thanks for spotting it. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Schley Andrew Kutz [mailto:sak...@gmail.com] Envoyé : jeudi 25 juin 2009 20:09 À : discuss@restlet.tigris.org Objet : bug? I want to prevent the use of HTTP VERB annotations in order to force sub-classes to respond with specific class types via abstract methods that I prototype in a base class. I marked the isAnnotated() method as @Override and final and returned false. However, when it returns false I get the following error: java.lang.NullPointerException at org .restlet .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106) at org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 649) at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 329) at org .restlet .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) at org .restlet .resource.ServerResource.doConditionalHandle(ServerResource.java:260) at org.restlet.resource.ServerResource.handle(ServerResource.java:921) at com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 159) at org.restlet.resource.Finder.handle(Finder.java:510) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org .restlet .engine.application.ApplicationHelper.handle(ApplicationHelper.java:71) at org.restlet.Application.handle(Application.java:396) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org.restlet.Component.handle(Component.java:397) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org .mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 505) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 395) at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:488) -- -a "Ide
Re: bug? - AccessControlException on Restlet GAE module
Hi Jerome,
Thanks, it is perfect.
Zsolt
2009/4/30 Jerome Louvel
> Hi Zsolt,
>
> The Restlet/GAE edition is a branch of the SVN trunk so it doesn't contain
> this feature yet. We will fully update the branch again for Restlet 1.2 M3.
> We also have some plans to automate the update of the GAE branch to remove
> such issues.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> --
> *De :* Zsolt Kovacs [mailto:zs.m...@gmail.com]
> *Envoyé :* mercredi 29 avril 2009 13:03
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: bug? - AccessControlException on Restlet GAE module
>
> Thierry,
> I use gae, and this followRedirect seems to be missing from there.
>
> Zsolt
>
> 2009/4/29 Thierry Boileau
>
>> Hello Zsolt,
>>
>> if you want to catch the redirection, just disable the automatic
>> redirection (ClientResource#setFollowRedirect(false)).
>> Then, you can check the status.
>>
>> I hope this helps,
>> Best regards,
>> Thierry Boileau
>>
>> > Bonjour Thierry,
>> >
>> > I do this:
>> >
>> > ClientResource itemsR = new
>> > ClientResource("http://localhost:8080/gae_restlet/items";);
>> > Representation r = itemsR.get();
>> >
>> > In the web.xml all URLs are security constrained, so GAE automatically
>> > redirects get to its login page. I am stuck at this point, because I
>> > could not figure out the way to catch the redirect.
>> >
>> > Thanks,
>> >
>> > Zsolt
>> >
>> >
>> > 2009/4/28 Thierry Boileau > > <mailto:thierry.boil...@noelios.com>>
>> >
>> > � � Hello Zsolt,
>> >
>> > � � do you mean that you want your clientResource to redirect
>> > � � automatically?
>> > � � In this case, this is the new default behavior (see the
>> > � � "followRedirect"
>> > � � attribute).
>> >
>> > � � best regards,
>> > � � Thierry Boileau
>> > � � > Hi Jerome,
>> > � � >
>> > � � > Your fix worked great for me!
>> > � � >
>> > � � > I use the FirstResource example to learn Restlet, which is based
>> on
>> > � � > ClientResource. Unfortunately I do not know how I should handle
>> this
>> > � � > kind of redirect in ClientResource. I have checked wiki and
>> examples
>> > � � > but I did not find any hints, so I would appretiate your help on
>> > � � this.
>> > � � >
>> > � � > Thanks,
>> > � � >
>> > � � > Zsolt
>> > � � >
>> > � � > 2009/4/25 Jerome Louvel > > � � <mailto:jerome.lou...@noelios.com>
>> > � � > <mailto:jerome.lou...@noelios.com
>> > � � <mailto:jerome.lou...@noelios.com>>>
>> > � � >
>> > � � > � � Hi Keke,
>> > � � >
>> > � � > � � I've changed the way it this method is implemented in order to
>> > � � > � � construct the Subject with the principals set already updated.
>> > � � > � � This should prevent security exception. Let me know if it
>> works
>> > � � > � � better.
>> > � � >
>> > � � > � � 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 :* keke [mailto:iamk...@gmail.com
>> > � � <mailto:iamk...@gmail.com> <mailto:iamk...@gmail.com
>> > � � <mailto:iamk...@gmail.com>>]
>> > � � > � � *Envoy� :* samedi 18 avril 2009 16:57
>> > � � > � � *� :* discuss@restlet.tigris.org
>>
>> > � � <mailto:discuss@restlet.tigris.org>
>> > � � <mailto:discuss@restlet.tigris.org
>> > � � <mailto:discuss@restlet.tigris.org>>
>> > � � > � � *Objet :* Re: bug? - AccessControlException on Restlet GAE
>> > � � module
>> > � � >
>> > � � > � � Can I simply return null in ServletCall.getSubject, because
>> > � � in GAE
>> >
RE: bug? - AccessControlException on Restlet GAE module
Hi Zsolt,
The Restlet/GAE edition is a branch of the SVN trunk so it doesn't contain this
feature yet. We will fully update the branch again for Restlet 1.2 M3. We also
have some plans to automate the update of the GAE branch to remove such issues.
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 : Zsolt Kovacs [mailto:zs.m...@gmail.com]
Envoyé : mercredi 29 avril 2009 13:03
À : discuss@restlet.tigris.org
Objet : Re: bug? - AccessControlException on Restlet GAE module
Thierry,
I use gae, and this followRedirect seems to be missing from there.
Zsolt
2009/4/29 Thierry Boileau
Hello Zsolt,
if you want to catch the redirection, just disable the automatic
redirection (ClientResource#setFollowRedirect(false)).
Then, you can check the status.
I hope this helps,
Best regards,
Thierry Boileau
> Bonjour Thierry,
>
> I do this:
>
> ClientResource itemsR = new
> ClientResource("http://localhost:8080/gae_restlet/items";);
> Representation r = itemsR.get();
>
> In the web.xml all URLs are security constrained, so GAE automatically
> redirects get to its login page. I am stuck at this point, because I
> could not figure out the way to catch the redirect.
>
> Thanks,
>
> Zsolt
>
>
> 2009/4/28 Thierry Boileau <mailto:thierry.boil...@noelios.com>>
>
> � � Hello Zsolt,
>
> � � do you mean that you want your clientResource to redirect
> � � automatically?
> � � In this case, this is the new default behavior (see the
> � � "followRedirect"
> � � attribute).
>
> � � best regards,
> � � Thierry Boileau
> � � > Hi Jerome,
> � � >
> � � > Your fix worked great for me!
> � � >
> � � > I use the FirstResource example to learn Restlet, which is based on
> � � > ClientResource. Unfortunately I do not know how I should handle this
> � � > kind of redirect in ClientResource. I have checked wiki and examples
> � � > but I did not find any hints, so I would appretiate your help on
> � � this.
> � � >
> � � > Thanks,
> � � >
> � � > Zsolt
> � � >
> � � > 2009/4/25 Jerome Louvel � � <mailto:jerome.lou...@noelios.com>
> � � > <mailto:jerome.lou...@noelios.com
> � � <mailto:jerome.lou...@noelios.com>>>
> � � >
> � � > � � Hi Keke,
> � � >
> � � > � � I've changed the way it this method is implemented in order to
> � � > � � construct the Subject with the principals set already updated.
> � � > � � This should prevent security exception. Let me know if it works
> � � > � � better.
> � � >
> � � > � � 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 :* keke [mailto:iamk...@gmail.com
> � � <mailto:iamk...@gmail.com> <mailto:iamk...@gmail.com
> � � <mailto:iamk...@gmail.com>>]
> � � > � � *Envoy� :* samedi 18 avril 2009 16:57
> � � > � � *� :* discuss@restlet.tigris.org
> � � <mailto:discuss@restlet.tigris.org>
> � � <mailto:discuss@restlet.tigris.org
> � � <mailto: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
> � � > � � -
> � � > � � We paranoid love life
> � � >
> � � >
> � � > � � On Sat, Apr 18, 2009 at 10:25 PM, keke � � <mailto:iamk...@gmail.com>
> � � > � � <mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>>> wrote:
> � � >
> � � > � � � � 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.AuthPermission modifyPrincipals)
> � � > � � � � B B B B
Re: bug? - AccessControlException on Restlet GAE module
Thierry,
I use gae, and this followRedirect seems to be missing from there.
Zsolt
2009/4/29 Thierry Boileau
> Hello Zsolt,
>
> if you want to catch the redirection, just disable the automatic
> redirection (ClientResource#setFollowRedirect(false)).
> Then, you can check the status.
>
> I hope this helps,
> Best regards,
> Thierry Boileau
>
> > Bonjour Thierry,
> >
> > I do this:
> >
> > ClientResource itemsR = new
> > ClientResource("http://localhost:8080/gae_restlet/items";);
> > Representation r = itemsR.get();
> >
> > In the web.xml all URLs are security constrained, so GAE automatically
> > redirects get to its login page. I am stuck at this point, because I
> > could not figure out the way to catch the redirect.
> >
> > Thanks,
> >
> > Zsolt
> >
> >
> > 2009/4/28 Thierry Boileau > <mailto:thierry.boil...@noelios.com>>
> >
> > Hello Zsolt,
> >
> > do you mean that you want your clientResource to redirect
> > automatically?
> > In this case, this is the new default behavior (see the
> > "followRedirect"
> > attribute).
> >
> > best regards,
> > Thierry Boileau
> > > Hi Jerome,
> > >
> > > Your fix worked great for me!
> > >
> > > I use the FirstResource example to learn Restlet, which is based on
> > > ClientResource. Unfortunately I do not know how I should handle
> this
> > > kind of redirect in ClientResource. I have checked wiki and
> examples
> > > but I did not find any hints, so I would appretiate your help on
> > this.
> > >
> > > Thanks,
> > >
> > > Zsolt
> > >
> > > 2009/4/25 Jerome Louvel > <mailto:jerome.lou...@noelios.com>
> > > <mailto:jerome.lou...@noelios.com
> > <mailto:jerome.lou...@noelios.com>>>
> > >
> > > Hi Keke,
> > >
> > > I've changed the way it this method is implemented in order to
> > > construct the Subject with the principals set already updated.
> > > This should prevent security exception. Let me know if it works
> > > better.
> > >
> > > 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 :* keke [mailto:iamk...@gmail.com
> > <mailto:iamk...@gmail.com> <mailto:iamk...@gmail.com
> > <mailto:iamk...@gmail.com>>]
> > > *Envoyé :* samedi 18 avril 2009 16:57
> > > *À :* discuss@restlet.tigris.org
> > <mailto:discuss@restlet.tigris.org>
> > <mailto:discuss@restlet.tigris.org
> > <mailto: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
> > > -
> > > We paranoid love life
> > >
> > >
> > > On Sat, Apr 18, 2009 at 10:25 PM, keke > <mailto:iamk...@gmail.com>
> > > <mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>>> wrote:
> > >
> > > 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.AuthPermission modifyPrincipals)
> > > B B B B B B B at
> > >
> > java.security.AccessControlContext.checkPermission(Unknown Source)
>
Re: bug? - AccessControlException on Restlet GAE module
Hello Zsolt,
if you want to catch the redirection, just disable the automatic
redirection (ClientResource#setFollowRedirect(false)).
Then, you can check the status.
I hope this helps,
Best regards,
Thierry Boileau
> Bonjour Thierry,
>
> I do this:
>
> ClientResource itemsR = new
> ClientResource("http://localhost:8080/gae_restlet/items";);
> Representation r = itemsR.get();
>
> In the web.xml all URLs are security constrained, so GAE automatically
> redirects get to its login page. I am stuck at this point, because I
> could not figure out the way to catch the redirect.
>
> Thanks,
>
> Zsolt
>
>
> 2009/4/28 Thierry Boileau <mailto:thierry.boil...@noelios.com>>
>
> Hello Zsolt,
>
> do you mean that you want your clientResource to redirect
> automatically?
> In this case, this is the new default behavior (see the
> "followRedirect"
> attribute).
>
> best regards,
> Thierry Boileau
> > Hi Jerome,
> >
> > Your fix worked great for me!
> >
> > I use the FirstResource example to learn Restlet, which is based on
> > ClientResource. Unfortunately I do not know how I should handle this
> > kind of redirect in ClientResource. I have checked wiki and examples
> > but I did not find any hints, so I would appretiate your help on
> this.
> >
> > Thanks,
> >
> > Zsolt
> >
> > 2009/4/25 Jerome Louvel <mailto:jerome.lou...@noelios.com>
> > <mailto:jerome.lou...@noelios.com
> <mailto:jerome.lou...@noelios.com>>>
> >
> > Hi Keke,
> >
> > I've changed the way it this method is implemented in order to
> > construct the Subject with the principals set already updated.
> > This should prevent security exception. Let me know if it works
> > better.
> >
> > 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 :* keke [mailto:iamk...@gmail.com
> <mailto:iamk...@gmail.com> <mailto:iamk...@gmail.com
> <mailto:iamk...@gmail.com>>]
> > *Envoyé :* samedi 18 avril 2009 16:57
> > *À :* discuss@restlet.tigris.org
> <mailto:discuss@restlet.tigris.org>
> <mailto:discuss@restlet.tigris.org
> <mailto: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
> > -
> > We paranoid love life
> >
> >
> > On Sat, Apr 18, 2009 at 10:25 PM, keke <mailto:iamk...@gmail.com>
> > <mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>>> wrote:
> >
> > 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.AuthPermission modifyPrincipals)
> > B B B B B B B at
> >
> java.security.AccessControlContext.checkPermission(Unknown Source)
> > B B B B B B B at
> > java.security.AccessController.checkPermission(Unknown
> Source)
> > B B B B B B B at
> > java.lang.SecurityManager.checkPermission(Unknown Source)
> > B B B B B B B at
> >
>
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76)
> > B B B B B B B at
> > javax.security.auth.Subject$SecureSet.add(Unknown Source)
> > B B B B B B B at
> > java.util.Collections$SynchronizedCollec
Re: bug? - AccessControlException on Restlet GAE module
Bonjour Thierry,
I do this:
ClientResource itemsR = new ClientResource("
http://localhost:8080/gae_restlet/items";);
Representation r = itemsR.get();
In the web.xml all URLs are security constrained, so GAE automatically
redirects get to its login page. I am stuck at this point, because I could
not figure out the way to catch the redirect.
Thanks,
Zsolt
2009/4/28 Thierry Boileau
> Hello Zsolt,
>
> do you mean that you want your clientResource to redirect automatically?
> In this case, this is the new default behavior (see the "followRedirect"
> attribute).
>
> best regards,
> Thierry Boileau
> > Hi Jerome,
> >
> > Your fix worked great for me!
> >
> > I use the FirstResource example to learn Restlet, which is based on
> > ClientResource. Unfortunately I do not know how I should handle this
> > kind of redirect in ClientResource. I have checked wiki and examples
> > but I did not find any hints, so I would appretiate your help on this.
> >
> > Thanks,
> >
> > Zsolt
> >
> > 2009/4/25 Jerome Louvel > <mailto:jerome.lou...@noelios.com>>
> >
> > Hi Keke,
> >
> > I've changed the way it this method is implemented in order to
> > construct the Subject with the principals set already updated.
> > This should prevent security exception. Let me know if it works
> > better.
> >
> > 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 :* keke [mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>]
> > *Envoyé :* samedi 18 avril 2009 16:57
> > *À :* discuss@restlet.tigris.org <mailto: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
> > -
> > We paranoid love life
> >
> >
> > On Sat, Apr 18, 2009 at 10:25 PM, keke > <mailto:iamk...@gmail.com>> wrote:
> >
> > 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.AuthPermission modifyPrincipals)
> > B B B B B B B at
> > java.security.AccessControlContext.checkPermission(Unknown
> Source)
> > B B B B B B B at
> > java.security.AccessController.checkPermission(Unknown Source)
> > B B B B B B B at
> > java.lang.SecurityManager.checkPermission(Unknown Source)
> > B B B B B B B at
> >
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76)
> > B B B B B B B at
> > javax.security.auth.Subject$SecureSet.add(Unknown Source)
> > B B B B B B B at
> > java.util.Collections$SynchronizedCollection.add(Unknown Source)
> > B B B B B B B at
> >
> org.restlet.engine.servlet.ServletCall.getSubject(ServletCall.java:345)
> > B B B B B B B at
> >
> org.restlet.engine.http.HttpRequest.getClientInfo(HttpRequest.java:231)
> >
> >
> >
> > Can I just use a mock Subject in gae env?
> >
> >
> > Cheers,
> > Keke
> > -
> > We paranoid love life
> >
> >
> >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1960032
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1968002
Re: bug? - AccessControlException on Restlet GAE module
Hello Zsolt, do you mean that you want your clientResource to redirect automatically? In this case, this is the new default behavior (see the "followRedirect" attribute). best regards, Thierry Boileau > Hi Jerome, > > Your fix worked great for me! > > I use the FirstResource example to learn Restlet, which is based on > ClientResource. Unfortunately I do not know how I should handle this > kind of redirect in ClientResource. I have checked wiki and examples > but I did not find any hints, so I would appretiate your help on this. > > Thanks, > > Zsolt > > 2009/4/25 Jerome Louvel <mailto:jerome.lou...@noelios.com>> > > Hi Keke, > > I've changed the way it this method is implemented in order to > construct the Subject with the principals set already updated. > This should prevent security exception. Let me know if it works > better. > > 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 :* keke [mailto:iamk...@gmail.com <mailto:iamk...@gmail.com>] > *Envoyé :* samedi 18 avril 2009 16:57 > *À :* discuss@restlet.tigris.org <mailto: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 > - > We paranoid love life > > > On Sat, Apr 18, 2009 at 10:25 PM, keke <mailto:iamk...@gmail.com>> wrote: > > 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.AuthPermission modifyPrincipals) > B B B B B B B at > java.security.AccessControlContext.checkPermission(Unknown Source) > B B B B B B B at > java.security.AccessController.checkPermission(Unknown Source) > B B B B B B B at > java.lang.SecurityManager.checkPermission(Unknown Source) > B B B B B B B at > > com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76) > B B B B B B B at > javax.security.auth.Subject$SecureSet.add(Unknown Source) > B B B B B B B at > java.util.Collections$SynchronizedCollection.add(Unknown Source) > B B B B B B B at > > org.restlet.engine.servlet.ServletCall.getSubject(ServletCall.java:345) > B B B B B B B at > > org.restlet.engine.http.HttpRequest.getClientInfo(HttpRequest.java:231) > > > > Can I just use a mock Subject in gae env? > > > Cheers, > Keke > - > We paranoid love life > > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1960032
Re: bug? - AccessControlException on Restlet GAE module
Hi Jerome, Your fix worked great for me! I use the FirstResource example to learn Restlet, which is based on ClientResource. Unfortunately I do not know how I should handle this kind of redirect in ClientResource. I have checked wiki and examples but I did not find any hints, so I would appretiate your help on this. Thanks, Zsolt 2009/4/25 Jerome Louvel > Hi Keke, > > I've changed the way it this method is implemented in order to construct > the Subject with the principals set already updated. This should prevent > security exception. Let me know if it works better. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ 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 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-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.AuthPermission modifyPrincipals) >> B B B B B B B at >> java.security.AccessControlContext.checkPermission(Unknown Source) >> B B B B B B B at java.security.AccessController.checkPermission(Unknown >> Source) >> B B B B B B B at java.lang.SecurityManager.checkPermission(Unknown Source) >> B B B B B B B at >> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76) >> B B B B B B B at javax.security.auth.Subject$SecureSet.add(Unknown Source) >> B B B B B B B at java.util.Collections$SynchronizedCollection.add(Unknown >> Source) >> B B B B B B B at >> org.restlet.engine.servlet.ServletCall.getSubject(ServletCall.java:345) >> B B B B B B B at >> org.restlet.engine.http.HttpRequest.getClientInfo(HttpRequest.java:231) >> >> Can I just use a mock Subject in gae env? >> >> >> Cheers, >> Keke >> - >> We paranoid love life >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1943957
RE: bug? - AccessControlException on Restlet GAE module
Hi Keke, I've changed the way it this method is implemented in order to construct the Subject with the principals set already updated. This should prevent security exception. Let me know if it works better. 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 : keke [mailto:iamk...@gmail.com] Envoyé : samedi 18 avril 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 - We paranoid love life On Sat, Apr 18, 2009 at 10:25 PM, keke wrote: 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.AuthPermission modifyPrincipals) B B B B B B B at java.security.AccessControlContext.checkPermission(Unknown Source) B B B B B B B at java.security.AccessController.checkPermission(Unknown Source) B B B B B B B at java.lang.SecurityManager.checkPermission(Unknown Source) B B B B B B B at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityMan ager.checkPermission(DevAppServerFactory.java:76) B B B B B B B at javax.security.auth.Subject$SecureSet.add(Unknown Source) B B B B B B B at java.util.Collections$SynchronizedCollection.add(Unknown Source) B B B B B B B at org.restlet.engine.servlet.ServletCall.getSubject(ServletCall.java:345) B B B B B B B at org.restlet.engine.http.HttpRequest.getClientInfo(HttpRequest.java:231) Can I just use a mock Subject in gae env? Cheers, Keke - We paranoid love life -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1909247
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. 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 : MattyJ [mailto:mjwat...@gmail.com] Envoyé : vendredi 10 avril 2009 02:14 À : discuss@restlet.tigris.org Objet : Bug in HttpAmazonS3Helper class Ok. I think I've figured out my the problem with the HttpAmazonS3Helper class. The code in the method getCanonicalizedResourceName(Reference resourceRef) isn't quite correct as It needs to incorporate the _bucketname_ into the path. Presently its just getting the resource path. >From the S3 developer guide examples: GET /photos/puppy.jpg HTTP/1.1 Host: _bucketname_.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 + Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA= Which should translate into the following string to sign: GET\n \n \n Tue, 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. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=16205 18 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1733047 -- View this message in context: http://n2.nabble.com/Bug-in-HttpAmazonS3Helper-class-tp2614094p2660703.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1813266
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-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.AuthPermission modifyPrincipals) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at > com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76) > at javax.security.auth.Subject$SecureSet.add(Unknown Source) > at java.util.Collections$SynchronizedCollection.add(Unknown Source) > at > org.restlet.engine.servlet.ServletCall.getSubject(ServletCall.java:345) > at > org.restlet.engine.http.HttpRequest.getClientInfo(HttpRequest.java:231) > > Can I just use a mock Subject in gae env? > > > Cheers, > Keke > - > We paranoid love life > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1791082
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.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : MattyJ [mailto:mjwat...@gmail.com] Envoyé : vendredi 10 avril 2009 02:14 À : discuss@restlet.tigris.org Objet : Bug in HttpAmazonS3Helper class Ok. I think I've figured out my the problem with the HttpAmazonS3Helper class. The code in the method getCanonicalizedResourceName(Reference resourceRef) isn't quite correct as It needs to incorporate the _bucketname_ into the path. Presently its just getting the resource path. >From the S3 developer guide examples: GET /photos/puppy.jpg HTTP/1.1 Host: _bucketname_.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 + Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA= Which should translate into the following string to sign: GET\n \n \n Tue, 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. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=16205 18 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1733047
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 > > 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 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 enough that I'm never quite sure if > > I'm looking at Google's code or Apache Group's. > >
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 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 enough that I'm never quite sure if > I'm looking at Google's code or Apache Group's.
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
enough that I'm never quite sure if I'm looking at Google's code or Apache
Group's.
On Mon, Nov 17, 2008 at 4:49 AM, Richard Hoberman <
[EMAIL PROTECTED]> wrote:
> Hi
>
> If I make a request using an empty string:
>
> Request request = new Request(Method.POST, "http://localhost:8080/...";);
> request.getClientInfo().getAcceptedMediaTypes().add(new
> Preference(MediaType.APPLICATION_JSON));
> request.setEntity("", MediaType.APPLICATION_JSON);
>
> my accept method will receive an entity with a null mediaType:
>
> public void acceptRepresentation(Representation entity)throws
> ResourceException {
>
>MediaType mediaType = entity.getMediaType(); // will be null
>
>
> }
>
> Simply adding a space to the string (i.e. " ") results in the correct
> media type. This behaviour occurs when I deploy the application on
> Tomcat, but not when run in standalone mode.
>
> I've attached a bare-bones Tomcat webapp demonstrating this behaviour
> and a test case showing that it does not occur when run in standalone mode.
>
> From what I can make out, when the entity is "", getRequestHeaders is
> returning 0 parameters at line 173 of HttpServerCall (revision 3882)
> but it is not clear to me where the underlying requestHeaders field is
> being populated (or not being).
>
> Regards
>
> Richard Hoberman
>
RE: (BUG) restlet-ext-jaxrs depends on a snapshot jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT).
Hi Hendy, Thanks for the report, this has been fixed in SVN trunk and 1.1 branch. This will be released in the upcoming 1.1.2 version. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -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 jax-rs (javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT). My project is not buildable under this configuration. Using Maven 2.0.9. 1) javax.ws.rs:jsr311-api:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.ws.rs -DartifactId=jsr311-api -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=javax.ws.rs -DartifactId=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.tigris.org/issues/show_bug.cgi?id=647 -- Best regards, Hendy Irawan "Help save my best friend Melissa from teeth infection, please!" -> www.rainbowpurple.com
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 JAXB into the JRE is still a complete nightmare for me. Try with a very recent Java 6
RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle
Stephan, I'm only running Eclipse with JDK 1.6. My Restlet projects are still based on JDK 1.5. Best regards, Jerome > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : mardi 15 avril 2008 12:38 > À : discuss@restlet.tigris.org > 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 regards >Stephan > > Jerome Louvel schrieb: > > Hi all, > > > > That's strange. In my environment (Eclipse 3.3 + JDK 1.6), > everything works > > fine. > > > > Can an OSGi expert have a look 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.restle > >> > >> Hi all, > >> > >> I've problems with com.noelios.restlet.ext.httpclient_3.1 > (import not > >> found) and com.noelios.restlet.ext.oauth (access restriction with > >> package org.apache.commons.digest). > >> > >> best regards, > >> Thierry Boileau > >> > >> > >>> Hi, > >>> > >>> I've problems now in com.noelios.restlet.ext.httpclient_3.1, > >>> com.noelios.restlet.ext.jetty_6.1, > >>> > >> com.noelios.restlet.ext.oauth and > >> > >>> com.noelios.restlet.test, because a lot of imports could > >>> > >> not be found. > >> > >>> Did others had the same problem? > >>> > >>> The problems go away, if I go back to the version with the > >>> Require-Bundle (SVN rev 3009) for com.noelios.restlet, > >>> com.noelios.restlet.ext.httpclient_3.1, > >>> com.noelios.restlet.ext.jetty_6.1 and > com.noelios.restlet.ext.oauth > >>> > >>> best regards > >>> Stephan > >>> > >>> > >>>> Hi Hendy, > >>>> > >>>> Thanks for reporting this. Your suggestion makes sense > and is more > >>>> flexible. > >>>> I 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.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. > >>>>> > >>> > >>> > > > >
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 regards Stephan Jerome Louvel schrieb: Hi all, That's strange. In my environment (Eclipse 3.3 + JDK 1.6), everything works fine. Can an OSGi expert have a look 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.restle Hi all, I've problems with com.noelios.restlet.ext.httpclient_3.1 (import not found) and com.noelios.restlet.ext.oauth (access restriction with package org.apache.commons.digest). best regards, Thierry Boileau Hi, I've problems now in com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1, com.noelios.restlet.ext.oauth and com.noelios.restlet.test, because a lot of imports could not be found. Did others had the same problem? The problems go away, if I go back to the version with the Require-Bundle (SVN rev 3009) for com.noelios.restlet, com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1 and com.noelios.restlet.ext.oauth best regards Stephan Hi Hendy, Thanks for reporting this. Your suggestion makes sense and is more flexible. I 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.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.
RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle
Hi all, That's strange. In my environment (Eclipse 3.3 + JDK 1.6), everything works fine. Can an OSGi expert have a look 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.restle > > Hi all, > > I've problems with com.noelios.restlet.ext.httpclient_3.1 (import not > found) and com.noelios.restlet.ext.oauth (access restriction with > package org.apache.commons.digest). > > best regards, > Thierry Boileau > > > Hi, > > > > I've problems now in com.noelios.restlet.ext.httpclient_3.1, > > com.noelios.restlet.ext.jetty_6.1, > com.noelios.restlet.ext.oauth and > > com.noelios.restlet.test, because a lot of imports could > not be found. > > Did others had the same problem? > > > > The problems go away, if I go back to the version with the > > Require-Bundle (SVN rev 3009) for com.noelios.restlet, > > com.noelios.restlet.ext.httpclient_3.1, > > com.noelios.restlet.ext.jetty_6.1 and com.noelios.restlet.ext.oauth > > > > best regards > > Stephan > > > >> Hi Hendy, > >> > >> Thanks for reporting this. Your suggestion makes sense and is more > >> flexible. > >> I 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.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. > > > > > > >
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.restlet.ext.oauth (access restriction with package org.apache.commons.digest). best regards, Thierry Boileau Hi, I've problems now in com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1, com.noelios.restlet.ext.oauth and com.noelios.restlet.test, because a lot of imports could not be found. Did others had the same problem? The problems go away, if I go back to the version with the Require-Bundle (SVN rev 3009) for com.noelios.restlet, com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1 and com.noelios.restlet.ext.oauth best regards Stephan Hi Hendy, Thanks for reporting this. Your suggestion makes sense and is more flexible. I 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.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.
Re: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restle
Hi, I've problems now in com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1, com.noelios.restlet.ext.oauth and com.noelios.restlet.test, because a lot of imports could not be found. Did others had the same problem? The problems go away, if I go back to the version with the Require-Bundle (SVN rev 3009) for com.noelios.restlet, com.noelios.restlet.ext.httpclient_3.1, com.noelios.restlet.ext.jetty_6.1 and com.noelios.restlet.ext.oauth best regards Stephan Hi Hendy, Thanks for reporting this. Your suggestion makes sense and is more flexible. I 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.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.
RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet
Hi Hendy, Thanks for reporting this. Your suggestion makes sense and is more flexible. I have converted all manifests in SVN trunk. Best regards, Jerome > -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.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.servlet.*, > however Restlet won't accept it because its bundle name is not > javax.servlet (and it can't be, since it's not the > javax.servlet bundle). > > This also applies to all other JARs. Please use Import-Package, not > Require-Bundle (at all). Also recommended even for "internal" RESTlet > JARs themselves. Rather than requesting a specific bundle, import > specific packages so the user can mix and match as needed. > > Thank you. > > -- > Hendy Irawan > www.hendyirawan.com >
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 found that the bean name /path/* becomes /path/\* as regular expression. > SpringBeanRouter is a Spring BeanFactoryPostProcessor. It will > operate on all the Resources defined in the same context as it, so it > has to go in the application context where your resources are > defined. For me, this is [servlet-name]-servlet.xml. Yeah, thats what I thought. I had everything restlet related in my [servlet-name]-servlet.xml, and it didn't work until I put it in my main application context.xml. Maybe its because I have a 'contextConfigLocation' configuration directive in my web.xml? While I was debugging, the applicationConfigLocations of the spring context of [servlet-name]-servlet.xml was empty, but its parent context had all the entries I defined in 'contextConfigLocation'. Oh, btw., I use 1.1 M3. Regards, Michael
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 anything Spring does specially with *, but there could be. Can you provide a reproduceable test case? The SpringBeanRouter also does not work when placed in the [servlet-name]-servlet.xml, it must be placed in the main applicationContext.xml. SpringBeanRouter is a Spring BeanFactoryPostProcessor. It will operate on all the Resources defined in the same context as it, so it has to go in the application context where your resources are defined. For me, this is [servlet-name]-servlet.xml. If you define your resources elsewhere, your SpringBeanRouter will have to go in the same place. If you want to put them in different places, you can use a regular Router and SpringBeanFinder. Rhett
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 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:
public Resource createResource(Request request, Response response) {
Resource result = createResource();
if (result != null) {
result.setContext(getContext());
result.setNegotiateContent(true);
result.setRequest(request);
result.setResponse(response);
}
return result;
}
Otherwise the variants of Resources will we set to NULL inside the
Resource.init(...) method and variants could not be set inside a
constructor. Or is it more appropriate to overwrite the init(...)
method of Resources instaniated by Spring?
Greetings
Flo
RE: Bug: DirectoryResource is broken if used with relative paths
Hi Rob, Sorry, the changes were indeed broken. I have removed the additional methods on LocalReference and updated Directory to make the normalization logic work. Best regards, Jerome > -Message d'origine- > De : Rob Heittman [mailto:[EMAIL PROTECTED] > Envoyé : lundi 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.ClassCastException: org.restlet.data.Reference > [junit] at > org.restlet.data.LocalReference.getTargetRef(LocalReference.java:333) > > etc. > > - Rob > > > - Original Message - > 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 normalize the root > URI/Reference to prevent this kind of issues. Please test the > code in SVN > trunk or in SVN 1.0 branch and let me know if this solves the issue. > > Also, the LocalReference's getTargetRef(), getRelativeRef() and > getParentRef() 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: 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, either to normalize or not. > > FileClientHelper is already normalizing these paths, so I > > suggested to just > > normalize the targetUri/directoryUri within the > > DirectoryResource, so the > > rootLength is appropriate. > > > > Please look at the code I'm talking about in > > DirectoryResource.getVariants(), and tell me if I'm making sense? > >
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.ClassCastException: org.restlet.data.Reference [junit] at org.restlet.data.LocalReference.getTargetRef(LocalReference.java:333) etc. - Rob - Original Message - 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 normalize the root URI/Reference to prevent this kind of issues. Please test the code in SVN trunk or in SVN 1.0 branch and let me know if this solves the issue. Also, the LocalReference's getTargetRef(), getRelativeRef() and getParentRef() 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: 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, either to normalize or not. > FileClientHelper is already normalizing these paths, so I > suggested to just > normalize the targetUri/directoryUri within the > DirectoryResource, so the > rootLength is appropriate. > > Please look at the code I'm talking about in > DirectoryResource.getVariants(), and tell me if I'm making sense?
RE: Bug: DirectoryResource is broken if used with relative paths
Hi all, The Directory constructors now automatically normalize the root URI/Reference to prevent this kind of issues. Please test the code in SVN trunk or in SVN 1.0 branch and let me know if this solves the issue. Also, the LocalReference's getTargetRef(), getRelativeRef() and getParentRef() 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: 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, either to normalize or not. > FileClientHelper is already normalizing these paths, so I > suggested to just > normalize the targetUri/directoryUri within the > DirectoryResource, so the > rootLength is appropriate. > > Please look at the code I'm talking about in > DirectoryResource.getVariants(), and tell me if I'm making sense?
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, either to normalize or not. FileClientHelper is already normalizing these paths, so I suggested to just normalize the targetUri/directoryUri within the DirectoryResource, so the rootLength is appropriate. Please look at the code I'm talking about in DirectoryResource.getVariants(), and tell me if I'm making sense?
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, then the rootLength calculated in DirectoryResource.getVariants() will be the length of "file:///foo" instead of "file:///foo/./", and the substring length that we remove from the results to get the file name will be correct.
Re: Bug: DirectoryResource is broken if used with relative paths
Rob Heittman wrote:
Learn something new every day! Makes sense. Just resolve the
relativisms then?
I'm not entirely sure we should
Anyway, I am afraid that on a file-system you can't do one without the other
suppose I have
/home/mpo/path/symlink => /var/whatever/target
then what should be the resolution of:
file:/home/mpo/path/symlink/../stuff
should it get me:
file:/home/mpo/path/stuff
or:
file:/var/whatever/stuff (linux and the java canonicalPath take this)
Continuing in this view to 'resources'
supposing there is something like
http://server/path/context-y/alias-for-x giving me the same as
http://(other?)server/canonical-x
what would be the least surprising:
that
http://server/path/content-y/alias-for-x/../some-resource
reproduces
http://server/path/content-y/some-x-rersource
or rather
http://(other?)server/canonical-x/../some-resource
Dunno but maybe there is some spec or guideline on relative notations in
URI's and how they should be 'cleaned out' / 'resolved'.
Haven't took the time to delve into your use case yet, is there anything
braking by these relativisms, or is it just a bit 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 paths
Rob Heittman wrote:
>
> With trunk rev 2170 Joel's problem still manifests.
>
> I confirmed issue 352 solved, but this is something different.
> LocalReference.getFileReference() does not make the ./ go away. I think
> it should:
>
> LocalReference.java:86
> < return createFileReference(file.getAbsolutePath());
> >return createFileReference(file.getCanonicalPath());
>
> Unless there is a useful reason to create a LocalReference that still
> contains ./ and ../ etc -- I can't think of one.
>
unless I'm missing something here:
the compelling reason was symbolic links
http://restlet.tigris.org/issues/show_bug.cgi?id=337
point being: the difference between absolute/canonical is about more
then only resolving ./ and ../ in paths (which is quite logic since
purely textual resolving the ./ and ../ might yield to quite different
results then what you expect when 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 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
> > Objet : Re: Bug: DirectoryResource is broken if used with
> > relative paths
> >
> >
> > Thanks for trying it anyway, Joel, I wasn't at an actual
> > computer yesterday.
> >
> > Something like this works around the issue for me:
> >
> > String path = null;
> > try{
> > path=new File("./").getCanonicalPath();
> > } catch (IOException handleMePlease) {}
> > LocalReference lr = LocalReference.createFileReference(path);
> > Directory directory = new Directory(getContext(),lr);
> >
> > You need to get the "." and ".." resolved away, which
> > getCanonicalPath()
> > does.
> >
> > I think LocalReference should do this for you when you pass a
> > File as in
> > your original example -- thoughts, 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 8:00:26 PM (GMT-0500)
> > America/New_York
> > Subject: 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 directory able to expose a hierarchy of files
> > > Directory directory = new Directory(getContext(),
> > > LocalReference.createFileReference(new File("./")).getTargetRef());
> >
> > This one doesn't compile, "The constructor Directory(Context,
> > Reference)
> > is undefined"
> >
> >
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: DirectoryResource is broken if used with relative paths
Rob Heittman wrote:
>
> With trunk rev 2170 Joel's problem still manifests.
>
> I confirmed issue 352 solved, but this is something different.
> LocalReference.getFileReference() does not make the ./ go away. I think
> it should:
>
> LocalReference.java:86
> < return createFileReference(file.getAbsolutePath());
> > return createFileReference(file.getCanonicalPath());
>
> Unless there is a useful reason to create a LocalReference that still
> contains ./ and ../ etc -- I can't think of one.
>
unless I'm missing something here:
the compelling reason was symbolic links
http://restlet.tigris.org/issues/show_bug.cgi?id=337
point being: the difference between absolute/canonical is about more
then only resolving ./ and ../ in paths (which is quite logic since
purely textual resolving the ./ and ../ might yield to quite different
results then what you expect when 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 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
> > Objet : Re: Bug: DirectoryResource is broken if used with
> > relative paths
> >
> >
> > Thanks for trying it anyway, Joel, I wasn't at an actual
> > computer yesterday.
> >
> > Something like this works around the issue for me:
> >
> > String path = null;
> > try{
> > path=new File("./").getCanonicalPath();
> > } catch (IOException handleMePlease) {}
> > LocalReference lr = LocalReference.createFileReference(path);
> > Directory directory = new Directory(getContext(),lr);
> >
> > You need to get the "." and ".." resolved away, which
> > getCanonicalPath()
> > does.
> >
> > I think LocalReference should do this for you when you pass a
> > File as in
> > your original example -- thoughts, 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 8:00:26 PM (GMT-0500)
> > America/New_York
> > Subject: 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 directory able to expose a hierarchy of files
> > > Directory directory = new Directory(getContext(),
> > > LocalReference.createFileReference(new File("./")).getTargetRef());
> >
> > This one doesn't compile, "The constructor Directory(Context,
> > Reference)
> > is undefined"
> >
> >
Re: Bug: DirectoryResource is broken if used with relative paths
Rob Heittman wrote:
With trunk rev 2170 Joel's problem still manifests.
I confirmed issue 352 solved, but this is something different.
LocalReference.getFileReference() does not make the ./ go away. I think
it should:
LocalReference.java:86
< return createFileReference(file.getAbsolutePath());
>return createFileReference(file.getCanonicalPath());
Unless there is a useful reason to create a LocalReference that still
contains ./ and ../ etc -- I can't think of one.
unless I'm missing something here:
the compelling reason was symbolic links
http://restlet.tigris.org/issues/show_bug.cgi?id=337
point being: the difference between absolute/canonical is about more
then only resolving ./ and ../ in paths (which is quite logic since
purely textual resolving the ./ and ../ might yield to quite different
results then what you expect when 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 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
> Objet : Re: Bug: DirectoryResource is broken if used with
> relative paths
>
>
> Thanks for trying it anyway, Joel, I wasn't at an actual
> computer yesterday.
>
> Something like this works around the issue for me:
>
> String path = null;
> try{
> path=new File("./").getCanonicalPath();
> } catch (IOException handleMePlease) {}
> LocalReference lr = LocalReference.createFileReference(path);
> Directory directory = new Directory(getContext(),lr);
>
> You need to get the "." and ".." resolved away, which
> getCanonicalPath()
> does.
>
> I think LocalReference should do this for you when you pass a
> File as in
> your original example -- thoughts, 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 8:00:26 PM (GMT-0500)
> America/New_York
> Subject: 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 directory able to expose a hierarchy of files
> > Directory directory = new Directory(getContext(),
> > LocalReference.createFileReference(new File("./")).getTargetRef());
>
> This one doesn't compile, "The constructor Directory(Context,
> Reference)
> is undefined"
>
>
Re: Bug: DirectoryResource is broken if used with relative paths
With trunk rev 2170 Joel's problem still manifests.
I confirmed issue 352 solved, but this is something different.
LocalReference.getFileReference() does not make the ./ go away. I think it
should:
LocalReference.java:86
< return createFileReference(file.getAbsolutePath());
> return createFileReference(file.getCanonicalPath());
Unless there is a useful reason to create a LocalReference that still contains
./ and ../ etc -- I can't think of one.
- 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 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
> Objet : Re: Bug: DirectoryResource is broken if used with
> relative paths
>
>
> Thanks for trying it anyway, Joel, I wasn't at an actual
> computer yesterday.
>
> Something like this works around the issue for me:
>
> String path = null;
> try{
> path=new File("./").getCanonicalPath();
> } catch (IOException handleMePlease) {}
> LocalReference lr = LocalReference.createFileReference(path);
> Directory directory = new Directory(getContext(),lr);
>
> You need to get the "." and ".." resolved away, which
> getCanonicalPath()
> does.
>
> I think LocalReference should do this for you when you pass a
> File as in
> your original example -- thoughts, 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 8:00:26 PM (GMT-0500)
> America/New_York
> Subject: 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 directory able to expose a hierarchy of files
> > Directory directory = new Directory(getContext(),
> > LocalReference.createFileReference(new File("./")).getTargetRef());
>
> This one doesn't compile, "The constructor Directory(Context,
> Reference)
> is undefined"
>
>
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
> Objet : Re: Bug: DirectoryResource is broken if used with
> relative paths
>
>
> Thanks for trying it anyway, Joel, I wasn't at an actual
> computer yesterday.
>
> Something like this works around the issue for me:
>
> String path = null;
> try{
> path=new File("./").getCanonicalPath();
> } catch (IOException handleMePlease) {}
> LocalReference lr = LocalReference.createFileReference(path);
> Directory directory = new Directory(getContext(),lr);
>
> You need to get the "." and ".." resolved away, which
> getCanonicalPath()
> does.
>
> I think LocalReference should do this for you when you pass a
> File as in
> your original example -- thoughts, 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 8:00:26 PM (GMT-0500)
> America/New_York
> Subject: 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 directory able to expose a hierarchy of files
> > Directory directory = new Directory(getContext(),
> > LocalReference.createFileReference(new File("./")).getTargetRef());
>
> This one doesn't compile, "The constructor Directory(Context,
> Reference)
> is undefined"
>
>
Re: Bug: DirectoryResource is broken if used with relative paths
Thanks for trying it anyway, Joel, I wasn't at an actual computer yesterday.
Something like this works around the issue for me:
String path = null;
try{
path=new File("./").getCanonicalPath();
} catch (IOException handleMePlease) {}
LocalReference lr = LocalReference.createFileReference(path);
Directory directory = new Directory(getContext(),lr);
You need to get the "." and ".." resolved away, which getCanonicalPath()
does.
I think LocalReference should do this for you when you pass a File as in
your original example -- thoughts, 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 8:00:26 PM (GMT-0500) America/New_York
Subject: 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 directory able to expose a hierarchy of files
> Directory directory = new Directory(getContext(),
> LocalReference.createFileReference(new File("./")).getTargetRef());
This one doesn't compile, "The constructor Directory(Context, Reference)
is undefined"
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 directory able to expose a hierarchy of files
> Directory directory = new Directory(getContext(),
> LocalReference.createFileReference(new File("./")).getTargetRef());
This one doesn't compile, "The constructor Directory(Context, Reference)
is undefined"
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 expose a hierarchy of files
Directory directory = new Directory(getContext(),
LocalReference.createFileReference(new File("./").getPath()));
2)
// Create a directory able to expose a hierarchy of files
Directory directory = new Directory(getContext(),
LocalReference.createFileReference(new File("./")).getTargetRef());
- Rob
- Original Message -
From: "Joel Nelson" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Sunday, September 16, 2007 12:25:31 PM (GMT-0500) America/New_York
Subject: 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
Directory directory = new Directory(getContext(),
LocalReference.createFileReference(new File("./")));
The problem seems to occur in DirectoryResource.getVariants(), where rootLength
is calculated against the file:// URL which has the relative path in it, e.g.
if
your app is running at "file://foo" (pardon me if this URL seems wrong, my
debugger shows the url in my instance to start with "file:" but that seems
like a suspicious number of "/" to me) , this would be "file://foo/./". However
around line 451 we see that the sortedSet contains URLs of the form
"file://foo/bar" rather than "file://foo/./bar", therefore later when we use
the
rootLength to strip the beginning part of the file path off, we strip off
"file://foo/ba", because that is the length of "file://foo/./"
Of course this gives us a bad response, where all the file names are 2
characters shorter than they should be.
Let me know if I can provide more information.
Re: Bug: Oversized messages cause erroneous behavior
Hello Alex,
Thanks for reporting this issue, which has been fixed in the SVN repository.
This issue happens when the Net client connector is used in conjunction
with the Jetty server connector.
The Jetty HTTP implementation throws an exception when the request size
exceeds the headerBufferSize 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 (CONNECTOR_ERROR_COMMUNICATION) is
returned instead.
As you may notice, this is not a standard HTTP status code because there
is no way to determine the real cause of error, and no status code has
been returned by the server.
Best regards,
Thierry Boileau
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 = new Client(Protocol.HTTP);
Response response = client.get(request);
response.getStatus() will be equal to "null (-1)"
However, if you insert:
server.getContext().getParameters().set("headerBufferSize", "6144", false);
before component.start(), then response.getStatus() will be 404, as expected.
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 = new Client(Protocol.HTTP);
Response response = client.get(request);
response.getStatus() will be equal to "null (-1)"
However, if you insert:
server.getContext().getParameters().set("headerBufferSize", "6144", false);
before component.start(), then response.getStatus() will be 404, as expected.
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 look at the standard HTTP codes says that it should be 'Request URI too long (414)'. Something to incorporate.
Re: Bug in bookmark example
Hello Sean, you're right again. The svn repository, the zip archive of the examples source code available on the restlet site have been updated. Thanks and have a good day, Thierry Boileau Hi Thierry, Thierry Boileau gmail.com> writes: Hello Sean, the example code has been updated in the SVN repository. Thanks for reporting this issue. I think there is still a bug. Try adding a user and two bookmarks. Shutdown the server and then restart it. One of the bookmarks seems to disappear. Sean
Re: Bug in bookmark example
Hi Thierry, Thierry Boileau gmail.com> writes: > > Hello Sean, > > the example code has been updated in the SVN repository. > Thanks for reporting this issue. I think there is still a bug. Try adding a user and two bookmarks. Shutdown the server and then restart it. One of the bookmarks seems to disappear. Sean
Re: Bug in bookmark example
Hello Sean, the example code has been updated in the SVN repository. Thanks for reporting this issue. Best regards, Thierry Boileau There's a bug in the bookmark example. If I create a user, say 'scl', and add a bookmark, say 'artima.com', all is well. I browse to http://localhost:3000/v1/users/ and I see scl. I browse to http://localhost:3000/v1/users/bookmarks and I see List of references artima.com Where 'artima.com' is a hyperlink. The problem is that the hyperlink is not correct. It is: http://localhost:3000/v1/users/artima.com and it should be: http://localhost:3000/v1/users/bookmarks/artima.com Sean
Re: Bug in bookmark example
What URI did you supply when you added the bookmark? On 14/03/2007, at 8:53 AM, Sean Landis wrote: I have some typos in my last email. Here are the corrections. Sean Landis gmail.com> writes: http://localhost:3000/v1/users/ and I see scl. I browse to http://localhost:3000/v1/users/bookmarks and I see Should be: http://localhost:3000/v1/users/scl/bookmarks List of references artima.com Where 'artima.com' is a hyperlink. The problem is that the hyperlink is not correct. It is: http://localhost:3000/v1/users/artima.com and it should be: http://localhost:3000/v1/users/bookmarks/artima.com The above two should be It is: http://localhost:3000/v1/users/scl/artima.com and http://localhost:3000/v1/users/scl/bookmarks/artima.com
Re: Bug in bookmark example
I have some typos in my last email. Here are the corrections. Sean Landis gmail.com> writes: > http://localhost:3000/v1/users/ and I see scl. I browse to > http://localhost:3000/v1/users/bookmarks and I see Should be: http://localhost:3000/v1/users/scl/bookmarks > > List of references > artima.com > > Where 'artima.com' is a hyperlink. The problem is that the hyperlink is > not correct. It is: http://localhost:3000/v1/users/artima.com > and it should be: http://localhost:3000/v1/users/bookmarks/artima.com The above two should be It is: http://localhost:3000/v1/users/scl/artima.com and http://localhost:3000/v1/users/scl/bookmarks/artima.com
RE: bug in Finder.java
Hi Brian,
Thanks for reporting this bug. It is now fixed in SVN. We are still working
on releasing 1.0 RC5 and updating the Web site, thanks for your patience.
After registering with Tigris.org, you can report bugs with the issue
tracker:
http://restlet.tigris.org/servlets/ProjectIssues
Best regards,
Jerome
> -Message d'origine-
> De : news [mailto:[EMAIL PROTECTED] De la part de Brian Crow
> Envoyé : vendredi 2 mars 2007 16:31
> À : discuss@restlet.tigris.org
> Objet : bug in Finder.java
>
> I could not find another way to report this issue.
>
> In getMethod in Finder.java
>
> "handle" is hardcoded into method name contruction instead of
> using the
> prefix parameter. This results in the allow[MethodName]() throwing a
> NullPointerException.
>
> Finder.java line 223 in rc4.
> sb.append("handle");
> should be
> sb.append(prefix);
>
Re: Bug in Directory handler
Hi Sean, thanks for the report, your fix has been integrated in svn. Best regards, Thierry Jerome Louvel a écrit : Hi Sean, Thanks for the report, I was able to simply reproduce it by creating a "test" directory: http://www.restlet.org/downloads/test/ We'll integrate your fix to 1.0 RC2. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis Envoyé : jeudi 28 décembre 2006 18:30 À : discuss@restlet.tigris.org Objet : Bug in Directory handler I found a bug in the Directory handler. It generates correct XML for the top level items, but if you click on a directory in a browser, then next level links are unusable. Here's what's generated by clicking on the 'jmx' link: Listing of directory "/jmx" http://localhost:8182/";>.. href="http://localhost:8182/jmxjmx_examples";>../jmxjmx_example s I've entered bug #233 that contains a proposed fix. Sean
RE: Bug in Directory handler
Hi Sean, Thanks for the report, I was able to simply reproduce it by creating a "test" directory: http://www.restlet.org/downloads/test/ We'll integrate your fix to 1.0 RC2. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis > Envoyé : jeudi 28 décembre 2006 18:30 > À : discuss@restlet.tigris.org > Objet : Bug in Directory handler > > I found a bug in the Directory handler. It generates correct > XML for the top > level items, but if you click on a directory in a browser, > then next level links > are unusable. Here's what's generated by clicking on the 'jmx' link: > > > Listing of directory "/jmx" > http://localhost:8182/";>.. > href="http://localhost:8182/jmxjmx_examples";>../jmxjmx_example > s > > > I've entered bug #233 that contains a proposed fix. > > Sean
Re: Bug in Reference.getHostPort() ?
Thierry,
Thanks for the heads-up -- i'll be sure to completely test my
implementation. There's always the possibility I had the wrong jars on the
classpath. Regardless, thanks for looking into it.
Regards
Jeff
On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
Jeff,
actually :
- Jerome solved the issue but was unable to test.
- I only tested the solution given by Jerome,
- you may have missed the latest files in SVN
Best regards,
Thierry
Reddite Quae sunt Caesaris, Caesari ; et quae sunt Dei, Deo. [Render to
Caesar the things that are Caesar's; and to God, the things that are God's]
**
On 12/6/06, Jerome Louvel <[EMAIL PROTECTED] > wrote:
>
> Cool, thanks for letting us know!
> Thanks also to Thierry for helping with the tests.
>
> Take care,
> Jerome
>
> > -Message d'origine-
> > De : Jeff Walter [mailto:[EMAIL PROTECTED]
> > Envoyé : mercredi 6 décembre 2006 22:38
> > À : discuss@restlet.tigris.org
> > Objet : Re: Bug in Reference.getHostPort() ?
> >
> > Thierry,
> >
> > The problem seems to be solved. Thanks for your effort.
> >
> > Love the project, keep up the great work.
> >
> > Regards,
> > Jeff Walter
> >
> >
> >
> > On 12/6/06, Thierry Boileau <[EMAIL PROTECTED] > wrote:
> >
> > Hello Jeff,
> >
> > can you get the latest source code from SVN and tell us
> > if it fixes the problem?
> >
> > Best regards,
> > Thierry Boileau
> >
> >
> >
> > On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
> >
> > Jeff,
> >
> > I've downloaded the beta21 and reproduced the
> > issue. We will quickly fix it.
> >
> > Thierry
> >
> >
> >
> > On 12/6/06, Thierry Boileau <
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote:
> >
> > Hello Jeff,
> >
> > I don't reproduce the issue. I
> > copy/paste the demo code with port 80 in my Eclipse JDE and
> > can test the demo with no NPE.
> > I'm trying again without my Eclipse JDE.
> >
> > best regards,
> > Thierry
> >
> >
> >
> > On 12/6/06, Jeff Walter
> > <[EMAIL PROTECTED] > wrote:
> >
> > Jerome,
> >
> > I downloaded the latest and I'm
> > still having the problem.
> >
> > The issue can easily be
> > reproduced by running the demo at the end of the section 5 of
> > the tutorial, but instead of port 8182, use port 80. Any
> > request will produce the NPE. I also tried adding the code
> > below to the tutorial code as you suggested in your response:
> >
> >
> > container.getDefaultHost().setResourcePort("80");
> >
> > ...but to no avail.
> >
> > Regards,
> > Jeff
> >
> >
> >
> >
> >
> >
> >
>
Re: Bug in Reference.getHostPort() ?
Jeff,
actually :
- Jerome solved the issue but was unable to test.
- I only tested the solution given by Jerome,
- you may have missed the latest files in SVN
Best regards,
Thierry
Reddite Quae sunt Caesaris, Caesari ; et quae sunt Dei, Deo. [Render to
Caesar the things that are Caesar's; and to God, the things that are God's]
**
On 12/6/06, Jerome Louvel <[EMAIL PROTECTED]> wrote:
Cool, thanks for letting us know!
Thanks also to Thierry for helping with the tests.
Take care,
Jerome
> -Message d'origine-
> De : Jeff Walter [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 6 décembre 2006 22:38
> À : discuss@restlet.tigris.org
> Objet : Re: Bug in Reference.getHostPort() ?
>
> Thierry,
>
> The problem seems to be solved. Thanks for your effort.
>
> Love the project, keep up the great work.
>
> Regards,
> Jeff Walter
>
>
>
> On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>
> Hello Jeff,
>
> can you get the latest source code from SVN and tell us
> if it fixes the problem?
>
> Best regards,
> Thierry Boileau
>
>
>
> On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>
> Jeff,
>
> I've downloaded the beta21 and reproduced the
> issue. We will quickly fix it.
>
> Thierry
>
>
>
> On 12/6/06, Thierry Boileau <
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote:
>
> Hello Jeff,
>
> I don't reproduce the issue. I
> copy/paste the demo code with port 80 in my Eclipse JDE and
> can test the demo with no NPE.
> I'm trying again without my Eclipse JDE.
>
> best regards,
> Thierry
>
>
>
> On 12/6/06, Jeff Walter
> <[EMAIL PROTECTED] > wrote:
>
> Jerome,
>
> I downloaded the latest and I'm
> still having the problem.
>
> The issue can easily be
> reproduced by running the demo at the end of the section 5 of
> the tutorial, but instead of port 8182, use port 80. Any
> request will produce the NPE. I also tried adding the code
> below to the tutorial code as you suggested in your response:
>
>
> container.getDefaultHost().setResourcePort("80");
>
> ...but to no avail.
>
> Regards,
> Jeff
>
>
>
>
>
>
>
RE: Bug in Reference.getHostPort() ?
Cool, thanks for letting us know!
Thanks also to Thierry for helping with the tests.
Take care,
Jerome
> -Message d'origine-
> De : Jeff Walter [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 6 décembre 2006 22:38
> À : discuss@restlet.tigris.org
> Objet : Re: Bug in Reference.getHostPort() ?
>
> Thierry,
>
> The problem seems to be solved. Thanks for your effort.
>
> Love the project, keep up the great work.
>
> Regards,
> Jeff Walter
>
>
>
> On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>
> Hello Jeff,
>
> can you get the latest source code from SVN and tell us
> if it fixes the problem?
>
> Best regards,
> Thierry Boileau
>
>
>
> On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>
> Jeff,
>
> I've downloaded the beta21 and reproduced the
> issue. We will quickly fix it.
>
> Thierry
>
>
>
> On 12/6/06, Thierry Boileau <
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote:
>
> Hello Jeff,
>
> I don't reproduce the issue. I
> copy/paste the demo code with port 80 in my Eclipse JDE and
> can test the demo with no NPE.
> I'm trying again without my Eclipse JDE.
>
> best regards,
> Thierry
>
>
>
> On 12/6/06, Jeff Walter
> <[EMAIL PROTECTED] > wrote:
>
> Jerome,
>
> I downloaded the latest and I'm
> still having the problem.
>
> The issue can easily be
> reproduced by running the demo at the end of the section 5 of
> the tutorial, but instead of port 8182, use port 80. Any
> request will produce the NPE. I also tried adding the code
> below to the tutorial code as you suggested in your response:
>
>
> container.getDefaultHost().setResourcePort("80");
>
> ...but to no avail.
>
> Regards,
> Jeff
>
>
>
>
>
>
>
Re: Bug in Reference.getHostPort() ?
Thierry,
The problem seems to be solved. Thanks for your effort.
Love the project, keep up the great work.
Regards,
Jeff Walter
On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
Hello Jeff,
can you get the latest source code from SVN and tell us if it fixes the
problem?
Best regards,
Thierry Boileau
On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>
> Jeff,
>
> I've downloaded the beta21 and reproduced the issue. We will quickly fix
> it.
>
> Thierry
>
> On 12/6/06, Thierry Boileau < [EMAIL PROTECTED]> wrote:
> >
> > Hello Jeff,
> >
> > I don't reproduce the issue. I copy/paste the demo code with port 80
> > in my Eclipse JDE and can test the demo with no NPE.
> > I'm trying again without my Eclipse JDE.
> >
> > best regards,
> > Thierry
> >
> > On 12/6/06, Jeff Walter <[EMAIL PROTECTED] > wrote:
> > >
> > > Jerome,
> > >
> > > I downloaded the latest and I'm still having the problem.
> > >
> > > The issue can easily be reproduced by running the demo at the end of
> > > the section 5 of the tutorial, but instead of port 8182, use port 80. Any
> > > request will produce the NPE. I also tried adding the code below to the
> > > tutorial code as you suggested in your response:
> > >
> > > container.getDefaultHost().setResourcePort("80");
> > >
> > > ...but to no avail.
> > >
> > > Regards,
> > > Jeff
> > >
> >
> >
>
Re: Bug in Reference.getHostPort() ?
Hello Jeff,
can you get the latest source code from SVN and tell us if it fixes the
problem?
Best regards,
Thierry Boileau
On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
Jeff,
I've downloaded the beta21 and reproduced the issue. We will quickly fix
it.
Thierry
On 12/6/06, Thierry Boileau < [EMAIL PROTECTED]> wrote:
>
> Hello Jeff,
>
> I don't reproduce the issue. I copy/paste the demo code with port 80 in
> my Eclipse JDE and can test the demo with no NPE.
> I'm trying again without my Eclipse JDE.
>
> best regards,
> Thierry
>
> On 12/6/06, Jeff Walter <[EMAIL PROTECTED] > wrote:
> >
> > Jerome,
> >
> > I downloaded the latest and I'm still having the problem.
> >
> > The issue can easily be reproduced by running the demo at the end of
> > the section 5 of the tutorial, but instead of port 8182, use port 80. Any
> > request will produce the NPE. I also tried adding the code below to the
> > tutorial code as you suggested in your response:
> >
> > container.getDefaultHost().setResourcePort("80");
> >
> > ...but to no avail.
> >
> > Regards,
> > Jeff
> >
>
>
Re: Bug in Reference.getHostPort() ?
Jeff,
I've downloaded the beta21 and reproduced the issue. We will quickly fix it.
Thierry
On 12/6/06, Thierry Boileau <[EMAIL PROTECTED]> wrote:
Hello Jeff,
I don't reproduce the issue. I copy/paste the demo code with port 80 in my
Eclipse JDE and can test the demo with no NPE.
I'm trying again without my Eclipse JDE.
best regards,
Thierry
On 12/6/06, Jeff Walter <[EMAIL PROTECTED]> wrote:
>
> Jerome,
>
> I downloaded the latest and I'm still having the problem.
>
> The issue can easily be reproduced by running the demo at the end of the
> section 5 of the tutorial, but instead of port 8182, use port 80. Any
> request will produce the NPE. I also tried adding the code below to the
> tutorial code as you suggested in your response:
>
> container.getDefaultHost().setResourcePort("80");
>
> ...but to no avail.
>
> Regards,
> Jeff
>
Re: Bug in Reference.getHostPort() ?
Hello Jeff,
I don't reproduce the issue. I copy/paste the demo code with port 80 in my
Eclipse JDE and can test the demo with no NPE.
I'm trying again without my Eclipse JDE.
best regards,
Thierry
On 12/6/06, Jeff Walter <[EMAIL PROTECTED]> wrote:
Jerome,
I downloaded the latest and I'm still having the problem.
The issue can easily be reproduced by running the demo at the end of the
section 5 of the tutorial, but instead of port 8182, use port 80. Any
request will produce the NPE. I also tried adding the code below to the
tutorial code as you suggested in your response:
container.getDefaultHost().setResourcePort("80");
...but to no avail.
Regards,
Jeff
RE: Bug in Reference.getHostPort() ?
Jerome,
I downloaded the latest and I'm still having the problem.
The issue can easily be reproduced by running the demo at the end of the
section 5 of the tutorial, but instead of port 8182, use port 80. Any
request will produce the NPE. I also tried adding the code below to the
tutorial code as you suggested in your response:
container.getDefaultHost().setResourcePort("80");
...but to no avail.
Regards,
Jeff
RE: Bug in Reference.getHostPort() ?
Hi Jeff, I've just attempted to fix the issue in SVN. I'm not able to test it right now. Could you let me know if this solves your issue? Note that you need to set the default port (80) in the VirtualHost.resourcePort property. Best regards, Jerome > -Message d'origine- > De : Jeff Walter [mailto:[EMAIL PROTECTED] > Envoyé : mardi 5 décembre 2006 20:48 > À : discuss@restlet.tigris.org > Objet : Bug in Reference.getHostPort() ? > > Hey Jerome, > > Working with Restlet on localhost:8080 works great -- but I > recently deployed an app onto a server running on port 80 and > got a NullPointerException in > com.noelios.restlet.container.HostScorer:89. Seems that it > does a toString() on what's returned from > request.getBaseRef().getHostPort(), which is null if you > don't have an explicit port (runs on 80). > > I'm running an SVN version of 1.0rc1 released on Nov. 29 > > Regards, > Jeff Walter > >
RE: Bug in TemplateRepresentation?
Quoting Jerome Louvel <[EMAIL PROTECTED]>: > > Hi AJ, I suggest that you take a second look at your Stax > representation to > see if there isn't other (hidden?) close attempts on the stream. If you > have > a sample code, I'll be happy to help testing it. > > Best regards, > Jerome > Thanks Jerome, Hidden is probably the right word. I'm using StaxMate, and it appears like it may be closing the Stream itself when you tell it that you have finished making the document; though you have to tell it you have finished so that it writes all the closing tags. I'll have to modify a test so that it doesn't use StaxMate (i.e. plain StAX). AJ
RE: Bug in TemplateRepresentation?
Hi Zohar, I've just tested this issue. Without the fix to TemplateRepresentation (removing the extra close() method call), I do get the Simple exception at each request. With the fix, everything works perfectly. Hi AJ, I suggest that you take a second look at your Stax representation to see if there isn't other (hidden?) close attempts on the stream. If you have a sample code, I'll be happy to help testing it. Best regards, Jerome > -Message d'origine- > De : A.J. Barnes [mailto:[EMAIL PROTECTED] > Envoyé : samedi 21 octobre 2006 19:25 > À : discuss@restlet.tigris.org > Objet : RE: Bug in TemplateRepresentation? > > The issue I'm having with Simple continues with the latest > release. Of > interest, it seems to be when I'm pulling the informaion from > the server > using IE that I'm getting the expection - if pulling it off > the server > with my own code (using the restlet client there is not a problem). I > remove the Staxmate statement that closes the stream, but I'm > stilling > getting the same problem. > > Here's the stack trace if its any help. > > 22/10/2006 06:19:10 com.noelios.restlet.impl.http.HttpServerConverter > commit > INFO: Exception intercepted > java.io.IOException: Stream closed > at simple.http.ResponseStream.ensureOpen(Unknown Source) > at simple.http.ResponseStream.flushBuffer(Unknown Source) > at simple.http.ResponseStream.flush(Unknown Source) > at > com.noelios.restlet.impl.http.HttpServerCall.sendResponse(Http > ServerCall.java:228) > at > com.noelios.restlet.ext.simple.SimpleCall.sendResponse(SimpleC > all.java:164) > at > com.noelios.restlet.impl.http.HttpServerConverter.commit(HttpS > erverConverter.java:84) > at > com.noelios.restlet.impl.http.HttpServerHelper.handle(HttpServ > erHelper.java:79) > at > com.noelios.restlet.ext.simple.SimpleServerHelper.handle(Simpl > eServerHelper.java:122) > at simple.http.Dispatcher.run(Unknown Source) > at simple.util.process.Daemon.execute(Unknown Source) > at simple.util.process.Daemon.run(Unknown Source) > > AJ > > Quoting Jerome Louvel <[EMAIL PROTECTED]>: > > > > > Hi all, > > > > I've solved it by removing the first "close". The fix will > be part of > > the > > next beta 19 snapshot due today. > > > > Zohar, AJ, could you test this fix and let me know if it > work fine with > > STaX > > and FreeMarker? > > > >
RE: Bug in TemplateRepresentation?
The issue I'm having with Simple continues with the latest release. Of interest, it seems to be when I'm pulling the informaion from the server using IE that I'm getting the expection - if pulling it off the server with my own code (using the restlet client there is not a problem). I remove the Staxmate statement that closes the stream, but I'm stilling getting the same problem. Here's the stack trace if its any help. 22/10/2006 06:19:10 com.noelios.restlet.impl.http.HttpServerConverter commit INFO: Exception intercepted java.io.IOException: Stream closed at simple.http.ResponseStream.ensureOpen(Unknown Source) at simple.http.ResponseStream.flushBuffer(Unknown Source) at simple.http.ResponseStream.flush(Unknown Source) at com.noelios.restlet.impl.http.HttpServerCall.sendResponse(HttpServerCall.java:228) at com.noelios.restlet.ext.simple.SimpleCall.sendResponse(SimpleCall.java:164) at com.noelios.restlet.impl.http.HttpServerConverter.commit(HttpServerConverter.java:84) at com.noelios.restlet.impl.http.HttpServerHelper.handle(HttpServerHelper.java:79) at com.noelios.restlet.ext.simple.SimpleServerHelper.handle(SimpleServerHelper.java:122) at simple.http.Dispatcher.run(Unknown Source) at simple.util.process.Daemon.execute(Unknown Source) at simple.util.process.Daemon.run(Unknown Source) AJ Quoting Jerome Louvel <[EMAIL PROTECTED]>: > > Hi all, > > I've solved it by removing the first "close". The fix will be part of > the > next beta 19 snapshot due today. > > Zohar, AJ, could you test this fix and let me know if it work fine with > STaX > and FreeMarker? >
RE: Bug in TemplateRepresentation?
Hi all, Thanks Zohar for reporting this issue. Looking at the code, it seems that we are closing the output stream too early in the FreemarkerRepresentation, causing Simple to fail when it's trying to also close the stream. I think I've solved it by removing the first "close". The fix will be part of the next beta 19 snapshot due today. Zohar, AJ, could you test this fix and let me know if it work fine with STaX and FreeMarker? Best regards, Jerome > -Message d'origine- > De : A.J. Barnes [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 20 octobre 2006 00:37 > À : discuss@restlet.tigris.org > Objet : Re: Bug in TemplateRepresentation? > > Hi, > > This only seems to happen with Simple - either of the Jetty > servers seem > fine - just thought it was my bad code. Note that its not just > TemplateRepresentations either, I've rolled my own STaX (Woodstox) > representation and this fell over with Simple. > > AJ > > Quoting Zohar Melamed <[EMAIL PROTECTED]>: > > > Hi > > I have a simple app with a single restlet using the > > TemplateRepresentation. > > On every request I get : > > INFO: Error while handling an HTTP server call > > java.io.IOException: Stream closed > > at simple.http.ResponseStream.ensureOpen(Unknown Source) > > at simple.http.ResponseStream.flushBuffer(Unknown Source) > > at simple.http.ResponseStream.flush(Unknown Source) > > at > > com.noelios.restlet.connector.AbstractHttpServerCall. > > sendResponseOutput(AbstractHttpServerCall.java:268) > > at > > com.noelios.restlet.connector. > > AbstractHttpServer.handle(AbstractHttpServer.java:131) > > at > > com.noelios.restlet.connector.AbstractHttpServer. > > handle(AbstractHttpServer.java:106) > > ... > > ... > > .. > > > > Looking at the code , I suspect the TemplateRepresentation > class closes > > the > > connection, and AbstractHttpServerCall then tries to flush it... > > > > any thoughts? > > > > Cheers > > Zohar > > > > > > > -- > A.J. Barnes, B.Sc., B.N. > Poisons Information Officer > National Poisons Centre / Te Kaunuku Paitini O Aotearoa > > Ph: +64 3 479 7250 > Fax: +64 3 477 0509 > > === > > CAUTION: This e-mail message may contain information that is > confidential > and subject to privilege. It is intended solely for the addressee. If > you > are not the intended recipient, you are notified that any use, > distribution > or copying of this message or data is prohibited. If you > received this > e-mail in error, please notify me immediately and delete all material > pertaining to this e-mail. Thank you. > >
Re: Bug in TemplateRepresentation?
Hi, This only seems to happen with Simple - either of the Jetty servers seem fine - just thought it was my bad code. Note that its not just TemplateRepresentations either, I've rolled my own STaX (Woodstox) representation and this fell over with Simple. AJ Quoting Zohar Melamed <[EMAIL PROTECTED]>: > Hi > I have a simple app with a single restlet using the > TemplateRepresentation. > On every request I get : > INFO: Error while handling an HTTP server call > java.io.IOException: Stream closed > at simple.http.ResponseStream.ensureOpen(Unknown Source) > at simple.http.ResponseStream.flushBuffer(Unknown Source) > at simple.http.ResponseStream.flush(Unknown Source) > at > com.noelios.restlet.connector.AbstractHttpServerCall. > sendResponseOutput(AbstractHttpServerCall.java:268) > at > com.noelios.restlet.connector. > AbstractHttpServer.handle(AbstractHttpServer.java:131) > at > com.noelios.restlet.connector.AbstractHttpServer. > handle(AbstractHttpServer.java:106) > ... > ... > .. > > Looking at the code , I suspect the TemplateRepresentation class closes > the > connection, and AbstractHttpServerCall then tries to flush it... > > any thoughts? > > Cheers > Zohar > > -- A.J. Barnes, B.Sc., B.N. Poisons Information Officer National Poisons Centre / Te Kaunuku Paitini O Aotearoa Ph: +64 3 479 7250 Fax: +64 3 477 0509 === CAUTION: This e-mail message may contain information that is confidential and subject to privilege. It is intended solely for the addressee. If you are not the intended recipient, you are notified that any use, distribution or copying of this message or data is prohibited. If you received this e-mail in error, please notify me immediately and delete all material pertaining to this e-mail. Thank you.
