Re: bug with SpringFinder?

2013-11-15 Thread Thierry Boileau
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?

2013-11-15 Thread 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=3068571

Re: bug with SpringFinder?

2013-11-15 Thread Thierry Boileau
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?

2011-08-12 Thread Thierry Boileau
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?

2011-08-11 Thread Glenn Bruns
> 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

2011-04-24 Thread Andrei Pozolotin
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

2011-03-17 Thread Andrei Pozolotin
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

2011-03-17 Thread Andrei Pozolotin
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?

2010-06-19 Thread Thierry Boileau
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

2010-06-06 Thread Jerome Louvel
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?

2010-06-06 Thread Jerome Louvel
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. I’ve 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?

2010-05-18 Thread Daniel Ferber
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?

2010-05-12 Thread Tim Peierls
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?

2010-05-11 Thread David Fogel
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?

2010-05-11 Thread Tim Peierls
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

2010-02-21 Thread Jerome Louvel
Hi guys,

 

After double checking, there was a bug. Parameters are actually part of the
media type name, so toString() shouldn’t add those parameters again.

 

I’ve 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?

2010-02-11 Thread Thierry Boileau
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

2010-01-25 Thread Thierry Boileau
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

2009-12-08 Thread Ben R Vesco
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

2009-12-08 Thread Thierry Boileau
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

2009-12-08 Thread Ben R Vesco
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

2009-12-07 Thread Thierry Boileau
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()

2009-12-02 Thread Jerome Louvel
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

2009-08-17 Thread Jerome Louvel
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?

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

--  
-a

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

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

> Hi Schley,
>
> For Maven refresh policy, please check:
> http://www.restlet.org/downloads/maven
>
> For Restlet 2.0 M4, I'd like to push it out by the end of the month.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : vendredi 10 juillet 2009 20:41
> À : discuss@restlet.tigris.org
> Objet : Re: bug?
>
> Jerome,
>
> Do you know when this will make it into the Maven snapshot? Thanks!
>
> --  
> -a
>
> "Ideally, a code library must be immediately usable by naive
> developers, easily customized by more sophisticated developers, and
> readily extensible by experts." -- L. Stein
>
> On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote:
>
>> Actually, I've just renamed the method to "doCatch" as the "error"
>> term was ambiguous regarding Java terminology (ie. errors vs
>> exceptions). Same logic.
>>
>> Best regards,
>> Jerome Louvel
>> --
>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>>
>>
>>
>> -Message d'origine-
>> De : Schley Andrew Kutz [mailto:sak...@gmail.com]
>> Envoyé : dimanche 5 juillet 2009 15:45
>> À : discuss@restlet.tigris.org
>> Objet : Re: bug?
>>
>> Great! I'm really looking forward to this and the OnError bit making
>> it into a release. :)
>>
>> -- 
>> -a
>>
>> "Ideally, a code library must be immediately usable by naive
>> developers, easily customized by more sophisticated developers, and
>> readily extensible by experts." -- L. Stein
>>
>> On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote:
>>
>>> Hi Schley,
>>>
>>> FYI, this has been fixed in SVN trunk.
>>>
>>> Best regards,
>>> Jerome Louvel
>>> --
>>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
>>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>>>
>>>
>>> Schley Andrew Kutz a écrit :
>>>> I want to prevent the use of HTTP VERB annotations in order to  
>>>> force
>>>> sub-classes to respond with specific class types via abstract
>>>> methods
>>>> that I prototype in a base class. I marked the isAnnotated() method
>>>> as
>>>> @Override and final and returned false. However, when it returns
>>>> false
>>>> I get the following error:
>>>>
>>>> java.lang.NullPointerException
>>>>at
>>>> org
>>>> .restlet
>>>> .engine 
>>>> .resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:
>>>> 106)
>>>>at
>>>> org
>>>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
>>>> 649)
>>>>at
>>>> org.restlet.resource.ServerResource.doHandle(ServerResource.java:
>>>> 329)
>>>>at
>>>> org
>>>> .restlet
>>>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java: 
>>>> 592)
>>>>at
>>>> org
>>>> .restlet
>>>> .resource.ServerResource.doConditionalHandle(ServerResource.java:
>>>> 260)
>>>>at org.restlet.resource.ServerResource.handle(ServerResource.java:
>>>> 921)
>>>>at
>>>> com
>>>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
>>>> 159)
>>>>at org.restlet.resource.Finder.handle(Finder.java:510)
>>>>at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>>>at org.restlet.routing.Filter.handle(Filter.java:201)
>>>>at org.restlet.routing.Router.handle(Router.java:490)
>>>>at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>>>at org.restlet.routing.Filter.handle(Filter.java:201)
>>>>at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>>>at org.restlet.routing.Filter.handle(Filter.java:201)
>>>>at org.restlet

RE: bug?

2009-07-15 Thread Jerome Louvel
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?

2009-07-10 Thread Schley Andrew Kutz
Jerome,

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

--  
-a

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

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

> Actually, I've just renamed the method to "doCatch" as the "error"  
> term was ambiguous regarding Java terminology (ie. errors vs  
> exceptions). Same logic.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
> -Message d'origine-
> De : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : dimanche 5 juillet 2009 15:45
> À : discuss@restlet.tigris.org
> Objet : Re: bug?
>
> Great! I'm really looking forward to this and the OnError bit making
> it into a release. :)
>
> -- 
> -a
>
> "Ideally, a code library must be immediately usable by naive
> developers, easily customized by more sophisticated developers, and
> readily extensible by experts." -- L. Stein
>
> On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote:
>
>> Hi Schley,
>>
>> FYI, this has been fixed in SVN trunk.
>>
>> Best regards,
>> Jerome Louvel
>> --
>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>>
>>
>> Schley Andrew Kutz a écrit :
>>> I want to prevent the use of HTTP VERB annotations in order to force
>>> sub-classes to respond with specific class types via abstract  
>>> methods
>>> that I prototype in a base class. I marked the isAnnotated() method
>>> as
>>> @Override and final and returned false. However, when it returns
>>> false
>>> I get the following error:
>>>
>>> java.lang.NullPointerException
>>> at
>>> org
>>> .restlet
>>> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:
>>> 106)
>>> at
>>> org
>>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
>>> 649)
>>> at  
>>> org.restlet.resource.ServerResource.doHandle(ServerResource.java:
>>> 329)
>>> at
>>> org
>>> .restlet
>>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
>>> at
>>> org
>>> .restlet
>>> .resource.ServerResource.doConditionalHandle(ServerResource.java: 
>>> 260)
>>> at org.restlet.resource.ServerResource.handle(ServerResource.java:
>>> 921)
>>> at
>>> com 
>>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
>>> 159)
>>> at org.restlet.resource.Finder.handle(Finder.java:510)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Router.handle(Router.java:490)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at
>>> org
>>> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:
>>> 153)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
>>> at
>>> org
>>> .restlet
>>> .engine.application.ApplicationHelper.handle(ApplicationHelper.java:
>>> 71)
>>> at org.restlet.Application.handle(Application.java:396)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Router.handle(Router.java:490)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.routing.Router.handle(Router.java:490)
>>> at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>> at org.restlet.routing.Filter.handle(Filter.java:201)
>>> at org.restlet.engine.

RE: bug?

2009-07-07 Thread Jerome Louvel
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?

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

-- 
-a

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

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

> Hi Schley,
>
> FYI, this has been fixed in SVN trunk.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> Schley Andrew Kutz a écrit :
>> I want to prevent the use of HTTP VERB annotations in order to force
>> sub-classes to respond with specific class types via abstract methods
>> that I prototype in a base class. I marked the isAnnotated() method  
>> as
>> @Override and final and returned false. However, when it returns  
>> false
>> I get the following error:
>>
>> java.lang.NullPointerException
>>  at
>> org
>> .restlet
>> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: 
>> 106)
>>  at
>> org 
>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
>> 649)
>>  at org.restlet.resource.ServerResource.doHandle(ServerResource.java:
>> 329)
>>  at
>> org
>> .restlet
>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
>>  at
>> org
>> .restlet
>> .resource.ServerResource.doConditionalHandle(ServerResource.java:260)
>>  at org.restlet.resource.ServerResource.handle(ServerResource.java: 
>> 921)
>>  at
>> com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
>> 159)
>>  at org.restlet.resource.Finder.handle(Finder.java:510)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Router.handle(Router.java:490)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at
>> org 
>> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:
>> 153)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
>>  at
>> org
>> .restlet
>> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: 
>> 71)
>>  at org.restlet.Application.handle(Application.java:396)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Router.handle(Router.java:490)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.routing.Router.handle(Router.java:490)
>>  at org.restlet.routing.Filter.doHandle(Filter.java:156)
>>  at org.restlet.routing.Filter.handle(Filter.java:201)
>>  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
>>  at org.restlet.Component.handle(Component.java:397)
>>  at org.restlet.Server.handle(Server.java:350)
>>  at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
>>  at
>> org 
>> .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:
>> 149)
>>  at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:
>> 932)
>>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>  at  
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
>> 487)
>>  at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 
>> 362)
>>  at
>> org 
>> .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
>> 216)
>>  at
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 
>> 181)
>>  at
>> org 
>> .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
>> 216)
>>  at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 
>> 729)
>>  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
>> 405)
>>  at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
>> 152)
>>  at
>> org
>> .mortbay 
>> .jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:
>> 49)
>>  at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
>> 152)
>>  at org.mortbay.jetty.Server.handle(Server.java:324)
>>  at  
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
>> 505)
>>  at org.mortbay.jetty.HttpConnection
>> $RequestHandler.headerComplete(HttpConnection.java:829)
>>  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.j

Re: bug?

2009-07-05 Thread Jerome Louvel
Hi Schley,

FYI, this has been fixed in SVN trunk.

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


Schley Andrew Kutz a écrit :
> I want to prevent the use of HTTP VERB annotations in order to force  
> sub-classes to respond with specific class types via abstract methods  
> that I prototype in a base class. I marked the isAnnotated() method as  
> @Override and final and returned false. However, when it returns false  
> I get the following error:
> 
> java.lang.NullPointerException
>   at  
> org 
> .restlet 
> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106)
>   at  
> org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 
> 649)
>   at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 
> 329)
>   at  
> org 
> .restlet 
> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
>   at  
> org 
> .restlet 
> .resource.ServerResource.doConditionalHandle(ServerResource.java:260)
>   at org.restlet.resource.ServerResource.handle(ServerResource.java:921)
>   at  
> com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 
> 159)
>   at org.restlet.resource.Finder.handle(Finder.java:510)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Router.handle(Router.java:490)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at  
> org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 
> 153)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
>   at  
> org 
> .restlet 
> .engine.application.ApplicationHelper.handle(ApplicationHelper.java:71)
>   at org.restlet.Application.handle(Application.java:396)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Router.handle(Router.java:490)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.routing.Router.handle(Router.java:490)
>   at org.restlet.routing.Filter.doHandle(Filter.java:156)
>   at org.restlet.routing.Filter.handle(Filter.java:201)
>   at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
>   at org.restlet.Component.handle(Component.java:397)
>   at org.restlet.Server.handle(Server.java:350)
>   at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
>   at  
> org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 
> 149)
>   at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 
> 932)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>   at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 
> 487)
>   at  
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
>   at  
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
> 216)
>   at  
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>   at  
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
> 216)
>   at  
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 
> 405)
>   at  
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at  
> org 
> .mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 
> 49)
>   at  
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:324)
>   at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 
> 505)
>   at org.mortbay.jetty.HttpConnection 
> $RequestHandler.headerComplete(HttpConnection.java:829)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>   at  
> org 
> .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 
> 395)
>   at org.mortbay.thread.QueuedThreadPool 
> $PoolThread.run(QueuedThreadPool.java:488)

--
http://restl

RE: bug?

2009-06-30 Thread Jerome Louvel
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

2009-04-30 Thread Zsolt Kovacs
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

2009-04-30 Thread 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/> 
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

2009-04-30 Thread Zsolt Kovacs
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

2009-04-29 Thread 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)
> > 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

2009-04-29 Thread Zsolt Kovacs
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

2009-04-28 Thread 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


Re: bug? - AccessControlException on Restlet GAE module

2009-04-27 Thread Zsolt Kovacs
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

2009-04-25 Thread 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/>
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

2009-04-19 Thread MattyJ
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

2009-04-18 Thread keke
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

2009-04-15 Thread Jerome Louvel
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

2008-11-17 Thread Rob Heittman
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

2008-11-17 Thread Richard Hoberman
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

2008-11-17 Thread Rob Heittman
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).

2008-11-10 Thread Jerome Louvel

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

2008-04-15 Thread Steve Loughran
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

2008-04-15 Thread Jerome Louvel

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

2008-04-15 Thread Stephan Koops
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

2008-04-15 Thread Jerome Louvel

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

2008-04-15 Thread Thierry Boileau

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

2008-04-15 Thread Stephan Koops

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

2008-04-14 Thread Jerome Louvel

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

2008-04-02 Thread Michael Böckling
> 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

2008-04-01 Thread Rhett Sutphin

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?

2007-10-31 Thread Thierry Boileau

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

2007-09-24 Thread Jerome Louvel

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

2007-09-23 Thread Rob Heittman

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

2007-09-23 Thread Jerome Louvel

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

2007-09-19 Thread Joel Nelson
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

2007-09-19 Thread Joel Nelson
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

2007-09-19 Thread Marc Portier



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

2007-09-19 Thread Rob Heittman

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

2007-09-19 Thread Marc Portier



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

2007-09-18 Thread Rob Heittman

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

2007-09-18 Thread Jerome Louvel

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

2007-09-18 Thread Rob Heittman

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

2007-09-17 Thread Joel Nelson
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

2007-09-17 Thread Rob Heittman
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

2007-04-06 Thread Thierry Boileau

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

2007-04-05 Thread Alex Combs
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

2007-04-03 Thread Thierry Boileau

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

2007-03-16 Thread Thierry Boileau

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

2007-03-15 Thread Sean Landis
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

2007-03-14 Thread Thierry Boileau

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

2007-03-13 Thread J. Matthew Pryor

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

2007-03-13 Thread Sean Landis
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

2007-03-02 Thread Jerome Louvel

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

2007-01-02 Thread Thierry Boileau

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

2006-12-29 Thread Jerome Louvel

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() ?

2006-12-06 Thread Jeff Walter

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() ?

2006-12-06 Thread Thierry Boileau

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() ?

2006-12-06 Thread Jerome Louvel
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() ?

2006-12-06 Thread Jeff Walter

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() ?

2006-12-06 Thread Thierry Boileau

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() ?

2006-12-06 Thread Thierry Boileau

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() ?

2006-12-06 Thread Thierry Boileau

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() ?

2006-12-06 Thread Jeff Walter

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() ?

2006-12-05 Thread Jerome Louvel

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?

2006-10-23 Thread A.J. Barnes
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?

2006-10-23 Thread Jerome Louvel

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?

2006-10-21 Thread A.J. Barnes
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?

2006-10-21 Thread Jerome Louvel

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?

2006-10-19 Thread A.J. Barnes
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.