bug with SpringFinder?
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?
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?
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?
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??
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
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??
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
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
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??
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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?
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
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
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
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.org 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
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
[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
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
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
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
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
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?
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?
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
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.org 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
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.org 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
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
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?
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?
Hi Dave and Tim,
This is an edge case, but I think we can safely check if there is already an
available response entity before replacing it with the result. Ive changed
the test to this in SVN trunk and added a note in the Javadocs:
if (!getResponse().isEntityAvailable()) {
// If the user manually set the entity, keep it
getResponse().setEntity(result);
}
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim
Peierls
Envoyé : mercredi 12 mai 2010 14:36
À : discuss@restlet.tigris.org
Objet : Re: Bug in ServerResource.handle() when using annotated methods?
On Tue, May 11, 2010 at 5:06 PM, David Fogel 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
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?
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
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?
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?
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?
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)
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)
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)
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)
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)
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
Hi guys, After double checking, there was a bug. Parameters are actually part of the media type name, so toString() shouldnt add those parameters again. Ive fixed the issue in SVN trunk and also improved the behavior of getParent() to return an instance of MediaType without parameters if possible first. See test case added: MediaType mediaType = MediaType.valueOf(application/atom+xml; name=value); assertEquals(application/atom+xml; name=value, mediaType.toString()); assertEquals(MediaType.APPLICATION_ATOM, mediaType.getParent()); Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com De : Thierry Boileau [mailto:thierry.boil...@noelios.com] Envoyé : lundi 25 janvier 2010 12:02 À : discuss@restlet.tigris.org Objet : Re: Bug in MediaType Parameter handling Hello Carsten, the current contract of the valueOf method is to use a name such as application/atom+xml instead of a complete string with the parameters. In your case, you can use the ContentType constructor with the String parameter. Best regards, Thierry Boileau Hi, when I do the following: --- MediaType mediaType = MediaType.valueOf(application/atom+xml; charset=UTF-8); System.out.println(mediaType.toString()); --- I get this output (with 2.0M6): application/atom+xml; charset=UTF-8; charset=UTF-8 Seems to be a bug in the handling of parameters. Cheers, Carsten -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2441 619 dsMessageId=2441619 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2449981
Re: Bug in OAuthHelper?
Hello Yu,
Thanks for your report. I've entered an issue for that:
http://restlet.tigris.org/issues/show_bug.cgi?id=1034
Best regards,
Thierry Boileau
Hi,
When I use Restlet (Acutally Noelios) OAuth together with OAuth lib from
Netflix, there's inconsistent in handling OAuth and non-oauth parameters and
causes invalid signature exception later on in
Noelios OAuthHelper saves all parameters (OAuth and Query parameters, for
example) into its OAuthMessage's arrtibutes.
see the code snippet from OAuthHelper.java:
// Query parameters.
for (final org.restlet.data.Parameter p : request.getResourceRef()
.getQueryAsForm()) {
parameters.add(new OAuth.Parameter(p.getName(), p.getValue()));
}
However, in Netflix's OAuthSignatureMethod class, the function validate
where the signature of the base string is calculated from both the
OAuthMessage arrtibutes PLUS the request parameters. See the code snippets in
the function getBaseString(OAuthMessage message)
parameters = new 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?
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
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
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
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
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
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
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
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
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
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()
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
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
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()
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
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
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
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
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
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?
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?
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?
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?
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?
Hi Schley, FYI, this has been fixed in SVN trunk. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Schley Andrew Kutz a écrit : I want to prevent the use of HTTP VERB annotations in order to force sub-classes to respond with specific class types via abstract methods that I prototype in a base class. I marked the isAnnotated() method as @Override and final and returned false. However, when it returns false I get the following error: java.lang.NullPointerException at org .restlet .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106) at org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 649) at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 329) at org .restlet .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) at org .restlet .resource.ServerResource.doConditionalHandle(ServerResource.java:260) at org.restlet.resource.ServerResource.handle(ServerResource.java:921) at com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 159) at org.restlet.resource.Finder.handle(Finder.java:510) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org .restlet .engine.application.ApplicationHelper.handle(ApplicationHelper.java:71) at org.restlet.Application.handle(Application.java:396) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org.restlet.Component.handle(Component.java:397) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org .mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 505) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 395) at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:488) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2368118
Re: bug?
Great! I'm really looking forward to this and the OnError bit making it into a release. :) -- -a Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts. -- L. Stein On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: Hi Schley, FYI, this has been fixed in SVN trunk. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Schley Andrew Kutz a écrit : I want to prevent the use of HTTP VERB annotations in order to force sub-classes to respond with specific class types via abstract methods that I prototype in a base class. I marked the isAnnotated() method as @Override and final and returned false. However, when it returns false I get the following error: java.lang.NullPointerException at org .restlet .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: 106) at org .restlet.resource.ServerResource.getAnnotation(ServerResource.java: 649) at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 329) at org .restlet .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) at org .restlet .resource.ServerResource.doConditionalHandle(ServerResource.java:260) at org.restlet.resource.ServerResource.handle(ServerResource.java: 921) at com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 159) at org.restlet.resource.Finder.handle(Finder.java:510) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org .restlet .engine.application.ApplicationHelper.handle(ApplicationHelper.java: 71) at org.restlet.Application.handle(Application.java:396) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org.restlet.Component.handle(Component.java:397) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 362) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 152) at org .mortbay .jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 505) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
bug?
I want to prevent the use of HTTP VERB annotations in order to force sub-classes to respond with specific class types via abstract methods that I prototype in a base class. I marked the isAnnotated() method as @Override and final and returned false. However, when it returns false I get the following error: java.lang.NullPointerException at org .restlet .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106) at org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 649) at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 329) at org .restlet .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) at org .restlet .resource.ServerResource.doConditionalHandle(ServerResource.java:260) at org.restlet.resource.ServerResource.handle(ServerResource.java:921) at com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 159) at org.restlet.resource.Finder.handle(Finder.java:510) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org .restlet .engine.application.ApplicationHelper.handle(ApplicationHelper.java:71) at org.restlet.Application.handle(Application.java:396) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org.restlet.Component.handle(Component.java:397) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org .mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 505) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 395) at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:488) -- -a 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?)
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?)
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
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
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
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
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
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
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
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
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
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
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 ???
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 ???
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
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
