RE: Example of a Restlet Application/Servlet using both Client and Server
Hi Peter, Thanks for sharing your experience with this application. I'm sure it will help users playing with transformations using the Restlet API. I've added an entry into the Wiki: http://wiki.java.net/bin/view/Javawsxml/Restlet Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Peter Murray > Envoyé : mardi 24 avril 2007 22:09 > À : discuss@restlet.tigris.org > Objet : Example of a Restlet Application/Servlet using both > Client and Server > > Thanks, Jerome, for your recent replies on questions about the 1.0.0 > release, and for your efforts on Restlet in general. It is truly a > useful piece of work. I'd like to share an Restlet-based application > that others may find useful as a template or example. It is called > "BaseDisseminator" and is used in conjunction with a digital object > repository to perform transformations on objects. It has a number of > interesting features made easy by Restlet. > > BaseDisseminator can be built as completely packaged Java application > (using the One-Jar class loader to embed the requisite JARs inside one > JAR) or as a servlet running in any servlet container. In its > command-line application form (built using `ant jar`), it takes two > optional parameters -- the first is the port to listen on and > the second > is the URL prefix of the digital object repository. In its > servlet form > (built using `ant war`), the the digital object repository > URL prefix is > specified as an init parameter in WEB-INF/web.xml. > > In addition to operating as a Restlet-based server, it uses the REST > client capabilities to pull files from the digital object repository. > In the case of the "GetFullDisplay" class, it uses the > built-in Restlet > TransformRepresentation to apply an XSLT stylesheet to a > Dublin Core XML > file. > > The source code can be browsed via our project management tool at > http://drc-dev.ohiolink.edu/browser/BaseDisseminator/trunk or > checked out at https://drc-dev.ohiolink.edu/svn/BaseDisseminator/trunk > (Subversion repository). > > Thanks again to Jerome and the rest of the Restlet contributors. > > > Peter > -- > Peter Murray > http://www.pandc.org/peter/work/ > Assistant Director, New Service Development > tel:+1-614-728-3600;ext=338 > OhioLINK: the Ohio Library and Information Network > Columbus, Ohio > The Disruptive Library Technology Jester > http://dltj.org/ > Attrib-Noncomm-Share > http://creativecommons.org/licenses/by-nc-sa/2.5/
restlet newbie question
Hi all, I am new to rest and restlet. I have a Spring based project and I would like to expose a web service using Restlet instead of SOAP. I came accross in this mailing list that Restlet (with Spring) can be used in one of the following 3 ways but I am still not sure as which way to adopt and if there is a code example that you can suggest specific to web services: 1) Standalone mode: based on the Spring extension (SpringContext + SpringFinder) and a standalone HTTP server connector. 2) Embedded mode A: based on the ServerServlet adapter and either the SpringContext (via the WAR client and "war:///path/config.xml" scheme) or via the usage of the ServletContext accessible when casting Restlet's Context to ServletContextAdapter. 3) Embedded mode B: lighter version where Spring and the Servlet container are not masked by the concept of Restlet Application. This requires the creating of a special Servlet (maybe a Spring's HttpBeanServlet subclass) and a bit of coding to convert Servlet's calls into Restlet's calls. In this mode, no Restlet's Application is created, Restlets/Filters/Routers/Finders are directly instantiated by Spring and configured like other Spring beans. Of course you loose the Application services and the portability of your Restlet code to other deployment environments. Any advice/help is highly appreciated. Thanks in advance.
Example of a Restlet Application/Servlet using both Client and Server
Thanks, Jerome, for your recent replies on questions about the 1.0.0 release, and for your efforts on Restlet in general. It is truly a useful piece of work. I'd like to share an Restlet-based application that others may find useful as a template or example. It is called "BaseDisseminator" and is used in conjunction with a digital object repository to perform transformations on objects. It has a number of interesting features made easy by Restlet. BaseDisseminator can be built as completely packaged Java application (using the One-Jar class loader to embed the requisite JARs inside one JAR) or as a servlet running in any servlet container. In its command-line application form (built using `ant jar`), it takes two optional parameters -- the first is the port to listen on and the second is the URL prefix of the digital object repository. In its servlet form (built using `ant war`), the the digital object repository URL prefix is specified as an init parameter in WEB-INF/web.xml. In addition to operating as a Restlet-based server, it uses the REST client capabilities to pull files from the digital object repository. In the case of the "GetFullDisplay" class, it uses the built-in Restlet TransformRepresentation to apply an XSLT stylesheet to a Dublin Core XML file. The source code can be browsed via our project management tool at http://drc-dev.ohiolink.edu/browser/BaseDisseminator/trunk or checked out at https://drc-dev.ohiolink.edu/svn/BaseDisseminator/trunk (Subversion repository). Thanks again to Jerome and the rest of the Restlet contributors. Peter -- Peter Murrayhttp://www.pandc.org/peter/work/ Assistant Director, New Service Development tel:+1-614-728-3600;ext=338 OhioLINK: the Ohio Library and Information NetworkColumbus, Ohio The Disruptive Library Technology Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: Getting servlet init parameters out of 'web.xml'
On 4/24/07 4:24 AM, Jerome Louvel wrote:
> In the Servlet extension, we have a ServletContextAdapter that is used to
> adapt a Servlet context into a Restlet context.
>
> It ensures that logging and init parameters are properly exposed to your
> Restlet Application. Therefore, you should be able to get your
> initialization parameters simply by doing:
>
> String value =
> getContext().getParameters().getFirstValue("myServletInitParam");
Oh, good heavens -- you're making it that easy? I was trying way to
hard to find it. Thank you.
Peter
--
Peter Murrayhttp://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information NetworkColumbus, Ohio
The Disruptive Library Technology Jesterhttp://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: Reference not resolving
On 4/24/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: [...] > That confusion over the file- or dir-ness is *precisely* why the "add > trailing slash" hack is done everywhere. Jerome's argument that > disagreement is moot because of the "add trailing slash" hack is > plenty of proof. :-) The Reference class has no clue about whether "dir" is a file name or a directory name or a logical resource name. It is only at the connector level that we can get this metadata. Understood. The URI RFC is very clear about the way relative URI references should be resolved, they even specify a generic algorithm: http://gbiv.com/protocols/uri/rfc/rfc3986.html#absolutize Just because the spec is clear doesn't mean it's right. As noted... The Reference class implements this exact algorithm and nothing more. Now, like the Apache HTTP Server does (http://httpd.apache.org/docs/2.2/mod/mod_dir.html) we provide an automatic redirection feature to prevent this unintuitive relative resolution. Note that this is only unintuitive for URIs mapped to directories or similar folders. ...the hack is necessary to mitigate the error. > If directories always have the trailing slash then there's no > (non-intentional) ambiguity. If directories don't always have the > trailing slash then it's always ambiguous and we end up with the > POLS-violating behavior that started this disagreement. In general, this directory redirections shouldn't be triggered if all representations contain hyperlinks with trailing slashes for directories. The only case where it can be necessary is when the user manually enters the URI or when such an URI is bookmarked. This takes us, full circle, back to the confusion that started this thread originally... The implementation, and all of the consequential edge cases, lead to a confusing mental model of the expected behavior. This specific example of adding a "sub" reference to a "http://some.com/dir"; gives the erroneous answer of "http://some.com/sub"; rather than "http://some.com/dir/sub";. As you noted, if the directory is "always" (re)written to the proper, normalized form "http://some.com/dir/"; then the expected behavior is kept. Great but that doesn't lessen the confusion for developers who have to keep this extraneous complicatification in mind and make sure their code works regardless. I hope this clarifies my position. Otherwise, could you concretely explain how you would implement your behavior in the Reference class code. I understand your position and so I shall discontinue further argument on this point. Take care, John
RE: Reference not resolving
John, [...] > That confusion over the file- or dir-ness is *precisely* why the "add > trailing slash" hack is done everywhere. Jerome's argument that > disagreement is moot because of the "add trailing slash" hack is > plenty of proof. :-) The Reference class has no clue about whether "dir" is a file name or a directory name or a logical resource name. It is only at the connector level that we can get this metadata. The URI RFC is very clear about the way relative URI references should be resolved, they even specify a generic algorithm: http://gbiv.com/protocols/uri/rfc/rfc3986.html#absolutize The Reference class implements this exact algorithm and nothing more. Now, like the Apache HTTP Server does (http://httpd.apache.org/docs/2.2/mod/mod_dir.html) we provide an automatic redirection feature to prevent this unintuitive relative resolution. Note that this is only unintuitive for URIs mapped to directories or similar folders. > If directories always have the trailing slash then there's no > (non-intentional) ambiguity. If directories don't always have the > trailing slash then it's always ambiguous and we end up with the > POLS-violating behavior that started this disagreement. In general, this directory redirections shouldn't be triggered if all representations contain hyperlinks with trailing slashes for directories. The only case where it can be necessary is when the user manually enters the URI or when such an URI is bookmarked. I hope this clarifies my position. Otherwise, could you concretely explain how you would implement your behavior in the Reference class code. Best regards, Jerome
Re: Restlet & XMPP
On 4/24/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Alex, Thanks for leveraging the Restlet API in this new effort. This looks useful and really promising! Thanks. I've actually just gotten it to the point where I can create an application and have it respond to both HTTP and XMPP. It attempts to chunk large messages so that they are delivered in smaller packets over XMPP. It seems to be working and I'm quite pleased with the result. The cool bit here is that I've been able to dump my old API in Xeerkat in favor of the restlet API. If you then want to do additional collaborative computing over XMPP, you just use a framework API that I provide via the context. That means writing simple applications is as simple as writing a Restlet--which is really the right abstraction. --Alex Milowski
Re: Reference not resolving
On 4/23/07, Mike Moran <[EMAIL PROTECTED]> wrote: On 23 Apr 2007, at 00:33, John D. Mitchell wrote: > Sorry for the slow response, too busy to keep up. :-( >> [ ... ] >> Note that we enforce all the URI spec examples with a set of unit >> tests. >> Looking at how tricky those examples are, we feel very confident >> about the >> quality of Reference's output :) > > Sorry, IMO that's still incorrect... > > If 'dir' is a directory then the behavior is as I noted. If 'dir' is > actually a file *then* the behavior that you mention would be correct. > > This behavior is obvious (Principle of Least Surprise) if one mimics > the behavior by actually trying these out in a shell and move around a > filesystem. :-) Just have to butt in here to support Jerome: the Reference is a representation of a URL and URLs can know nothing about whether a path represents a directory or a file. It is up to the server to enforce any semantic breakage that occurs. This *must* be the case, otherwise URL manipulations would have to round-trip to the server to discover 'dirness' or 'fileness'. I'll continue to disagree... That confusion over the file- or dir-ness is *precisely* why the "add trailing slash" hack is done everywhere. Jerome's argument that disagreement is moot because of the "add trailing slash" hack is plenty of proof. :-) If directories always have the trailing slash then there's no (non-intentional) ambiguity. If directories don't always have the trailing slash then it's always ambiguous and we end up with the POLS-violating behavior that started this disagreement. Thanks, John
Re: ConnectorService implementation
Jerome Louvel noelios.com> writes: > > > Hi Dig, > > This attribute should indeed have been set early by the Application itself. > This bug is now fixed in SVN. > > Let me know if the ConverterService now works as expected without you custom > Finder. BTW, calling setConnectorService() is sufficient. > > Best regards, > Jerome > Jerome, Many thanks for looking at this. I will wait for your next binary release and upgrade at a suitable time. Our application is in UAT and moving to live very soon so I can't change anything at the moment. Best regards, Dig.
Re: Maven support
On 24 Apr 2007, at 10:50, Jerome Louvel wrote: If we automate the refresh of the first repository every week (and immediately in case of a major security issue), I think this is reasonable for most projects depending on Restlets. What do you think? This sounds quite reasonable, one week is not bad :-) Understood, its mostly a packaging/distribution indeed. We don't want to move to Maven yet as it doesn't play well with Eclipse plugins organization (flat structure), and beside that Ant fully satisfied us so far. We have experienced similar problems with the Maven2 plugin for Eclipse, yes. :-) (Our project has perhaps 35 sub-projects, all flattened to one giant thing in Eclipse.. which is mainly an issue with dependencies) -- Stian Soiland, myGrid team School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/
RE: HTTP client don't support long username/pw for HTTP basic authentication
Stian, Thanks for the report and the patch. This is now fixed in SVN. I would also like to integrate your JUnit test case. For this, would it be possible for you to return me (scanned by email, fax or letter) the signed Joint Copyright Assignment available here: http://www.restlet.org/community/contribute ? Best regards, Jerome > -Message d'origine- > De : Stian Soiland [mailto:[EMAIL PROTECTED] > Envoyé : lundi 23 avril 2007 15:19 > À : discuss@restlet.tigris.org > Objet : HTTP client don't support long username/pw for HTTP > basic authentication > > > Hello! > > I found a bug in that the REST HTTP client fails with HTTP basic > authentication if the username/password is too long. > > The fault occurs because the base64 encoding inserts linebreaks, > although this is not what the servers (including Jetty) > expects. This > means that even Restlet client to Restlet server fails. > > Attached is a JUnit 4 testcase (where are the other unit tests > located..? Is it modules/org.restlet.test in SVN?) > HTTPBasicTest.java > and a patch to SecurityUtils.java in restlet-1.0.0-httpauth.patch > > The test is a simple application with a guard and two possible > username/passwords, one short combination and one long combination. > The guard system.out-s the combinations. When running with Restlet > 1.0.0, the output is: > > (From the direct tests against the Guard) > > Checking user13 pw15 > Checking aVeryLongUsernameIsIndeedRequiredForThisTest > thisLongPasswordIsExtremelySecure > (..) > > (From the tests through HTTP Basic auth) > > INFO: Basic HTTP authentication succeeded: identifier=user13. > Checking user13 pw15 > (..) > Checking aVeryLongUsernameIsIndeedRequiredForThisTest thisLongPass > (..) > > > Notice how the password has been chopped of. This is due to the > base64 encoding inserting \n linebreaks, although RFC 2617 says: > > base64-user-pass = except not limited to 76 char/line> > > A debug and tracing of the actual headers reveal that the header is > sent with a \n, and that the Jetty server interprets this as one > header with the beginning of the WWW-Authenticate header and > the next > as a header named "aksdjaksdj". > > > Note that the patch also changes the base64 encoding for SMTP and > AWS, although I haven't made test cases or tested these variants. > > > Attached: > > HTTPBasicTest.javaJUnit4 testcase > restlet-1.0.0-httpauth.patch patch of SecurityUtils.java from > Restlet 1.0.0 > SecurityUtils.javafrom Restlet 1.0.0 and > patch applied > > > >
RE: Maven support
Hi Stian, > If you do start your own repository, and there's nothing in the > license of say Asyncweb or Simple preventing you from doing so, you > can include those artefacts in that repository as well. Ideally > adding the repository for Restlet and the dependency for the chosen > Restlet artefacts should then be able to pull down automatically the > rest. That's what we thought too. Controlling the repository allows us to fix some dependencies with broken POMs or dependencies missing from other public Maven repositories. > > 1) fully free > > If you go for #1 I can contribute with at least 2 mirror sites which > should have enough bandwidth available. Thanks for the proposition. I will keep that in mind when needed :) > A commercial maven repository for a so-called open source project > don't sound quite right for me - what would prevent me from making a > competing "free" maven repository that would more easily get support > and possibly later merged with ibiblio? And if so - what is then the > point of the commercial repository except to encourage forking..? OK, let's cleanly separate things. There would be two repositories: 1) "maven.restlet.org" with a free access 2) "maven.noelios.com" with an access restricted to subscribers If we automate the refresh of the first repository every week (and immediately in case of a major security issue), I think this is reasonable for most projects depending on Restlets. What do you think? The second repository would be immediately refreshed with new releases, could also contain customer specific patches, provide a secure access, etc. The idea is to offer some extra features to Noelios customers who subscribe to a support plan, not to exclude other types of usages. I acknowledge that there are different ways to contribute to the Restlet project (code contributions, bug reports, suggestions, communication, etc.). > For me, Maven 2, definitively. I don't see a point in a maven 1 > repository, as Vincent points out, typical Restlet users are not > using Maven 1. OK, unless others disagree, we will follow your advice. > Maven 2 has lots of functionality built-in (OK, it's all > plugins) for > deploying to repositories, for instance using scp towards an Apache- > hosted (or Restlet-directory hosted, I Guess) directory. In our case, the build machine would be also hosting the repository, so the deployment part is easy. > The Maven book "Better builds with Maven" - available for free from > http://www.mergere.com/common/reg.jsp?form_source=m- > m2book&form_landing=DefaultPage - should have some references. You > don't have to move the whole build process to Maven to do the > deploy, although of course in the long run it could be worthwhile to > do that as well. Understood, its mostly a packaging/distribution indeed. We don't want to move to Maven yet as it doesn't play well with Eclipse plugins organization (flat structure), and beside that Ant fully satisfied us so far. Best regards, Jerome
RE: Maven support
Hi Vincent, Here is the guide to Ibiblio upload: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html As you can see, the default upload mechanism has manual steps. They do propose a synchronization script but that forces me to give an SSH access to their script, which I'm not too fond of. And I'm not even sure about the refresh delay. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : mardi 24 avril 2007 09:15 > À : discuss@restlet.tigris.org > Objet : Re: Maven support > > Jerome, > > > > Instead of relying on a public Maven repository such as > Ibiblio, we would > > prefer to host our own Maven repository at > "maven.noelios.com" and control > > its freshness and service quality. > > what prevents you from controlling ibiblio's freshness? > > -Vincent.
RE: Restlet & XMPP
Alex,
Thanks for leveraging the Restlet API in this new effort. This looks useful
and really promising!
I've just updated the Restlet Web site to mention third-party integrations
(eXist and XMPP for now). Let me know if important info is missing:
http://www.restlet.org/documentation/1.0/integrations
Best regards,
Jerome
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
> part de Alex Milowski
> Envoyé : vendredi 20 avril 2007 08:31
> À : discuss@restlet.tigris.org
> Objet : Restlet & XMPP
>
> I've been working on an integration of the Restlet Client and
> Server APIs
> with XMPP. I now have a working version (with many caveats).
>
> You can now do post, put, get, or head via XMPP with uris
> structured as:
>
>
> xmpp://{sender}/{sender-resource}/{recipient}/{recipient-resou
> rce}/{path}
>
> I struggled with how to structure this URI but I think this makes
> sense in that an XMPP client is connected to the server associated
> with their sender id (e.g. gmail.com for google talk). To get to
> the recipient, you need to talk to your XMPP server, via your
> resource name. The message is then sent to the recipient's
> specific resource. Keep in mind in XMPP that resources are just
> you logged into your IM client on different machines.
>
> The server is associated with a specific identity that you
> pre-establish
> when you start your application. In theory, you can have multiple
> XMPP+resource pairs running in one process but I haven't tested
> that.
>
> Internally, I'm using the smack API for XMPP.
>
> So, sending a message over XMPP is now:
>
> Response response = client.post(
>"xmpp://[EMAIL PROTECTED]/chat/[EMAIL PROTECTED]/chat/echo",
>new StringRepresentation("Hello World!"],MediaType.TEXT_PLAIN));
>
> and setting up a server is a little more complicated. For
> example, inside a
> component:
>
> XMPP.Identity id =
> XMPP.getInstance().addIdentity("[EMAIL PROTECTED]","password");
> Protocol xmpp = Protocol.valueOf("xmpp");
> getServers().add(xmpp, id.getId(),0);
> getClients().add(xmpp);
>
> and now you can attach a restlet that you can talk to over xmpp:
>
> VirtualHost host = new VirtualHost(getContext());
> host.attach("/echo",new Restlet() {
> public void handle(Request request,Response response) { ... }
> });
>
>
> So far I haven't figured out whether I need to do something
> special with
> the VirtualHost instance. The "server name", address, etc,
> are rather funny
> for XMPP since the connection is actually outward and the host doesn't
> actually bind to an address.
>
> I've put in some support for sending "binary types" but I haven't
> finished the receiving
> part. Right now you can send text/* media types and anything that is
> XML (types ending
> in "+xml" or any of the XML media types).
>
> You can take a peek at the code at the new xeerkat project:
>
>http://code.google.com/p/xeerkat/
>
> The old project is at java.net:
>
>https://xeerkat.dev.java.net/
>
> My plans are to move the whole API over to the restlet API and
> hide all the agent brokering in local services.
>
> --Alex Milowski
Re: Maven support
On 23 Apr 2007, at 18:10, Jerome Louvel wrote: Still, some dependencies like AsyncWeb and Simple are not available (yet?) in public repositories. It seems that users could workaround the current limitations by managing a local repository where they would manually upload the missing JAR files with matching POM files and version tags. We could even provide those POM files in the distribution if that would help. If you do start your own repository, and there's nothing in the licence of say Asyncweb or Simple preventing you from doing so, you can include those artefacts in that repository as well. Ideally adding the repository for Restlet and the dependency for the chosen Restlet artefacts should then be able to pull down automatically the rest. 1) fully free If you go for #1 I can contribute with at least 2 mirror sites which should have enough bandwidth available. A commercial maven repository for a so-called open source project don't sound quite right for me - what would prevent me from making a competing "free" maven repository that would more easily get support and possibly later merged with ibiblio? And if so - what is then the point of the commercial repository except to encourage forking..? As I said, we haven't fully decided yet so it's time to express your opinion. Thierry has already started the work on the repository which will of course run on Restlets :) He is struggling a bit to find reliable reference information on the repository layouts. For example, should we support the "legacy" layout from Maven 1 or should be directly move to the better one introduced by Maven 2. Does anyone has good pointers? For me, Maven 2, definitively. I don't see a point in a maven 1 repository, as Vincent points out, typical Restlet users are not using Maven 1. Maven 2 has lots of functionality built-in (OK, it's all plugins) for deploying to repositories, for instance using scp towards an Apache- hosted (or Restlet-directory hosted, I Guess) directory. The Maven book "Better builds with Maven" - available for free from http://www.mergere.com/common/reg.jsp?form_source=m- m2book&form_landing=DefaultPage - should have some references. You don't have to move the whole build process to Maven to do the deploy, although of course in the long run it could be worthwhile to do that as well. -- Stian Soiland, myGrid team School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/
RE: Getting servlet init parameters out of 'web.xml'
Hi Peter,
In the Servlet extension, we have a ServletContextAdapter that is used to
adapt a Servlet context into a Restlet context.
It ensures that logging and init parameters are properly exposed to your
Restlet Application. Therefore, you should be able to get your
initialization parameters simply by doing:
String value =
getContext().getParameters().getFirstValue("myServletInitParam");
Let me know if it doesn't work as expected.
Best regards,
Jerome
> -Message d'origine-
> De : news [mailto:[EMAIL PROTECTED] De la part de Peter Murray
> Envoyé : lundi 23 avril 2007 17:41
> À : discuss@restlet.tigris.org
> Objet : Getting servlet init parameters out of 'web.xml'
>
> If I'm putting a Restlet-based server into a servlet
> container, is there
> a way to get the parameters out of the 'web.xml'
> file? If
> so, how and where?
>
> I see 'getInitParameter()' in the ServerServlet extension
> let/ext/servlet/ServerServlet.html#getInitParameter(java.lang.
> String,%20java.lang.String)>
> but I'm not sure how to get to it in a Restlet era with no
> "RestletContainer". (I found sample code that used RestletContainer,
> but that was before the API was finalized.)
>
>
> Peter
> --
> Peter Murray
> http://www.pandc.org/peter/work/
> Assistant Director, New Service Development
> tel:+1-614-728-3600;ext=338
> OhioLINK: the Ohio Library and Information Network
> Columbus, Ohio
> The Disruptive Library Technology Jester
> http://dltj.org/
> Attrib-Noncomm-Share
> http://creativecommons.org/licenses/by-nc-sa/2.5/
RE: RE: Directory restlet
Hi Chuck,
Agreed, the Javadocs have been updated in SVN. The general rule is to use
the constructor with the Context parameter instead of the default/"lazy"
one.
Best regards,
Jerome
> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED]
> Envoyé : lundi 23 avril 2007 15:31
> À : discuss@restlet.tigris.org
> Objet : RE: RE: Directory restlet
>
> I've always wondered about this...
>
> I've noticed that a lot of the Restlet subclasses have two
> constructors - a no-arg constructor and one that takes a
> Context object. Trouble is, none of the API documentation
> indicates why I would use one over the other. It would be
> nice if there were something in the API docs that says which
> should be used when.
>
> --Chuck
>
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 23, 2007 8:07 AM
> To: discuss@restlet.tigris.org
> Subject: RE: Directory restlet
>
>
> Hi all,
>
> This is the same issue indeed. I've added a test to prevent
> the NPE and log a warning message in the log instead.
> Committed to SVN.
>
> Best regards,
> Jerome
>
> > -Message d'origine-
> > De : Jeff Walter [mailto:[EMAIL PROTECTED] Envoyé : lundi 23
> > avril 2007 13:55 À : discuss@restlet.tigris.org Objet : Re:
> Directory
> > restlet
> >
> > Hey Chuck,
> >
> > I had this same issue earlier this month -- it seems now
> when creating
> > your application object, you need to pass it the component Context.
> >
> > Application application = new ProxyEngine(component.getContext ());
> >
> > Hope this helps,
> > Jeff
> >
> >
> > On 4/20/07, Chuck Hinson <[EMAIL PROTECTED]> wrote:
> >
> >
> > I thought I had done this before and had it working.
> > Can somebody tell
> > me what I' m doing wrong?
> > I'm using the 1.0.0 release.
> >
> > --Chuck
> >
> > public Restlet createRoot() {
> >
> > Context context = getContext();
> > Router router = new Router(getContext());
> >
> > // router.attach("/provider/", ProviderResource.class);
> > Directory directory = new Directory(getContext(),
> > " file:///D:/tmp/");
> > router.attach("/files/",directory);
> >
> > return router;
> >
> > }
> >
> > public static void main(String[] args)
> > throws Exception
> > {
> >
> > Component component = new Component();
> > component.getServers().add(Protocol.HTTP, 8003);
> > component.getClients().add(Protocol.FILE);
> >
> > Application application = new ProxyEngine();
> >
> > VirtualHost host = component.getDefaultHost();
> > if (host == null) throw new RuntimeException("test");
> > host.attach("", application);
> >
> > component.start();
> >
> > }
> >
> >
> > When I put http://localhost:8003/files/ in my browser,
> an exception
> > is
> > thrown:
> >
> >
> > Apr 20, 2007 4:20:00 PM
> > com.noelios.restlet.StatusFilter getStatus
> > SEVERE: Unhandled exception or error intercepted
> > java.lang.NullPointerException
> > at
> >
> >
> com.noelios.restlet.application.ApplicationDispatcher.handle(Applicat
> > ionDispatcher.java:81)
> > at
> > com.noelios.restlet.TemplateDispatcher.handle
> > (TemplateDispatcher.java
> > :89)
> > at org.restlet.Uniform.handle(Uniform.java:97)
> > at org.restlet.Uniform.get(Uniform.java:74)
> > at
> >
> >
> com.noelios.restlet.local.DirectoryResource.(DirectoryResource.
> > java:142)
> > at
> >
> > com.noelios.restlet.Engine.createDirectoryResource(Engine.java:253)
> > at org.restlet.Directory.findTarget(Directory.java:145)
> > at org.restlet.Finder.handle(Finder.java:268)
> > at org.restlet.Filter.doHandle(Filter.java:105)
> > at org.restlet.Filter.handle(Filter.java:134)
> > at org.restlet.Router.handle(Router.java:441)
> > at org.restlet.Filter.doHandle(Filter.java :105)
> > at org.restlet.Filter.handle(Filter.java:134)
> > at org.restlet.Filter.doHandle(Filter.java:105)
> > at
> > com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:87)
> > at org.restlet.Filter.handle (Filter.java:134)
> > at org.restlet.Filter.doHandle(Filter.java:105)
> > at org.restlet.Filter.handle(Filter.java:134)
> > at
> >
> >
> com.noelios.restlet.application.ApplicationHelper.handle(ApplicationH
> > elper.java:92)
> > at org.restlet.Application.handle(Application.java:290)
> > at org.restlet.Filter.doHandle(Filter.java:105)
> > at org.restlet.Filter.handle(Filter.java:134)
> > at
RE: Context, Attributes, and Parameters...
Hi Alex,
> I've run into a snag where I've set an attribute on the
> context to pass along environment information to parts of
> my application. When I pass the attribute via the context
> in the constructor, the constructor can get access to the
> attribute but later on the getContext() method's return
> doesn't have that attribute. I assume that is because the
> "parent" context's attributes aren't available to the
> "current" context.
You report an issue similar to Chuck. The idea is indeed to isolate the
parent component's attributes and parameters from the contained
applications.
[...]
> In the createRoot(), the getContext() call is return a
> different instance.
True, it returns a wrapper context that has its own attributes and
parameters. The parent dispatcher is reused and enhanced to provide URI
templating support and support for the war:// scheme.
> Should the attributes of the parent be available?
>
> If not, how is one suppose to pass along contextual configuration
> information to parts of your application.
Just like this:
Application myApp = new MyApplication(getContext());
myApp.getContext().getAttributes().put("att1", value1);
myApp.getContext().getParameters().add("param1", "value1");
> In my case, each Application instance is loaded from specific
> jar files and given a number of environment objects via attirbutes
> on the Context instance. Should I be doing this differently?
If you want to ensure the portability of your Application and preserve its
"self-contained" aspect, you shouldn't rely on environment attributes. When
we add support for WAR packaging in 1.1, we will provide a way to declare
parameters to be set on the Application, but not for Attributes. Instead,
each application should initialize its own attribute objects based on
environment parameters for example.
> A similar use case would be the "JDBC data source" in that if
> the application creates the data source, how does should it pass that
> along to arbitrary resources that use the data source?
Application attributes are definitely available for this kind of usage. You
should just set them inside your Application rather that externally inside
the Component code.
> It also isn't clear what the difference between parameters
> and attributes of are in the context.
Parameters are series/list of Parameter instances (name/value String pairs)
that are primarily intended for configuration purpose, like Java properties.
The "attributes"
property is a map of objects whose primarily purpose is to share contextual
objects
among all Restlets and Resources of an Application. I've clarified the
Javadocs
regarding those differences.
> Finally, in some situations (like my agent example where I load an
> jar file containing the application), I want to provide access to
> certain objects via, say, attributes but I don't want the Application
> instance to be able to change that object. Since getAttributes() and
> getParameters() return modifiable collections, that gets a bit
> complicated.
>
> I've now resorted to:
>
> Context agentContext = new Context() {
> Map attrs =
> Collections.unmodifiableMap(getContext().getAttributes());
> public Map getAttributes() {
> return attrs;
> }
> public Uniform getDispatcher() {
> return getContext().getDispatcher();
> }
> public Logger getLogger() {
> return getContext().getLogger();
> }
> public Series getParameters() {
> return getContext().getParameters();
> }
> };
>
> but that seems like it might be useless if the context is
> shadowed somehow.
This makes sense and the attributes set by your application (in the
constructor or in the createRoot() method) should be fully available to
attached Restlets and Resources. The "shadowing" only takes place between
the parent component and the contained applications.
Changes to Javadocs committed to SVN.
Best regards,
Jerome
Re: Maven support
Jerome, > Instead of relying on a public Maven repository such as Ibiblio, we would > prefer to host our own Maven repository at "maven.noelios.com" and control > its freshness and service quality. what prevents you from controlling ibiblio's freshness? -Vincent.
Re: Maven support
Jerome , > > should we > support the "legacy" layout from Maven 1 or should be directly move to the > better one introduced by Maven 2. Does anyone has good pointers? I don't think that too many people will want to add restlet to an existing project that is built with maven 1.x. It's more likely that the framework is being used for new projects, which should use maven 2. -vincent http://gmane.org/word.php?id=76346
