No available xxx connector supports the required protocols
hello, i'm a new user to the RESTlet library and i'm having problems getting few things done. i would appreciate it if a seasoned user can point me to some documentation which can help me solve my problems. i'll describe later the make-up of the test application in case it's known to have a bearing on the problems: 1. in my browser when i enter the url to the resource/page i want to go to i see in the logs the following: Nov 19, 2008 8:16:06 PM org.restlet.Connector FINE: The connector has been instantiated without any protocol. Nov 19, 2008 8:16:06 PM com.noelios.restlet.Engine createHelper WARNING: No available client connector supports the required protocols: 'CLAP' 'FILE' 'HTTP' 'HTTPS' . Please add the JAR of a matching connector to your classpath. Nov 19, 2008 8:16:06 PM com.noelios.restlet.Engine createHelper WARNING: No available server connector supports the required protocols: 'HTTP' 'HTTPS' . Please add the JAR of a matching connector to your classpath. Nov 19, 2008 8:16:06 PM org.restlet.Connector FINE: The connector has been instantiated without any protocol. Nov 19, 2008 8:16:06 PM org.restlet.Connector FINE: The connector has been instantiated without any protocol. Nov 19, 2008 8:16:06 PM org.restlet.Connector FINE: The connector has been instantiated without any protocol. Nov 19, 2008 8:16:06 PM org.restlet.Connector FINE: The connector has been instantiated without any protocol. the Application is wired with a restlet.xml that has the following elements; ... ... my WEB-INF/lib folder contains the required (i think) JARs: com.noelios.restlet-1.1.1.jar, c.n.r.ext.servlet-1.1.1.jar, c.n.r.e.simple-1.1.1.jar, org.restlet-1.1.1.jar and o.r.ext.freemarker-1.1.1.jar. am i missing a JAR? can i ignore the warnings? 2. the example uses a hard-coded path for configuring FreeMarker. wanting to experiment with the restlet API i tried to use an "initParam" name-value to pass this path to my Application but so far unsuccessfully. i interpreted the c.n.r.ext.servlet.ServerServlet javadoc part about the initParameters to mean as follows (in my webapp web.xml): RestletServlet ...ServerServlet myParamName myParamValue and tried to get it from both the context getAttributes() and getParameters() methods but they both return an empty collection in the constructor of my Application as well as in the createRoot method. i tested also the assumption that the Context returned could be a ServletContextAdapter in the hope that i can then getServletContext() on it and invoke getInitParamater(xxx) but it wasn't. how can i access from my Application or Filter such parameters? in case it matters, my test application is a modified version of the book ch8 example running in Tomcat 6.0.18 and protected by a in the web.xml. the config.xml of this webapp uses a JDBCRealm to check user credentials from a database. thanks in advance for any help + cheers; rsn signature.asc Description: This is a digitally signed message part.
Re: No available xxx connector supports the required protocols
salut Thierry,
thanks for your prompt response. my comments are in-line.
On Friday 21 November 2008 03:24:26 am Thierry Boileau wrote:
> Hello Raif,
>
> I have several remarks.
>
> I think you can remove the following parameter which is useless in a
> context of a servlet container (you can see this tutorial
> http://www.restlet.org/documentation/1.1/firstSteps):
>
noted.
> I would like to add also that c.n.r.e.simple.jar is not required here
> since the servlet container can be considered as the HTTP/HTTPS
> connector.
noted.
> Regarding the trace log, this kind of trace is only informative and
> can't be interpreted as a warning:
> FINE: The connector has been instantiated without any protocol.
>
> Regarding this part of the configuration, it means that from your
> application, you will send requests with these protocols:
>
> That means also that your classpath must contain the client connectors
> that support these protocols. If you have a look at this page [1] taken
> from the wiki (http://wiki.restlet.org, or
> http://www.restlet.org/documentation/1.1/ and choose "User Guide"), you
> will see that the HTTPS protocol is supported by either the Apache
> HttpClient based client connector or the JDK based client connector. So
> you need to complete the WEB-INF/lib folder.
noted. once i added the c.n.r.ext.httpclient dependency the WARNING
disappeared.
> Finally, I succeed in getting parameter value as follow:
> getContext().getParameters().getFirstValue("myParamName");
well i tried with both 1.1.0 and 1.1.1 jars unsuccessfully. i also tried
introspecting the context from a Filter but again without success.
the User Guide (at the end of section 2.12.2.1 Handling of context) seems to
justify why i'm not able to get hold of an init-param: "Another consequence
is that parameters or attributes are not copied from the component to the
application by the default implementation of the
Context#createChildContext() method which is typically used to prepare the
Application's context based on the parent Component's context."
am i mis-interpreting this paragraph, or simply confusing Component with
ServerServlet?
> Could you provide a sample test case?
let me know what is needed and i can zip and email you (off the list may be)
the files.
> I hope I forget nothing,
>
> [1]
> http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html
thanks for your help.
> Best regards,
> Thierry Boileau
> --
> Restlet ~ Core developer ~ http://www.restlet.org
>
Re: No available xxx connector supports the required protocols
salut Thierry,
thank you muchly for spending so much time on this :-) really appreciate
it.
i installed your test application and ran it and it worked ok. but since it
does not reflect the environment i described in my initial post, i started
changing the configuration to resemble my setup. it was enough to
configure the application through a restlet.xml file for the parameters to
return null. of course i could have mis-configured the application but if
that was the case i would've expected to receive some message or an
exception not the resource page itself.
i'm attaching the modified web.xml and the new restlet.xml that reproduce
the problem --start the webapp and in your browser goto
http://localhost:8080/RestletTestServlet/ the page returned shows:
contextParam=null initParam=null
On Monday 24 November 2008 09:14:31 pm Thierry Boileau wrote:
>
>
>
>
>
>
> Hello Raif,
>
> I send you a sample Eclipse project that works correctly for me (with
> last Restlet snapshot).
> http://www.noelios.com/";>The application is not based on
> customized Component and ServerServlet. In this case, parameters are
> directly copied from the Servlet context to the Application context.
> In addition the default behaviour of the ServerServlet class is to copy
> parameters also into the context of the Component. style="font-family: Tahoma,arial,sans-serif; font-size: 10pt;"> style="font-family: Tahoma,arial,sans-serif; font-size:
> 10px;">
>
>
> type="cite">
>
> Finally, I succeed in getting parameter value as follow:
> getContext().getParameters().getFirstValue("myParamName");
>
>
> well i tried with both 1.1.0 and 1.1.1 jars
> unsuccessfully. i also tried introspecting the context from a Filter but
> again without success.
>
> the User Guide (at the end of section 2.12.2.1 Handling of context) seems
> to justify why i'm not able to get hold of an init-param: "Another
> consequence is that parameters or attributes are not copied from the
> component to the application by the default implementation of the
> Context#createChildContext() method which is typically used to prepare
> the Application's context based on the parent Component's context."
>
> am i mis-interpreting this paragraph, or simply confusing Component with
> ServerServlet?
>
>
> Yes, you just made the confusion between
> Component and ServerServlet.
>
> type="cite">
>
> Could you provide a sample test case?
>
>
> let me know what is needed and i can zip and email
> you (off the list may be) the files.
>
>
> Generally the source code (with
> configuration files) is sufficient. Could you try the sample code and
> tells us if it works for you?
>
>
> Best regards,
> Thierry Boileau
> --
>
> Restlet ~ Core developer ~
> href="http://www.restlet.org/";>http://www.restlet.orgr> Noelios Technologies ~ Co-founder ~ style="color: rgb(0, 64, 128);"> href="http://www.noelios.com/";>http://www.noelios.comspan>
>
cheers;
rsn
http://www.restlet.org/schemas/1.1/Component";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.restlet.org/schemas/1.1/Component";>
Test Restlet Servlet
contextParam
contextParamValue
RestletServlet
com.noelios.restlet.ext.servlet.ServerServlet
initParam
initParamValue
RestletServlet
/*
signature.asc
Description: This is a digitally signed message part.
Re: No available xxx connector supports the required protocols
salut Thierry,
On Wednesday 26 November 2008 08:54:29 pm Thierry Boileau wrote:
> Hello Raif,
>
> at this time, servlet parameters are only copied into the application's
> context when using the "org.restlet.application" parameter in the
> "web.xml" file...
noted.
> I'm looking for a way to transmit them to the attached restlets when
> using the "restlet.xml" file.
good news. this way configuring an Application will be consistent across
the different mechanisms.
> Best regards,
> Thierry Boileau
> --
> Restlet ~ Core developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
> > salut Thierry,
> >
> > thank you muchly for spending so much time on this :-) really
> > appreciate it.
> >
> >
> > i installed your test application and ran it and it worked ok. but
> > since it does not reflect the environment i described in my initial
> > post, i started changing the configuration to resemble my setup. it
> > was enough to configure the application through a restlet.xml file for
> > the parameters to return null. of course i could have mis-configured
> > the application but if that was the case i would've expected to receive
> > some message or an exception not the resource page itself.
> >
> > i'm attaching the modified web.xml and the new restlet.xml that
> > reproduce the problem --start the webapp and in your browser goto
> > http://localhost:8080/RestletTestServlet/ the page returned shows:
> >
> > contextParam=null initParam=null
> >
> > On Monday 24 November 2008 09:14:31 pm Thierry Boileau wrote:
> >>
> >>
> >>
> >>>> http-equiv="Content-Type">
> >>
> >> Hello Raif,
> >>
> >> I send you a sample Eclipse project that works correctly for me (with
> >> last Restlet snapshot).
> >> http://www.noelios.com/";>The application is not based on
> >> customized Component and ServerServlet. In this case, parameters are
> >> directly copied from the Servlet context to the Application
> >> context. In addition the default behaviour of the ServerServlet
> >> class is to copy parameters also into the context of the
> >> Component.
> >>
> >>
> >> >> type="cite">
> >>
> >> Finally, I succeed in getting parameter value as
> >> follow: getContext().getParameters().getFirstValue("myParamName");
> >>
> >>
> >> well i tried with both 1.1.0 and 1.1.1 jars
> >> unsuccessfully. i also tried introspecting the context from a Filter
> >> but again without success.
> >>
> >> the User Guide (at the end of section 2.12.2.1 Handling of context)
> >> seems to justify why i'm not able to get hold of an init-param:
> >> "Another consequence is that parameters or attributes are not copied
> >> from the component to the application by the default implementation of
> >> the Context#createChildContext() method which is typically used to
> >> prepare the Application's context based on the parent Component's
> >> context."
> >>
> >> am i mis-interpreting this paragraph, or simply confusing Component
> >> with ServerServlet?
> >>
> >>
> >> Yes, you just made the confusion
> >> between Component and ServerServlet.
> >>
> >> >> type="cite">
> >>
> >> Could you provide a sample test case?
> >>
> >>
> >> let me know what is needed and i can zip and
> >> email you (off the list may be) the files.
> >>
> >>
> >> Generally the source code (with
> >> configuration files) is sufficient. Could you try the sample code and
> >> tells us if it works for you?
> >>
> >>
> >> Best regards,
> >> Thierry Boileau
> >> --
> >>
> >> Restlet ~ Core developer ~ >>
> >> href="http://www.restlet.org/";>http://www.restlet.org >>> Noelios Technologies ~ Co-founder ~ >> style="color: rgb(0, 64, 128);"> >> href="http://www.noelios.com/";>http://www.noelios.com >>>
> >>
> >
> > cheers;
> > rsn
--
cheers;
rsn
signature.asc
Description: This is a digitally signed message part.
Re: No available xxx connector supports the required protocols
salut Jerome,
On Thursday 27 November 2008 01:43:31 am Jerome Louvel wrote:
> Hi all,
>
> My opinion is that we shouldn't blindly copy the parameters from a
> Component to an Application. This is important for security purpose and
> to properly isolate applications hosted in the same component.
that's fine as long as IMO it's consistent across the different
configuration mechanisms. there probably are/will be cases where one would
want to share some parameters between Applications in a Component.
as a side-note, i see in the Component schema a "parameter" element in
the "ComponentType" type. where can i find more documentation about this
element?
> In your case, you should make sure that your custom Component manually
> copies the required parameters to the Application(s) that really need
> them. To pass parameters to an application, you should do that in your
> Component subclass:
>
> // Prepare the application context
> Context appContext = getContext().createChildContext();
> appContext.getParameters().add(getContext().getParameters().getFirst("myP
>ara m1"));
> appContext.getParameters().add(getContext().getParameters().getFirst("myP
>ara m2"));
>
> // Attach the application
> MyApplication myApp = new MyApplication(appContext);
> getDefaultHost().attach("/myApp", myApp);
what's the difference between programmatically doing this versus a mechanism
that would allow me to do the same through a configuration file? one thing
i can think of would be more flexibility (in terms of object's type) of the
parameter value.
one easy way to allow this could be to add a sequence of "init-param"
(or "context-param") elements of type "ParameterType" to the "AttachType".
> Hope this helps.
it sure does help me get further in understanding the API. thank you and
Thierry for your help. btw. the more i get to know the toolkit the more i
like how you guys have designed it! in time i hope i'll be able to
contribute to the code.
> 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:[EMAIL PROTECTED]
> Envoyé : mercredi 26 novembre 2008 10:54
> À : Raif S. Naffah; discuss@restlet.tigris.org
> Objet : Re: No available xxx connector supports the required protocols
>
> Hello Raif,
>
> at this time, servlet parameters are only copied into the application's
> context when using the "org.restlet.application" parameter in the
> "web.xml" file...
> I'm looking for a way to transmit them to the attached restlets when
> using the "restlet.xml" file.
>
> Best regards,
> Thierry Boileau
> --
> Restlet ~ Core developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
> > salut Thierry,
> >
> > thank you muchly for spending so much time on this :-) really
> > appreciate it.
> >
> >
> > i installed your test application and ran it and it worked ok. but
> > since
>
> it
>
> > does not reflect the environment i described in my initial post, i
> > started
> >
> > changing the configuration to resemble my setup. it was enough to
> > configure the application through a restlet.xml file for the parameters
> > to
> >
> > return null. of course i could have mis-configured the application but
> > if
> >
> > that was the case i would've expected to receive some message or an
> > exception not the resource page itself.
> >
> > i'm attaching the modified web.xml and the new restlet.xml that
> > reproduce the problem --start the webapp and in your browser goto
> > http://localhost:8080/RestletTestServlet/ the page returned shows:
> >
> > contextParam=null initParam=null
> >
> > On Monday 24 November 2008 09:14:31 pm Thierry Boileau wrote:
> >>
> >>
> >>
> >>>> http-equiv="Content-Type">
> >>
> >> Hello Raif,
> >>
> >> I send you a sample Eclipse project that works correctly for me (with
> >> last Restlet snapshot).
> >> http://www.noelios.com/";>The application is not based on
> >> customized Component and ServerServlet. In this case, parameters are
> >> directly copied from the Servlet context to the Application
> >> context. In addition the default behaviour of the ServerServlet
> >> class is to copy parameters also into the context of the
> >> Compone
Re: No available xxx connector supports the required protocols
hello Thierry,
On Thursday 27 November 2008 08:38:17 pm Thierry Boileau wrote:
> Hello Raif,
>
> > as a side-note, i see in the Component schema a "parameter" element in
> > the "ComponentType" type. where can i find more documentation about
> > this element?
>
> Actually, there is no documentation about this element... It simply adds
> key/value pairs into the list of parameters of the component's context.
no worries.
> >> In your case, you should make sure that your custom Component manually
> >> copies the required parameters to the Application(s) that really need
> >> them. To pass parameters to an application, you should do that in your
> >> Component subclass:
> >>
> >> // Prepare the application context
> >> Context appContext = getContext().createChildContext();
> >> appContext.getParameters().add(getContext().getParameters().getFirst("
> >>myP ara m1"));
> >> appContext.getParameters().add(getContext().getParameters().getFirst("
> >>myP ara m2"));
> >>
> >> // Attach the application
> >> MyApplication myApp = new MyApplication(appContext);
> >> getDefaultHost().attach("/myApp", myApp);
> >
> > what's the difference between programmatically doing this versus a
> > mechanism that would allow me to do the same through a configuration
> > file? one thing i can think of would be more flexibility (in terms of
> > object's type) of the parameter value.
> >
> > one easy way to allow this could be to add a sequence of "init-param"
> > (or "context-param") elements of type "ParameterType" to the
> > "AttachType".
>
> I've added an RFE for this issue =>
> http://restlet.tigris.org/issues/show_bug.cgi?id=670
cool. i might have a go at implementing it and submitting a patch.
> Best regards,
> Thierry Boileau
> --
> Restlet ~ Core developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
cheers;
rsn
signature.asc
Description: This is a digitally signed message part.
Restlet and Java 6
hello there, before i delve in with a debugger i thought i'd ask first: are there any known issues running Restlet (w/ ServerServlet) in tomcat 6.0.18 with: # java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) and # uname -a Linux ... 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13 20:52:14 EST 2008 i686 athlon i386 GNU/Linux TIA + cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=148338 signature.asc Description: This is a digitally signed message part.
Re: Restlet and Java 6
hello Rob, On Wednesday 03 December 2008 01:11:39 am Rob Heittman wrote: > More details on the problem would help ... but since I'm seeing Athlon > SMP in your uname, I'd suspect you may be getting JVM crashes when the > JVM recompiles certain classes? If so, it's a JDK bug that you can work > around by blocking certain classes from recompilation. Or is it > something else? yesterday i tracked it down to a method in the org.restlet.util.ByteUtils (i think the toString() method) returning an empty string when the resource's data is all available (double-checked with wireshark). > On Tue, Dec 2, 2008 at 2:38 AM, Raif S. Naffah <[EMAIL PROTECTED]>wrote: > > before i delve in with a debugger i thought i'd ask first: are there > > any known issues running Restlet (w/ ServerServlet) in tomcat 6.0.18 > > with: cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=978724 signature.asc Description: This is a digitally signed message part.
Re: Restlet and Java 6
hello Stephan, On Wednesday 03 December 2008 08:32:21 am Stephan Koops wrote: > Hi Raif, > > if you use the JAXB extension of Restlet, you could get some problems, > because Java 6 contains JAXB in a different version, I think. no i'm not using it. > If you need it and will have a good solution, Jerome and Thierry will be > happy, if you could contribute. > > best regards >Stephan > > Raif S. Naffah schrieb: > > java version "1.6.0_10" > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=97 >8537 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=978725 signature.asc Description: This is a digitally signed message part.
Re: Restlet and Java 6
hello Mark, On Wednesday 03 December 2008 09:50:38 am Mark Derricutt wrote: > We used to get LOTS of JVM crashes with Restlet under JDK 6 update 10, > the "solution" (aka work around) was to add: > > -XX:CompileCommand=exclude,com/noelios/restlet/http/HeaderReader,readValu >e > > to our JVM init script, having hotspot recompile that method all the > time seemed to trigger very ungraceful behaviour. i'll give that a go with jdk6u11 which btw. also didn't work. if it works i'll post a reply to this thread so other users may benefit. > On Wed, Dec 3, 2008 at 10:32 AM, Stephan Koops <[EMAIL PROTECTED]> wrote: > > Hi Raif, > > > > if you use the JAXB extension of Restlet, you could get some problems, > > because Java 6 contains JAXB in a different version, I think. > > > > If you need it and will have a good solution, Jerome and Thierry will > > be happy, if you could contribute. > > > > best regards > > Stephan > > > > Raif S. Naffah schrieb: > >> java version "1.6.0_10" > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId= > >978537 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=978728 signature.asc Description: This is a digitally signed message part.
Re: Restlet and Java 6
hello again, On Wednesday 03 December 2008 06:46:39 pm Raif S. Naffah wrote: > hello Mark, > > On Wednesday 03 December 2008 09:50:38 am Mark Derricutt wrote: > > We used to get LOTS of JVM crashes with Restlet under JDK 6 update 10, > > the "solution" (aka work around) was to add: > > > > -XX:CompileCommand=exclude,com/noelios/restlet/http/HeaderReader,readVa > >lu e > > > > to our JVM init script, having hotspot recompile that method all the > > time seemed to trigger very ungraceful behaviour. > > i'll give that a go with jdk6u11 which btw. also didn't work. if it > works i'll post a reply to this thread so other users may benefit. the above did not work. the input stream returned (as it was before) an EOF --last call that is not returning the correct (read expected) characters is a sun.nio.cs.StreamDecoder.read([char,int,int) although the (Restlet) Entity.getSize() and .getAvailableSize() both return the right length. i switched to Jetty (6.1.14) and everything works with jdk1.6.0_11. thanks everybody for your help. > > On Wed, Dec 3, 2008 at 10:32 AM, Stephan Koops <[EMAIL PROTECTED]> > > wrote: > > > Hi Raif, > > > > > > if you use the JAXB extension of Restlet, you could get some > > > problems, because Java 6 contains JAXB in a different version, I > > > think. > > > > > > If you need it and will have a good solution, Jerome and Thierry will > > > be happy, if you could contribute. > > > > > > best regards > > > Stephan > > > > > > Raif S. Naffah schrieb: > > >> java version "1.6.0_10" > > > > > > -- > > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageI > > >d= 978537 > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=97 >8728 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=978780 signature.asc Description: This is a digitally signed message part.
RE: Re: No available xxx connector supports the required protocols
hi there, i've already attached a patch to that issue to handle "init-param" elements both in the component and the attach elements. cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=978798
Re: Restlet and Java 6
hello Jerome, On Thursday 04 December 2008 05:23:13 am Jerome Louvel wrote: > Hi Raif, > > Thanks for the updates. I'm glad you found a solution! > > The conclusion, there is an integration issue between Tomcat 6.0, JDK 6 > and Restlet 1.1... We need to have a look as it might be a common > scenario. > > Do you have some reproducible code (ideally a WAR with source would be > perfect) that could help us debug this? i'll put something together in the next few days and send it to you directly. > 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 : Raif S. Naffah [mailto:[EMAIL PROTECTED] > Envoye : mercredi 3 decembre 2008 10:33 > A : discuss@restlet.tigris.org > Objet : Re: Restlet and Java 6 > > hello again, > > On Wednesday 03 December 2008 06:46:39 pm Raif S. Naffah wrote: > > hello Mark, > > > > On Wednesday 03 December 2008 09:50:38 am Mark Derricutt wrote: > > > We used to get LOTS of JVM crashes with Restlet under JDK 6 update > > > 10, the "solution" (aka work around) was to add: > > > > > > -XX:CompileCommand=exclude,com/noelios/restlet/http/HeaderReader,read > > >Va lu e > > > > > > to our JVM init script, having hotspot recompile that method all the > > > time seemed to trigger very ungraceful behaviour. > > > > i'll give that a go with jdk6u11 which btw. also didn't work. if it > > works i'll post a reply to this thread so other users may benefit. > > the above did not work. the input stream returned (as it was before) an > EOF --last call that is not returning the correct (read expected) > characters is a sun.nio.cs.StreamDecoder.read([char,int,int) although the > (Restlet) Entity.getSize() and .getAvailableSize() both return the right > length. > > i switched to Jetty (6.1.14) and everything works with jdk1.6.0_11. > > thanks everybody for your help. > > > > On Wed, Dec 3, 2008 at 10:32 AM, Stephan Koops <[EMAIL PROTECTED]> > > > > wrote: > > > > Hi Raif, > > > > > > > > if you use the JAXB extension of Restlet, you could get some > > > > problems, because Java 6 contains JAXB in a different version, I > > > > think. > > > > > > > > If you need it and will have a good solution, Jerome and Thierry > > > > will be happy, if you could contribute. > > > > > > > > best regards > > > > Stephan > > > > > > > > Raif S. Naffah schrieb: > > > >> java version "1.6.0_10" > > > > > > > > -- > > > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessag > > > >eI d= 978537 > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId= > >97 8728 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=97 >8780 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=97 >9015 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=979313 signature.asc Description: This is a digitally signed message part.
contributing - areas of interest
hello there, (i'm sending this again since it does not look like it made it to the list the first time around). i'd like to contribute to this project in my free time. areas of interests which i've identified so far --and am personally interested in-- are: * Java Bindings to XML Schemas: replace XML parsing with pre-generated classes (XMLBeans xmlbeans.apache.org) from published/known schemas; e.g. the parsing of the restlet.xml. * authorization toolkit: something equivalent to what is available with servlets in Apache Tomcat; see http://tomcat.apache.org/tomcat-6.0- doc/realm-howto.html. * KML/KMZ support: something beyond issue #677; more like a SPI toolkit to allow building KML files (e.g. from a CSV document). if this is of interest to the project maintainers, then pls. let me know how to proceed next. cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981057 signature.asc Description: This is a digitally signed message part.
Re: contributing - areas of interest
hello Thierry, On Monday 08 December 2008 20:14:28 Thierry Boileau wrote: > Hello Raif, > > that's very nice of you to help the project and of course you're very > welcome. thank you. > Since Jérôme is on vacations right now, you have to wait a little bit. > He will be back in the middle of the new week. no problems. look forward to his input. > Best regards, > Thierry Boileau > -- > Restlet ~ Core developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > hello there, > > > > (i'm sending this again since it does not look like it made it to the > > list the first time around). > > > > i'd like to contribute to this project in my free time. > > > > areas of interests which i've identified so far --and am personally > > interested in-- are: > > > > * Java Bindings to XML Schemas: replace XML parsing with pre-generated > > classes (XMLBeans xmlbeans.apache.org) from published/known schemas; > > e.g. the parsing of the restlet.xml. > > > > * authorization toolkit: something equivalent to what is available with > > servlets in Apache Tomcat; see http://tomcat.apache.org/tomcat-6.0- > > doc/realm-howto.html. > > > > * KML/KMZ support: something beyond issue #677; more like a SPI toolkit > > to allow building KML files (e.g. from a CSV document). > > > > > > if this is of interest to the project maintainers, then pls. let me > > know how to proceed next. > > > > > > cheers; > > rsn > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId= > >981057 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >1072 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981215 signature.asc Description: This is a digitally signed message part.
Re: contributing - areas of interest
hello Avi, On Tuesday 09 December 2008 03:32:54 Avi Flax wrote: > On Mon, Dec 8, 2008 at 03:04, Raif S. Naffah <[EMAIL PROTECTED] raif.name>wrote: > > i'd like to contribute to this project in my free time. > > Raif, that's great! Can I suggest RFE 658, Add support for JSecurity? > > http://restlet.tigris.org/issues/show_bug.cgi?id=658 > > Since you're interested in security, this might be interesting to you. > I'd love to see this one make progress! yah! it's very close to what i had in mind. i'll look closer into JSecurity and may be add my comment to that RFE. > Thanks, thanks for bringing JSecurity to my attention! > Avi > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >1192 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981217 signature.asc Description: This is a digitally signed message part.
Re: contributing - areas of interest
hello Bruno, On Tuesday 09 December 2008 08:23:52 Bruno Harbulot wrote: > Hi, > > You might also be interested in RFE 505, which already has a few > comments, including pointers to discussions on this mailing list: >http://restlet.tigris.org/issues/show_bug.cgi?id=505 indeed! thanks for the pointer. > (I doubt I'll be able to follow the discussions in details over the next > couple of weeks at least.) > > Best wishes, > > Bruno. > > Raif S. Naffah wrote: > > hello Avi, > > > > On Tuesday 09 December 2008 03:32:54 Avi Flax wrote: > >> On Mon, Dec 8, 2008 at 03:04, Raif S. Naffah <[EMAIL PROTECTED] > > > > raif.name>wrote: > >>> i'd like to contribute to this project in my free time. > >> > >> Raif, that's great! Can I suggest RFE 658, Add support for JSecurity? > >> > >> http://restlet.tigris.org/issues/show_bug.cgi?id=658 > >> > >> Since you're interested in security, this might be interesting to you. > >> I'd love to see this one make progress! > > > > yah! it's very close to what i had in mind. i'll look closer into > > JSecurity and may be add my comment to that RFE. > > > >> Thanks, > > > > thanks for bringing JSecurity to my attention! > > > >> Avi > >> > >> -- > >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId > >>=98 1192 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >1301 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981535 signature.asc Description: This is a digitally signed message part.
securing Restlet
hello all, as a follow up to my original post re. contributing to the project (see http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981057), and after digesting the suggestions and responses that followed, here's a summary of the discussion threads and issues (see list at the end) related to the above subject i was able to find to-date. pls. let me know if i missed, mis-interpreted, or overlooked anything pertaining to the issue: * there's a recognized need for better, more pluggable authentication and authorization (AA) capabilities within the Restlet project. * successful integration with both Spring Security (Acegi Security http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were reported. * the Guard class does not seem to always suit developers' needs when it comes to integrating external security libraries to offer AA capabilities. Filter was used successfully and Resolver was suggested for authorization needs beyond URIs. * there was no direct mention about securing the Restlet library code itself separately from users application; e.g. if using the Java SE Security what would be a conservative security policy and permissions to use/grant. * it's unclear (to me at least) whether the desired outcome is to integrate one (of many) external security library, or build within Restlet a "commons" layer and artifacts (configuration data) to allow (and map to) different ones. the other two subjects mentioned in the other post remain of interest to me as well. i look forward to the input of the project maintainers. references: [D1] Spring Security Integration http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=40454 [D2] Restlet Servlet and Security http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=58357 [D3] Re: What is missing from Restlet? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=94828 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=95151 [D4] Security Issues with Dynamic Loading of Applications? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=963302 [I264] Support Spring Security http://restlet.tigris.org/issues/show_bug.cgi?id=264 [I505] Refactor authentication and authorization http://restlet.tigris.org/issues/show_bug.cgi?id=505 [I658] Add support for JSecurity http://restlet.tigris.org/issues/show_bug.cgi?id=658 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=986463 signature.asc Description: This is a digitally signed message part.
Re: securing Restlet
hello Stephan, my comments are in-lined. On Friday 19 December 2008 19:49:12 Stephan Koops wrote: > Hi Raif, > > I think it is good, if a developer could build a HTML application with > Restlet, where he could give a typical login HTML web page and the user > could login without the browsers HTTP authentication prompt (because you > can't design it and so on). In Servlet apps you typically use sessions, > but this we don't want. But we can use Cookies for it, which shows, who > is logged in. It would be very good, if we (optionally) use a cryptical > check, so that nobody could create it's own Cookie by hand to fake a > logged in user. > This should be a ready-to-use-class a developer could instantiate, plug > an authentication mechansim in it (Basic, Digest, ...), an authenticator > (against a file (as in apache e.g.), a database, a JSecurity, ...) and > go. yes. this is where i started from: essentially a clone of what is available with servlets in Apache Tomcat. if we have this in Restlet then a developer would be able to configure Authentication based on credentials accessed from different Realms. this with developer's own HTML (JSP really) form provided the user-name and the password fields are specifically named. the page here (http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html) has more details. plumbing-wise i thought of using the restlet.xml as the primary way for configuring the Realm. directly using the classes should also work albeit is not recommended. for one, you don't want to modify and recompile your code if you decide later you want to use another Realm, and two, sometimes choosing which Realm to use is the privilege of the Administrator running the application not its developer. > Another possibility to not require the browser login prompt is to use an > AJAX reqeust and set the credentials in it. I've implemented this, but I > needed a new return status for it, because if the server returns 401 > (authentication required / invald) to the client, then the browser would > open a login prompt. If needed, a could attach it to issue 505 > > It is also good, if it is allowed to have multiple authentication > mechanims allowed for one resource, e.g. with cookies as descibed above > for browsers and with a HTML authentiction for software clients, which > requesting e.g. XML or JSON. correct me if i'm wrong but if the aim of the Authentication is to assert "who are you" then your identity should be the same whatever Authentication mechanism was used. in that respect _one_ Authentication mechanism should be enough. on the other hand, "what are you allowed to do" (incl. what type of Representation for a requested Resource) is the domain of Authorization. in that respect one (of potentially several conditions, incl. for example the time-of-day) for authorizing a type of Representation could be the "grade" of the Authentication mechanism used to establish your identity; i.e. an Authentication mechanism based on a personal X.509 Certificate has a higher grade than one based on non-encrypted user-name and password. what could be gained though from having an "aggregation/compounded" style of user-credentials gathering mechanisms would be to increase the trust in the established identity. e.g. i would have more confidence in your identity if i can check your credentials from two separate sources; as a consequence i can then authorize you to do more. > best regards > Stephan > > Raif S. Naffah schrieb: > > hello all, > > > > as a follow up to my original post re. contributing to the project (see > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId= > >981057), and after digesting the suggestions and responses that > > followed, here's a summary of the discussion threads and issues (see > > list at the end) related to the above subject i was able to find > > to-date. pls. let me know if i missed, mis-interpreted, or overlooked > > anything pertaining to the issue: > > > > * there's a recognized need for better, more pluggable authentication > > and authorization (AA) capabilities within the Restlet project. > > > > * successful integration with both Spring Security (Acegi Security > > http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were > > reported. > > > > * the Guard class does not seem to always suit developers' needs when > > it comes to integrating external security libraries to offer AA > > capabilities. Filter was used successfully and Resolver was suggested > > for authorization needs beyond URIs. > > > > * there was no direct mention about securing the Restlet library code > > itself separ
Re: securing Restlet
hello Stephan, On Saturday 20 December 2008 22:32:50 Stephan Koops wrote: > Hi Raif, > > >> Another possibility to not require the browser login prompt is to use > >> an AJAX reqeust and set the credentials in it. I've implemented this, > >> but I needed a new return status for it, because if the server returns > >> 401 (authentication required / invald) to the client, then the browser > >> would open a login prompt. If needed, a could attach it to issue 505 > >> > >> It is also good, if it is allowed to have multiple authentication > >> mechanims allowed for one resource, e.g. with cookies as descibed > >> above for browsers and with a HTML authentiction for software clients, > >> which requesting e.g. XML or JSON. > > > > correct me if i'm wrong but if the aim of the Authentication is to > > assert "who are you" then your identity should be the same whatever > > Authentication mechanism was used. in that respect _one_ > > Authentication mechanism should be enough. on the other hand, "what > > are you allowed to do" (incl. what type of Representation for a > > requested Resource) is the domain of Authorization. in that respect one > > (of potentially several conditions, incl. for example the time-of-day) > > for authorizing a type of Representation could be the "grade" of the > > Authentication mechanism used to establish your identity; i.e. an > > Authentication mechanism based on a personal X.509 Certificate has a > > higher grade than one based on non-encrypted user-name and password. > > > > what could be gained though from having an "aggregation/compounded" > > style of user-credentials gathering mechanisms would be to increase the > > trust in the established identity. e.g. i would have more confidence > > in your identity if i can check your credentials from two separate > > sources; as a consequence i can then authorize you to do more. > > Here I was not precise enough: I meant alternative authentication > mechanisms, not both must be passed. > If I use a software client (web service), than basic or digest is fine, > but if the client is a browser, than the cookie based may be better, > because it allows corporate design: I think, a reason for not using REST > styled web apps in the commercial is, that authentication in corporate > design is more difficult than with Servlets: If the developer says to > the manager: We have two alternatives: One allows corporated design to > be used easily, and the other options has problems with it, what would > he say? Right, he will say: "Use the options which allows it". i see what you mean but just to clarify: Cookies per se are not an authentication mechanism but a technique to maintain a state which could be used to claim previous alleged successful authentication. even then, i see two problems with Cookies: (a) users can have their Browsers reject them, and (b) they contradict the REST principle (see section 6.3.4.2 of R. Fielding dissertation http://roy.gbiv.com/pubs/dissertation/evaluation.htm). i agree with you that allowing Restlet users/developers to plug-in their own customized log-in form where user credentials can be obtained will be a selling point. this i think can be achieved by implementing in Restlet something similar to what the Servlet specs' and elements provide. > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >8124 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=988300 signature.asc Description: This is a digitally signed message part.
Re: securing Restlet
hello Stephan, On Sunday 21 December 2008 00:41:48 Stephan Koops wrote: > Hi Raif, > > Another possibility to not require the browser login prompt is to > use an AJAX reqeust and set the credentials in it. I've implemented > this, but I needed a new return status for it, because if the server > returns 401 (authentication required / invald) to the client, then > the browser would open a login prompt. If needed, a could attach it > to issue 505 > > It is also good, if it is allowed to have multiple authentication > mechanims allowed for one resource, e.g. with cookies as descibed > above for browsers and with a HTML authentiction for software > clients, which requesting e.g. XML or JSON. > >>> > >>> correct me if i'm wrong but if the aim of the Authentication is to > >>> assert "who are you" then your identity should be the same whatever > >>> Authentication mechanism was used. in that respect _one_ > >>> Authentication mechanism should be enough. on the other hand, "what > >>> are you allowed to do" (incl. what type of Representation for a > >>> requested Resource) is the domain of Authorization. in that respect > >>> one (of potentially several conditions, incl. for example the > >>> time-of-day) for authorizing a type of Representation could be the > >>> "grade" of the Authentication mechanism used to establish your > >>> identity; i.e. an Authentication mechanism based on a personal X.509 > >>> Certificate has a higher grade than one based on non-encrypted > >>> user-name and password. > >>> > >>> what could be gained though from having an "aggregation/compounded" > >>> style of user-credentials gathering mechanisms would be to increase > >>> the trust in the established identity. e.g. i would have more > >>> confidence in your identity if i can check your credentials from two > >>> separate sources; as a consequence i can then authorize you to do > >>> more. > >> > >> Here I was not precise enough: I meant alternative authentication > >> mechanisms, not both must be passed. > >> If I use a software client (web service), than basic or digest is > >> fine, but if the client is a browser, than the cookie based may be > >> better, because it allows corporate design: I think, a reason for not > >> using REST styled web apps in the commercial is, that authentication > >> in corporate design is more difficult than with Servlets: If the > >> developer says to the manager: We have two alternatives: One allows > >> corporated design to be used easily, and the other options has > >> problems with it, what would he say? Right, he will say: "Use the > >> options which allows it". > > > > i see what you mean but just to clarify: Cookies per se are not an > > authentication mechanismbut a technique to maintain a state which could > > be used to claim previous alleged successful authentication. > > Right, I fully agree with you; that was my idea. > > > even then, i see two problems with Cookies: > > (a) users can have their Browsers reject them, > > Yes, I know. That is really a problem. > > > and (b) they contradict the REST principle (see section 6.3.4.2 of R. > > Fielding dissertation > > http://roy.gbiv.com/pubs/dissertation/evaluation.htm). > > You are right, that cookies produces problems, if they contain > application state, e.g. to match a Servlet session. But IMO it is not a > problem, if you only save, that the user is logged in and it's user name > (perhaps secured by an additional crypto hash or something like that). > > > i agree with you that allowing Restlet users/developers to plug-in > > their own customized log-in form where user credentials can be obtained > > will be a selling point. this i think can be achieved by implementing > > in Restlet something similar to what the Servlet specs' > > and elements provide. > > And how do a Servlet Container check the authentication? It could only > set a cookie or use a session and save it in the session. No we have > back the cookies, or - worse - a session. but doesn't the current Guard implementation obviate the need for both sessions and cookies, and yet provide us with basic authentication? if yes, then a solution for providing customizable form-based login could be to extend its capabilities to allow declaring and re-directing to a resource URI to use when the credentials are missing. does this make sense? > The only idea is to have the option to use an authentication in a HTML > application, so that a user could type his credentials in some fields in > the HTML page. - Another possibility is to use JavaSript to set the HTML > credentials into a XmlHttprequest. Here you use the HTTP authentication > mechansim. But there is also no guarantee, that JavaScript is enabled, > the same as with cookies. > > best regards >Stephan > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >8307 -- cheers; rsn
Re: securing Restlet
On Sunday 21 December 2008 09:05:46 Rhett Sutphin wrote: > On Dec 20, 2008, at 3:34 PM, Raif S. Naffah wrote: > > hello Stephan, > > > > On Sunday 21 December 2008 00:41:48 Stephan Koops wrote: > >> Hi Raif, > >> > >>>>>> Another possibility to not require the browser login prompt is to > >>>>>> use an AJAX reqeust and set the credentials in it. I've > >>>>>> implemented > >>>>>> this, but I needed a new return status for it, because if the > >>>>>> server > >>>>>> returns 401 (authentication required / invald) to the client, > >>>>>> then > >>>>>> the browser would open a login prompt. If needed, a could > >>>>>> attach it > >>>>>> to issue 505 > >>>>>> > >>>>>> It is also good, if it is allowed to have multiple authentication > >>>>>> mechanims allowed for one resource, e.g. with cookies as descibed > >>>>>> above for browsers and with a HTML authentiction for software > >>>>>> clients, which requesting e.g. XML or JSON. > >>>>> > >>>>> correct me if i'm wrong but if the aim of the Authentication is to > >>>>> assert "who are you" then your identity should be the same > >>>>> whatever > >>>>> Authentication mechanism was used. in that respect _one_ > >>>>> Authentication mechanism should be enough. on the other hand, > >>>>> "what > >>>>> are you allowed to do" (incl. what type of Representation for a > >>>>> requested Resource) is the domain of Authorization. in that > >>>>> respect > >>>>> one (of potentially several conditions, incl. for example the > >>>>> time-of-day) for authorizing a type of Representation could be the > >>>>> "grade" of the Authentication mechanism used to establish your > >>>>> identity; i.e. an Authentication mechanism based on a personal X. > >>>>> 509 > >>>>> Certificate has a higher grade than one based on non-encrypted > >>>>> user-name and password. > >>>>> > >>>>> what could be gained though from having an "aggregation/ > >>>>> compounded" > >>>>> style of user-credentials gathering mechanisms would be to > >>>>> increase > >>>>> the trust in the established identity. e.g. i would have more > >>>>> confidence in your identity if i can check your credentials from > >>>>> two > >>>>> separate sources; as a consequence i can then authorize you to do > >>>>> more. > >>>> > >>>> Here I was not precise enough: I meant alternative authentication > >>>> mechanisms, not both must be passed. > >>>> If I use a software client (web service), than basic or digest is > >>>> fine, but if the client is a browser, than the cookie based may be > >>>> better, because it allows corporate design: I think, a reason for > >>>> not > >>>> using REST styled web apps in the commercial is, that > >>>> authentication > >>>> in corporate design is more difficult than with Servlets: If the > >>>> developer says to the manager: We have two alternatives: One allows > >>>> corporated design to be used easily, and the other options has > >>>> problems with it, what would he say? Right, he will say: "Use the > >>>> options which allows it". > >>> > >>> i see what you mean but just to clarify: Cookies per se are not an > >>> authentication mechanismbut a technique to maintain a state which > >>> could > >>> be used to claim previous alleged successful authentication. > >> > >> Right, I fully agree with you; that was my idea. > >> > >>> even then, i see two problems with Cookies: > >>> (a) users can have their Browsers reject them, > >> > >> Yes, I know. That is really a problem. > >> > >>> and (b) they contradict the REST principle (see section 6.3.4.2 of > >>> R. > >>> Fielding dissertation > >>> http://roy.gbiv.com/pubs/dissertation/evaluation.htm). > >> > >> You are right, that cookies produces problems, i
Re: contributing - areas of interest
hello Jerome, On Wednesday 24 December 2008 06:56:47 Jerome Louvel wrote: > Hi Raif, > > Cool! > > * Java Bindings to XML Schemas: we already support JAXB and JiBX > technologies. What would adding an extension for XMLBeans add > (pros/cons)? There are many serializations technologies to consider > (Castor comes to mind) so we need to be very selective in what we add to > the main Restlet project. i thought of this while working on the patch for supporting "init-param" (Issue #670) in the org.restlet package and not as another Extension. the current code relies only on the DOM structure of a restlet.xml file. my suggestion is to replace those bits by (a) pre-compiling schema-to-Java bindings for whatever is defined in the Components.xsd --which today is not much but could be a subject of change depending on how authentication and authorization will be configured in the future-- and (b) replacing the Component and other classes configuration and initialization based on the Data Access Objects representing a successful parsing of a restlet.xml. the current code has the advantage of not relying on other than a JDK but also has the disadvantage IMO of not separating the configuration from the other life-cycle states of software components. in addition having those Java Binding classes would allow configuring a Restlet application through other than a restlet.xml file. > * authorization toolkit: thanks for the pointer to Tomcat Realms, I've > added a comment about it in issue #505. This is definitely an area that > would benefit from contributions during Restlet 1.2 development cycle! great. > * KML/KMZ support: this might be a too application specific to fit into > the main Restlet project, but you could start a dedicated open source > project (for example on Google Code), that would leverage Restlet. We > would be happy to point users to it and support you. makes sense. what's the next step? > 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] > Envoye : lundi 8 decembre 2008 09:05 > A : discuss@restlet.tigris.org > Objet : contributing - areas of interest > > hello there, > > (i'm sending this again since it does not look like it made it to the > list the first time around). > > i'd like to contribute to this project in my free time. > > areas of interests which i've identified so far --and am personally > interested in-- are: > > * Java Bindings to XML Schemas: replace XML parsing with pre-generated > classes (XMLBeans xmlbeans.apache.org) from published/known schemas; e.g. > the parsing of the restlet.xml. > > * authorization toolkit: something equivalent to what is available with > servlets in Apache Tomcat; see http://tomcat.apache.org/tomcat-6.0- > doc/realm-howto.html. > > * KML/KMZ support: something beyond issue #677; more like a SPI toolkit > to allow building KML files (e.g. from a CSV document). > > > if this is of interest to the project maintainers, then pls. let me know > how to proceed next. > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >1057 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=99 >0910 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=992116 signature.asc Description: This is a digitally signed message part.
Re: Sample code for using FreeMarker with Restlets
hello Mark, On Friday 26 December 2008 07:17:55 Mark Petrovic wrote: > Good day, and Merry Christmas to all who are celebrating it. > > Would someone be kind enough to post a few lines of example config and > code showing how you use FreeMarker with Restlets in returning html > views. the org.restlet.example folder (in the src folder of the restlet-1.1.1.zip) contains a comprehensive example of how to use FreeMarker with Restlet specifically the code in org/restlet/example/book/restlet/ch8. > Thanks much. > > -- > Mark Petrovic > m...@petrovic.org > http://www.petrovic.org > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=99 >2541 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=992830 signature.asc Description: This is a digitally signed message part.
Re: contributing - areas of interest
hello Jerome, On Friday 26 December 2008 19:20:03 Jerome Louvel wrote: > Hi Raif, > > The main reason for using manual DOM-based parsing of XML files is mainly > to prevent any dependency beside JDK/JRE API. > > Also, the restlet.xsd schema is trying to match exactly the structure and > property of Restlet API classes. In some way, the API classes are the DAO > beans... definitely a special case in my mind. > > Another major concern is keeping the core Restlet as compact as possible. > It would be possible to add those DAO beans in the Restlet engine package > though without cluttering the Restlet API itself. > > In a normal project, I would definitely not write the XML code by hand > and prefer a generated approach like JAXB or EMF. > > Anyway, you make a good point regarding the support of other > serialization formats (JSON would be nice). I suggest that you open a RFE > to cover those requirements and remarks so we keep thinking about them in > the future. done: http://restlet.tigris.org/issues/show_bug.cgi?id=696 > Regarding the next steps for security, I'll reply to the other thread > "securing Restlet" :) great! > 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] > Envoye : jeudi 25 decembre 2008 08:03 > A : discuss@restlet.tigris.org > Cc : Jerome Louvel > Objet : Re: contributing - areas of interest > > hello Jerome, > > On Wednesday 24 December 2008 06:56:47 Jerome Louvel wrote: > > Hi Raif, > > > > Cool! > > > > * Java Bindings to XML Schemas: we already support JAXB and JiBX > > technologies. What would adding an extension for XMLBeans add > > (pros/cons)? There are many serializations technologies to consider > > (Castor comes to mind) so we need to be very selective in what we add > > to the main Restlet project. > > i thought of this while working on the patch for supporting "init-param" > (Issue #670) in the org.restlet package and not as another Extension. > the current code relies only on the DOM structure of a restlet.xml file. > my suggestion is to replace those bits by (a) pre-compiling > schema-to-Java bindings for whatever is defined in the Components.xsd > --which today is not much but could be a subject of change depending on > how authentication and authorization will be configured in the future-- > and (b) replacing the Component and other classes configuration and > initialization based on the Data Access Objects representing a successful > parsing of a restlet.xml. > > the current code has the advantage of not relying on other than a JDK but > also has the disadvantage IMO of not separating the configuration from > the other life-cycle states of software components. in addition having > those Java Binding classes would allow configuring a Restlet application > through other than a restlet.xml file. > > > * authorization toolkit: thanks for the pointer to Tomcat Realms, I've > > added a comment about it in issue #505. This is definitely an area that > > would benefit from contributions during Restlet 1.2 development cycle! > > great. > > > * KML/KMZ support: this might be a too application specific to fit into > > the main Restlet project, but you could start a dedicated open source > > project (for example on Google Code), that would leverage Restlet. We > > would be happy to point users to it and support you. > > makes sense. > > > what's the next step? > > > 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] > > Envoye : lundi 8 decembre 2008 09:05 > > A : discuss@restlet.tigris.org > > Objet : contributing - areas of interest > > > > hello there, > > > > (i'm sending this again since it does not look like it made it to the > > list the first time around). > > > > i'd like to contribute to this project in my free time. > > > > areas of interests which i've identified so far --and am personally > > interested in-- are: > > > > * Java Bindings to XML Schemas: replace XML parsing with pre-generated > > classes (XMLBeans xmlbeans.apache.org) from published/known schemas; > > e.g. the parsing of the restlet.xml. > > > > * authorization toolkit
Re: securing Restlet
hello Jerome, On Friday 26 December 2008 20:14:02 Jerome Louvel wrote: > Hi Raif, > > This is a good start. We have a page on the developers' wiki that should > be used during this refactoring project. I have updated it based on the > issues and discussions you have selected, extending to all other I could > find. > > "Security refactoring" > http://wiki.restlet.org/developers/172-restlet/212-restlet.html > > You should create an account on the wiki, and then update the page > (section "Analysis/Synthesis", with the main points you have reported > below. See instructions to register here: > > "Restlet Wiki Site" > http://wiki.restlet.org/about/2-restlet.html account created and Docs Author karma granted. thanks! the page as it stands is very comprehensive and IMO does not need at this stage any amendments since it already addresses all the points raised. if i could make one suggestion it would be to separate the work on the SecurityManager (and associated policy file) from the Authentication and Authorization aspects since these two tasks can be done in parallel. > 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] > Envoye : jeudi 18 decembre 2008 10:34 > A : discuss@restlet.tigris.org > Objet : securing Restlet > > hello all, > > as a follow up to my original post re. contributing to the project (see > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >1057), and after digesting the suggestions and responses that followed, > here's a summary of the discussion threads and issues (see list at the > end) related to the above subject i was able to find to-date. pls. let > me know if i missed, mis-interpreted, or overlooked anything pertaining > to the issue: > > * there's a recognized need for better, more pluggable authentication and > authorization (AA) capabilities within the Restlet project. > > * successful integration with both Spring Security (Acegi Security > http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were > reported. > > * the Guard class does not seem to always suit developers' needs when it > comes to integrating external security libraries to offer AA > capabilities. Filter was used successfully and Resolver was suggested for > authorization needs beyond URIs. > > * there was no direct mention about securing the Restlet library code > itself separately from users application; e.g. if using the Java SE > Security what would be a conservative security policy and permissions to > use/grant. > > * it's unclear (to me at least) whether the desired outcome is to > integrate one (of many) external security library, or build within > Restlet a "commons" layer and artifacts (configuration data) to allow > (and map to) different ones. > > > the other two subjects mentioned in the other post remain of interest to > me as well. i look forward to the input of the project maintainers. > > > references: > [D1] Spring Security Integration > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=40 >454 > > [D2] Restlet Servlet and Security > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=58 >357 > > [D3] Re: What is missing from Restlet? > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=94 >828 > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=95 >151 > > [D4] Security Issues with Dynamic Loading of Applications? > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=96 >3302 > > [I264] Support Spring Security > http://restlet.tigris.org/issues/show_bug.cgi?id=264 > > [I505] Refactor authentication and authorization > http://restlet.tigris.org/issues/show_bug.cgi?id=505 > > [I658] Add support for JSecurity > http://restlet.tigris.org/issues/show_bug.cgi?id=658 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=992872 signature.asc Description: This is a digitally signed message part.
Re: Just a test: Full compatibility with the Maven build system
hello JY,
this is a good effort and i'm willing to help in the migration if the
project maintainers are willing to make the switch.
On Thursday 25 December 2008 03:04:11 JY wrote:
> Here a exemple of Restlet Maven Site generated:
> http://jycronier.free.fr/tmp/restlet-maven-site/
>
> > - Global JavaDoc
>
> http://jycronier.free.fr/tmp/restlet-maven-site/apidocs/index.html
>
> > - Code coverage (Cobertura)
>
> Example with org.restlet Core API:
> http://jycronier.free.fr/tmp/restlet-maven-site/org.restlet/cobertura/ind
>ex.html (This report isn't representative because Unit Tests aren't move
> in their respective projects)
>
> > - Static analysis of code (PDM)
>
> Example with org.restlet Core API:
> http://jycronier.free.fr/tmp/restlet-maven-site/org.restlet/pmd.html
>
> > - HTML cross reference sources
>
> http://jycronier.free.fr/tmp/restlet-maven-site/xref/index.html
>
> > - Global Dashboard of results
>
> http://jycronier.free.fr/tmp/restlet-maven-site/dashboard-report.html
> (This report isn't representative because Unit Tests aren't move in
> their respective projects)
>
>
> I will remove these pages in very few months
>
> JY a écrit :
> > "Restlet" uses "Ant" to build the entire project and modules. And it
> > works pretty well! :-)
> >
> > It's very difficult for me to compare actual huge and complex Restlet
> > Ant build system with a Maven's one because I never use ant for big
> > projects like Restlet. And I know too much of Maven to be objective! ;)
> > So, let's the community have an opinion.
> >
> > So, I begin a little migration of project's structure to be more
> > compliant: - remove number version on extension project folder
> > (ex: org.restlet.ext.atom_1.0 -> org.restlet.ext.atom)
> > - Move all Java source from /src to /src/main/java
> > - Move all other than Java source from /src to /src/main/resources
> > - Create a parent pom.xml to define all common properties
> > (specially for the "maven site" generation)
> > - Move pom from build/tmpl/poms to their respective project
> > - Copy (quick and dirty way) properties to pom.xml
> >
> > Now, simple command "mvn package" make packaging of each extensions.
> > In attachments, you can find an export of modified project (only folder
> > "modules" from commit 4070) and the "mvn site" will generate
> > automatically from sources ("mvn site") :
> > - Global JavaDoc
> > - Code coverage (Cobertura)
> > - Static analysis of code (PDM)
> > - HTML cross reference sources
> > - Global Dashboard of results
> > - Etc …
> >
> > Other works can be performed:
> > - Use of Maven Tycho
> > (http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs) :
> > * Automatic build of OSGi bundle
> > * No need of dependency declarations in pom.xml
> >(MANIFEST.MF is enough)
> > - Move Unit tests under each modules
> > - Finish moving no-Java files to: src/resources
> > - Continuous integration (ex: Continuum, Cruise Control or Hudson?)
> >
> >
> >
> >
> >
> >
> > Merry Christmas!!! :)
> >
> > --
> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=
> >991625
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=99
>1696
--
cheers;
rsn
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=994219
signature.asc
Description: This is a digitally signed message part.
Re: Maven Dependancy Referances
hello Gan123,
it's not clear from your message if you are, or not, able to access the
template directory at all. in other words are you able to load the
...myApplication.propeties file in one application but not the other?
i would suggest you first ensure that you can indeed access this properties
file by may be building a small TestCase that just loads this file with the
CLAP client and print its contents.
On Tuesday 30 December 2008 00:21:33 Gan123 wrote:
> Hi,
>
> I am creating two maven projects. my first maven project is having
> the Application class, this contains free marker configuration. the FTL
> files reffered by this configuration are in second project, which is a
> web application.The project1 is added as dependency to project2.
>
> Application class source code ( project 1 )
>
> private Configuration fmc;
> public TestApplication() throws IOException{
> getConnectorService().getClientProtocols().add(Protocol.FILE);
> getConnectorService().getClientProtocols().add(Protocol.CLAP);
> Properties properties =
> getProperties("clap://class/config/myApplication.properties");
>
> this.webRootPath = properties.getProperty("web.root.path");
> try {
> final File templateDir = new File(webRootPath + "/template");
> this.fmc = new freemarker.template.Configuration();
> this.fmc.setDirectoryForTemplateLoading(templateDir);
> } catch (Exception e) {
>
>
>
> directory structure of project 2
>
> HotelWebApp
> --src
> main
> --webapp
> template
> ---listHotels.ftl
>
> when i run the second project it is throwing exception .. stack trace is
> below..
>
> java.io.FileNotFoundException: \template does not exist.
> at
> freemarker.cache.FileTemplateLoader$1.run(FileTemplateLoader.java:125) at
> java.security.AccessController.doPrivileged(Native Method)
> at
> freemarker.cache.FileTemplateLoader.(FileTemplateLoader.java:122)
> at
> freemarker.cache.FileTemplateLoader.(FileTemplateLoader.java:108)
> at
> freemarker.template.Configuration.setDirectoryForTemplateLoading(Configur
>ation.java:314)
>
>
> can any one please help me to solve this issue? i am trying this by
> following
> "\restlet-1.1.1\src\org.restlet.example\org\restlet\example\book\restlet\
>ch8" sample application.
>
> Thanks in advance.
--
cheers;
rsn
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=995752
signature.asc
Description: This is a digitally signed message part.
securing Restlet 1.2
hello all, i went through the 13 "High priority enhancements for Restlet 1.2" in the "Requirements" section of "Security re-factoring" found here (http://wiki.restlet.org/developers/172-restlet/212-restlet.html) and tried to classify them in order to come up with an implementation plan. here are my thoughts: * the only one comprehensive approach for covering Authentication and Authorization needs is JSecurity ([I658] Add support for JSecurity). if implemented, this would IMO also achieve: # [I288] Support pre-emptive authentication # [I503] Give access to connector authentication # [I504] Add notion of realm # [I605] Support cookie based authentication the other requirements, excluding [I505] Re-factor authentication and authorization, can be classified as: * add support for more/other authentication mechanisms. these could be achieved by implementing JSecurity classes (in org.jsecurity.authc packages) either in the JSecurity project, or here and contributing them to that project: # [I444] Support SPNEGO authentication # [I446] Support OpenID authentication # [I447] Support JAAS authentication * improving the current mechanisms. these could be achieved by designing the framework to allow (at least the Guard) to inject security constraints and have the (Guard) methods delegate the work to the security framework. this way the existing (and future) work done on the Guard would not be lost or in need of (too much) re-writing: # [I485] Support htpasswd encrypted files in Guard # [I567] Improve HTTP Digest support # [I606] Improve OAuth extension # [I634] Guard.checkSecret should accept a Response object i'm seeking feedback on the following proposed plan: * adopt JSecurity (http://www.jsecurity.org/) as the base Authentication and Authorization provider for Restlet. their code is published under an Apache 2.0 Open Source License, and the project itself is in incubation state for becoming an Apache product. * hide as little as possible JSecurity classes in Restlet. this basically means adding a dependency to the Restlet Core on the JSecurity JARs --for JDK 5 and later, the following is a minimum (when the security services are enabled): jsecurity.jar, commons-logging.jar; for heterogeneous clients, SSO support: ehcache.jar, and backport-util-concurrent.jar. * add one service (SecurityService in org.restlet.service) and enough classes in Restlet (mainly org.restlet.security package) to configure, enable/disable and use the JSecurity classes. * re-factor Guard to re-use the above so its existing sub-classes can continue to work unchanged. at a later stage, i think it could be beneficial to look at how we can configure and use this security framework separately or in collaboration at the Component, VirtualHost and Application levels. cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1000150 signature.asc Description: This is a digitally signed message part.
Patch to parameterize port numbers in JUnit tests
hello there,
the JUnit tests (in org.restlet.test) have hard-wired port numbers which may
not suit every developer's environment. this patch introduces a new
property in the main build.xml, and injects at as a system environment
variable.
when more than one port is required, the property value is used as a base;
i.e. second port number is valueOf(property) + 1, etc.
the only test i was not able to parametrize was the Spring test (and its
.xml file).
cheers;
rsn
### Eclipse Workspace Patch 1.0
#P org.restlet.test
Index: src/org/restlet/test/TemplateFilterTestCase.java
===
--- src/org/restlet/test/TemplateFilterTestCase.java(revision 4104)
+++ src/org/restlet/test/TemplateFilterTestCase.java(working copy)
@@ -198,7 +198,7 @@
// Create a new component
final Component component = new Component();
-component.getServers().add(Protocol.HTTP, 8182);
+component.getServers().add(Protocol.HTTP, RestletTestSuite.PORT);
component.getClients().add(Protocol.FILE);
// Create an application filtered with Freemarker
@@ -220,28 +220,28 @@
freemarkerApplication.getTunnelService().setExtensionsTunnel(true);
velocityApplication.getTunnelService().setExtensionsTunnel(true);
final Client client = new Client(Protocol.HTTP);
-Response response = client.get("http://localhost:8182/freemarker/";
-+ testFileFm1.getName());
+Response response = client.get("http://localhost:";
++ RestletTestSuite.PORT +"/freemarker/" +
testFileFm1.getName());
if (response.isEntityAvailable()) {
assertEquals(response.getEntity().getText(),
-"Method=GET/Authority=localhost:8182");
+"Method=GET/Authority=localhost:" +
RestletTestSuite.PORT);
}
-response = client.get("http://localhost:8182/freemarker/";
-+ testFileFm2.getName());
+response = client.get("http://localhost:"; + RestletTestSuite.PORT
++ "/freemarker/" + testFileFm2.getName());
assertTrue(response.getStatus().isSuccess());
if (response.isEntityAvailable()) {
assertEquals(response.getEntity().getText(),
"Method=${m}/Authority=${ra}");
}
-response = client.get("http://localhost:8182/velocity/";
-+ testFileVl1.getName());
+response = client.get("http://localhost:"; + RestletTestSuite.PORT
++ "/velocity/" + testFileVl1.getName());
if (response.isEntityAvailable()) {
assertEquals(response.getEntity().getText(),
"Method=GET/Path=/velocity/testVl1");
}
-response = client.get("http://localhost:8182/velocity/";
-+ testFileVl2.getName());
+response = client.get("http://localhost:"; + RestletTestSuite.PORT
++ "/velocity/" + testFileVl2.getName());
assertTrue(response.getStatus().isSuccess());
if (response.isEntityAvailable()) {
assertEquals(response.getEntity().getText(),
Index: src/org/restlet/test/HeaderTestCase.java
===
--- src/org/restlet/test/HeaderTestCase.java(revision 4104)
+++ src/org/restlet/test/HeaderTestCase.java(working copy)
@@ -65,8 +65,6 @@
private static final String HTTP_HEADERS = "org.restlet.http.headers";
-private static final int PORT = 8182;
-
/**
* Name of a test header field
*/
@@ -101,20 +99,21 @@
private Response getWithParams(Parameter... parameters) {
final Client client = new Client(Protocol.HTTP);
final Request request = new Request(Method.GET, "http://localhost:";
-+ PORT);
++ RestletTestSuite.PORT);
final Form headers = getHttpHeaders(request);
for (final Parameter p : parameters) {
headers.add(p);
}
-return client.handle(request);
+Response result = client.handle(request);
+return result;
}
@Override
public void setUp() throws Exception {
if (this.component == null) {
this.component = new Component();
-this.component.getServers().add(Protocol.HTTP, PORT);
+this.component.getServers().add(Protocol.HTTP,
RestletTestSuite.PORT);
this.component.getDefaultHost().attachDefault(
new TestHeaderRestlet());
}
Index: src/org/restlet/test/SpringTestCase.xml
===
--- src/org/restlet/test/SpringTestCase.xml (revision 4104)
+++ src/org/restlet/test/SpringTestCase.xml
Re: Patch to parameterize port numbers in JUnit tests
hello Jerome,
i've attached a new version done with kdesvn instead of Eclipse (previous
version).
On Thu January 15 2009 06:59:06 Jerome Louvel wrote:
> Hi Raif,
>
> That sounds like a useful thing to do. I was trying to apply the patch
> but got issues with the paths of the patched files.
>
> Could you try to use SVN instead to generate it, starting at the root of
> the SVN trunk instead?
>
> For Spring it should be possible to inject the static value into the bean
> property. I don't remember the exact syntax, but we can figure this out.
> Any Spring wizard listening?
>
> 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name]
> Envoye : samedi 10 janvier 2009 07:48
> A : discuss@restlet.tigris.org
> Objet : Patch to parameterize port numbers in JUnit tests
>
> hello there,
>
> the JUnit tests (in org.restlet.test) have hard-wired port numbers which
> may not suit every developer's environment. this patch introduces a new
> property in the main build.xml, and injects at as a system environment
> variable.
>
> when more than one port is required, the property value is used as a
> base; i.e. second port number is valueOf(property) + 1, etc.
>
> the only test i was not able to parametrize was the Spring test (and its
> .xml file).
>
>
> cheers;
> rsn
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=10
>24775
cheers;
rsn
Index: build/build.properties
===
--- build/build.properties (revision 4122)
+++ build/build.properties (working copy)
@@ -58,7 +58,8 @@
# Indicates if the NSIS tool should be run over the
# distribution files
-nsis: true
+#nsis: true
+nsis: false
nsis-makensis-path: /usr/bin
# Verbose flag currently used during Java compilation
@@ -73,3 +74,6 @@
# Indicates if the final packaging phase should be done.
package: true
+
+# Port number to use for JUnit tests
+port-number: 3
Index: modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
===
--- modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
(revision 4122)
+++ modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
(working copy)
@@ -42,9 +42,9 @@
*/
public class ComponentXmlTestCase extends TestCase {
-private final int port = 8182;
+private final int port = RestletTestSuite.PORT;
-private final int port2 = 8183;
+private final int port2 = port + 1;
public void testComponentXMLConfig() throws Exception {
final StringBuilder builder = new StringBuilder();
Index: modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
===
--- modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
(revision 4122)
+++ modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
(working copy)
@@ -178,7 +178,7 @@
@Override
protected void setUp() throws Exception {
component = new Component();
-component.getServers().add(Protocol.HTTP, 8182);
+component.getServers().add(Protocol.HTTP, RestletTestSuite.PORT);
component.getClients().add(Protocol.FILE);
component.getDefaultHost().attach(new TestRangeApplication());
component.start();
@@ -199,13 +199,14 @@
Client client = new Client(Protocol.HTTP);
// Test partial Get.
Request request = new Request(Method.GET,
-"http://localhost:8182/testGet";);
+"http://localhost:"; + RestletTestSuite.PORT + "/testGet");
Response response = client.handle(request);
assertEquals(Status.SUCCESS_OK, response.getStatus());
assertEquals("1234567890", response.getEntity().getText());
assertEquals(10, response.getEntity().getSize());
-request = new Request(Method.GET, "http://localhost:8182/testGet";);
+request = new Request(Method.GET, "http://localhost:";
++ RestletTestSuite.PORT +"/testGet");
request.setRanges(Arrays.asList(new Range(0, 10)));
response = client.handle(request);
assertEquals(Status.SUCCESS_PARTIAL_CONTENT, response.getStatus());
@@ -268,7 +269,7 @@
// PUT on a file that does not exist
Request request = new Request(Method.PUT,
-"http://localhost:8182/testPut/essai.txt";);
+"http://localhost:"
Re: feedback on restlet
hello dude,
this is not the best sort of email one can hope getting any help for. if
it's really an advertisement for a new project, then congratulations but
pls. next time re-word the subject line accordingly.
if on the other hand, this is a real cry for help and an earnest desire to
contribute for improving the code then consider the following aspects which
you may have overlooked --if you haven't you didn't make it clear enough in
your email:
* GET and POST parameters: Restlet abstract the HTTP request in a Request
object --a subclass of Message-- both live in the org.restlet.data package.
if you look at the source (or the javadocs) you'll see a wealth of methods
that should be able to suit many and varying needs; e.g.: getEntity() which
returns a Representation, and getEntityAsXxx() methods. having obtained,
for example a Form instance (from getEntityAsForm()) you can then have in
your concrete Resource type something that would materialize a Data Access
Object (DAO) for the object type represented by this Resource in a way
similar to the following:
public class MyObjectResource extends Resource {
public MyObjectDAO getDAO(Form f) {
final MyObjectDAO result = new MyObjectDAO();
result.setNickname(form.getFirstValue("nickname"));
result.setFirstName(form.getFirstValue("firstName"));
...
return result;
}
}
* Asynchronous communication: Restlet does not impose any communication
model or technology. how the call arrives to a Restlet Connector is in a
way orthogonal to how it is dealt with. if you're like me convinced of the
value of REST and its "stateless" nature, then leaving this out of the
concerns of the library / framework could only be beneficial. my opinion is
that if your application really needs something like that build a layer that
sits outside and in front of any REST-ful tier.
* Should have option to run as webapp: Restlet already allows you to do
that. in addition it allows you to run your Server application outside any
J2EE WebApp Containers --see the Grizzly and Simple Extensions.
* Use Jetty for standalone: i presume you meant for Server standalone,
since with Restlet you can build Clients as well as Servers that communicate
in a REST-ful manner. i personally don't like being herded to use one type
of software however good it is --and Jetty is definitely a first grade piece
of software. but if you think that this could facilitate the adoption of
Restlet and REST in general, nothing prevents you from exploring the Servlet
and Jetty Extensions and identifying any weaknesses and submitting
improvements.
* Too Complex: this is like Beauty; it's in the eye of the beholder! i
would love to see pseudo code that gives concrete examples of how it could
be made easy --something like Before and After. seriously, there may be
areas where you need to wire lots of parameters and objects but the fact
that at the base line it's flexible to allow you almost complete control on
how to handle a request-response chain, for me this is an advantage. that
said, if you think there are representative Use Cases which would benefit
from cut down versions or reduced functionality of some classes and
operations, then may be you can propose either new classes to offer this
functionality or ultimately a new Extension (RestletMadeEasy?) that would
benefit developers with such needs. if the API exposed by these classes is
appealing i'm sure developers would move to adopt it. of course you can go
and write such a beast from scratch, or you can build it on top of Restlet.
your choice.
On Sat February 7 2009 05:24:39 code dude wrote:
> Hi folks ,
>
> I used restlet on one my projects which live since one year , i fond
> RESTLET to be too complex and confusing also it lacks some features like
> (i maynot be aware if features might exist)
>
>- restlet get or post parameters should be automatically mapped to
> some kind of object
>- asycn communtication should be supported
>- restlet should have option to run as webapp on tomcat or jetty
>- Pl use jetty for standalone
>- its too complex !! too many new concepts , use KISS
>
> so i am writting my own trimmed down RESTLET framework using jetty
> continuations , I hope opensource when its done
>
> Best Regards,
>
> Code Dude
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=11
>14069
cheers;
rsn
signature.asc
Description: This is a digitally signed message part.
