RE: [2.0 trunk] Using get(Variant) to return representation after PUT
Hi Bruno and Tim,
This is a good idea but I need to spend a little more time thinking about it
and the implementation. Ideally, it should be usable for all methods, not
just PUT. Id like to have some better factorized code, ideally using a
cache as suggested by Tim, so I entered a RFE:
Allow using get(Variant) to return representation after PUT
http://restlet.tigris.org/issues/show_bug.cgi?id=961
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 : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim
Peierls
Envoyé : mardi 17 novembre 2009 17:29
À : discuss@restlet.tigris.org
Objet : Re: [2.0 trunk] Using get(Variant) to return representation after
PUT
If your patch is accepted, it would be nice to have the logic in the first
else-clause cached (in a manner similar to that of
AnnotationUtils.getAnnotationDescriptors) so that it becomes a relatively
inexpensive map lookup on a Variant key.
It looks odd to me to mix the annotation approach with the non-annotation
approach in this way, but I can guess how you got to that point.
--tim
On Tue, Nov 17, 2009 at 11:06 AM, Bruno Harbulot
bruno.harbu...@manchester.ac.uk wrote:
Hello,
I've just tried a short-cut to return the representation after a PUT:
calling get(variant), but it doesn't work as if it was doing a direct
GET. I'm not sure if it's a just a bad idea or if we should try to make
it work.
The test case looks like this:
public MyClass extends ServerResource {
@Get(xml)
public Document toXml() {
return ...;
}
public Representation put(Representation input, Variant variant) {
// Do something with input.
return get(variant);
}
}
The problem with this approach is that 'variant' is not an instance of
'VariantInfo', so in ServerResource.get(Variant), doHandle isn't called:
if (variant instanceof VariantInfo) {
result = doHandle(((VariantInfo) variant).getAnnotationInfo(),
variant);
} else {
setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED);
}
To make get(variant) from a variant that's not a VariantInfo, something
like the following patch could work. I'm just not sure if it's worth
doing it this way. Any thoughts?
Best wishes,
Bruno.
diff --git
a/modules/org.restlet/src/org/restlet/resource/ServerResource.java
b/modules/org.restlet/src/org/restlet/resource/ServerResource.java
index 1dfee23..39dd86d 100644
--- a/modules/org.restlet/src/org/restlet/resource/ServerResource.java
+++ b/modules/org.restlet/src/org/restlet/resource/ServerResource.java
@@ -635,9 +635,31 @@ public abstract class ServerResource extends
UniformResource {
protected Representation get(Variant variant) throws
ResourceException {
Representation result = null;
+VariantInfo variantInfo = null;
+
if (variant instanceof VariantInfo) {
-result = doHandle(((VariantInfo) variant).getAnnotationInfo(),
-variant);
+variantInfo = (VariantInfo) variant;
+} else {
+ListVariant annoVariants = null;
+for (AnnotationInfo annotationInfo : getAnnotations()) {
+if (Method.GET.equals(annotationInfo.getRestletMethod())) {
+annoVariants = annotationInfo.getResponseVariants(null,
+getMetadataService(), getConverterService());
+if (annoVariants != null) {
+for (Variant v : annoVariants) {
+if (v.isCompatible(variant)) {
+variantInfo = new VariantInfo(variant,
+annotationInfo);
+break;
+}
+}
+}
+}
+}
+}
+
+if (variantInfo != null) {
+result = doHandle(variantInfo.getAnnotationInfo(), variant);
} else {
setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED);
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2419
000 dsMessageId=2419000
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426265
RE: logging framework for restlet
FYI, I've just entered a related RFE: Facilitate usage of a custom LoggerFacade in Servlet mode http://restlet.tigris.org/issues/show_bug.cgi?id=962 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é : vendredi 20 novembre 2009 09:25 À : discuss@restlet.tigris.org Objet : Re: logging framework for restlet Hello Arjohn, as a quick workaround, you can inherit from the ServerServlet and override the init method. Then, register your own ServerServlet class in the web.xml configuration file: servlet-classmy.package.MyServerServlet/servlet-class Best regards, Thierry Boileau Hi Jerome, Some feedback as promised: I am now setting the system property in the class that creates and starts the Component. Routing log request works like a charm in this setup. For users the prefer a simple war-file we're also offering an alternative using the ServerServlet wrapper. I don't know yet how to reroute the logging in this case. ServerServlet works on an Application so the Engine likely already has been initialized by the time the Application class is created. It's too late to set the system property then. Any suggestions? Arjohn Arjohn Kampman wrote: Hi Jerome, Many thanks. I'll have a look at this as soon as possible and let you know the results. Arjohn Jerome Louvel wrote: Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! Best regards, Jerome Louvel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24200 41 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24204 42 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426268
Re: logging framework for restlet
OK, thanks. I guess adding an initialization parameter to ServerServlet would be a possible solution. Arjohn Jerome Louvel wrote: FYI, I've just entered a related RFE: Facilitate usage of a custom LoggerFacade in Servlet mode http://restlet.tigris.org/issues/show_bug.cgi?id=962 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é : vendredi 20 novembre 2009 09:25 À : discuss@restlet.tigris.org Objet : Re: logging framework for restlet Hello Arjohn, as a quick workaround, you can inherit from the ServerServlet and override the init method. Then, register your own ServerServlet class in the web.xml configuration file: servlet-classmy.package.MyServerServlet/servlet-class Best regards, Thierry Boileau Hi Jerome, Some feedback as promised: I am now setting the system property in the class that creates and starts the Component. Routing log request works like a charm in this setup. For users the prefer a simple war-file we're also offering an alternative using the ServerServlet wrapper. I don't know yet how to reroute the logging in this case. ServerServlet works on an Application so the Engine likely already has been initialized by the time the Application class is created. It's too late to set the system property then. Any suggestions? Arjohn Arjohn Kampman wrote: Hi Jerome, Many thanks. I'll have a look at this as soon as possible and let you know the results. Arjohn Jerome Louvel wrote: Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! Best regards, Jerome Louvel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24200 41 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24204 42 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426268 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426271
Re: Case-insensitive version of Series.getValuesArray(...)
FYI: I've verified the fix using the current snapshot code. Works like a charm now :-) Arjohn Thierry Boileau wrote: Hi Arjohn, Should the case-sensitive variant be modified to call this method? Sure! Best regards, Thierry Boileau Wow, that was quick! Thanks for the fix. Should the case-sensitive variant be modified to call this method? All case-sensitive methods except getValuesArray are implemented that way. Arjohn Hello Arjohn, thanks for your report, the fix is now available in the svn repository. Best regards, Thierry Boileau Hi Jerome, I've finally been able to test this new method. Unfortunately, it's implementation is broken. Calling Series.getValuesArray(String name, boolean ignoreCase) results in a ClassCastException. Looking into the code, it looks like this method is casting a array of type E (e.g. Parameter) to an array of String's. Arjohn Jerome Louvel wrote: Hi Arjohn, Good point, I've just added such method in SVN trunk! 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 : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] Envoyé : lundi 4 mai 2009 15:41 À : discuss@restlet.tigris.org Objet : Case-insensitive version of Series.getValuesArray(...) Hi all, I've just started working with the restlet framework, so please excuse me if I'm overlooking something. In Restlet 1.1.4 the Series class offers various utility methods for getting parameter values, often with a variant allowing you to control the case-sensitivity. This variant is missing for getValuesArray(), however, which is what I'd like to use. Can this method be added? Regards, Arjohn Kampman -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=20565 27 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2261414 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420017 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420050 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426273
RE: How use header: HTTP_X_FORWARDED_FOR with jetty, restlet, nginx
Hi Eugene,
To make this variable available, you need to set the useForwardedForHeader
parameter to true in your HTTP server connector's context.
In Servlet mode, this is trickier. I would suggest to create a subclass o
SpringServerServlet, overriding the createServer() method and call
getContext().getParameters().add(useForwardedForHeader, true);
on the result of the super.createServer() method.
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 : Eugene Batogov [mailto:johnba...@gmail.com]
Envoyé : vendredi 20 novembre 2009 14:06
À : discuss@restlet.tigris.org
Objet : How use header: HTTP_X_FORWARDED_FOR with jetty, restlet, nginx
Hello all.
I use Restlet-2.0m5 with Jetty-6.1.21 via
org.restlet.ext.spring.SpringServerServlet.
I use nginx at front-end;
MY TASK: I need to receive real IP client browser in resources and Log
Service.
I try configure LogTemplate so:
property name=logFormat value=IP:{cia} Real-IP: {ciua}
{m} {S} {rp} AGENT:{cig}REF:{fp} /
But {ciua} returned front-end address, i.e. IP = Real-IP
In Jetty enabled forwarded:
Call name=addConnector
Arg
New class=org.mortbay.jetty.nio.SelectChannelConnector
Set name=portSystemProperty name=jetty.port
default=8080//Set
Set name=maxIdleTime3/Set
Set name=Acceptors2/Set
Set name=confidentialPort8443/Set
Set name=forwardedtrue/Set
/New
/Arg
/Call
In nginx I set next:
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_headerHost $http_host;
But in LogService I don't get Real-IP of client
Q: How I may receive REAL IP of client, which work via proxy or front-end
(nginx)?
--
Best Regards, Eugene Batogov
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24205
21
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426281
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
RE: Restlet translated in CIL (dotNet) with IKVM
Hi Xavier, Thanks for the additional info about db4o, I’ve added a comment to the RFE. Definitely something to experiment with when we get a chance. 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 : xavier.meh...@gmail.com [mailto:xavier.meh...@gmail.com] De la part de Xavier Méhaut Envoyé : mardi 1 décembre 2009 16:44 À : discuss@restlet.tigris.org Objet : Re: Restlet translated in CIL (dotNet) with IKVM It is a project which has been ongoing since 2004, and the developer is clever. For information DB4O use it for working on dotNet too. regards Xavier 2009/12/1 Jerome Louvel jerome.lou...@noelios.com Hello Xavier, IKVM looks like a great tool indeed. I would also be interested to learn how well it works with Restlet. I’ve added a related comment to this RFE: “Port to .NET platform” http://restlet.tigris.org/issues/show_bug.cgi?id=106 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 : xavier.meh...@gmail.com [mailto:xavier.meh...@gmail.com] De la part de Xavier Méhaut Envoyé : mardi 1 décembre 2009 11:41 À : discuss@restlet.tigris.org Objet : Restlet translated in CIL (dotNet) with IKVM Hello, I would like to knwo if someone has already tried to compile restlets into CIL (dotNet) with IKVM? Is so, it would open Restlets to the dotnet world on the server side without a lot of pain. regards Xavier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426292
RE: Data Services Ext for Android?
Hi Luiz, I don't see any reason why this extension shouldn't work on Android as well. Using the JAR from the Java SE/EE editions should work, but we'll make sure to fix the distribution. I've just entered this RFE: Support additional extensions on Android http://restlet.tigris.org/issues/show_bug.cgi?id=960 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 : Luiz Alberto [mailto:luiz...@gmail.com] Envoyé : mardi 1 décembre 2009 18:55 À : discuss@restlet.tigris.org Objet : Data Services Ext for Android? I had downloaded Restlet for Android, M6, and not found org.restlet.ext.dataservices extension. I'snt supported? Will implement in future versions? Can I use Java DataServices extensions directed in Android? Thanks all and sorry by bad english. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24259 41 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426293
Empty HTTP WWW-Authenticate header in response
Hi, I implemented a custom Guard that handles multiple authentications, e.g. HTTP Simplem, Amazon S3 (my own AmazonS3ServerHelper implementation), etc. According to HTTP spec., the server responses the WWW-Authenticate header(s) when credentials are not provided in the request. So my code had lines like: final ListChallengeRequest list = new CopyOnWriteArrayListChallengeRequest(); list.add(new ChallengeRequest(ChallengeScheme.HTTP_BASIC, HTTP Simple Authentication)); list.add(new ChallengeRequest(ChallengeScheme.HTTP_AWS_S3, Amazon S3 Authentication)); //list.add(new ChallengeRequest(ChallengeScheme.HTTP_AWS, Amazon S3 Authentication)); list.add(new ChallengeRequest(ChallengeScheme.HTTP_OAUTH, HTTP OAuth Authentication)); response.setChallengeRequests(list); However, the HTTP response looks like: HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 Date: WWW-Authenticate: Basic realm=MRSP Simple Authentication WWW-Authenticate: WWW-Authenticate: OAuth realm=HTTP OAuth Authentication Accept-Ranges: bytes ... The header value for Amazon S3 was empty. Does anyone know what and where it's wrong? BRs, Yu -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426314
Re: CAS authentication in Restlet server
Hi Jerome, Thanks for the pointer, it was very useful. I think I'm starting to see the picture now. I'm a bit confused about the various places where a Verifier is referenced. I've seen such references in Context, ChallengeAuthenticator and Realm. I assume that the context's verifier serves as a default for the ChallengeAuthenticator in that context. The distinction betwee these two and Realm isn't very clear to me yet. What's the role of these verifiers and when should I use which option? Arjohn Jerome Louvel wrote: Hi Arjohn, That would be a nice contribution indeed! Regarding the security API, the best for now is our specification page: Security API refactoring http://wiki.restlet.org/developers/172-restlet/212-restlet.html Feel free to post questions here if needed. We'll cover this topic in the book and make sure to update the existing docs for 2.0 final. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426362
Obtaining ServletContext in 2.0-M5
In restlet 2.0-M5, from a ServerResource attached to a router used as the root of a SpringComponent and served from a SpringServerServlet, I had to do the following to get the ServletContext: ServletContext servletContext = (ServletContext) getContext().getServerDispatcher().getContext() .getAttributes().get(org.restlet.ext.servlet.ServletContext); Is this the recommended way to get the ServletContext? Ben -- View this message in context: http://n2.nabble.com/Obtaining-ServletContext-in-2-0-M5-tp4100861p4100861.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426398
Re: CAS authentication in Restlet server
Hi Rhett, others, Thanks for your suggestion. Since I'm fairly new to the subject, I hope you (and others) can help me a bit to get things clear. If I understand you correctly, you are suggesting to use a CAS proxy ticket as an authentication token. However, such a token can only be sent once to a CAS server for verification. This very much looks like a problem for (preemptive) authentication in consecutive requests. Or am I overlooking something? Regards, Arjohn Rhett Sutphin wrote: If I were adding support for just CAS, I would define a new challenge scheme (call it something like cas_proxy_ticket) and define a Guard and AuthenticationHelper pair which handle this scheme. This would mean that a client would need to acquire a proxy ticket and then include it in the HTTP request as the Authentication header, something like Authentication: cas_proxy_ticket PT-123456789 Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426434
IE 8 HTML request not working
Has any found this problem. Firefox and Chrome get directed to the HTML
output, but IE 8 is being routed to the JSON call.
class SampleResource extends ServerResource {
@Get(html)
def asHtml() = {
new StringRepresentation(h1Hello World/h1.toString,
MediaType.TEXT_HTML)
}
@Get(json)
def asJson() = {
new StringRepresentation({message:hello world},
MediaType.APPLICATION_JSON)
}
}
object RestlyServer {
def main(args:Array[String]) {
val component = new Component
component.getServers.add(Protocol.HTTP, 8080)
//component.getDefaultHost.attach(new blog.BlogApplication)
component.getDefaultHost.attachDefault(classOf[SampleResource])
component.start
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426468
Re: Obtaining ServletContext in 2.0-M5
I'm also interested to know if there's a better way, but you can also shorten that a bit to: ServletContext sc = (ServletContext) getContext().getAttributes().get(org.restlet.ext.servlet.ServletContext); On Wed, Dec 2, 2009 at 8:57 AM, BenT ben.tomas...@gmail.com wrote: In restlet 2.0-M5, from a ServerResource attached to a router used as the root of a SpringComponent and served from a SpringServerServlet, I had to do the following to get the ServletContext: ServletContext servletContext = (ServletContext) getContext().getServerDispatcher().getContext() .getAttributes().get(org.restlet.ext.servlet.ServletContext); Is this the recommended way to get the ServletContext? Ben -- View this message in context: http://n2.nabble.com/Obtaining-ServletContext-in-2-0-M5-tp4100861p4100861.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426398 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426422
Re: CAS authentication in Restlet server
Hi Arjohn, On Dec 2, 2009, at 12:34 PM, Arjohn Kampman wrote: Hi Rhett, others, Thanks for your suggestion. Since I'm fairly new to the subject, I hope you (and others) can help me a bit to get things clear. If I understand you correctly, you are suggesting to use a CAS proxy ticket as an authentication token. However, such a token can only be sent once to a CAS server for verification. This very much looks like a problem for (preemptive) authentication in consecutive requests. Or am I overlooking something? That's correct. When the client application is using proxy tickets for authentication, it needs to get a new proxy ticket from the CAS server for each request. This was intentional in the design of CAS. Rhett Regards, Arjohn Rhett Sutphin wrote: If I were adding support for just CAS, I would define a new challenge scheme (call it something like cas_proxy_ticket) and define a Guard and AuthenticationHelper pair which handle this scheme. This would mean that a client would need to acquire a proxy ticket and then include it in the HTTP request as the Authentication header, something like Authentication: cas_proxy_ticket PT-123456789 Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426434 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426475
Re: IE 8 HTML request not working
Yes, I have found the same behaviour, and not only with IE8, but with IE7 too.
The problem seems to be that IE sends an Accept: */* HTTP header and
Restlet's content negotiation logic is providing the default
representation, in your case JSON (in mine XML), for the Resource.
All the other major browsers (Firefox, Safari, Opera, Chrome) send the
correct text/html media type in their Accept HTTP header, thus making
things work as expected (as usual).
As a workaround you could add browser sniffing code targetting IE on
your Restlet/Resource class(es), and if IE is detected provide it with
the HTML representation. It may prove to be lots of work, but this is
not really Restlet's fault, but IE's (why a web browser would accept
anything other than the usual expected web media types, and even more
accept ANYTHING as the sole representation of a web resource, is
really out of my understanding).
Hope this helps.
On Wed, Dec 2, 2009 at 5:52 PM, Erick Fleming efleming...@gmail.com wrote:
Has any found this problem. Firefox and Chrome get directed to the HTML
output, but IE 8 is being routed to the JSON call.
class SampleResource extends ServerResource {
@Get(html)
def asHtml() = {
new StringRepresentation(h1Hello World/h1.toString,
MediaType.TEXT_HTML)
}
@Get(json)
def asJson() = {
new StringRepresentation({message:hello world},
MediaType.APPLICATION_JSON)
}
}
object RestlyServer {
def main(args:Array[String]) {
val component = new Component
component.getServers.add(Protocol.HTTP, 8080)
//component.getDefaultHost.attach(new blog.BlogApplication)
component.getDefaultHost.attachDefault(classOf[SampleResource])
component.start
}
}
--
Fabián Mandelbaum
IS Engineer
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426491
Re: Obtaining ServletContext in 2.0-M5
I tried that, but the map of attributes for the context was empty. I had to obtain the context getServerDispatcher().getContext() in order to get a populated attribute map. Ben On Wed, Dec 2, 2009 at 10:15 AM, Ben R Vesco bve...@gmail.com wrote: I'm also interested to know if there's a better way, but you can also shorten that a bit to: ServletContext sc = (ServletContext) getContext().getAttributes().get(org.restlet.ext.servlet.ServletContext); On Wed, Dec 2, 2009 at 8:57 AM, BenT ben.tomas...@gmail.com wrote: In restlet 2.0-M5, from a ServerResource attached to a router used as the root of a SpringComponent and served from a SpringServerServlet, I had to do the following to get the ServletContext: ServletContext servletContext = (ServletContext) getContext().getServerDispatcher().getContext() .getAttributes().get(org.restlet.ext.servlet.ServletContext); Is this the recommended way to get the ServletContext? Ben -- View this message in context: http://n2.nabble.com/Obtaining-ServletContext-in-2-0-M5-tp4100861p4100861.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426398 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426422 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426537
