Re: Restlet + Dojo?
Yes I am. Have a look at this: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/@http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos@/OFFERINGS/Buchensteige/observations (It's still a litte slow) Basically I use FreeMarker to dynamically generate HTML-representations of resources at runtime, including various Dojo elements. For example, one of them is a dojo-grid which uses the JSON-representation of the same resource as data-input for the grid embedded in the HTML-page. Greetings Ralf Justin Stanczak schrieb: Anyone using this combo? Any tips? Just wanted to give a shout out. I'm looking into using this combo, seems like a good fit. I would just use JSON services with Restlet resources.
Re: Restlet + Dojo?
Okay the link below seems to be broken: This should work: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/%40http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos%40/OFFERINGS/Buchensteige/observations Ralf Bommersbach schrieb: Yes I am. Have a look at this: http://restfulswe.iitb.fraunhofer.de/REST-SOS/CATALOGUE/SOSSEARCH/@http://stl-d-p11.htw-saarland.de:8080/52nSOSv3/sos@/OFFERINGS/Buchensteige/observations (It's still a litte slow) Basically I use FreeMarker to dynamically generate HTML-representations of resources at runtime, including various Dojo elements. For example, one of them is a dojo-grid which uses the JSON-representation of the same resource as data-input for the grid embedded in the HTML-page. Greetings Ralf Justin Stanczak schrieb: Anyone using this combo? Any tips? Just wanted to give a shout out. I'm looking into using this combo, seems like a good fit. I would just use JSON services with Restlet resources.
Re: Django’s Cache Framework
On Mon, Sep 15, 2008 at 11:40, Rob Heittman [EMAIL PROTECTED] wrote: I agree! Want to tack that reference on to http://restlet.tigris.org/issues/show_bug.cgi?id=25 ? Cool, done!
Django’s Cache Framework
Hi all, I thought this was interesting, and potentially relevant to Restlet and how it does caching. Ryan Tomayko linked to: http://docs.djangoproject.com/en/dev/topics/cache/ with the note: All frameworks should approach caching the way Django does. The core app/origin framework does no real caching but provides utility/helper methods for setting standard RFC 2616 cache related headers on the response easily and correctly. A completely separate set of caching goo (middleware) sits between your app and performs the actual caching based purely on the headers set by the origin. The benefit to this approach is that caching is totally independent from the app framework and can be swapped out for a true gateway (reverse proxy) cache at any time. here: http://tomayko.com/linkings/ (no direct link) -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: ObjectRepresentation and String encoding
Hi Thierry, Thierry Boileau wrote: I had a look at the issue and I don't see what's wrong. I was able to send a serialized object from a client using UTF-8 to a server using ISO-8859-1 without encoding issues. Could you send us a reproductible test case, and send us also the trace of the following code on both client and server side? I planned to write a reproducable test case, but I didn't get that far. I tried your small application first (the one attached to the bug report) and ran it directly on the server which uses ISO-8859-1. The server sent some data to itself and printed it on the console, so I guess there is no change in the encoding involved. The result that I got on the console was: Une cha�ne de caract�res. I could also reproduce it on another server with ISO-8859-1, but not on a third one which was configured for UTF-8. With UTF-8 I got the correct string: Une chaîne de caractères. I also tried to pipe the console output into a file, which I transferred to my development machine (which uses UTF-8). A simple cat of this file on the console showed question marks like above, but when I opened the same file on the same machine with a graphical editor (gedit), the special characters showed up correctly. I'm confused now, it seems to be an encoding issue which might not even be related to restlets. The questions are now: how do I solve it, and why does it work to transfer the special characters with the old version of my service, which does not use restlets (it uses Object-to-XML serialization over a socket). I also attached the requested system properties to this mail, one file with the settings from an ISO-8859-1 server, the other one with UTF-8. I don't know whether it helps you to find something, I couldn't see anything strange. Perhaps you have or somebody else on the list has some experience with problems related to character encodings, I'm out of ideas right now. Best regards, Hannes java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition sun.boot.library.path=/usr/lib/j2sdk1.5-sun/jre/lib/i386 java.vm.version=1.5.0_11-b03 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io sun.java.launcher=SUN_STANDARD user.country=US sun.os.patch.level=unknown java.vm.specification.name=Java Virtual Machine Specification user.dir=/mnt/user/home/ebner/test-case java.runtime.version=1.5.0_11-b03 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment java.endorsed.dirs=/usr/lib/j2sdk1.5-sun/jre/lib/endorsed os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. os.name=Linux sun.jnu.encoding=UTF-8 java.library.path=/usr/lib/j2sdk1.5-sun/jre/lib/i386/client:/usr/lib/j2sdk1.5-sun/jre/lib/i386:/usr/lib/j2sdk1.5-sun/jre/../lib/i386 java.specification.name=Java Platform API Specification java.class.version=49.0 sun.management.compiler=HotSpot Client Compiler os.version=2.6.18-6-686 user.home=/home/ebner user.timezone= java.awt.printerjob=sun.print.PSPrinterJob file.encoding=UTF-8 java.specification.version=1.5 java.class.path=test.jar user.name=ebner java.vm.specification.version=1.0 java.home=/usr/lib/j2sdk1.5-sun/jre sun.arch.data.model=32 user.language=en java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode, sharing java.version=1.5.0_11 java.ext.dirs=/usr/lib/j2sdk1.5-sun/jre/lib/ext sun.boot.class.path=/usr/lib/j2sdk1.5-sun/jre/lib/rt.jar:/usr/lib/j2sdk1.5-sun/jre/lib/i18n.jar:/usr/lib/j2sdk1.5-sun/jre/lib/sunrsasign.jar:/usr/lib/j2sdk1.5-sun/jre/lib/jsse.jar:/usr/lib/j2sdk1.5-sun/jre/lib/jce.jar:/usr/lib/j2sdk1.5-sun/jre/lib/charsets.jar:/usr/lib/j2sdk1.5-sun/jre/classes java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi sun.io.unicode.encoding=UnicodeLittle sun.cpu.endian=little sun.cpu.isalist= java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition sun.boot.library.path=/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386 java.vm.version=1.5.0_14-b03 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Server VM file.encoding.pkg=sun.io sun.java.launcher=SUN_STANDARD user.country=US sun.os.patch.level=unknown java.vm.specification.name=Java Virtual Machine Specification user.dir=/var/collaborilla-rest java.runtime.version=1.5.0_14-b03 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment java.endorsed.dirs=/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/endorsed os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. os.name=Linux sun.jnu.encoding=ISO-8859-1 java.library.path=/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/../lib/i386 java.specification.name=Java Platform API Specification java.class.version=49.0
Re: Django’s Cache Framework
I agree! Want to tack that reference on to http://restlet.tigris.org/issues/show_bug.cgi?id=25 ? - R On Mon, Sep 15, 2008 at 11:36 AM, Avi Flax [EMAIL PROTECTED] wrote: The core app/origin framework does no real caching but provides utility/helper methods for setting standard RFC 2616 cache related headers on the response easily and correctly.
RE: client-side support for Negotiate authentication scheme
Hi Roman, Bruno and all, Roman, thanks for reporting this parsing bug with WWW-Authenticate HTTP header. I have just fixed it in SVN trunk. Regarding the support for SPNEGO, I've updated the related RFE with a link to Bruno's original filter and another one back to this thread. I've also changed the target milestone of this RFE to 1.2 as it seems there is a good chance we could effectively add support for it. Support SPNEGO authentication http://restlet.tigris.org/issues/show_bug.cgi?id=444 It is indeed very important to be careful as soon as we copy and paste somebody else code, even for private play, as it might at some point leak out of our computers. Fortunately in this case Bruno is a gentleman :-) Roman, if we want to reuse your work to support SPNEGO in Restlet 1.2, here is the proper legal process that you will need to follow: - hope that Bruno (actually University of Manchester) effectively decides to contribute the original code to the Restlet project - wait for the code to be effectively contributed (ex: attached to the RFE or checked in SVN trunk) - based on this code, reapply your changes (or make sure Bruno's code hasn't changed since you worked on it!) - sign a Restlet JCA (see http://www.restlet.org/community/contribute) - contribute your changes as a patch or a set of new files It might seems like painful/useless legal work but it is in fact essential to keep Restlet copyright clean and to respect the rights of all copyright holders. Best regards, Jérôme 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 : Thierry Boileau [mailto:[EMAIL PROTECTED] Envoyé : jeudi 11 septembre 2008 11:59 À : discuss@restlet.tigris.org Objet : Re: client-side support for Negotiate authentication scheme Mail sent on the 08/28 and apparently lost. --- Hi Stephan, Roman, I think we will wait for the end of the vacations of Jérôme (11th of september). Anyway, thanks Roman for your effort! best regards, Thierry Boileau Stephan Koops a écrit : Hi Roman, nice for the code. Because I only changes the code of the JAX-RS extension, this is a job for Jerome or Thierry. I hope they will include it. best regards Stephan Roman Geus schrieb: Hi Stephan The NegotiateFilter, together with an example client and server is attached to this post. You are free to add this code to the Restlet codebase if you find it useful. Since I borrowed some ideas and code from Bruno Harbulot's SpnegoFilter, he should be consulted as well. Also IMHO more testing is needed. The README file: NegotiateFilter is a Restlet filter that implements Negotiate and Basic authentication on both the client and the server side. The server accepts both SPNEGO and Kerberos v5 GSSAPI tokens. It comes with a runnable test client and test server. The code has only been tested in a Windows Active Directory environment but should work with any Kerberos v5 infrastructure. The code has been tested with Restlet 1.1rc1 with a patched version of the com.noelios.restlet.authentication.AuthenticationUtils.parseAuthenticateHead er() method (see mailing list). The jaas.conf file and the some constants in ExampleClient.java and some system properties contain site-specific information and need to be adjusted. Also a working keytab file and krb5.conf file (or similar) are needed. See the *.launch file for information how to set the system properties. NegotiateFilter is based on Bruno Harbulot's SpnegoFilter. Roman Geus Cheers, Roman Stephan Koops wrote: Hi Roman, cool. Could you share the full filter class(es?) to be added to the Restlet API? best regards Stephan Roman Geus schrieb: Hi all I have been working on a Filter that implements client and server side HTTP Negotiate and Basic authentication. The code is based on Bruno Harbulot's nice SpnegoFilter. Everything works fine so far. However to get the client-side authentication working I had to change the parseAuthenticateHeader() method in the com.noelios.restlet.authentication.AuthenticationUtils class a bit. The original implementation (version 1.1rc1) fails to locate the correct AuthenticationHelper, if the realm parameter is missing in the authenticate header, as e.g. for the Negotiate scheme. Would it be possible to fix for this problem? The diff for my quick fix is attached. Best regards, Roman
Re: How to prevent access to nested directories?
Hi,
Now it seems to work for me, thanks.
2008/9/11 Thierry Boileau [EMAIL PROTECTED]:
Mail sent on the 08/22 and apparently lost.
---
Hi Carlos,
thanks again for your report, I've upated the svn repository. A new snapshot
(called unstable in the following page http://www.restlet.org/downloads/)
will be available tomorow morning.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Hi,
I want to restrict access to the nested directories inside the root
directory but I don't know how to accomplish this. I tried to set
deepaccessible property to false but doesn't work because I'm still
getting access to the directories within the ROOT_DIR.
Here's what I'm trying to do (using restlet-1.1m4):
@Override
public synchronized Restlet createRoot() {
Directory directory = new Directory(getContext(), file:///
+ ROOT_DIR);
directory.setDeeplyAccessible(false);
Router router = new Router(getContext());
router.attach(site,
Site.class).getTemplate().setMatchingMode(Template.MODE_EQUALS);
router.attach(files, directory);
return router;
}
Can anybody help me with this?
--
Carlos Alexandre Moscoso
