bug with SpringFinder?

2013-11-15 Thread 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 id=router1 class=org.restlet.ext.spring.SpringRouter
 property name=attachments
 map
 entry key=/metadata !-- GET --
  bean class=org.restlet.ext.spring.SpringFinder
  lookup-method name=create 
bean=metadataResource /
  /bean
  /entry
 ...
 /bean

 bean id=metadataResource class=...Metadata1Resource 
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=4447dsMessageId=3068568

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 s...@clixtec.ca

  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 id=router1 class=org.restlet.ext.spring.SpringRouter
 property name=attachments
 map
 entry key=/metadata!-- GET --
  bean class=org.restlet.ext.spring.SpringFinder
  lookup-method name=create
 bean=metadataResource /
  /bean
  /entry
 ...
 /bean

 bean id=metadataResource class=...Metadata1Resource
 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=4447dsMessageId=3068569

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 id=router1 class=org.restlet.ext.spring.SpringRouter
 property name=attachments
 map
 entry key=/metadata !-- GET --
  bean class=org.restlet.ext.spring.SpringFinder
  lookup-method name=create 
 bean=metadataResource /
  /bean
  /entry
 ...
 /bean

 bean id=metadataResource class=...Metadata1Resource 
 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=4447dsMessageId=3068571

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 s...@clixtec.ca

  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 id=router1 class=org.restlet.ext.spring.SpringRouter
 property name=attachments
 map
 entry key=/metadata!-- GET --
  bean class=org.restlet.ext.spring.SpringFinder
  lookup-method name=create
 bean=metadataResource /
  /bean
  /entry
 ...
 /bean

 bean id=metadataResource class=...Metadata1Resource
 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=4447dsMessageId=3068572

Re: Potential Namespace Bug in SaxRepresentation??

2012-04-06 Thread Thierry Boileau
Hello Nicholas,

thanks a lot for pointing this bug. I've updated the
XmlWriter#writeAttributes method. It takes care of the declaration of the
namespace.
I've updated the 2.0 and 2.1 branches, and the 2.2 master.

Best regards,
Thierry Boileau

Look at this further. It seems the problem may be in XMLWriter
 specifically in writeAttributes.

 It will only not write the attribute it if relates to a default
 namespace. Qualified namspaces will be written out
 no matter what.

 Does anyone have any ideas for a work around?

 Thanks a lot,
 Regards,
 Nicholas

 For reference:

 private void writeAttributes(Attributes atts) throws SAXException {
final int len = atts.getLength();
for (int i = 0; i  len; i++) {
if (!xmlns.equals(atts.getQName(i))) {
final char ch[] = atts.getValue(i).toCharArray();
write(' ');
writeName(atts.getURI(i), atts.getLocalName(i),
atts.getQName(i), false);
write(=\);
writeEsc(ch, 0, ch.length, true);
write('');
} else {
// Redefines the default namespace.
forceNSDecl(atts.getValue(i));
 }
}
}






 On Tue, Apr 3, 2012 at 3:28 PM, Nicholas Waltham nw...@log1.net wrote:
  Hi All,
   I have produced some simplified code to demonstrate what appears to
  be a bug. However I would like to check with the list before I file a
  report.
 
  If I have the following code:
 
 
  String uri = LocalReference.createClapReference(getClass().getPackage())
  + /xmlwns.xml;
  Representation listVtl = new ClientResource(uri).get();
  SaxRepresentation r = new SaxRepresentation(listVtl);
  log.debug(r.getText());
 
  I observe the following behavior:
 
  inputfile xmlwns.xml
 
  a xmlns=uri:a xmlns:b=uri:b  
   b:content/
  /a
 
  gives as output to the logger:
 
  a xmlns:b=uri:b xmlns=uri:a
   b:content xmlns:b=uri:b/b:content
  /a
 
  which is a little more verbose, but technically correct.
 
  While with inputfile xmlwns.xml
 
  a:doc xmlns:a=uri:a xmlns:b=uri:b 
   b:content/
  /a:doc
 
  gives as output to the logger:
 
  a:doc xmlns:a=uri:a xmlns:b=uri:b xmlns:a=uri:a
   b:content xmlns:b=uri:b/b:content
  /a:doc
 
  you will see that the namspace definition for xmlns:a is duplicated,
  which gives an error on some XML readers. For example Google Chrome
  will complain about a redefinition of the namespace.
 
  Whats your view on this? Is this a bug in Restlet?
 
  Thanks a lot,
  Regards,
  Nicholas

 --

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


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

Re: Bad Request exception bug

2012-04-06 Thread Thierry Boileau
it looks like the response contains a www-authenticate header that we
don't handle at this moment:
I mean : the value of the header is not supported, as it seems it does not
comply with RFC rules.

Best regards,
Thierry Boileau

Hello Mutaz,

 it looks like the response contains a www-authenticate header that we
 don't handle at this moment:
 WWW-Authenticate: OAuth Facebook Platform invalid_token Invalid OAuth
 access token.

 The specification of oauth (http://oauth.net/core/1.0/#rfc.section.5.4)
 indicates that:
 This section defines an [RFC2617] 
 http://oauth.net/core/1.0/#RFC2617extension to support OAuth. It uses the 
 standard HTTP
 Authorization and WWW-Authenticate headers to pass OAuth Protocol
 Parameters.
 According to the RFC 2617, the WWW-authenticate looks like:

   auth-scheme= token
   auth-param = token = ( token | quoted-string )
   challenge   = auth-scheme 1*SP 1#auth-param
   WWW-Authenticate  = WWW-Authenticate : 1#challenge


 I'm not convinced the header value follows this rule. But, it seems that
 the interpretation is quite restrictive, we may relax the parsing logic in
 order to not stop the process.

 Best regards,
 Thierry Boileau




 I have the following code


String openGraphUri = https://graph.facebook.com/;;
String accessToken = gerkjh43kj5h43kjh34k;
ClientResource clientResource = new
 ClientResource(openGraphUri + me/feed + ?access_token= + accessToken);
Form form = new Form();
form.add(message, test message);
Representation resp = clientResource.post(form);

 When I run it I get the below exception. You can try the code without any
 change because the access token provided above is invalid so the code will
 throw the same exception (Bad Request 400)




 java.io.IOException: Parameter or extension has no name. Please check your
 value
at

 org.restlet.engine.http.header.HeaderReader.readParameter(HeaderReader.java:425)
at

 org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:128)
at

 org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:46)
at

 org.restlet.engine.http.header.HeaderReader.addValues(HeaderReader.java:243)
at

 org.restlet.engine.http.header.HeaderReader.readValues(HeaderReader.java:605)
at

 org.restlet.engine.security.AuthenticatorUtils.parseRequest(AuthenticatorUtils.java:378)
at

 org.restlet.engine.http.header.HeaderUtils.copyResponseTransportHeaders(HeaderUtils.java:814)
at

 org.restlet.engine.http.connector.ClientConnection.copyResponseTransportHeaders(ClientConnection.java:152)
at

 org.restlet.engine.http.connector.ClientConnection.readMessage(ClientConnection.java:269)
at

 org.restlet.engine.http.connector.Connection.readMessages(Connection.java:673)
at
 org.restlet.engine.http.connector.Controller$2.run(Controller.java:95)
at

 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
 Exception in thread main Bad Request (400) - Bad Request
at
 org.restlet.resource.ClientResource.handle(ClientResource.java:867)
at
 org.restlet.resource.ClientResource.post(ClientResource.java:1206)
at
 org.restlet.resource.ClientResource.post(ClientResource.java:1152)
at
 com.zeedna.applications.social.facebook.resources.Test.main(Test.java:21)


 Thank you
 Mutaz

 --
 View this message in context:
 http://restlet-discuss.1400322.n2.nabble.com/Bad-Request-exception-bug-tp7431921p7431921.html
 Sent from the Restlet Discuss mailing list archive at Nabble.com.

 --

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




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

Re: Potential Namespace Bug in SaxRepresentation??

2012-04-04 Thread Nicholas Waltham
Look at this further. It seems the problem may be in XMLWriter
specifically in writeAttributes.

It will only not write the attribute it if relates to a default
namespace. Qualified namspaces will be written out
no matter what.

Does anyone have any ideas for a work around?

Thanks a lot,
Regards,
Nicholas

For reference:

private void writeAttributes(Attributes atts) throws SAXException {
final int len = atts.getLength();
for (int i = 0; i  len; i++) {
if (!xmlns.equals(atts.getQName(i))) {
final char ch[] = atts.getValue(i).toCharArray();
write(' ');
writeName(atts.getURI(i), atts.getLocalName(i),
atts.getQName(i), false);
write(=\);
writeEsc(ch, 0, ch.length, true);
write('');
} else {
// Redefines the default namespace.
forceNSDecl(atts.getValue(i));
}
}
}






On Tue, Apr 3, 2012 at 3:28 PM, Nicholas Waltham nw...@log1.net wrote:
 Hi All,
  I have produced some simplified code to demonstrate what appears to
 be a bug. However I would like to check with the list before I file a
 report.

 If I have the following code:


 String uri = LocalReference.createClapReference(getClass().getPackage())
 + /xmlwns.xml;
 Representation listVtl = new ClientResource(uri).get();
 SaxRepresentation r = new SaxRepresentation(listVtl);
 log.debug(r.getText());

 I observe the following behavior:

 inputfile xmlwns.xml

 a xmlns=uri:a xmlns:b=uri:b  
  b:content/
 /a

 gives as output to the logger:

 a xmlns:b=uri:b xmlns=uri:a
  b:content xmlns:b=uri:b/b:content
 /a

 which is a little more verbose, but technically correct.

 While with inputfile xmlwns.xml

 a:doc xmlns:a=uri:a xmlns:b=uri:b 
  b:content/
 /a:doc

 gives as output to the logger:

 a:doc xmlns:a=uri:a xmlns:b=uri:b xmlns:a=uri:a
  b:content xmlns:b=uri:b/b:content
 /a:doc

 you will see that the namspace definition for xmlns:a is duplicated,
 which gives an error on some XML readers. For example Google Chrome
 will complain about a redefinition of the namespace.

 Whats your view on this? Is this a bug in Restlet?

 Thanks a lot,
 Regards,
 Nicholas

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


Re: Bad Request exception bug

2012-04-04 Thread Thierry Boileau
Hello Mutaz,

it looks like the response contains a www-authenticate header that we don't
handle at this moment:
WWW-Authenticate: OAuth Facebook Platform invalid_token Invalid OAuth
access token.

The specification of oauth (http://oauth.net/core/1.0/#rfc.section.5.4)
indicates that:
This section defines an [RFC2617]
http://oauth.net/core/1.0/#RFC2617extension to support OAuth. It
uses the standard HTTP
Authorization and WWW-Authenticate headers to pass OAuth Protocol
Parameters.
According to the RFC 2617, the WWW-authenticate looks like:

  auth-scheme= token
  auth-param = token = ( token | quoted-string )
  challenge   = auth-scheme 1*SP 1#auth-param
  WWW-Authenticate  = WWW-Authenticate : 1#challenge


I'm not convinced the header value follows this rule. But, it seems that
the interpretation is quite restrictive, we may relax the parsing logic in
order to not stop the process.

Best regards,
Thierry Boileau



I have the following code


String openGraphUri = https://graph.facebook.com/;;
String accessToken = gerkjh43kj5h43kjh34k;
ClientResource clientResource = new
 ClientResource(openGraphUri + me/feed + ?access_token= + accessToken);
Form form = new Form();
form.add(message, test message);
Representation resp = clientResource.post(form);

 When I run it I get the below exception. You can try the code without any
 change because the access token provided above is invalid so the code will
 throw the same exception (Bad Request 400)




 java.io.IOException: Parameter or extension has no name. Please check your
 value
at

 org.restlet.engine.http.header.HeaderReader.readParameter(HeaderReader.java:425)
at

 org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:128)
at

 org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:46)
at

 org.restlet.engine.http.header.HeaderReader.addValues(HeaderReader.java:243)
at

 org.restlet.engine.http.header.HeaderReader.readValues(HeaderReader.java:605)
at

 org.restlet.engine.security.AuthenticatorUtils.parseRequest(AuthenticatorUtils.java:378)
at

 org.restlet.engine.http.header.HeaderUtils.copyResponseTransportHeaders(HeaderUtils.java:814)
at

 org.restlet.engine.http.connector.ClientConnection.copyResponseTransportHeaders(ClientConnection.java:152)
at

 org.restlet.engine.http.connector.ClientConnection.readMessage(ClientConnection.java:269)
at

 org.restlet.engine.http.connector.Connection.readMessages(Connection.java:673)
at
 org.restlet.engine.http.connector.Controller$2.run(Controller.java:95)
at

 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
 Exception in thread main Bad Request (400) - Bad Request
at
 org.restlet.resource.ClientResource.handle(ClientResource.java:867)
at
 org.restlet.resource.ClientResource.post(ClientResource.java:1206)
at
 org.restlet.resource.ClientResource.post(ClientResource.java:1152)
at
 com.zeedna.applications.social.facebook.resources.Test.main(Test.java:21)


 Thank you
 Mutaz

 --
 View this message in context:
 http://restlet-discuss.1400322.n2.nabble.com/Bad-Request-exception-bug-tp7431921p7431921.html
 Sent from the Restlet Discuss mailing list archive at Nabble.com.

 --

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


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

Bad Request exception bug

2012-04-03 Thread Mutaz Qasem
I have the following code   


String openGraphUri = https://graph.facebook.com/;; 
String accessToken = gerkjh43kj5h43kjh34k; 
ClientResource clientResource = new
ClientResource(openGraphUri + me/feed + ?access_token= + accessToken); 
Form form = new Form(); 
form.add(message, test message); 
Representation resp = clientResource.post(form); 

When I run it I get the below exception. You can try the code without any
change because the access token provided above is invalid so the code will
throw the same exception (Bad Request 400) 




java.io.IOException: Parameter or extension has no name. Please check your
value 
at
org.restlet.engine.http.header.HeaderReader.readParameter(HeaderReader.java:425)
 
at
org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:128)
 
at
org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:46)
 
at
org.restlet.engine.http.header.HeaderReader.addValues(HeaderReader.java:243) 
at
org.restlet.engine.http.header.HeaderReader.readValues(HeaderReader.java:605) 
at
org.restlet.engine.security.AuthenticatorUtils.parseRequest(AuthenticatorUtils.java:378)
 
at
org.restlet.engine.http.header.HeaderUtils.copyResponseTransportHeaders(HeaderUtils.java:814)
 
at
org.restlet.engine.http.connector.ClientConnection.copyResponseTransportHeaders(ClientConnection.java:152)
 
at
org.restlet.engine.http.connector.ClientConnection.readMessage(ClientConnection.java:269)
 
at
org.restlet.engine.http.connector.Connection.readMessages(Connection.java:673) 
at
org.restlet.engine.http.connector.Controller$2.run(Controller.java:95) 
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
at java.lang.Thread.run(Thread.java:680) 
Exception in thread main Bad Request (400) - Bad Request 
at
org.restlet.resource.ClientResource.handle(ClientResource.java:867) 
at
org.restlet.resource.ClientResource.post(ClientResource.java:1206) 
at
org.restlet.resource.ClientResource.post(ClientResource.java:1152) 
at
com.zeedna.applications.social.facebook.resources.Test.main(Test.java:21) 


Thank you 
Mutaz

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Bad-Request-exception-bug-tp7431921p7431921.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


Potential Namespace Bug in SaxRepresentation??

2012-04-03 Thread Nicholas Waltham
Hi All,
 I have produced some simplified code to demonstrate what appears to
be a bug. However I would like to check with the list before I file a
report.

If I have the following code:


String uri = LocalReference.createClapReference(getClass().getPackage())
+ /xmlwns.xml;
Representation listVtl = new ClientResource(uri).get();
SaxRepresentation r = new SaxRepresentation(listVtl);
log.debug(r.getText());

I observe the following behavior:

inputfile xmlwns.xml

a xmlns=uri:a xmlns:b=uri:b  
 b:content/
/a

gives as output to the logger:

a xmlns:b=uri:b xmlns=uri:a
 b:content xmlns:b=uri:b/b:content
/a

which is a little more verbose, but technically correct.

While with inputfile xmlwns.xml

a:doc xmlns:a=uri:a xmlns:b=uri:b 
 b:content/
/a:doc

gives as output to the logger:

a:doc xmlns:a=uri:a xmlns:b=uri:b xmlns:a=uri:a
 b:content xmlns:b=uri:b/b:content
/a:doc

you will see that the namspace definition for xmlns:a is duplicated,
which gives an error on some XML readers. For example Google Chrome
will complain about a redefinition of the namespace.

Whats your view on this? Is this a bug in Restlet?

Thanks a lot,
Regards,
Nicholas

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


Bad Request (400) - Bad Request exception. Bug?

2012-03-29 Thread Mutaz Qasem
I have the following code   


String openGraphUri = https://graph.facebook.com/;;
String accessToken = gerkjh43kj5h43kjh34k;
ClientResource clientResource = new ClientResource(openGraphUri 
+
me/feed + ?access_token= + accessToken);
Form form = new Form();
form.add(message, test message);
Representation resp = clientResource.post(form);

When I run it I get the below exception. You can try the code without any
change because the access token provided above is invalid and the code will
throw the same exception (Bad Request 400)




java.io.IOException: Parameter or extension has no name. Please check your
value
at
org.restlet.engine.http.header.HeaderReader.readParameter(HeaderReader.java:425)
at
org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:128)
at
org.restlet.engine.http.header.ChallengeRequestReader.readValue(ChallengeRequestReader.java:46)
at
org.restlet.engine.http.header.HeaderReader.addValues(HeaderReader.java:243)
at
org.restlet.engine.http.header.HeaderReader.readValues(HeaderReader.java:605)
at
org.restlet.engine.security.AuthenticatorUtils.parseRequest(AuthenticatorUtils.java:378)
at
org.restlet.engine.http.header.HeaderUtils.copyResponseTransportHeaders(HeaderUtils.java:814)
at
org.restlet.engine.http.connector.ClientConnection.copyResponseTransportHeaders(ClientConnection.java:152)
at
org.restlet.engine.http.connector.ClientConnection.readMessage(ClientConnection.java:269)
at
org.restlet.engine.http.connector.Connection.readMessages(Connection.java:673)
at 
org.restlet.engine.http.connector.Controller$2.run(Controller.java:95)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Exception in thread main Bad Request (400) - Bad Request
at org.restlet.resource.ClientResource.handle(ClientResource.java:867)
at org.restlet.resource.ClientResource.post(ClientResource.java:1206)
at org.restlet.resource.ClientResource.post(ClientResource.java:1152)
at
com.zeedna.applications.social.facebook.resources.Test.main(Test.java:21)


Thank you
Mutaz

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Bad-Request-400-Bad-Request-exception-Bug-tp7417695p7417695.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


Bug in Restlet RC 2.1 RC?

2012-03-29 Thread Ping Tang
I have a PUT method to accept any java object in one of our resource class.
This method is annotated with @Put shown below:
@Put
public void send(DataTransporter obj);

I have successfully sent the serialized Java objects as well as Java File 
object created with a binary file using Restlet JEE 2.0.1, but failed in 
version 2.1 RC3. I'd like to report this issue so that your team can take a 
look into it. The POJO transport support is the main reason why we are 
considering to use Restlet in our application. Below is the short version of 
the exception caught from the client code.

Unsupported Media Type (415) - Unsupported Media Type
at
org.restlet.resource.ClientResource.doError(ClientResource.java:582)
at
org.restlet.engine.resource.ClientInvocationHandler.invoke(ClientInvocationH
andler.java:236)

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


Re: @Post generic parameter conversion bug/missing feature

2012-02-29 Thread Thierry Boileau
Hello all,

thanks for claiming this : I've entered a new issue
http://restlet.tigris.org/issues/show_bug.cgi?id=1378.

Best regards,
Thierry Boileau




Did anybody log an issue for this?  I didn't see one, but I don't want to
 log
 a dup.

 --
 View this message in context:
 http://restlet-discuss.1400322.n2.nabble.com/Post-generic-parameter-conversion-bug-missing-feature-tp7223520p7319344.html
 Sent from the Restlet Discuss mailing list archive at Nabble.com.

 --

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


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

RE: @Post generic parameter conversion bug/missing feature

2012-02-26 Thread Andy Dennie
Did anybody log an issue for this?  I didn't see one, but I don't want to log
a dup.

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Post-generic-parameter-conversion-bug-missing-feature-tp7223520p7319344.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


RE: @Post generic parameter conversion bug/missing feature

2012-01-27 Thread Andy Dennie
I ran into the same issue recently.  I was going to try to fix it, but the 
reflection code was too hairy for me :-)

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


@Post generic parameter conversion bug/missing feature

2012-01-25 Thread Dencel
If you use an annotated interface like 
[CODE]
interface CRUDHandlerT extends Request{
   
@Post
public Object handlePost(T request);
}
[/CODE]

Parameter conversion does not work, because Restlet can't figure out T. It 
should find it on the implementing class, but Restlet uses the interface to 
resolve the actual parameter. 

@See AnnotationInfo


I don't know if this is a bug or a missing feature.

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


Re: @Post generic parameter conversion bug/missing feature

2012-01-25 Thread Tim Peierls
I think it's a bug. I created a JUnit test here to demonstrate it:

http://pastebin.com/xfvC6y2a

The two resource hierarchies are identical except that in one case the
@Post annotation is on the generic version of the method and in the other
it isn't. That's enough to confuse the machinery in AnnotationInfo,
specifically this code:

// From AnnotationInfo, with index == 0 at run time:
return getJavaActualType(
method.getParameterTypes()[index],
method.getGenericParameterTypes()[index]);

The private method getJavaActualType has a complicated implementation that
I don't have time to follow, but the upshot is that the @Post on the
generic method causes a null to be returned, which turns into an internal
server error.

--tim

On Wed, Jan 25, 2012 at 6:20 AM, Dencel dennie...@gmail.com wrote:

 If you use an annotated interface like
 [CODE]
 interface CRUDHandlerT extends Request{

@Post
public Object handlePost(T request);
 }
 [/CODE]

 Parameter conversion does not work, because Restlet can't figure out T. It
 should find it on the implementing class, but Restlet uses the interface to
 resolve the actual parameter.

 @See AnnotationInfo


 I don't know if this is a bug or a missing feature.

 --

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


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

RE: Re: Serious bug in ClientResource

2011-12-13 Thread Koen Maes
I have a problem that an outbound connection sends the wrong representation, it 
sends the representation it received from the incoming connection (GWT 
serialized object) while it should send JSON.

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

Might this bug be causing this problem ?

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


Re: Serious bug in ClientResource

2011-12-13 Thread Arjohn Kampman
This looks like a related but different bug to me. ClientResource.wrap()
doesn't seem to call AnnotationInfo.getRequestVariants(...) at all.

-- 
Arjohn Kampman - www.aduna-software.com

On 13/12/2011 13:42, Koen Maes wrote:
 I have a problem that an outbound connection sends the wrong representation, 
 it sends the representation it received from the incoming connection (GWT 
 serialized object) while it should send JSON.

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

 Might this bug be causing this problem ?

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

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


Re: Serious bug in ClientResource

2011-12-09 Thread Arjohn Kampman
Fix verified, it works as expected now. Thanks.

On 08/12/2011 10:12, Thierry Boileau wrote:
 Hello Arjohn,
 the snapshots are refreshed three times in a day, and the maven
 repository once a day. I've just checked, you can test it.
 Best regards,
 Thierry Boileau

-- 
Arjohn Kampman - www.aduna-software.com

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


Re: Serious bug in ClientResource

2011-12-08 Thread Thierry Boileau
Hello Arjohn,

the snapshots are refreshed three times in a day, and the maven repository
once a day. I've just checked, you can test it.

Best regards,
Thierry Boileau

 The fix looks fine to me. How often are the snapshot builds updated on
 maven.restlet.org so that I can test it?

 --
 Arjohn Kampman - www.aduna-software.com

 On 07/12/2011 19:39, Thierry Boileau wrote:
  Hello Arjohn,
 
  thanks a lot for the issue and for reporting this bug. The fix is now
  available in the trunk and the 2.0 branch.
 
  Best regards,
  Thierry Boileau

 --

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


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

Re: Serious bug in ClientResource

2011-12-07 Thread Thierry Boileau
Thanks a lot Arjohn,

I've opened an issue for this bug :
http://restlet.tigris.org/issues/show_bug.cgi?id=1357

Best regards,
Thierry Boileau


Hi all,

 I think I've run into a serious bug in ClientResource. I've found this
 in method handle(Method method, Object entity, ClassT resultClass) in
 restlet 2.0.10, but 2.1.x seems to be affected too.

 What I think is wrong with this method is that it uses the variants for
 the response to convert the request entity to a representation. Imagine
 doing the following call:

clientResource.post(1234, Integer.class)

 ClientResource.handle(...) will try to convert the string 1234 to a
 representation using a converter for integers. This will succeed with
 the DefaultConverter as it happens to be able to encode both strings and
 integers, but in other situations it will fail misserably.

 I hope you can fix this soon. Are there any work-arounds that I can use
 until then?

 --
 Arjohn Kampman - www.aduna-software.com

 --

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


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

Re: Serious bug in ClientResource

2011-12-07 Thread Arjohn Kampman
FYI: I've logged this issue earlier as:
http://restlet.tigris.org/issues/show_bug.cgi?id=1356

On 07/12/2011 17:57, Thierry Boileau wrote:
 Thanks a lot Arjohn,

 I've opened an issue for this bug :
 http://restlet.tigris.org/issues/show_bug.cgi?id=1357

 Best regards,
 Thierry Boileau


-- 
Arjohn Kampman - www.aduna-software.com

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


Re: Serious bug in ClientResource

2011-12-07 Thread Thierry Boileau
Hello Arjohn,

thanks a lot for the issue and for reporting this bug. The fix is now
available in the trunk and the 2.0 branch.

Best regards,
Thierry Boileau


FYI: I've logged this issue earlier as:
 http://restlet.tigris.org/issues/show_bug.cgi?id=1356

 On 07/12/2011 17:57, Thierry Boileau wrote:
  Thanks a lot Arjohn,
 
  I've opened an issue for this bug :
  http://restlet.tigris.org/issues/show_bug.cgi?id=1357
 
  Best regards,
  Thierry Boileau


 --
 Arjohn Kampman - www.aduna-software.com

 --

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


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

Re: Serious bug in ClientResource

2011-12-07 Thread Arjohn Kampman
The fix looks fine to me. How often are the snapshot builds updated on
maven.restlet.org so that I can test it?

-- 
Arjohn Kampman - www.aduna-software.com

On 07/12/2011 19:39, Thierry Boileau wrote:
 Hello Arjohn,

 thanks a lot for the issue and for reporting this bug. The fix is now
 available in the trunk and the 2.0 branch.

 Best regards,
 Thierry Boileau

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


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=4447dsMessageId=2815760


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

Bug in 2.1M5

2011-08-11 Thread Sebastian Wenninger
Hi!
I have a ServerResource that looks like this:

@Post
public Representation store(Product product) {
ProductService service =
MyThreadLocal.getServiceFactory().productService();
if (null == getRequestAttributes().get(id)) {
Setlt;ConstraintViolationlt;Productgt; violations =
service.validate(product);
if (violations.size() == 0) {
product = service.create(product);
MyJacksonRepresentationProduct response = new 
   
MyJacksonRepresentationProduct(product);
setStatus(Status.SUCCESS_CREATED);
return response;
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
JSONObject response = new JSONObject();
try {
response.put(error, Validation of 
this Product failed);
for (ConstraintViolationProduct cv : 
violations) {
response.append(Violations, 
cv.getPropertyPath().toString() +   +
cv.getMessage());
}
JsonRepresentation res = new 
JsonRepresentation(response);
return res;
} catch (JSONException e) {
setStatus(Status.SERVER_ERROR_INTERNAL, 
Error generating the
Json-Error response.);
return null;
}
}
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST, You must 
not provide an id
when creating a new Product.);
return null;
}
}

When i use Restlet 2.1 Milestone5 and Post an invalid Product-Json, i get a
Response with a 400 Status Code (as expected), but an empty Response body.
However, if i use Restlet 2.0.8 i get the correct JSON Response.
Don't know what, but something seems to be wrong (or just different) in M5
that causes this behaviour...
Someone here knows what it could be?

Regards,
Sebastian

--
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/Bug-in-2-1M5-tp6676452p6676452.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


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=4447dsMessageId=2815760


ChildContext, subtle bug

2011-07-14 Thread Daniele Dellafiore
Hi.

I instantiate a new ClientResource in the context of a Restlet
Application to communicate to a third web service (in restlet itself).
This just created client resource is set a ChildContext as the
context. This resource does not seem to have any protocols cause it
refers to the application protocols, that's an empty list.

Here's what happens (restlet 2.0.8)

1. the server receives the request and answer correctly (200, right entity set)
2. the client logs a Warning about the missing protocol
(ChildClientDispatcher, line 105)
3. the client see a 404 response
4. a ResourceException on the client side is raised.

It took a lot to find this cause the server was answering a 200 and
the correct entity, while the client was receiving a 404. This is very
subtle, despite the warning.

How can I add HTTP protocol to my application connector service?
I've tried

getConnectorService().getClientProtocols().add(Protocol.HTTP);

in the application constructor but does not work, a sever exception is raised.

Thanks.

-- 
Daniele Dellafiore
http://danieledellafiore.net

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


Re: ChildContext, subtle bug

2011-07-14 Thread Thierry Boileau
Hello Daniele,

actually the Application declares its need of an HTTP client connector by
using the connectorService. I wonder if the javadocs clairly explains this
point.
Here is the documentation of the ConnectorService#getClientProtocols:
Returns the modifiable list of required client protocols. You need to update
this list if you need the parent component to provide additional client
connectors.

The ConnectorService allows the applicaion to describe its need in terms of
client connectors. These client connectors must be provided by the parent
component:
Component#getClients#add(Protocol);

I hope this will help you.

Best regards,
Thierry Boileau


Hi.

 I instantiate a new ClientResource in the context of a Restlet
 Application to communicate to a third web service (in restlet itself).
 This just created client resource is set a ChildContext as the
 context. This resource does not seem to have any protocols cause it
 refers to the application protocols, that's an empty list.

 Here's what happens (restlet 2.0.8)

 1. the server receives the request and answer correctly (200, right entity
 set)
 2. the client logs a Warning about the missing protocol
 (ChildClientDispatcher, line 105)
 3. the client see a 404 response
 4. a ResourceException on the client side is raised.

 It took a lot to find this cause the server was answering a 200 and
 the correct entity, while the client was receiving a 404. This is very
 subtle, despite the warning.

 How can I add HTTP protocol to my application connector service?
 I've tried

 getConnectorService().getClientProtocols().add(Protocol.HTTP);

 in the application constructor but does not work, a sever exception is
 raised.

 Thanks.

 --
 Daniele Dellafiore
 http://danieledellafiore.net

 --

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


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

RE: Fwd: Bug in WriterRepresentation with internal connector

2011-05-13 Thread Jerome Louvel
Hi Tim,

 

This is now fixed, see the issue for details.

 

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~  http://www.restlet.org/ 
http://www.restlet.o​rg
Noelios Technologies ~  http://www.noelios.com/ http://www.noelios.com

 

 

De : Tim Peierls [mailto:tpeie...@gmail.com] 
Envoyé : jeudi 5 mai 2011 14:28
À : discuss@restlet.tigris.org
Objet : Re: Fwd: Bug in WriterRepresentation with internal connector

 

In summary, this is a reproducible bug: Using WriterRepresentation and the 
internal connector with content of size  1024 in 2.1-M4 (at least) on Windows 
(at least) hangs the Restlet component.

WriterRepresentation is the supertype of JacksonRepresentation, so this means 
you can't use Jackson with the internal connector, at least not reliably.

--tim

On May 2, 2011 10:43 AM, Tim Peierls t...@peierls.net wrote:
 [I already posted to the Restlet code list, but I'm posting here as well, in
 case anyone else has noticed this and come up with workarounds.]
 
 I've created an issue in the issue tracker about a problem with
 WriterRepresentation, the internal connector, and large (1024) entities:
 
 http://restlet.tigris.org/issues/show_bug.cgi?id=1264
 
 The code to reproduce is here:
 
 http://pastebin.com/XDr36dyc
 
 --tim

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

Re: Fwd: Bug in WriterRepresentation with internal connector

2011-05-05 Thread Tim Peierls
In summary, this is a reproducible bug: Using WriterRepresentation and the
internal connector with content of size  1024 in 2.1-M4 (at least) on
Windows (at least) hangs the Restlet component.

WriterRepresentation is the supertype of JacksonRepresentation, so this
means you can't use Jackson with the internal connector, at least not
reliably.

--tim
On May 2, 2011 10:43 AM, Tim Peierls t...@peierls.net wrote:
 [I already posted to the Restlet code list, but I'm posting here as well,
in
 case anyone else has noticed this and come up with workarounds.]

 I've created an issue in the issue tracker about a problem with
 WriterRepresentation, the internal connector, and large (1024) entities:

 http://restlet.tigris.org/issues/show_bug.cgi?id=1264

 The code to reproduce is here:

 http://pastebin.com/XDr36dyc

 --tim

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

Fwd: Bug in WriterRepresentation with internal connector

2011-05-02 Thread Tim Peierls
[I already posted to the Restlet code list, but I'm posting here as well, in
case anyone else has noticed this and come up with workarounds.]

I've created an issue in the issue tracker about a problem with
WriterRepresentation, the internal connector, and large (1024) entities:

http://restlet.tigris.org/issues/show_bug.cgi?id=1264

The code to reproduce is here:

http://pastebin.com/XDr36dyc

--tim

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

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=4447dsMessageId=2723440


BUG: restlet client ignores SSL parameters

2011-03-17 Thread Andrei Pozolotin
Hello People of Restlet;

I made self-sign keys and cert for both:

restlet server:
http://code.google.com/p/carrotgarden/source/browse/trunk/test-restlet/src/main/java/restlet_01/MainServerSSL.java

restlet client:
http://code.google.com/p/carrotgarden/source/browse/trunk/test-restlet/src/main/java/restlet_01/MainClientSSL.java

when I run server, I can accept exception in browser and hence confirm that 
server did aceept SSL parameters;

but when I run client which tries to connect to the server, it blows up with 
exceptions which show that client is still using default java ssl stores;

I verified this by placing a break point on:
org.restlet.ext.ssl.PkixSslContextFactory.init(SeriesParameter parameters)

namely, server does call it; but in client it never gets called;

please let me know what am I missing?

thank you;

Andrei

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


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=4447dsMessageId=2712171


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=4447dsMessageId=2712183


Bug: ChunkedInputStream

2010-11-25 Thread Mark Thornton
The condition in the checkCRLF method seems to be wrong. The  should be 
replaced by ||.

(This is from the 2.0 branch)


private void checkCRLF() throws IOException {
final int cr = this.source.read();
final int lf = this.source.read();

if ((cr != '\r')  (lf != '\n')) {
this.source.unread(lf);
this.source.unread(cr);
}
}

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


2.0.1 ClientResource bug?

2010-10-29 Thread Tony Rozga
Hi,
I'm creating a ClientResource and passing it a Context object.  When the 
ClientResource object is finalized I'm seeing the Context get released which is 
unexpected as I'm trying to use a single Context to get many resources.

ClientResource.handle() calls ClientResource.getNext() and getNext looks 
suspicious:

result = createNext();

if (result != null) {
setNext(result);
this.nextCreated = true; --- hmmh.
}

createNext() does not always appear to create a Uniform, it will return the 
applications outbound root if set or the 
ClientResource.getContext().getClientDispatcher() which is non-null in my case. 
 Only if both of those are null will it create a client connector.

I can call ClientResource.setNext(myClientObject) to workaround this but I 
though I'd post this observation anyway.

Tony Rozga

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


Jackson vs JaxB Converter score bug in 2.0.1?

2010-10-29 Thread Tony Rozga
Hi,
I have both the jaxb and jackson extensions and a @Post(xml|json:xml|json) 
annotated method.  Posting an xml entity works great but when I post json I see 
exceptions.  The jaxb converter helper is getting selected.

breakpoint in ConverterUtils.java reveals:

args:
source is a Representation with MediaType application/json as expected.  target 
is one of my classes (the argument to the annotated method) as expected.  
resource is my resource class that has the annotated method as expected.

JacksonConverter.score returns 0.8
JaxBConverter.score return 1.0

Thanks,
Tony Rozga

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


Re: JaxRs routing bug

2010-10-04 Thread Jeroen Goubert
Hello all,

this issue is already reported: 
http://restlet.tigris.org/issues/show_bug.cgi?id=1148

Regards,
Jeroen


On 03-10-10 01:29, Jerome Louvel wrote:
 Hi Stephan,

 Our JIRA installation isn't ready yet as we need to migrate existing content 
 from Tigris. People should still use Tigris issue tracker for now. When this 
 changes, we'll notify this list and update this page: 
 http://www.restlet.org/community/issues

 Best regards,
 Jerome
 --
 Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
 Noelios Technologies ~ http://www.noelios.com




 -Message d'origine-
 De : stephan.ko...@web.de [mailto:stephan.ko...@web.de]
 Envoyé : lundi 27 septembre 2010 21:11
 À : discuss@restlet.tigris.org
 Objet : Re: JaxRs routing bug

 Hi Sriram,

 Am 27.09.2010 21:03, schrieb Sriram C:

 I have defined a JaxRs resource (Restlet 2.0 RC4)
  
 Do you tried the newest version? Maybe it solves the problem. Otherwise 
 please file a bug on http://jira.restlet.org/ . Please also note the 
 workaround with the order of the methods.
 I can't say when I have time to wolve it. You could also add a patch.

 Thanks for reporting

 best regards
   Stephan

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

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




  DISCLAIMER 
http://www.schaubroeck.be/maildisclaimer.htm

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


RE: JaxRs routing bug

2010-10-02 Thread Jerome Louvel
Hi Stephan,

Our JIRA installation isn't ready yet as we need to migrate existing content 
from Tigris. People should still use Tigris issue tracker for now. When this 
changes, we'll notify this list and update this page: 
http://www.restlet.org/community/issues

Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg
Noelios Technologies ~ http://www.noelios.com




-Message d'origine-
De : stephan.ko...@web.de [mailto:stephan.ko...@web.de] 
Envoyé : lundi 27 septembre 2010 21:11
À : discuss@restlet.tigris.org
Objet : Re: JaxRs routing bug

Hi Sriram,

Am 27.09.2010 21:03, schrieb Sriram C:
 I have defined a JaxRs resource (Restlet 2.0 RC4)
Do you tried the newest version? Maybe it solves the problem. Otherwise please 
file a bug on http://jira.restlet.org/ . Please also note the workaround with 
the order of the methods.
I can't say when I have time to wolve it. You could also add a patch.

Thanks for reporting

best regards
 Stephan

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

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


JaxRs routing bug

2010-09-27 Thread Sriram C
I have defined a JaxRs resource (Restlet 2.0 RC4) with multiple methods for
distinct paths. The paths and methods have the following signature:

@Path(/{var_a}/test)
public MyTestRep getTestRep1(@PathParam(var_a) String var_a){}

@Path(/{var_a}/{var_b})
public MyTestRep getTestRep2(@PathParam(var_a) String var_a,
@PathParam(var_b) String var_b){}

If I make a request for /foo/test, the method getTestRep2 is invoked instead
of getTestRep1. The order seems to be determined by the order of the methods
returned from java.lang.class.getMethods().

org.restlet.ext.jaxrs.internal.wrappers.ResourceClass:getMethodsForPath
doesn't seem to be matching for substring in the URI. With the current
logic, both the methods are returned as matches without an ordering of
methods for closest match and the 1st one in the list always seems to be
getting executed. The closer match should be returned at the top of the list
from the above method.

Sriram


-- 
View this message in context: 
http://restlet-discuss.1400322.n2.nabble.com/JaxRs-routing-bug-tp5576500p5576500.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


Re: JaxRs routing bug

2010-09-27 Thread Stephan Koops
Hi Sriram,

Am 27.09.2010 21:03, schrieb Sriram C:
 I have defined a JaxRs resource (Restlet 2.0 RC4)
Do you tried the newest version? Maybe it solves the problem. Otherwise 
please file a bug on http://jira.restlet.org/ . Please also note the 
workaround with the order of the methods.
I can't say when I have time to wolve it. You could also add a patch.

Thanks for reporting

best regards
 Stephan

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


Bug when serializing sub-class to GWT?

2010-06-16 Thread fred bloggs
In my domain model, the dto classes are all Abstract and are subclassed into 
business objects which is what my application manipulates and persists. In 
hibernate terms I have a @MappedSuperclass and an @Entity subclass.

If I make the abstract class concrete, I can serialize it to GWT without any 
problem. However if I serialize the subclass, the result is garbage in GWT.

Specifically, my class has 2 int fields and a String. When I serialize the 
superclass, I correctly see a string value of fred. However when I serialize 
the subclass and display the string contents it comes out as 
java.lang.Integer/3438268394.

To track the problem down, I wiresharked the http traffic. First the good reply 
then the bad. 

  2f 2f 4f 4b 5b 31 32 33 2c 31 32 33 34 35 36 2c   //OK[123,123456,
0010  33 2c 32 2c 31 2c 5b 22 63 6f 75 6b 2e 63 6c 65   3,2,1,[couk.cle
0020  76 65 72 74 68 69 6e 6b 69 6e 67 2e 74 6c 32 30   verthinking.tl20
0030  31 30 2e 73 68 61 72 65 64 2e 47 77 74 2f 31 34   10.shared.Gwt/14
0040  32 35 33 37 38 35 37 22 2c 22 63 68 61 72 22 2c   2537857,fred,
0050  22 6a 61 76 61 2e 6c 61 6e 67 2e 49 6e 74 65 67   java.lang.Integ
0060  65 72 2f 33 34 33 38 32 36 38 33 39 34 22 5d 2c   er/3438268394],
0070  30 2c 35 5d   0,5]


  2f 2f 4f 4b 5b 31 32 33 2c 31 32 33 34 35 36 2c   //OK[123,123456,
0010  33 2c 32 2c 31 2c 5b 22 63 6f 75 6b 2e 63 6c 65   3,2,1,[couk.cle
0020  76 65 72 74 68 69 6e 6b 69 6e 67 2e 74 6c 32 30   verthinking.tl20
0030  31 30 2e 73 68 61 72 65 64 2e 47 77 74 2f 31 36   10.shared.Gwt/16
0040  33 32 35 31 30 37 30 37 22 2c 22 63 68 61 72 22   32510707,fred
0050  2c 22 6a 61 76 61 2e 6c 61 6e 67 2e 49 6e 74 65   ,java.lang.Inte
0060  67 65 72 2f 33 34 33 38 32 36 38 33 39 34 22 5d   ger/3438268394]
0070  2c 30 2c 35 5d,0,5]

The bad reply (the sub-class) seems to be one byte longer. Is this enough to 
confuse the parser at the client?

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


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 carrotsa...@gmail.com 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=4447dsMessageId=2617644

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=4447dsMessageId=26087
25

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


RE: Re: Bug in ServerResource.handle() when using annotated methods?

2010-05-19 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=4447dsMessageId=2610395


Bug in Atom extension Readers

2010-05-13 Thread Martin Svensson
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=4447dsMessageId=2608725


Bug in ServerResource.handle() when using annotated methods?

2010-05-11 Thread David Fogel
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=4447dsMessageId=2607795


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 carrotsa...@gmail.com 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=4447dsMessageId=2607795


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

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 t...@peierls.net 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=4447dsMessageId=2607811


RE: Re: Multiple cookie bug (2.0RC1 and snapshot)

2010-03-27 Thread Thierry Boileau
Hello all,

I've updated the svn repository. As far as I notice, the bug is fixed. Thanks 
Rob for reporting this.

Could you give it a try?

David, thanks a lot for taking time to debug and propose a solution.
I just propose another one that consists in removing the need of caching pair 
in the CookieReader class. The underlying convention is that readers are 
exhausted when the current character is -1, not when the next read value is 
null. This has an impact on the addValues method, as you clearfully noticed. We 
decided to do so because in some cases, empty tokens (if I remember well) were 
not taken correctly into account.

Best regards,
Thierry Boileau

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


Re: Multiple cookie bug (2.0RC1 and snapshot)

2010-03-26 Thread David Fogel
Hi folks.

So, we've been bit by this cookie problem as well.

After diving into the debugger for a couple of hours I think I've
pinpointed exactly where cookie reading is failing.

From what I can tell, the problem isn't that request.getCookies() is
returning only the first cookie, it's that it's returning all cookies
EXCEPT FOR THE LAST ONE.

The problem is an interaction between the code in
HeaderReader.addValues() and the code in CookieReader.readValue().
The former runs a do-while loop based on peek()ing to see if the end
of the string has been reached.   the readValue() method does some
weird stuff where it reads the NEXT value after it is done reading the
current value, and stores the next one in the CookieReader.cachedPair
field, to be returned during the next call to readValue.  However,
when it reads ahead I think it must be advancing the current index
into the header value.  The final time through the addValues() method
gets short-circuited due to peek() returning -1, so the final CACHED
cookie value is never added to the collection.

I'm not sure what the best way is to fix this.  It seems like the
CookieReader is doing something fundamentally incompatible with the
algorithm in the HeaderReader.addValues() method- it seems like a hack
gone awry.  I don't know what the special cookie values involving
$ are for.

I would put this bug at the HIGHEST PRIORITY, since being unable to
read all cookies is a very broken state for the build to be in!

-Dave Fogel

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


Re: Multiple cookie bug (2.0RC1 and snapshot)

2010-03-26 Thread David Fogel
I posted the following to the restlet.tigris.org issue tracker, but
there's a notice on tigris that it's going down for service starting
tonight for 20 hours, so I figure I'd repost my message here, in case
anyone wants a totally-no-guarantees patch for the cookie issue.
Obviously the best thing to do for most folks would be to wait for the
official fix, which I'm sure will come quickly from the Jerome,
Thierry etc like usual.

In order to get our stack to work, I've locally changed the
HeaderReader.addValues() method, see below.
However, I'm not recommending this as a patch, since I don't really
have a good feel for what _other_
header types do besides the CookieReader one, and even that one I am
only able to follow some of it,
and based on the CookieReader I imagine that other headerreader
subclasses may also be doing fragile
things- which is probably why the addValues() method was changed in
the first place (the svn
comment for the breaking change said approximately fixing the
addValues method).  Anyhow, here is
how I've re-written the method- note the main change is executing the
loop while(nextValue != null)
as opposed to while(peek() != -1):

In HeaderReader.java:

public void addValues(CollectionV values) {
try {
// Skip leading spaces
skipSpaces();

// Read the first value
V nextValue = readValue();

while(nextValue != null) {

if (canAdd(nextValue, values)) {
// Add the value to the list
values.add(nextValue);
}

// Attempt to skip the value separator
skipValueSeparator();

nextValue = readValue();
}
} catch (IOException ioe) {
Context.getCurrentLogger().log(Level.INFO,
Unable to read a header, ioe);
}
}

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


Multiple cookie bug (2.0RC1 and snapshot)

2010-03-25 Thread Rob Heittman
Hi all,

I haven't explored it in sufficient detail yet to have a patch, but
request.getCookies() is returning only the first cookie sent by the browser,
I think since some of the engine refactoring in early March may have to do
with it?  I think it was OK before then.

A quick step thru seems to indicate that CookieReader gets the first pair,
caches the second pair, but never gets visited again to actually read pairs
2..n

- Rob

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

Re: Multiple cookie bug (2.0RC1 and snapshot)

2010-03-25 Thread Thierry Boileau
Hello Rob,

thanks for your report, I've entered an issue for that: 
http://restlet.tigris.org/issues/show_bug.cgi?id=1068

Best regards,
Thierry Boileau

 Hi all,

 I haven't explored it in sufficient detail yet to have a patch, but 
 request.getCookies() is returning only the first cookie sent by the 
 browser, I think since some of the engine refactoring in early March 
 may have to do with it?  I think it was OK before then.

 A quick step thru seems to indicate that CookieReader gets the first 
 pair, caches the second pair, but never gets visited again to actually 
 read pairs 2..n

 - Rob



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

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=4447dsMessageId=2441
619 dsMessageId=2441619

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=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 ArrayListMap.EntryString, String();
  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=4447dsMessageId=2444857



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

Bug in OAuthHelper?

2010-02-04 Thread ZDC
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 ArrayListMap.EntryString, String();
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=4447dsMessageId=2444857


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=4447dsMessageId=2441619



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

Bug in MediaType Parameter handling

2010-01-24 Thread Carsten Lohmann
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=4447dsMessageId=2441619


Re: not sure if null identifier is user error or bug

2010-01-15 Thread Thierry Boileau
Hello Taylor,

Thanks for reporting this issue. It is now fixed in the svn repository.

Best regards,
Thierry Boileau

 I'm getting a null identifier using the Restlet client

 Response res = client.post(http://localhost:8080/nodes;, r);
 Representation rep = res.getEntity();
 System.out.println(rep.getIdentifier());
 System.out.println(rep.getSize());
 System.out.println(rep.getMediaType());

 results in null, 12, and application/json.  Am I correct in expecting 
 getIdentifier() to extract the newly created Content-Location?

 I used curl to get the headers.  I'm assuming that getIdentifier() utilizes 
 the Content-Location: which is returned by my restlet:

 HTTP/1.1 200 The request has succeeded
 Content-Length: 12
 Content-Location: http://localhost:8080/nodes/21
 Content-Type: application/json; charset=ISO-8859-1
 Date: Fri, 15 Jan 2010 02:13:50 GMT
 Accept-Ranges: bytes
 Server: Restlet-Framework/2.0snapshot

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



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

not sure if null identifier is user error or bug

2010-01-14 Thread Taylor Cowan
I'm getting a null identifier using the Restlet client

Response res = client.post(http://localhost:8080/nodes;, r);
Representation rep = res.getEntity();
System.out.println(rep.getIdentifier());
System.out.println(rep.getSize());
System.out.println(rep.getMediaType());

results in null, 12, and application/json.  Am I correct in expecting 
getIdentifier() to extract the newly created Content-Location?

I used curl to get the headers.  I'm assuming that getIdentifier() utilizes the 
Content-Location: which is returned by my restlet:

HTTP/1.1 200 The request has succeeded
Content-Length: 12
Content-Location: http://localhost:8080/nodes/21
Content-Type: application/json; charset=ISO-8859-1
Date: Fri, 15 Jan 2010 02:13:50 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0snapshot

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


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=4447dsMessageId=2428093


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=4447dsMessageId=2428093



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


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
thierry.boil...@noelios.com 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=4447dsMessageId=2428093



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


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


BUG?: JsonRepresentation does not inherit size from wrapped StringRep

2009-12-07 Thread Ben R Vesco
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=4447dsMessageId=2427907


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=4447dsMessageId=2427907



--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=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=4447dsMessageId=24231
88

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


BUG?: JsonRepresentation does not inherit size from wrapped StringRep

2009-11-25 Thread Ben R Vesco
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=4447dsMessageId=2424382


RE: DomRepresentation setIndent bug

2009-11-23 Thread Jerome Louvel
Hi Remi,

 

Thanks for spotting this. I’ve applied your fix in SVN trunk.

 

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 : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : jeudi 12 novembre 2009 12:11
À : discuss@restlet.tigris.org
Objet : Re: DomRepresentation setIndent bug

 

Thierry,

Unfortunately this is buggy :
java.lang.IllegalArgumentException: Serialization parameter {indent} must have 
the value yes or no

Boolean.toString(isIndent()) should be replaced by:
isIndent() ? yes : no

Cheers,
Rémi

On Thu, Nov 12, 2009 at 09:34, Thierry Boileau thierry.boil...@noelios.com 
wrote:

Hi,

thanks for your report, the fix is available in the svn repository.

Best regards,
Thierry Boileau


 Hi,

 There seems to be a bug in DocRepresentation#createTransformer. Why this:

 transformer.setOutputProperty(
javax.xml.transform.OutputKeys.INDENT, Boolean
  .toString(isIndent()));

 is inside the if (docType != null).

 The setIndent is not working because of this.

 Thanks


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

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

Bug with getClientInfo().getPreferredVariant()

2009-11-22 Thread David Bordoley
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=4447dsMessageId=2423188


Re: DomRepresentation setIndent bug

2009-11-12 Thread Thierry Boileau
Hi,

thanks for your report, the fix is available in the svn repository.

Best regards,
Thierry Boileau

 Hi,

 There seems to be a bug in DocRepresentation#createTransformer. Why this:

 transformer.setOutputProperty(
javax.xml.transform.OutputKeys.INDENT, Boolean
  .toString(isIndent()));

 is inside the if (docType != null).

 The setIndent is not working because of this.

 Thanks


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


Re: DomRepresentation setIndent bug

2009-11-12 Thread Rémi Dewitte
Thierry,

Unfortunately this is buggy :
java.lang.IllegalArgumentException: Serialization parameter {indent} must
have the value yes or no

Boolean.toString(isIndent()) should be replaced by:
isIndent() ? yes : no

Cheers,
Rémi

On Thu, Nov 12, 2009 at 09:34, Thierry Boileau
thierry.boil...@noelios.comwrote:

 Hi,

 thanks for your report, the fix is available in the svn repository.

 Best regards,
 Thierry Boileau

  Hi,
 
  There seems to be a bug in DocRepresentation#createTransformer. Why this:
 
  transformer.setOutputProperty(
 javax.xml.transform.OutputKeys.INDENT, Boolean
   .toString(isIndent()));
 
  is inside the if (docType != null).
 
  The setIndent is not working because of this.
 
  Thanks
 

 --

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


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

DomRepresentation setIndent bug

2009-11-11 Thread legege
Hi,

There seems to be a bug in DocRepresentation#createTransformer. Why this:

transformer.setOutputProperty(
   javax.xml.transform.OutputKeys.INDENT, Boolean
 .toString(isIndent()));

is inside the if (docType != null).

The setIndent is not working because of this.

Thanks
-- 
View this message in context: 
http://n2.nabble.com/DomRepresentation-setIndent-bug-tp3988303p3988303.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


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=4447dsMessageId=23800
36

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


bug: riap://host and attachDefault

2009-08-11 Thread Rob Heittman
In snapshot (and probably since forever):

riap://host doesn't work if a Restlet is attached to a VirtualHost using
attachDefault instead of attach(pattern,target); an NPE is thrown in
ComponentClientDispatcher.

This is because setCurrent(hashCode) only gets called inside Routes created
by VirtualHost.createRoute(), and VirtualHost.createRoute() is not invoked
for the default attachment point.

I didn't see a no-brainer way to patch, since VirtualHost.attachDefault(...)
relies on super.attachDefault(...) to get its Route.

Should I bother filing a bug on this?  Or somebody just recommend the
approach to fix it and I'll send in a patch.

- R

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

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.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

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.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

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.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

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
 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

Re: bug?

2009-07-05 Thread Jerome Louvel
Hi Schley,

FYI, this has been fixed in SVN trunk.

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


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

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


Re: bug?

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

-- 
-a

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

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

 Hi Schley,

 FYI, this has been fixed in SVN trunk.

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


 Schley Andrew Kutz a écrit :
 I want to prevent the use of HTTP VERB annotations in order to force
 sub-classes to respond with specific class types via abstract methods
 that I prototype in a base class. I marked the isAnnotated() method  
 as
 @Override and final and returned false. However, when it returns  
 false
 I get the following error:

 java.lang.NullPointerException
  at
 org
 .restlet
 .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: 
 106)
  at
 org 
 .restlet.resource.ServerResource.getAnnotation(ServerResource.java:
 649)
  at org.restlet.resource.ServerResource.doHandle(ServerResource.java:
 329)
  at
 org
 .restlet
 .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592)
  at
 org
 .restlet
 .resource.ServerResource.doConditionalHandle(ServerResource.java:260)
  at org.restlet.resource.ServerResource.handle(ServerResource.java: 
 921)
  at
 com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java:
 159)
  at org.restlet.resource.Finder.handle(Finder.java:510)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at
 org 
 .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:
 153)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
  at
 org
 .restlet
 .engine.application.ApplicationHelper.handle(ApplicationHelper.java: 
 71)
  at org.restlet.Application.handle(Application.java:396)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.routing.Router.handle(Router.java:490)
  at org.restlet.routing.Filter.doHandle(Filter.java:156)
  at org.restlet.routing.Filter.handle(Filter.java:201)
  at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111)
  at org.restlet.Component.handle(Component.java:397)
  at org.restlet.Server.handle(Server.java:350)
  at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71)
  at
 org 
 .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:
 149)
  at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:
 932)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  at  
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
 487)
  at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 
 362)
  at
 org 
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
  at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 
 181)
  at
 org 
 .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
 216)
  at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 
 729)
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
 405)
  at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
 152)
  at
 org
 .mortbay 
 .jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:
 49)
  at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
 152)
  at org.mortbay.jetty.Server.handle(Server.java:324)
  at  
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
 505)
  at org.mortbay.jetty.HttpConnection
 $RequestHandler.headerComplete(HttpConnection.java:829)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
  at
 org
 .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
 

bug?

2009-06-25 Thread Schley Andrew Kutz
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

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

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


RE: Possible bug in Restlet 1.2m2 (maybe solved in post 1.2m2?)

2009-06-01 Thread Jerome Louvel
Hi,

Thierry is correct, we have fixed this. It is only necessary to support GET
if you want to support conditional PUTs as they conditions evaluation is
based on the representation returned by GET.

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 : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : lundi 25 mai 2009 11:01
À : discuss@restlet.tigris.org
Objet : Re: Possible bug in Restlet 1.2m2 (maybe solved in post 1.2m2?)

Hello Fabian,

I've just make the test, and I think this has been fixed in 1.2m2.

best regards,
Thierry Boileau
 Hello,

 I have a resource which should only accept PUT requests (to modify its
 state; the resource is created with a POST to a 'parent' resource)

 If I implement it like this:

 public class MyResource extends ServerResource {

   @Override
   public void init() {
 // Perform initialization here
 setExists(true);
   }

   @Put
   public Representation storeRepresentation(Representation entity) {
 // Logic to change resource state here
   }

 }

 every time I make the PUT request to the resource I get a 404 (Not
 found) error. Now, if I add

 @Get
 public Representation represent() {
return new StringRepresentation(Toto, MediaType.TEXT_PLAIN);
 }

 the PUT request succeeds.

 Why should I code a dummy GET handler if I want my resource to answer
 PUT requests *only*? What and where should I put to be explicit enough
 that I only want the resource to answer PUT requests?

 Thanks in advance for your prompt and accurate answer



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

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


Possible bug in Restlet 1.2m2 (maybe solved in post 1.2m2?)

2009-05-25 Thread Fabian Mandelbaum
Hello,

I have a resource which should only accept PUT requests (to modify its
state; the resource is created with a POST to a 'parent' resource)

If I implement it like this:

public class MyResource extends ServerResource {

  @Override
  public void init() {
// Perform initialization here
setExists(true);
  }

  @Put
  public Representation storeRepresentation(Representation entity) {
// Logic to change resource state here
  }

}

every time I make the PUT request to the resource I get a 404 (Not
found) error. Now, if I add

@Get
public Representation represent() {
   return new StringRepresentation(Toto, MediaType.TEXT_PLAIN);
}

the PUT request succeeds.

Why should I code a dummy GET handler if I want my resource to answer
PUT requests *only*? What and where should I put to be explicit enough
that I only want the resource to answer PUT requests?

Thanks in advance for your prompt and accurate answer

-- 
Fabián Mandelbaum
IS Engineer

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


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 thierry.boil...@noelios.com

 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 thierry.boil...@noelios.com
  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 jerome.lou...@noelios.com
  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 iamk...@gmail.com
  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$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

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 thierry.boil...@noelios.com


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 thierry.boil...@noelios.com

 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 jerome.lou...@noelios.com
 � � 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 iamk...@gmail.com
 � � 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$SynchronizedCollection.add(Unknown
 � � Source)
 � �  � � � � B B B B B B B

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 jerome.lou...@noelios.com

  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 thierry.boil...@noelios.com

 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 thierry.boil...@noelios.com
  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 jerome.lou...@noelios.com
  � � 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 iamk...@gmail.com
  � � 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

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 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]
 *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 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$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=4447dsMessageId=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 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
 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 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=4447dsMessageId=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 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$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=4447dsMessageId=1909247

bug? - AccessControlException on Restlet GAE module

2009-04-18 Thread keke
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=4447dsMessageId=1790594

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 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)
 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=4447dsMessageId=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=4447dsMessageId=16205
18

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


Bug in HttpAmazonS3Helper class

2009-04-12 Thread MattyJ
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=4447dsMessageId=1620518


RE: ApplicationStatusFilter - bug ???

2008-12-23 Thread Jerome Louvel
Hi guys,

Very reasonable indeed. I've fixed the behavior in SVN branch 1.1 and in SVN 
trunk (with additional refactoring in the engine).

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 : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : jeudi 11 décembre 2008 17:30
À : discuss@restlet.tigris.org
Objet : Re: ApplicationStatusFilter - bug ???

Hello Rémi,

your suggestion looks really reasonnable.
As I'm not fully aware of the original design choice, I've entered an 
RFC = http://restlet.tigris.org/issues/show_bug.cgi?id=683

Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

 Hello,

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

 .isOverwrite(), application.getStatusService()
 .getContactEmail(), /);
 }
 instead of something like that :

 public ApplicationStatusFilter(Application application) {
 super(application.getContext(), application.getStatusService()
 .isOverwrite(), application.getStatusService()

 .getContactEmail(), 
 application.getStatusService().getHomeRef().getTargetRef().toString());
 }
 Because that way doing this on Application initialization has no effect:

 getStatusService().setHomeRef(new Reference(/some/path/));

 Cheers,
 Rémi

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

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


ApplicationStatusFilter - bug ???

2008-12-11 Thread Rémi Dewitte
Hello,

I just wonder if it is a bug having in ApplicationStatusFilter :

public ApplicationStatusFilter(Application application) {
super(application.getContext(), application.getStatusService()
.isOverwrite(), application.getStatusService()
.getContactEmail(), /);
}

instead of something like that :

public ApplicationStatusFilter(Application application) {
super(application.getContext(), application.getStatusService()
.isOverwrite(), application.getStatusService()
.getContactEmail(),
application.getStatusService().getHomeRef().getTargetRef().toString());
}

Because that way doing this on Application initialization has no effect:

getStatusService().setHomeRef(new Reference(/some/path/));

Cheers,
Rémi

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

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
 PreferenceMediaType(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



  1   2   >