Re: PUT with no entity (architecture question)

[Chuck Hinson]

Someone might consider putting this question to the people doing the
2616bis update to HTTP.  See
http://www.ietf.org/html.charters/httpbis-charter.html - there is a
mailing list.

As I understand it, part of their charter is to clarify some of the
murkier pieces of the spec; this sounds like it might be one of those
places.

--Chuck

On Jan 14, 2008 10:50 AM, Rob Heittman <[EMAIL PROTECTED]> wrote:
> > My interpretation of the spec is that an entity is required for a PUT
>
> I always thought so, but couldn't find a clear citation thereof, which
> surprises me greatly.  This kind of contravenes one of my core understanding
> about what "existence" means for a resource.  If anyone is in conversational
> contact with any of the HTTP/1.1 authors, I'd be academically interested in
> their intent on this point!
>
> In reality, I think the issue is that lots of implementors and
> implementations have interpreted it the same way as Restlet, so for all
> intents and purposes it's probably a bad idea to introduce an API that
> relies on PUT of empty entities.
>
> Rhett, I looked back at some of our projects using this design and found
> that in all cases the link attributes are /important./  So maybe if you
> define the entity body as containing a list of link attributes (which may be
> empty for now; ) you may find that instead of being an ad
> hoc workaround, this is a good forward-looking step for future evolution of
> your solution.  Unless your understanding of the problem domain indicates
> that there will never be any attributes associated with such a linkage.
>
> - Rob
>
>

Re: Testing strategies

[Chuck Hinson]

On Nov 19, 2007 3:35 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Chuck,
>
> > Jerome, I know you've made this statement before (interfaces in public
> > APIs), and since it is your project, I've not pressed you about it,
> > but I'd still like to see some evidence that this is more than just
> > personal opinion.
>
> Initially, the API had many interfaces but some (Henry Story I think)
> pointed me that public APIs based on interfaces are fragile because once
> they are published they can't easily evolve.
>
> If you have interface A with method A1 in version 1.0, then users will
> implement it in their custom classes, this is fine, they can easily mock
> them.
>
> Then, for version 2.0, the need to add method A2 appears and is added to the
> A interface. When the API is published, users try to upgrade and realize
> that their custom classes don't implement method A2, or implement it with a
> different purpose or different arguments. Their code is broken and the API
> break the ascendant compatibility.
[...]
I see the point, but remain unconvinced; with modern refactoring and
dependency management tools, I'm not sure that this is an actual
problem.

I'd also point out that many people view the addition of a method to a
base class (abstract or otherwise) as a breaking change (because
existing clients may have already implemented a method with the same
signature in existing subclasses).

If you change an API, it doesnt seem unreasonable to me to expect
that implementors will have to change their implementation.

To me, it seems like a case of throwing the baby out with the bath
water.  Versioning's hard, and there are appropriate and inappropriate
uses of interfaces, but to make a blanket statement that interfaces
shouldn't be used in a published API seems unwarranted.

I was actually hoping for a pointer to a discussion about the pros and
cons of using abstract classes instead of the interfaces in published
APIs, but I haven't been able to find anything - which makes me wonder
whether it's really that big a deal.

--Chuck

Re: Testing strategies

[Chuck Hinson]

Jerome, I know you've made this statement before (interfaces in public
APIs), and since it is your project, I've not pressed you about it,
but I'd still like to see some evidence that this is more than just
personal opinion.

As for unit testing Restlets, I've found them much easier to test than
servlets, primarily because there's no need to mock request objects -
you can just create and initialize a Request and feed it directly to
your resource via getRepresentation() (or put(), post(), etc).

--Chuck


On Nov 19, 2007 4:39 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
> Hi Justin,
>
> The usage of interfaces is discouraged in public APIs because they prevent
> changes in later releases (breaking existing implementation classes).
>
> I'm not familiar with EasyMock, but isn't it possible to generate mock
> objects that are subclasses of other classes, like a MockRequest extending a
> Request and setting custom values ?
>
> Could you describe a typical test that you would like to write, and we can
> discuss how we could write it ?
>
> Best regards,
> Jerome
>
>
> 2007/11/18, Justin Makeig < [EMAIL PROTECTED]>:
>
> > I'm curious if and how others are writing unit tests for Restlet
> > applications. In previous J2EE web apps I've written I've made heavy
> > use of Easy Mock  for mocking collaborators
> > and replaying scripts to validate behavior. Mocks lend themselves
> > very well to interface-centric architectures, such as the style that
> > Spring encourages. However, types, such as Context, Request, and
> > Response are all concrete classes, requiring runtime contortions to
> > mock or stub implementations, for example to set the attributes on a
> > Request. The tests in the trunk don't seem very illustrative. Any
> > suggestions would be much appreciated. Thanks.
> >
> > Justin
> >
>
>

Re: HEAD not well supported?

[Chuck Hinson]

On 10/11/07, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Sean,
>
> > I think *Representation is problematic: headRepresentation()?
> > I understand your
> > concerns with get(Variant), getVariant(). A colleague of mine
> > pointed out that
> > conceptually, merely using post(), get(), etc., is like
> > encroaching on a global
> > name space. He suggested (and I'm comfortable with),
> > doPost(), doGet(), doHead(),
> > doDelete(), doPut(), and doOptions(). The 'do' has the effect
> > of taking
> > the names out of the global name space...conceptually.
>
> I agree, but what do you think about the fact that we already have the
> handleGet, handlePost, handleHead or handleOptions right in the Resource
> class?
>
> Do you think that handleHead() should call a doHead() method? What would be
> the added value?
>
> In case of handleGet() we provide a default implementation based on the
> getVariants() and getRepresentation(Variant) methods in order to provide a
> default support for content negotiation. Same for handleHead() which in 99%
> of the case is just a GET with no entity sent back on the wire.
>
> The handleOptions() also has a default implementation which is based on the
> "alloww*" methods available that return true.
>
> If you don't want to use content negotiation, you could directly override
> the handleGet(), handleHead() methods. Doesn't it cover your needs?
>

allowPut(), allowPost(), allowDelete(), allowGet()

handlePut(), handlePost(), handleDelete(), handleGet()

put(), post(), delete(), getRepresentation() - eh? what?

The lack of symmetry there is jarring - it leads people to go looking
for the get() method and when they cant find it, they're confused.

I think two things need to happen.  First, the documentation for
handlePut(), handlePost(), handleDelete() and handleGet() needs a
whole lot more detail making it plain what exactly they do.   As the
documentation stands right now (1.0), it's not even clear that
handleGet() will ultimately call getRepresentation().  And handlePut,
handlePost and handleDelete appear to do nothing more than call
put,post or delete respectively - even though the code shows that
there's a lot more going on.

And second, yes, I think put(), post() and delete() and
getRepresentation() need to be renamed.  While doPut(), doPost(),
doDelete() and doGet() are OK, I think I'd prefer processPut(),
processPost(), processDelete() and processGet() - but anything that
makes it clear that they are at the same level of processing is fine.

I've puposely avoided head and options because they're less
well-known, but the do*() and process*() patterns seem to cover them
just fine.

And if you don't want handleHead() being a one-liner with a call to
doHead(), make it clear in the docs that handleHead() actually calls
doGet().  Besides, I think the number of people who will be looking
for a head() or doHead() method will be significantly smaller than the
number of people looking for get() or doGet(). (And just how many
cases are there where you'd want to override the default behavior of
head anyway?)

--Chuck

Re: HEAD not well supported?

[Chuck Hinson]

On 10/10/07, Sean Landis <[EMAIL PROTECTED]> wrote:
[...]
> We have about a dozen people writing web services using Restlet. Although
> head is confusing, I'd say we experience more confusion over the fact
> that GET is a 'special case'. That is, there's no get(), but instead you
> must use getRepresentation(). So far, every single developer here has stumbled
> on this and required explanation. I'm afraid I can't give a rationale, I
> just tell them that's the way it is.
>
> Sean
>

+1

I've had the same experience with my group, and like Sean, I am at a
loss as to how to explain why it has to be this way.

At this point, i don't have a suggestion for how to resolve this, but
I do think it violates the principle of least surprise (in a sort of
roundabout way), and probably should have some effort devoted to
determining whether this approach is worth the cognitive overhead it
imposes.

--Chuck

Re: Facelets

[Chuck Hinson]

On 10/4/07, Michael Terrington <[EMAIL PROTECTED]> wrote:
> Chuck Hinson wrote:
> > Interesting.  What were the biggest reasons for removing JSF
> > references/dependencies?
>
> Several really:
>
>   * JSF is a full MVC framework and I just wanted a templating engine to
> create XML views.  I really liked Facelet's syntax vs. Velocity and
> Freemarker.
>
Sounds reasonable.


>   * I prefer to create proper XHTML templates that I can preview in a
> browser, not replace every HTML tag with some JSF equivalent. (There's
> some caveats to that, since there's still a lot of taglib usage and
> often you want to just right one tag and have it expand to a heap of HTML.)
>
As does this.

>   * The JSF component model is stateful.  I wouldn't be using Restlets
> if I didn't already think that was a bad thing :)
>
I thought I read that you could configure facelets (or maybe it was
myfaces) to do client-side state saving;  wouldn't that take care of
the state issue, or is there something else going on besides that?

Mind you, I'm just starting to look into facelets.  My main attraction
initially is that it doesnt require a servlet container (which makes
testing a whole lot easier).

--Chuck

Re: Facelets

[Chuck Hinson]

Interesting.  What were the biggest reasons for removing JSF
references/dependencies?

--Chuck

On 10/3/07, Michael Terrington <[EMAIL PROTECTED]> wrote:
> Hi Chuck,
>
> I've ported Facelets to Restlets (removed the JSF dependencies).  You
> can get it here: http://trac.sarugo.org/xtc
>
> Regards,
> Michael.
>
> Chuck Hinson wrote:
> > Has anyone tried to do anything with Facelets in Restlets.  Is it even 
> > possible?
> >
> > --Chuck
>

Facelets

[Chuck Hinson]

Has anyone tried to do anything with Facelets in Restlets.  Is it even possible?

--Chuck

RE: WSSE lib, Guard and restlet

[Chuck Hinson]

FWIW, we needed some WSSE processing for something we were doing a few
months ago.  We started out with Wss4j, but it didn't handle
certificate-based signing, so we switched to XWss (part of glassfish).

Both of these require valid SOAP envelopes (don't know how that fits in
with your Restlet plans) and XWss definitely had some (painful) quirks
(as of 6 months ago).  Neither required a SOAP stack (which is why we
selected them), and we did use them as part of a Restlet-base app, but
not as guards.

--Chuck

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien PLISSON
Sent: Friday, August 31, 2007 3:30 PM
To: discuss@restlet.tigris.org
Subject: WSSE lib, Guard and restlet

Hi,

I m looking for a good WSSE java library that I could use to implement a
Guard that woul manage WSSE security in the Restlet API.

Any idea ? comment ?

Thanks

Sebastien

RE: Reusable representations

[Chuck Hinson]

First, I'm not sure I understand why you'd call getEntityAsForm() if the
params are in the URI.
 
Second, this really doesnt have anything to do with REST - it has to do
with network communications.  When you're recieving data from a socket,
once you've read the bytes, you can't put them back.
 
As far as caching goes, my experience is that it is hard to implement in
a meaningfully general way that doesn't kill performance in any
non-trivial system.  First off, some messages can be really large and
you'd rather stream them directly to a file rather than trying to cache
them in memory.  Secondly (and probably more important), you don't
generally know ahead of time how big the incoming entity is, so you
can't efficiently allocate memory.
 
Finally,I'm in agreement with Rob's later message - this
getEntityAsXXX() stuff really belongs outside of the Message/Request
classes.
 
 
--Chuck
 
 
 


From: Rob Heittman [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 28, 2007 10:12 AM
To: discuss@restlet.tigris.org
Cc: discuss@restlet.tigris.org
Subject: Reusable representations



(Changed subject line to reflect drift)  Adam and I were discussing this
at our shop yesterday ...

One of the issues I have seen bite Restlet newbies is that Form is the
idiomatic path to access query string parameters and such, but
getEntityAsForm() consumes the request.  If someone calls
getEntityAsForm() in, say, a Guard, to look for an authentication token
on the URI, a downstream Restlet trying to get the representation will
fail and this results in puzzlement.

Now, it is not good REST to mix a function call paradigm with
representational state transfer in the same call; while it is a common
Web practice to glue query string parameters onto an unrelated
representation as a signalling mechanism, this is not RESTful, and it is
probably good that the NRE discourages this.  Notionally, a single HTTP
operation transacts a single representation, and that representation
should represent a single thing.

But I think it would be perfectly fine, however, if getEntityAsForm()
and getEntityAsDom() could be called repeatedly, and subsequent calls
against the same Entity would simply retrieve a reference to the Form or
DomRepresentation created in the prior call.  This neither encourages
sloppy REST nor breaks scalability.  The relevant in-memory objects have
already been created and will go away when the request completes.  While
the underlying representation types (e.g. StreamRepresentation or
SaxRepresentation) are indeed transient, the Form and DomRepresentation
actually represent a completed in-memory parse of the underlying
transient representation ... and need not be transient themselves.

So this would work:

Form form1 = request.getEntityAsForm();
String f1s = form1.getFirstValue("foo");
Form form2 = request.getEntityAsForm(); // just returns
another reference to form1
String f2s = form2.getFirstValue("foo"); // should not
throw an exception

While you might no longer be able to access the original entity or a
/different/ Representation after calling one of these methods, there's
no reason that a number of Restlets in the same chain, needing to
operate on a Form or DomRepresentation, actually need to implement their
own private caching mechanism.  We already have some fairly long chains
of Restlets using components that are supposed to be pluggable and
interoperable; the less they have to be aware of each other the better.

I haven't looked into a patch yet, but I can't imagine it would be
tragically complex.

Thoughts?

- Original Message -
From: "Thierry Boileau" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Tuesday, August 28, 2007 2:59:36 AM (GMT-0500) America/New_York
Subject: Re: Custom gaurds

Hello Alan,

well, you're right, Jerome could have define Representations with some
caching system allowing to get content anytime we want. I think that
Jerome had made the design choice that :
 - gives you the lighter and cheaper way to use transient
representations, when you read them once (which is a basic but probably
the most frequent case, I think) 
 - let you free to simply and transparently convert a transient
representation to a StringRepresentation (or any kind of self defined
representations) for example in case you want to read it several times
which means unavoidably that the content is "stored" in memory, in a
file, etc. 

best regards,
Thierry Boileau




On 8/27/07, Alan <[EMAIL PROTECTED]> wrote: 

Thierry Boileau  gmail.com> writes: 

>
> Hi,
>
> This "limitation" concerns the following representation
classes (and
> descendants included in the Restlet API and NRE) :
>

Ok, for my clarification:
the "limitation" is due to the implementation of the NRE
library,
not a limitation of the http model?

In th

RE: RE: Keep Alive Problem with Simple Framwork

[Chuck Hinson]

We were having a similar problem where PUT requests over a slow link would 
fail.  We resolved it by using the maxWaitTimeMs parameter for Simple.

I have no idea whether our issue is related or not, but I thought it'd be 
useful to have this in the archives.

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 16, 2007 2:39 PM
To: discuss@restlet.tigris.org
Subject: RE: Keep Alive Problem with Simple Framwork


Hi all,

Let's tackle this one now as it seems to bother several users. I've entered a 
bug report here:
http://restlet.tigris.org/issues/show_bug.cgi?id=348

Rob, if you could contribute your test case to report that would help us.

Best regards,
Jerome  

> -Message d'origine-
> De : Rob Heittman [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 16 août 2007 01:51
> À : discuss@restlet.tigris.org
> Objet : Re: Keep Alive Problem with Simple Framwork
> 
> Confirming all three methods exhibit the same problem on Simple with 
> 1.0-current as well as trunk.  I'll look at it further tonight if I 
> have time; we have a nicely reproducible test case.
> 
> - Original Message -
> From: "Rob Heittman" <[EMAIL PROTECTED]>
> To: discuss@restlet.tigris.org
> Sent: Wednesday, August 15, 2007 6:26:34 PM (GMT-0500) 
> America/New_York
> Subject: RE: Keep Alive Problem with Simple Framwork
> 
> I just saw this behavior in svn trunk on Simple with not just POST, 
> also PROPFIND and PUT ... anything with an entity body in the request.  
> I worked around it with the new
> Request.release() mechanism, but was not able to locate the underlying 
> cause.
> 
> 
> 

RE: RE: two quick questions

[Chuck Hinson]

I'll second Serge's feedback on the documentation.  

A user guide would be nice, but I'd argue that having accurate and useful 
javadoc would be much, much more helpful. 

For example, a coworker was implementing something that handled PUT - he 
overrode handlePut() instead of put(). Looking at the Javadoc, its not clear 
why you would use one vs. the other.  In fact, without looking at the code, I 
have no idea why you would use one over the other.  

There are dozens of other examples I could give - there are just too many 
entries where the description is simply just a restatement of the method name 
with no clue how it relates to anything else.

It would also be useful if there were more explicit references to HTTP instead 
of just using the generic REST terminology. Often, the REST terminology is way 
too vague - when I'm trying to interoperate with someone else, I'm operating at 
the HTTP level, not the REST level, so I need to know precisely what impact 
various methods have on request or response methods.  For example, it would be 
nice if Response.setRedirectRef actually said that it sets the Location header 
and whether it does anything else.


--Chuck


-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 15, 2007 1:33 PM
To: discuss@restlet.tigris.org
Subject: RE: two quick questions


Hi Serge,

You're welcome! Thanks for your patience in solving your routing issue. We know 
that a detailed user guide is missing in our documentation. We hope to start 
filling this hole at the end of the year.

Thanks also for the positive comparison against other frameworks. If you see 
anything missing for your requirements, please feel free to share them, we are 
always looking for improvements ideas.

BTW, the Restlet project is composed of a Restlet API, a reference 
implementation (called Noelios Restlet Engine, NRE), and a set of extensions. 
The whole package is considered as a framework.

Best regards,
Jerome  

> -Message d'origine-
> De : news [mailto:[EMAIL PROTECTED] De la part de serge Envoyé : 
> mercredi 15 août 2007 19:16 À : discuss@restlet.tigris.org Objet : Re: 
> two quick questions
> 
> > This should definitely work! :)Regards,Jerome
> > 
> Hi Jerome,
> 
> Thank you very much for helping - your suggestion helped, and it's 
> working as expected. I also would like to give a quick feedback. I 
> looked at messages on the board - a lot of people here are interested 
> in RESTful alternative to web services. I am primarily evaluating this 
> API (at least at this moment) as an alternative to building Web sites 
> with "cool" URLs (this also explains why I pay special attention to 
> anything that relates to this issue). I have gone already through a 
> number of frameworks that can do this (including Struts2/Webwork, 
> Rails, etc). I should say, so far from what I've seen and my attempts 
> to implement complex site designs, Restlet API (why you call it a 
> framework?) is the best option for various reasons. As far as this 
> thread is concerned, I can only say that just reading API javadocs I 
> would have probably never figured out how to solve the problem, and I 
> would have ended up with going through the source code. So, your help 
> is certainly appreciated.
> 
> Best regards,
> Serge

RE: support for apache abdera

[Chuck Hinson]

We implemented an APP-based datastore using restlets and abdera.  Was
there something in particular you wanted to know?

--Chuck 

-Original Message-
From: Jim Alateras [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 01, 2007 12:10 AM
To: discuss@restlet.tigris.org
Subject: support for apache abdera

Just wondering whether anyone has integrated aspects of Apache Abdera
using the restlet framework.

cheers

RE: Re: 404 from getRepresentation/handleGet?

[Chuck Hinson]

 

-Original Message-
> From: Thierry Boileau [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 19, 2007 4:41 PM
> To: discuss@restlet.tigris.org
> Subject: Re: 404 from getRepresentation/handleGet?
 [. . .]
>
> I hope this will help you,
> Thierry Boileau
> p.s.: DELETE method does not return 404 according to the HTTP rfc:
> "A successful response SHOULD be 200 (OK) if the response includes an
entity describing the 
> status, 202 (Accepted) if the action has not yet been enacted, or 204
(No Content) if the
> action has been enacted but the response does not include an entity."

This is only true for successful DELETE requests.

>From section 10.4 Client Error 4xx in rfc 2616:
"... These status codes are applicable to any request method."  

A DELETE may, in fact, result in a response with 404 status.

Consider the difference between 404 and 410.  If a server is able to
make the determination needed to return a 410 in response to a delete,
then I would expect that it would probably want to return a 404 for
those resources where it knows the resource is not permanently gone.  It
also seems reasonable to expect that it might want to return a 404 to
indicate that a delete is being attempted on a resource that never
existed in the first place.

Also consider that some application protocols use DELETE as part of
larger interaction where responding with a 2xx for a delete on an object
that never existed in the first place would cause the overall
interaction to complete erroneously. HTTPLR
(http://www.dehora.net/doc/httplr/draft-httplr-01.html) uses DELETE on a
message exchange resource to allow the client to signal to the server
that it believes it has finished sending a message.  If the server
responded with a 200 for a non-existant exchange resource, it would be
erroneously confirming that the message transfer was complete when in
fact, the server has no knowledge of the message transfer being referred
to.

--Chuck

RE: Re: PUT support for Directory

[Chuck Hinson]

OK.  I saw this, but I didn't know what a context Resource was, so I assumed it 
wasn't what I was looking for.  What's a context resource?

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 28, 2007 5:04 AM
To: discuss@restlet.tigris.org
Subject: Re: PUT support for Directory

Hi Chuck,

The Directory class already supports this! To enable it, use the 
Directory.modifiable property which is set to false by default.

Thanks,
Jerome


Chuck Hinson a écrit :
> I'm building something where I need to be able to PUT files to a 
> directory on the file system.  Is there something that would support 
> this out of the box.  It seems like Directory is close, but it doesn't 
> support PUT (and I'm not sure that it should).  Any suggestions other 
> than write my own resource?
>
>
> --Chuck
>
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  
>
>   

PUT support for Directory

[Chuck Hinson]

I'm building something where I need to be able to PUT files to a
directory on the file system.  Is there something that would support
this out of the box.  It seems like Directory is close, but it doesn't
support PUT (and I'm not sure that it should).  Any suggestions other
than write my own resource?


--Chuck

--------
Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: 2-way ssl

[Chuck Hinson]

I'd be happy to contribute a patch, though I don't know how one submits such a 
thing or in what format it should be submitted.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 04, 2007 3:35 PM
To: discuss@restlet.tigris.org
Subject: RE: 2-way ssl


Hi Chuck,

This sounds good. If you have time to contribute a patch that would help.
Otherwise, I'll get back to this a bit later. I've updated the issue with your 
suggestion:
http://restlet.tigris.org/issues/show_bug.cgi?id=281

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : lundi 4 
> juin 2007 20:38 À : discuss@restlet.tigris.org Objet : 2-way ssl
> 
> Thanks to some help from Toby, I've managed to get 2-way 
> authentication working.
> 
> However, it was not quite as simple as I expected.  The problem is in 
> the way the simple extension is handling keystores.
> 
> Usually, you have two keystores - one that contains all of the 
> certificates that you trust (called a trust store), and one that 
> contains the certificate and private keys used to sign things (called 
> a key store).  Most security policies require that the two stores be 
> separate files.  In particular, a keystore should only ever have one 
> entry in it, while a trust store will have many entries (one per root 
> cert that is trusted).
> 
> The simple extension, however, is using the same keystore file for 
> both the trust store as well as the keystore:
> 
> KeyStore keyStore = KeyStore.getInstance(getKeystoreType());
> FileInputStream fis = new FileInputStream(getKeystorePath());
> keyStore.load(fis, getKeystorePassword().toCharArray());
> 
> KeyManagerFactory keyManagerFactory = KeyManagerFactory
> .getInstance(getCertAlgorithm());
> keyManagerFactory.init(keyStore, 
> getKeyPassword().toCharArray());
> 
> TrustManagerFactory trustManagerFactory = TrustManagerFactory
> .getInstance(getCertAlgorithm());
> trustManagerFactory.init(keyStore);
> 
> I was able to get this to work by putting everything into a single jks 
> file, but, as I said above, this violates most security policies (at 
> least those of current my project and those in the US Dept of Defense)
> 
> This needs to be changed so that two separate files can be used - one 
> for trust and one for keys.  Something along the lines of (this is 
> untested, so dont copy and paste):
> 
> 
> KeyStore keyStore = KeyStore.getInstance(getKeystoreType());
> FileInputStream fis = new FileInputStream(getKeystorePath());
> keyStore.load(fis, getKeystorePassword().toCharArray());
> 
> KeyManagerFactory keyManagerFactory = KeyManagerFactory
> .getInstance(getCertAlgorithm());
> keyManagerFactory.init(keyStore, 
> getKeyPassword().toCharArray());
> 
> KeyStore trustStore =
> KeyStore.getInstance(getTruststoreType());
> fis = new FileInputStream(getTruststorePath());
> trustStore.load(fis, getTruststorePassword().toCharArray());
> 
> TrustManagerFactory trustManagerFactory = TrustManagerFactory
> .getInstance(getCertAlgorithm());
> trustManagerFactory.init(trustStore);
> 
> which also would require the following additional properties to be
> defined:
> truststorePath  
> truststorePassword
> truststoreType
> 
> Thanks.
> 
> --Chuck
> 
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

2-way ssl

[Chuck Hinson]

Thanks to some help from Toby, I've managed to get 2-way authentication
working.

However, it was not quite as simple as I expected.  The problem is in
the way the simple extension is handling keystores.

Usually, you have two keystores - one that contains all of the
certificates that you trust (called a trust store), and one that
contains the certificate and private keys used to sign things (called a
key store).  Most security policies require that the two stores be
separate files.  In particular, a keystore should only ever have one
entry in it, while a trust store will have many entries (one per root
cert that is trusted).

The simple extension, however, is using the same keystore file for both
the trust store as well as the keystore:

KeyStore keyStore = KeyStore.getInstance(getKeystoreType());
FileInputStream fis = new FileInputStream(getKeystorePath());
keyStore.load(fis, getKeystorePassword().toCharArray());

KeyManagerFactory keyManagerFactory = KeyManagerFactory
.getInstance(getCertAlgorithm());
keyManagerFactory.init(keyStore,
getKeyPassword().toCharArray());

TrustManagerFactory trustManagerFactory = TrustManagerFactory
.getInstance(getCertAlgorithm());
trustManagerFactory.init(keyStore);

I was able to get this to work by putting everything into a single jks
file, but, as I said above, this violates most security policies (at
least those of current my project and those in the US Dept of Defense)

This needs to be changed so that two separate files can be used - one
for trust and one for keys.  Something along the lines of (this is
untested, so dont copy and paste):


KeyStore keyStore = KeyStore.getInstance(getKeystoreType());
FileInputStream fis = new FileInputStream(getKeystorePath());
keyStore.load(fis, getKeystorePassword().toCharArray());

KeyManagerFactory keyManagerFactory = KeyManagerFactory
.getInstance(getCertAlgorithm());
keyManagerFactory.init(keyStore,
getKeyPassword().toCharArray());

KeyStore trustStore = KeyStore.getInstance(getTruststoreType());
fis = new FileInputStream(getTruststorePath());
trustStore.load(fis, getTruststorePassword().toCharArray());

TrustManagerFactory trustManagerFactory = TrustManagerFactory
.getInstance(getCertAlgorithm());
trustManagerFactory.init(trustStore);

which also would require the following additional properties to be
defined:
truststorePath  
truststorePassword
truststoreType

Thanks.

--Chuck


Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: Re: 2-way SSL authentication

[Chuck Hinson]

Toby,

I'm about to try out the ssl client auth stuff.  I looked in javadoc,
but didn't see anything.
What all did you have to do to get client auth working?

I assume I at least have to do (the equivalent of) the following (on the
command line):
-Djavax.net.ssl.trustStore=arces-ca-trust.jks
-Djavax.net.ssl.trustStorePassword=secret
-Djavax.net.ssl.keyStore=b-0480-identity.jks
-Djavax.net.ssl.keyStorePassword=secret

Did you use Simple?  Is there any additional configuration required
there?

Also, where are you doing:
getContext().getParameters().add("needClientAuthentication",
"true")

Are you doing it in Restlet.createRoot() or somewhere else?


--Chuck

-Original Message-
From: Toby Thain [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 30, 2007 10:51 AM
To: discuss@restlet.tigris.org
Subject: Re: 2-way SSL authentication


On 21-May-07, at 6:43 AM, Jerome Louvel wrote:

> Hi all,
>
> I've added support for client authentication in the SVN trunk 
> (upcoming 1.1). Only Simple connector has support to retrieve the 
> client certificates,

These two features are working well for me in 1.1b1.

More specifically, as expected, client authentication succeeds against
my CA and fails against foreign CA, or out of date certificate. I
haven't tested a revocation list.

getContext().getParameters().add("needClientAuthentication",
"true")

And I can retrieve the certificate details that I need as follows:

List certs =

(List)req.getAttributes().get("org.restlet.https.clientCertificates");
X509Certificate firstCert = certs.get(0);
... firstCert.getSubjectX500Principal().getName() ...

Thankyou very much for the work.
--Toby

> but other connectors should ask/require a certificate too if you set 
> the connector attributes correctly (see Javadocs for each connector).
>
> See details in the RFE:
> http://restlet.tigris.org/issues/show_bug.cgi?id=281
>
> I'm looking forward to getting your feed-back and test results. I will

> post a first 1.1 snapshot soon.
>
> Best regards,
> Jerome

RE: Re: Can I call my Restlet classes without a Web container?

[Chuck Hinson]

As Adam points out, it is a good idea to keep the bulk of your business
logic outside your restlet classes for testing purposes.  However, we've
found it very easy to directly invoke various restlet components for
testing purposes - mostly to check return codes and ensure content
negotiation stuff is being handled properly.  For example:

public void testDelete()
{
Context context = new Context();
context.getAttributes().put(...stuff...);
Request request = new
Request(Method.DELETE,"http://host/entries/"+entryId);
Response response = new Response(request);
ContextEntryResource resource = new
ContextEntryResource(context,request,response);
resource.delete();

assertEquals(response.getStatus(),Status.SUCCESS_NO_CONTENT);

  assertTrue(...other tests to ensure delete worked
properly...);
}

where ContextEntryResource is defined as:

public class ContextEntryResource extends Resource 
{
public ContextEntryResource(Context context, Request request,
Response response) {
super(context, request, response);

}
public boolean allowDelete(){
return true;
}
public void delete(){
. . .
}
. . .
}


--Chuck 

-Original Message-
From: Adam Taft [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 30, 2007 9:13 PM
To: discuss@restlet.tigris.org
Subject: Re: Can I call my Restlet classes without a Web container?

Bryan,

I know this isn't directly answering your question, but how we do
testing is by integrating with the Spring Framework.  With Spring, you
get various DAO and service layer support classes which are easily
testable.

Essentially, if you make your Restlets as "dumb" as possible by
transferring all the business logic code into a Spring managed bean,
then you can isolate and test these beans and not need to generate mock
Request/Response objects.

 From there, if you want to test the whole stack, you can do so by using
the Jakarta Commons Http Client or other types of web testing
frameworks.

All of these tests can run as JUnit tests, so you can leverage its
testing support.

I'm sure others will have more ideas about how to mock a Request or
Response object like you're looking to do.  So, the above is just one
of, I'm sure, dozens of ideas.

Hope this helps,

Adam


Bryan Loofbourrow wrote:
> I'm interested in adding a unit test for certain aspects of the 
> behavior of my REST service, one that can execute outside the confines

> of a Web server. It would be sufficient if there were merely a way for

> me to call the Restlet classes directly, then examine the response.
> 
> What's not obvious to me is how one would go about this. I'd need to 
> create Request and Response objects, obviously, but what's the best 
> way to do that, and what would I need to put in there? Is there a 
> Factory somewhere I should be using for this? Or is this the wrong 
> approach; is there some other way to accomplish this (short of 
> decoupling the code underlying the Restlet and testing that by
itself)?
> 
> Thanks,
> 
> -- Bryan

RE: Re: 2-way SSL authentication

[Chuck Hinson]

I'm going to need this in a day or two.  Can I get this in a binary, or
do I have to build from trunk?

--Chuck 

-Original Message-
From: Toby Thain [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 22, 2007 6:19 PM
To: discuss@restlet.tigris.org
Subject: Re: 2-way SSL authentication


On 21-May-07, at 6:43 AM, Jerome Louvel wrote:

> Hi all,
>
> I've added support for client authentication in the SVN trunk 
> (upcoming 1.1). Only Simple connector has support to retrieve the 
> client certificates, but other connectors should ask/require a 
> certificate too if you set the connector attributes correctly (see 
> Javadocs for each connector).
>
> See details in the RFE:
> http://restlet.tigris.org/issues/show_bug.cgi?id=281
>
> I'm looking forward to getting your feed-back and test results. I will

> post a first 1.1 snapshot soon.


Great, I can test this right away.

--Toby

>
> Best regards,
> Jerome

RE: Re: Maven Repository available

[Chuck Hinson]

I'll (strongly) second these sentiments.
 
--Chuck



From: Mark Reynolds [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 03, 2007 2:44 PM
To: discuss@restlet.tigris.org
Subject: Re: Maven Repository available


Thanks for doing this. It is a huge step in the right direction. I only
wish you hadn't decided to create your own release repository, and
instead would use the maven central repository. Perhaps you may consider
this for the next level of making things easy for your users. 

In my project, I have many dependencies. If each project set up their
own repository, I would have a huge repository section in my pom and
each repository would have to be checked for each artifact. Moreover,
there are many mirrors of the central repository so there isn't a single
point of failure for retrieving an artifact, whereas it is unlikely that
each individual project will be able to provide mirroring, and even if
they did, I would have to manage referencing all those mirrors. 

I know many projects have set up an automatic syncing with with the
central repository, so that they don't have to do any extra work (after
the syncing is set up) to publish releases to the central repo.

Again, I am most appreciative of what you have done. I just hope it is
not a part of a trend for everyone to set up their own release
repositories (and yes, restlet is not the only one but thankfully they
are still few in number). 

-- Mark R


On 5/3/07, Thierry Boileau <[EMAIL PROTECTED]> wrote: 

**Hello all,

One the most frequent enhancement request that we received was
to
improve our support for Apache Maven 
technology. We
initially responded by shipping some Maven POM files within our
Restlet 
distribution. This enabled users to upload those JAR files to a
local
Maven repository, using a script like the one available in our
Wiki.

But, this was clearly not easy enough and forced users to
download the 
full distribution for each new version released, instead of just
updating a couple of JARs. We also had issues with some
third-party
dependencies which aren't available in public Maven
repositories, like
the db4o, AsyncWeb or Simple.

We listened to your feed-back and decided to launch dedicated
Maven
repository. It is freely accessible from
http://maven.restlet.org and
contains all Restlet JARs and third party dependencies that
aren't 
available in the main public Maven repository. It will be
automatically
refreshed on the 1st and on the 15th of each month.

Best regards,
Thierry Boileau

RE: RE: RE: Proxy server

[Chuck Hinson]

Yes - I think I agree.  As I said, we're building a proxy-like application - it 
will dom some processing on messages beyond simply proxying.  Since Restlets 
have become my default tool when playing with HTTP stuff, I just kind of 
assumed that it would be useful.  The more I think about it, though, I tend to 
agree - we wouldn't really be making much use of the framework since we'd be 
operating at a lower level.  I'll look into working at the connector level, but 
the requirement for SSL proxying might require us to just deal directly with 
sockets.

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 27, 2007 9:35 AM
To: discuss@restlet.tigris.org
Subject: RE: RE: Proxy server


Hi Chuck,

The more I think about it, the less appropriate it seems to be to use the 
Restlet API for that, at least in the current 1.0 API. I would be interested to 
understand what would the API bring for a proxy? Are you looking at leveraging 
the routing and filtering mechanisms?

However, it seems possible to implement a proxy by working at the lower HTTP 
connector API level:
http://www.restlet.org/documentation/1.0/nre/com/noelios/restlet/http/packag
e-summary.html

I've updated the RFE to mention that:
http://restlet.tigris.org/issues/show_bug.cgi?id=207

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : vendredi 
> 27 avril 2007 15:12 À : discuss@restlet.tigris.org Objet : RE: RE: 
> Proxy server
> 
> We're attempting to build a proxy-like application along the lines of 
> what it looks like the RFE might be addressing (a true HTTP proxy, not 
> a reverse proxy).
> 
> I was mainly wondering if someone else had tried and had discovered 
> some fundamental drawback that would make it impossible.  It turns out 
> that, at least for non-SSL traffic, Restlets can be used as a crude 
> proxy mechanism - I built one in less than 100 lines of code, but it 
> doesnt process HTTP headers so it wouldn't be useful in a production 
> environment.
>  There remains the question, however,  of whether it's even 
> appropriate to use Restlets as an HTTP proxy (especially because I 
> don't think it would work well with TLS-tunneling via CONNECT).
> 
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 27, 2007 1:41 AM
> To: discuss@restlet.tigris.org
> Subject: RE: Proxy server
> 
> 
> Hi Chuck,
> 
> There is a reverse proxy available via the Redirector class:
> http://www.restlet.org/documentation/1.0/api/org/restlet/Redir
> ector.html
> 
> This is not however a true HTTP proxy if this is what you are looking 
> for.
> There is a RFE for this:
> http://restlet.tigris.org/issues/show_bug.cgi?id=207
> 
> I'm not sure I understand what do you mean by "I'm looking for 
> anything that would rule out using Restlets". Are you worried about 
> the lack of some specific features? Could you give more details?
> 
> Best regards,
> Jerome
> 
> > -Message d'origine-
> > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> jeudi 26
> > avril 2007 17:42 À : discuss@restlet.tigris.org Objet : Proxy server
> > 
> > Does anyone have any experience using Restlets as the basis
> for a HTTP
> > proxy?  I'm looking for anything that would rule out using Restlets.
> > 
> > 
> > --Chuck
> > 
> > 
> > Chuck Hinson
> > Gestalt LLC
> > phone: 610.994.2833
> > IM: chucking24 (Yahoo)
> >  

RE: RE: RE: 2-way SSL authentication

[Chuck Hinson]

I intend to do the experiment with the Simple adapter - as long as our project 
direction permits.

I did not look at the other adapters, but any adapter that works similarly to 
the Simple one and uses the java SSLSocket should be configurable in the same 
way that Simple  adapter.

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 27, 2007 9:53 AM
To: discuss@restlet.tigris.org
Subject: RE: RE: 2-way SSL authentication


OK, that's clear now :) 

If you could experiment your proposition with the Simple HTTPS connector, that 
would be great. We could then apply it to other connectors.

For the ServerServlet adapter, I think this would be the responsibility of the 
Servlet container to provide this feature. I don't think that the Servlet API 
itself allows to configure this aspect.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : vendredi 
> 27 avril 2007 15:21 À : discuss@restlet.tigris.org Objet : RE: RE: 
> 2-way SSL authentication
> 
> No, I mean SSL with client authentication - i.e., rather than just the 
> server authenticating itself to the client (by sending its server 
> cert), both the client and the server authenticate with each other.
> 
> I did look at the code for the Simple HttpsServerHelper and it appears 
> that it would be relatively simply to accomplish this.  The main issue 
> would be change the call to
> SLLContext.init() to include a TrustManagers along with the 
> KeyManagers - along the lines of:
> 
> sslContext.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory,getTrustManagers(), null);
> 
> This would require some additional properties in order to be able to 
> specify the location of the trust store and password along with 
> specifying whether or not client authentication is not asked for at 
> all; asked for but not required; or required.
> 
> I suspect that a similar solution exists for the Servlet server helper 
> if not all of the other helpers.
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 27, 2007 1:48 AM
> To: discuss@restlet.tigris.org
> Subject: RE: 2-way SSL authentication
> 
> 
> Chuck,
> 
> Sorry I'm not sure I understand. Do you mean reusing the exact same 
> SSL socket?
> 
> Otherwise a single Restlet application can use an HTTPS server and 
> client connector at the same time. But it seems that you are looking 
> for more, right?
> 
> Best regards,
> Jerome
> 
> > -Message d'origine-
> > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> jeudi 26
> > avril 2007 17:45 À : discuss@restlet.tigris.org Objet : 2-way SSL 
> > authentication
> > 
> > Does anyone know if it is possible to use Restlets in
> scenarios where
> > https with 2-way/client authentication is required (server-side and 
> > client-side)?
> > 
> > -Chuck
> > 
> > 
> > Chuck Hinson
> > Gestalt LLC
> > phone: 610.994.2833
> > IM: chucking24 (Yahoo)
> >  

RE: RE: 2-way SSL authentication

[Chuck Hinson]

No, I mean SSL with client authentication - i.e., rather than just the server 
authenticating itself to the client (by sending its server cert), both the 
client and the server authenticate with each other.

I did look at the code for the Simple HttpsServerHelper and it appears that it 
would be relatively simply to accomplish this.  The main issue would be change 
the call to SLLContext.init() to include a TrustManagers along with the 
KeyManagers - along the lines of:

sslContext.init(keyManagerFactory.getKeyManagers(), 
trustManagerFactory,getTrustManagers(), null);

This would require some additional properties in order to be able to specify 
the location of the trust store and password along with specifying whether or 
not client authentication is not asked for at all; asked for but not required; 
or required.

I suspect that a similar solution exists for the Servlet server helper if not 
all of the other helpers.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 27, 2007 1:48 AM
To: discuss@restlet.tigris.org
Subject: RE: 2-way SSL authentication


Chuck,

Sorry I'm not sure I understand. Do you mean reusing the exact same SSL socket? 

Otherwise a single Restlet application can use an HTTPS server and client 
connector at the same time. But it seems that you are looking for more, right?

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : jeudi 26 
> avril 2007 17:45 À : discuss@restlet.tigris.org Objet : 2-way SSL 
> authentication
> 
> Does anyone know if it is possible to use Restlets in scenarios where 
> https with 2-way/client authentication is required (server-side and 
> client-side)?
> 
> -Chuck
> 
> ----
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

RE: RE: Proxy server

[Chuck Hinson]

We're attempting to build a proxy-like application along the lines of what it 
looks like the RFE might be addressing (a true HTTP proxy, not a reverse proxy).

I was mainly wondering if someone else had tried and had discovered some 
fundamental drawback that would make it impossible.  It turns out that, at 
least for non-SSL traffic, Restlets can be used as a crude proxy mechanism - I 
built one in less than 100 lines of code, but it doesnt process HTTP headers so 
it wouldn't be useful in a production environment.  There remains the question, 
however,  of whether it's even appropriate to use Restlets as an HTTP proxy 
(especially because I don't think it would work well with TLS-tunneling via 
CONNECT).


--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 27, 2007 1:41 AM
To: discuss@restlet.tigris.org
Subject: RE: Proxy server


Hi Chuck,

There is a reverse proxy available via the Redirector class:
http://www.restlet.org/documentation/1.0/api/org/restlet/Redirector.html

This is not however a true HTTP proxy if this is what you are looking for.
There is a RFE for this:
http://restlet.tigris.org/issues/show_bug.cgi?id=207

I'm not sure I understand what do you mean by "I'm looking for anything that 
would rule out using Restlets". Are you worried about the lack of some specific 
features? Could you give more details? 

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : jeudi 26 
> avril 2007 17:42 À : discuss@restlet.tigris.org Objet : Proxy server
> 
> Does anyone have any experience using Restlets as the basis for a HTTP 
> proxy?  I'm looking for anything that would rule out using Restlets.
> 
> 
> --Chuck
> 
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

2-way SSL authentication

[Chuck Hinson]

Does anyone know if it is possible to use Restlets in scenarios where
https with 2-way/client authentication is required (server-side and
client-side)?

-Chuck


Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

Proxy server

[Chuck Hinson]

Does anyone have any experience using Restlets as the basis for a HTTP
proxy?  I'm looking for anything that would rule out using Restlets.


--Chuck


Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: Directory restlet

[Chuck Hinson]

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 org.restlet.Router.handle (Router.java:441)
>   at org.restlet.Filter.doHandl

Directory restlet

[Chuck Hinson]

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 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.Router.handle(Router.java:441)
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.component.ComponentHelper.handle(ComponentHelper.
java:115)
at org.restlet.Component.handle(Component.java:228)
at org.restlet.Server.handle(Server.java:281)
at com.noelios.restlet.ServerHelper.handle(ServerHelper.java:99)
at
com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.jav
a:94)
at
com.noelios.restlet.ext.simple.SimpleProtocolHandler.handle(SimplePro
tocolHandler.java:66)
at simple.http.Dispatcher.run(Unknown Source)
at simple.util.process.Daemon.execute(Unknown Source)
at simple.util.process.Daemon.run(Unknown Source)
Apr 20, 2007 4:20:00 PM com.noelios.restlet.LogFilter afterHandle
INFO: 2007-04-2016:20:00127.0.0.1   -   -
8003
GET /files/ -   500 366 -   80
http://localhost:8003
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3)
Gecko/20070309 Firef
ox/2.0.0.3  -



Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: Re: Classpath or config?

[Chuck Hinson]

Given the number of times I've seen this question asked (both on this
list and here at my company), it seems to me that the configuring of
connectors should be directly addressed in the tutorial (since this is
where most people seem to start when trying to get something running).

--Chuck

-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 10, 2007 10:59 AM
To: discuss@restlet.tigris.org
Subject: Re: Classpath or config?

Hello Donald,

this is a good remark. Your classpath need to be updated with some other
jars.
The Restlet framework is composed of 3 parts : restlet API, NRE
implementation of this API and some extensions.
Some of them are called "connectors" because they are responsible of
linking two components on the network.
You can find server connectors (for example, an HTTP connectors that get
requests from clients delegate the call to a restlet, component, etc and
give the response back) and client connectors that initiate requests to
a server.
Because you make some HTTP requests, you need to add one client HTTP
connector.
Please go to this page in order to make your choice between the two
provided by the current delivery and add the right jars : 
http://www.restlet.org/documentation/1.0/connectors

Best regards,
Thierry Boileau

> Hi,
>
> I am just setting up Restlet at home. (Restlet-1.0rc6.zip) I am just 
> playing around at the moment and I have converted SimpleClient.java
into a Junit test.
> I have com.noelios.restlet.jar and org.restlet.jar in my classpath but
get this warning.
> (Using jre1.5.0_10).
>
> 10/04/2007 23:47:58 com.noelios.restlet.Engine createHelper
> WARNING: No available client connector supports the required
protocols: HTTP . Please add the JAR of a matching connector to your
classpath.
>
> Can someone tell me is this classpath or a config issue?
>
> Regards
> Donald.
>
> public class SimpleClientTest extends TestCase {
>
> public void testSimpleForm() throws Exception {
> // Prepare the REST call.
> Request request = new Request();
>
> // Identify ourselves.
> request.setReferrerRef("http://www.foo.com/";);
>
> // Target resource.
> request.setResourceRef("http://127.0.0.1:9876/test";);
>
> // Action: Update
> request.setMethod(Method.PUT);
>
> Form form = new Form();
> form.add("name", "John D. Mitchell");
> form.add("email", "[EMAIL PROTECTED]");
> form.add("email2", "[EMAIL PROTECTED]");
> request.setEntity(form.getWebRepresentation());
>
> System.out.println("client: one!");
>
> // Prepare HTTP client connector.
> Client client = new Client(Protocol.HTTP);
> System.out.println("client: two!");
>
> client.getLogger().log(Level.INFO, "client: two!");
> // Make the call.
> Response response = client.handle(request);
> client.getLogger().log(Level.INFO, "client: three!");
>
> if (response.getStatus().isSuccess()) {
> client.getLogger().log(Level.INFO, "client: four!");
>// Output the response entity on the JVM console
> response.getEntity().write(System.out);
> System.out.println("client: success!");
> } else {
> System.out.println(response.getStatus().getDescription());
> fail("client: failure!");
> }
> }
> }
>
>
>   

RE: Re: RC4 dist. refers to nonexistent Jetty version

[Chuck Hinson]

It must be exact in the sense that you can't just say 6.1 and expect to know 
that mean 6.1.x.

If you mean 6.1.x, I believe you have to specify a range - something like

 [6.1.0,)

(actually, this really say version greater than 6.1.0, so 7.0.x would be 
included)

--Chuck

-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 23, 2007 11:30 AM
To: discuss@restlet.tigris.org
Subject: Re: RC4 dist. refers to nonexistent Jetty version

Hello Mikkel,

do you confirm that the POM file must reference an exact version of Jetty?
Actually, we were not sure about the way Maven manage versions. We hoped a kind 
of behaviour which allows to provide only a minor version (e.g. 
6.1)...
If it's not the case, the pom file will be updated with the latest release of 
Jetty.

Best regards,
Thierry Boileau


> It makes sense to use the minor version number internally but I still 
> think that the pom file should be updated to refer to an existing 
> Jetty version.
> If not it will be impossible to build projects using Maven!
>
> Any plans to fix this?
>
> - Mikkel
>
> On 2/23/07, Thierry Boileau <[EMAIL PROTECTED]> wrote:
>> Hello Mikkel,
>>
>> the provided release of Jetty is 6.1.1 but for internal reason it's 
>> referenced with it's minor version (6.1).
>> The complete version number has been provided in the changes file (in 
>> release RC3).
>>
>> Best regards,
>> Thierry Boileau
>>
>> Mikkel Jensen a écrit :
>> > Hi there,
>> >
>> > It seems that the latest release refers to Jetty version 6.1.
>> > This version does not seem to exist on ibiblio or other repositories.
>> > Instead it should probably be 6.1.0 or 6.1.1 if any of these are 
>> > considered stable.
>> >
>> > - Mikkel
>> >
>>
>

RE: RE: Find host info from Application

[Chuck Hinson]

Thanks for listening, Jerome, and thanks for the suggested workarounds.  I've 
got a week or so of adminstrative stuff coming up, so I wont be trying any of 
this for a little bit.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 8:27 AM
To: discuss@restlet.tigris.org
Subject: RE: Find host info from Application


Hi Chuck,

I agree with the AWWW sections that you mentioned and still see value in 
localizing the URIs even if they technically correspond to the same resource. 
The exposed representations and content negotiation could be adapted based on 
the URI used to get them. 

More importantly, the same application instance could be attached to multiple 
virtual hosts, and still consider that requests from each host point to 
completely separate resources. For example, let's consider that Yahoo! has a 
forum application, it could attach it to http://groups.yahoo.com and 
http://groups.yahoo.ca. This application could know that 
http://groups.yahoo.com/group/rest-discuss/ exists and that 
http://groups.yahoo.ca/group/rest-discuss/ doesn't. Nothing prevent them for 
distinguishing different URIs and from taking the URI authority into account 
when processing requests.

Nonetheless, I understand the problem that you are currently facing and the 
need to host information at initialization time. Thanks for detailing your use 
case.

If you were using the standalone Restlet mode, you could easily workaround it 
by specifying application parameters. When we support WAR style packaging in 
1.1, we won't have a "web.xml", just a property in the manifest pointing to the 
Application class. However, we will have an XML configuration file for the 
parent Component managing the deployed applications. For each application, 
setting of context parameters will be allowed in the XML config. Therefore, 
your application could be redeployed (as a WAR) several times without having to 
reconfigure it.

As I don't think we can do something similar with Servlet WARs, if modifying 
the "web.xml" file before packaging your WAR file isn't easy for you (for 
example if you have to deploy to different environments/containers at the same 
time), then we need to explore another path :-) 

Note that the Servlet API appears to have had similar issues with their 
"contextPath" property. That was addressed in Servlet API 2.5. See:
http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.
html#getContextPath()

Suggested workaround: 
-
You could provide a custom ServerServlet adapter, overriding the "init()"
method to add a parameter with the full Servlet host information to your 
application. Currently, the application is only created on the first request, 
which is really annoying in your case. So, I've just fixed this limitation and 
released a new snapshot (see other email). 

Now, Restlet applications are started upon Servlet initialization and stopped 
upon Servlet destruction. There is also a new "getApplication()"
method that you can use when overriding the default init() behavior to set the 
parameter based on the Servlet's context path/real path. Just remember to 
invoke super.init() when your done.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 
> février 2007 23:36 À : discuss@restlet.tigris.org Objet : RE: Find 
> host info from Application
> 
> > REST/HTTP perfectly allows multiple URIs to point to the same
> resource.
> 
> My car allows me to drive at high speeds - it doesnt mean that I 
> should.
> 
> There have been numerous debates about the advisability of having 
> multiple URIs for the same resource.  See this thread, for example, 
> from the REST-discuss archives:
> http://tech.groups.yahoo.com/group/rest-discuss/message/7321
> 
> And I'll point back to "Architecture of the World Wide Web, Volume 
> One"
> (AWWW) published by the W3C TAG (of which I belive Roy Fielding was a 
> member when the document was published) - "Assign distinct URIs to 
> distinct resources."  See section 2.3.1 URI Aliases for a discussion 
> of why it is bad practice to have multiple URIs for the same resource.
> 
> Having said that, your 'customers' obviously like to do that sort of 
> thing, so you're going to support it.
> 
> 
> > Another strategy would be to initialize your application upon first
> request.
> 
> Except that I may have a need for the information before I ever 
> receive a request.  My application acts as both a client and a server.  
> As a client, it needs to send its canonical URI to other services on 
> the network, and it needs to do that regardless of whether or when it 
> receives a request.
&

RE: Find host info from Application

[Chuck Hinson]

> REST/HTTP perfectly allows multiple URIs to point to the same
resource.

My car allows me to drive at high speeds - it doesnt mean that I should.

There have been numerous debates about the advisability of having
multiple URIs for the same resource.  See this thread, for example,
from the REST-discuss archives:
http://tech.groups.yahoo.com/group/rest-discuss/message/7321

And I'll point back to "Architecture of the World Wide Web, Volume One"
(AWWW) published by the W3C TAG (of which I belive Roy Fielding was a
member when the document was published) - "Assign distinct URIs to
distinct resources."  See section 2.3.1 URI Aliases for a discussion of
why it is bad practice to have multiple URIs for the same resource.

Having said that, your 'customers' obviously like to do that sort of
thing, so you're going to support it.  


> Another strategy would be to initialize your application upon first
request.

Except that I may have a need for the information before I ever receive
a request.  My application acts as both a client and a server.  As a
client, it needs to send its canonical URI to other services on the
network, and it needs to do that regardless of whether or when it
receives a request.

--Chuck


-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 20, 2007 4:43 PM
To: discuss@restlet.tigris.org
Subject: RE: RE: RE: RE: Find host info from Application


Hi Chuck,

> The more I think about this, the more it seems that something is 
> fundamentally wrong here.
:-/

> According to AWWW[1], "Assign distinct URIs to distinct resources."
> 
> So if an application is the thing that manages a set of resources 
> (i.e,. a URI space), having it attached to multiple virtual hosts 
> guarantees that your resources will not have distinct URIs.

REST/HTTP perfectly allows multiple URIs to point to the same resource.
For example, you could have a virtual host accepting translated domain
names like www.mysite.org and www.monsite.org. Other useful cases are
when you want to support "localhost" access by IP address, etc. This is
useful to flexible in these cases for development and pre-production.

> I'm also wondering if the baby's being thrown out with the bathwater 
> here.  Just because some people want to attach an application to 
> multiple virtual hosts doesn't rule out the case the some people will 
> only ever attach an application to a single virtual host.

Actually, the virtual hosting we support is even more flexible as we
take into account the following attributes when determining if a request
matches a given virtual host:
 - hostRef (hostDomain + hostPort + hostScheme)
 - resourceRef (resourceDomain + resourcePort + resourceScheme)
 - serverInfo (serverAddress + serverPort)

As a result, we are even able to properly route requests for resources
with URIs like "urn:isbn:..." submitted via HTTP. This is more flexible
than Apache HTTP Server's virtual hosting support, and hopefully it
doesn't compromise RESTful design.

> Perhaps its worth revisiting the way virtual hosting is being handled.

> Or maybe I'm misunderstanding who is repsonsible for managing an 
> application's URI space.

The URI space is managed by both the virtual hosts and then by the
applications. If the resource URIs don't match the host URI (like for
the URN example given above), then the resource URI space is entirely
managed by the application.
 
> As for using the application's context in web.xml - that's just plain 
> ugly; everytime I deploy, I have to unwrap my war so I can modify 
> web.xml to change hostname and port info.
> (Deployment-specific config info just shouldn't be in web.xml)

Hmm, that's true.

> Oh well, for now web.xml will have to do for a temporary solution.

Another strategy would be to initialize your application upon first
request.
You can override the "init(Request, Response)" method on your
Application class for this purpose. Just remember to check whether the
application is already started and to call super.init() when you are
done with your initialization.

Hope this helps,
Jerome

RE: RE: RE: RE: Find host info from Application

[Chuck Hinson]

The more I think about this, the more it seems that something is fundamentally 
wrong here.

According to AWWW[1], "Assign distinct URIs to distinct resources."

So if an application is the thing that manages a set of resources (i.e,. a URI 
space), having it attached to multiple virtual hosts guarantees that your 
resources will not have distinct URIs.

I'm also wondering if the baby's being thrown out with the bathwater here.  
Just because some people want to attach an application to multiple virtual 
hosts doesn't rule out the case the some people will only ever attach an 
application to a single virtual host.  

Perhaps its worth revisiting the way virtual hosting is being handled.  Or 
maybe I'm misunderstanding who is repsonsible for managing an application's URI 
space.

As for using the application's context in web.xml - that's just plain ugly; 
everytime I deploy, I have to unwrap my war so I can modify web.xml to change 
hostname and port info. (Deployment-specific config info just shouldn't be in 
web.xml)

Oh well, for now web.xml will have to do for a temporary solution.


--Chuck

[1]http://www.w3.org/TR/webarch/#id-resources


-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 20, 2007 2:01 PM
To: discuss@restlet.tigris.org
Subject: RE: RE: RE: Find host info from Application


That's interesting :) 

Another aspect to consider is the fact that a virtual host can 
correspond/accept multiple domain names, multiple ports, etc. In addition the 
sample application instance could perfectly well be attached to several virtual 
hosts at the same time. 

For those reasons, I don't want to change the API. The best in your case is to 
manually pass this info to your application. You can also rely on application's 
context parameters to pass the host info as this will be more portable when 
support WAR-style packaging in 1.1.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 
> février 2007 19:01 À : discuss@restlet.tigris.org Objet : RE: RE: RE: 
> Find host info from Application
> 
> Except that when I need the host info, I don't have a Request object 
> handy.  In fact, when I need the host info, my application may not 
> have even received any requests yet.
>  
> The application needs to know host info for application 
> initialization.  There are data structures that need to be set up 
> before any requests are ever handled.
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 20, 2007 12:43 PM
> To: discuss@restlet.tigris.org
> Subject: RE: RE: Find host info from Application
> 
> 
> Ok I see. For this you can use the Request.getRootRef() method that 
> was recently added.
> 
> Best regards,
> Jerome
> 
> > -Message d'origine-
> > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> mardi 20
> > février 2007 18:29 À : discuss@restlet.tigris.org Objet : 
> RE: RE: Find
> > host info from Application
> > 
> > I need, for example, to find out what the canonical
> hostname/base url
> > of my deployment environment is.
> > 
> > For example, when creating atom:source elements, I have to
> be able to
> > construct a URL for a feed (that's part of my application), and I 
> > can't do that if I don't know what my hostname and port number are.
> > 
> > --Chuck
> > 
> > -Original Message-
> > From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 20, 2007 12:12 PM
> > To: discuss@restlet.tigris.org
> > Subject: RE: Find host info from Application
> > 
> > 
> > Hi Chuck,
> > 
> > As an Application is expected to be portable from one deployment 
> > environment to another, we intentionally don't have a
> reference to the
> > parent VirtualHost.
> > 
> > I would be interested to know what is the requirement
> leading you in
> > the path. For now, if you really need this reference, you should 
> > manually pass it to the constructor of your application.
> > 
> > Best regards,
> > Jerome
> > 
> > > -Message d'origine-
> > > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> > mardi 20
> > > février 2007 18:06 À : discuss@restlet.tigris.org Objet : 
> Find host
> > > info from Application
> > > 
> > > 
> > > From within an Application, how does one get hold of the
> > VirtualHost
> > > to which the application is attached?
> > > 
> > > --Chuck
> > > 
> > > 
> > > 
> > > Chuck Hinson
> > > Gestalt LLC
> > > phone: 610.994.2833
> > > IM: chucking24 (Yahoo)
> > >  

RE: RE: RE: RE: Find host info from Application

[Chuck Hinson]

I really don't understand what's so bad about allowing to application to figure 
out what its deployment environment looks like.  And so what if an application 
is attached to multiple hosts - I may want to know that and act differently.

Part of the reason I'm having this problem is that my app is hosted in a 
servlet container and it's not clear to me how I would pass the host info to 
the constructor.

--Chuck

 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 20, 2007 2:01 PM
To: discuss@restlet.tigris.org
Subject: RE: RE: RE: Find host info from Application


That's interesting :) 

Another aspect to consider is the fact that a virtual host can 
correspond/accept multiple domain names, multiple ports, etc. In addition the 
sample application instance could perfectly well be attached to several virtual 
hosts at the same time. 

For those reasons, I don't want to change the API. The best in your case is to 
manually pass this info to your application. You can also rely on application's 
context parameters to pass the host info as this will be more portable when 
support WAR-style packaging in 1.1.

Best regards,
Jerome  

> -----Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 
> février 2007 19:01 À : discuss@restlet.tigris.org Objet : RE: RE: RE: 
> Find host info from Application
> 
> Except that when I need the host info, I don't have a Request object 
> handy.  In fact, when I need the host info, my application may not 
> have even received any requests yet.
>  
> The application needs to know host info for application 
> initialization.  There are data structures that need to be set up 
> before any requests are ever handled.
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 20, 2007 12:43 PM
> To: discuss@restlet.tigris.org
> Subject: RE: RE: Find host info from Application
> 
> 
> Ok I see. For this you can use the Request.getRootRef() method that 
> was recently added.
> 
> Best regards,
> Jerome
> 
> > -Message d'origine-
> > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> mardi 20
> > février 2007 18:29 À : discuss@restlet.tigris.org Objet : 
> RE: RE: Find
> > host info from Application
> > 
> > I need, for example, to find out what the canonical
> hostname/base url
> > of my deployment environment is.
> > 
> > For example, when creating atom:source elements, I have to
> be able to
> > construct a URL for a feed (that's part of my application), and I 
> > can't do that if I don't know what my hostname and port number are.
> > 
> > --Chuck
> > 
> > -Original Message-
> > From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 20, 2007 12:12 PM
> > To: discuss@restlet.tigris.org
> > Subject: RE: Find host info from Application
> > 
> > 
> > Hi Chuck,
> > 
> > As an Application is expected to be portable from one deployment 
> > environment to another, we intentionally don't have a
> reference to the
> > parent VirtualHost.
> > 
> > I would be interested to know what is the requirement
> leading you in
> > the path. For now, if you really need this reference, you should 
> > manually pass it to the constructor of your application.
> > 
> > Best regards,
> > Jerome
> > 
> > > -Message d'origine-
> > > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> > mardi 20
> > > février 2007 18:06 À : discuss@restlet.tigris.org Objet : 
> Find host
> > > info from Application
> > > 
> > > 
> > > From within an Application, how does one get hold of the
> > VirtualHost
> > > to which the application is attached?
> > > 
> > > --Chuck
> > > 
> > > 
> > > 
> > > Chuck Hinson
> > > Gestalt LLC
> > > phone: 610.994.2833
> > > IM: chucking24 (Yahoo)
> > >  

RE: RE: RE: Find host info from Application

[Chuck Hinson]

Except that when I need the host info, I don't have a Request object handy.  In 
fact, when I need the host info, my application may not have even received any 
requests yet.
 
The application needs to know host info for application initialization.  There 
are data structures that need to be set up before any requests are ever handled.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 20, 2007 12:43 PM
To: discuss@restlet.tigris.org
Subject: RE: RE: Find host info from Application


Ok I see. For this you can use the Request.getRootRef() method that was 
recently added.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 
> février 2007 18:29 À : discuss@restlet.tigris.org Objet : RE: RE: Find 
> host info from Application
> 
> I need, for example, to find out what the canonical hostname/base url 
> of my deployment environment is.
> 
> For example, when creating atom:source elements, I have to be able to 
> construct a URL for a feed (that's part of my application), and I 
> can't do that if I don't know what my hostname and port number are.
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 20, 2007 12:12 PM
> To: discuss@restlet.tigris.org
> Subject: RE: Find host info from Application
> 
> 
> Hi Chuck,
> 
> As an Application is expected to be portable from one deployment 
> environment to another, we intentionally don't have a reference to the 
> parent VirtualHost.
> 
> I would be interested to know what is the requirement leading you in 
> the path. For now, if you really need this reference, you should 
> manually pass it to the constructor of your application.
> 
> Best regards,
> Jerome
> 
> > -Message d'origine-
> > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : 
> mardi 20
> > février 2007 18:06 À : discuss@restlet.tigris.org Objet : Find host 
> > info from Application
> > 
> > 
> > From within an Application, how does one get hold of the
> VirtualHost
> > to which the application is attached?
> > 
> > --Chuck
> > 
> > 
> > 
> > Chuck Hinson
> > Gestalt LLC
> > phone: 610.994.2833
> > IM: chucking24 (Yahoo)
> >  

RE: RE: Find host info from Application

[Chuck Hinson]

I need, for example, to find out what the canonical hostname/base url of my 
deployment environment is.

For example, when creating atom:source elements, I have to be able to construct 
a URL for a feed (that's part of my application), and I can't do that if I 
don't know what my hostname and port number are.

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 20, 2007 12:12 PM
To: discuss@restlet.tigris.org
Subject: RE: Find host info from Application


Hi Chuck,

As an Application is expected to be portable from one deployment environment to 
another, we intentionally don't have a reference to the parent VirtualHost. 

I would be interested to know what is the requirement leading you in the path. 
For now, if you really need this reference, you should manually pass it to the 
constructor of your application.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 
> février 2007 18:06 À : discuss@restlet.tigris.org Objet : Find host 
> info from Application
> 
> 
> From within an Application, how does one get hold of the VirtualHost 
> to which the application is attached?
> 
> --Chuck
> 
> 
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

Find host info from Application

[Chuck Hinson]

>From within an Application, how does one get hold of the VirtualHost to
which the application is attached?

--Chuck


----
Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: Unit testing and the Client class

[Chuck Hinson]

Hmmm.  I was hoping for something a little simpler and less sophisticated, but 
let poke around and see if maybe it turns out to be easier than it looks.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 19, 2007 2:57 AM
To: discuss@restlet.tigris.org
Subject: RE: Unit testing and the Client class


Hi Chuck,

A better way to do this is to customize the NRE engine (create a MyEngine 
subclass for example) and override the createHelper(Client) method. See 
Javadocs at:
http://www.restlet.org/docs/nre/com/noelios/restlet/Engine.html#createHelper
(org.restlet.Client)

The Helper instance will intercept all the "handle()" method calls and will 
give you an opportunity to simulate an actual connector.

Once this is done, you will need to manually register the customized Engine 
with the API before actually using the API:
http://www.restlet.org/docs/api/org/restlet/util/Engine.html#setInstance(org
.restlet.util.Engine)

Just do something like: "MyEngine.register();"

Another more sophisticated way is to develop a pluggable Mock connector, 
similar to the real ones but that wouldn't actually do the work. This would 
require you to modify the classpath to remove the real connector and add the 
mock one. Let me know if you are interested by this other approach.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : dimanche 
> 18 février 2007 06:23 À : discuss@restlet.tigris.org Objet : Unit 
> testing and the Client class
> 
> 
> Before I go off and reinvent the wheel, I was wondering if anyone has 
> done anything along the lines of mocking up the Client class to make 
> unit testing easier.
> 
> One way to do this is to subclass Client and then override handle(), 
> but then I'll have to create some sort of Client factory for 
> constructing Client instances so that the mock gets used during 
> testing and the real one gets used in production.
> 
> Is there something underneath Client whereby I can intercept outgoing 
> requests and insert my own respone without having to do anything 
> special in the production code?
> 
> --Chuck
> 
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

Unit testing and the Client class

[Chuck Hinson]

Before I go off and reinvent the wheel, I was wondering if anyone has
done anything along the lines of mocking up the Client class to make
unit testing easier.

One way to do this is to subclass Client and then override handle(), but
then I'll have to create some sort of Client factory for constructing
Client instances so that the mock gets used during testing and the real
one gets used in production.

Is there something underneath Client whereby I can intercept outgoing
requests and insert my own respone without having to do anything special
in the production code?

--Chuck


Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: New JSR to define a high-level REST API for Java

[Chuck Hinson]

I'm not familiar with how expert groups work on a jsr.  Will you all be 
carrying out your work in public with everyone able to participate, or will you 
be going off behind closed doors (private mail list)?

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 14, 2007 11:22 AM
To: discuss@restlet.tigris.org
Subject: RE: New JSR to define a high-level REST API for Java


Hi Sean,

Thanks for this feedback, it helps to set the expectations correctly. 

A good point for this JSR is the intent to run it in an open source way. I'm 
planning to maintain an implementation prototype based on NRE along the way so 
that Restlet users can experiment with the annotations and report how the JSR 
draft works for them.

Best regards,
Jerome  

> -Message d'origine-
> De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis Envoyé 
> : mercredi 14 février 2007 17:10 À : discuss@restlet.tigris.org Objet 
> : Re: New JSR to define a high-level REST API for Java
> 
> I think this is a great opportunity and I'm really glad your are 
> participating Jerome. I have some fears based on what I know about Sun 
> and their approach to web services. I glanced at WADL and it made me 
> cringe. My fear is that this JSR could become a farce in REST terms. 
> Sorry to throw water on the fire...The JCP is a decent system that has 
> produced both wildly successful and extremely disappointing results. 
> I'm glad to know you are involved Jerome.
> 
> Why am I posting this? I hope to inject an additional perspective so 
> that we don't get blindsided by unrealistic expectations. I 
> continually hope I'm over pessimistic :-)
> 
> Sean

Response status codes

[Chuck Hinson]

I notice that Status defines the following codes:

CLIENT_ERROR_UNPROCESSABLE_ENTITY
CLIENT_ERROR_LOCKED
CLIENT_ERROR_FAILED_DEPENDENCY

These don't appear in 2616.  Can someone tell me what rfc these come
from so I can make sure I understand the requirements for using them.

It would be convenient if the javadocs included the actual text from
2616 for each of the error codes.  Yes, I can figure out the mapping and
go look them up myself, but some people aren't so inclined and they're
also the ones likely to misuse the status codes.  At a minimum, at least
indicate which ones come from 2616 and which ones come from somewhere
else (and indicate where that somewhere else is).

--Chuck

--------
Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: RE: Re: Response Headers

[Chuck Hinson]

OK.  So it appears that I am blind - the answers were right there and I just 
didn't see them.  Thanks.

As for abstraction and protocol independence part, I'll just have to say I 
respectfully disagree and leave it at that for now; I'd love to have the 
discussion, but I don't have the bandwidth for it right now.  And I should 
probably spend a little more time with the package before I form any strong 
opinions.

Oh, and thanks for all the hard work.  Restlets is one of the few packages that 
I've worked with that does what I need and 'just works'.  I'd really love to 
contribute, but right now I have other things demanding my attention.

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 12, 2007 12:18 PM
To: discuss@restlet.tigris.org
Subject: RE: RE: Re: Response Headers


Chuck,

The Javadocs do have the info about the HTTP headers, in addition you can check 
this FAQ entry:
http://www.restlet.org/faq#05

>From an HTTP protocol point of view, headers are indeed first class citizens. 
>Our HTTP connectors actually use an HTTP specific API with direct access to 
>headers. At the Restlet API level, our focus is not the HTTP protocol, but the 
>Web application developer needs. We don't want people to manually deal with 
>HTTP headers, their formatting or parsing. Instead we provide an 
>object-oriented API that provides a full mapping of information available in 
>HTTP without requiring developer to know how to parse/format, etc. Also, HTTP 
>as both communication aspects (pipeline, persistent connection, chunk 
>encoding, etc.) and "pure" application aspects like the request URI, method, 
>body and a subset of headers. By exposing only the "pure" HTTP application 
>aspect into the Restlet API, we shield the application developer from 
>manipulating/interfering with the communication aspects (we let the HTTP 
>connectors deal with that).

As for the protocol independence. To be more precise, the Restlet API is a 
direct and complete abstraction of the HTTP protocol ("pure" application
aspects) that can also be use to work with other "compatible" protocols like 
FILE, SMTP, FTP, JDBC, etc. If the protocol doesn't support a feature of HTTP 
(like redirection), then the connector will simply ignore it. Protocol 
independence doesn't mean that the application developer can or should ignore 
the actual protocol used. Just that he can use the same API to work with 
several protocols, nothing more.

I hope this clarifies. In any case, your feed-back is important so don't worry 
about complaining too loudly as long as the discussion stays constructive. 
There is always an opportunity to influence changes in version 1.1, 2.0, etc.

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 
> février 2007 15:27 À : discuss@restlet.tigris.org Objet : RE: RE: Re: 
> Response Headers
> 
> I don't know what the 1.0.0 snapshot javadocs have in them so ignore 
> this if it's already addressed, but
> message.getAttributes() make no mentions of being able to retrieve 
> http headers nor what one uses for the key name (I'm guessing the 
> header name, but it'd be nice if the docs say so).
> 
> It'd also be nice if the methods that wrap access to the headers were 
> more explicit about what headers they manipulate.
> 
> I'm also a little puzzled at the idea of considering headers as 
> lower-level artifacts; it seems to me that, http being an application 
> protocol, the headers are first-class citizens.
> When I'm attempting to implement a spec that's based on http and it 
> says that such-and-such a header must be set, then that's an important 
> thing for me to be able to do.
> 
> I'd also argue that it's a waste of time to try to make Restlets 
> protocol agnostic.  While REST certainly doesnt specify an application 
> protocol, at this point there is only one and http is it.  Google 
> around for leaky abstractions and protocol independence.  You'll find 
> that true protocol-independence is rarely acheived and almost always 
> costs more than its worth in additional complexity.  (For example, how 
> would you support an underlying protocol that doesn't have the concept 
> of redirection - all those redirect methods become pretty useless.)
> 
> But hey - you guys are the ones doing the work, so I'm not going to 
> complain too loudly.
> 
> --Chuck
> 
> -Original Message-
> From: Jerome Louvel [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 12, 2007 4:38 AM
> To: discuss@restlet.tigris.org
> Subject: RE: Re: Response Headers
> 
> 
> Hi Chuck,
> 
> Al

RE: RE: Re: Response Headers

[Chuck Hinson]

I don't know what the 1.0.0 snapshot javadocs have in them so ignore this if 
it's already addressed, but message.getAttributes() make no mentions of being 
able to retrieve http headers nor what one uses for the key name (I'm guessing 
the header name, but it'd be nice if the docs say so).  

It'd also be nice if the methods that wrap access to the headers were more 
explicit about what headers they manipulate.

I'm also a little puzzled at the idea of considering headers as lower-level 
artifacts; it seems to me that, http being an application protocol, the headers 
are first-class citizens.  When I'm attempting to implement a spec that's based 
on http and it says that such-and-such a header must be set, then that's an 
important thing for me to be able to do.

I'd also argue that it's a waste of time to try to make Restlets protocol 
agnostic.  While REST certainly doesnt specify an application protocol, at this 
point there is only one and http is it.  Google around for leaky abstractions 
and protocol independence.  You'll find that true protocol-independence is 
rarely acheived and almost always costs more than its worth in additional 
complexity.  (For example, how would you support an underlying protocol that 
doesn't have the concept of redirection - all those redirect methods become 
pretty useless.)

But hey - you guys are the ones doing the work, so I'm not going to complain 
too loudly.

--Chuck 

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 12, 2007 4:38 AM
To: discuss@restlet.tigris.org
Subject: RE: Re: Response Headers


Hi Chuck,

All standard HTTP headers have an equivalent class/property in the Restlet API. 
It was a deliberate choice to not expose those headers as first-class citizens, 
because we consider them as lower-level artifacts and because we want to 
support multiple protocols via the same API. 

However, you do have access to those raw headers via the request.attributes 
property. You can also add non standard HTTP headers if required. See the 
Javadocs for details:
http://www.restlet.org/docs/api/org/restlet/data/Message.html#getAttributes(
)

Best regards,
Jerome  

> -Message d'origine-
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 
> février 2007 06:36 À : discuss@restlet.tigris.org Objet : RE: Re: 
> Response Headers
> 
> Umm.  OK, thanks.  Not was I was expecting, but I'll take it.
> 
> However, the more generic question is then how do I set an arbitrary 
> HTTP header (entity or response) on a response?
> 
> --Chuck
> 
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
> Sent: Sunday, February 11, 2007 8:51 PM
> To: discuss@restlet.tigris.org
> Subject: Re: Response Headers
> 
> 
> 
> > Maybe I'm blind, but I don't see how to set a header in a response.
> > 
> > I need to set the Location header on a response to a POST,
> but I can't
> 
> > seem to find the right place to do that.  What am I missing?
> 
> 
>  response.setStatus(Status.SUCCESS_CREATED);
>  response.setRedirectRef(request.getRootRef() + );
> 
> -Vincent.

RE: Re: Response Headers

[Chuck Hinson]

Umm.  OK, thanks.  Not was I was expecting, but I'll take it.

However, the more generic question is then how do I set an arbitrary
HTTP header (entity or response) on a response? 

--Chuck

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Sent: Sunday, February 11, 2007 8:51 PM
To: discuss@restlet.tigris.org
Subject: Re: Response Headers



> Maybe I'm blind, but I don't see how to set a header in a response.
> 
> I need to set the Location header on a response to a POST, but I can't

> seem to find the right place to do that.  What am I missing?


 response.setStatus(Status.SUCCESS_CREATED);
 response.setRedirectRef(request.getRootRef() + );

-Vincent.

Response Headers

[Chuck Hinson]

Maybe I'm blind, but I don't see how to set a header in a response.

I need to set the Location header on a response to a POST, but I can't
seem to find the right place to do that.  What am I missing?

--Chuck

--------
Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)
 

RE: RE: Unit testing for Resource

[Chuck Hinson]

It appears that a meaningful request just requires a proper method and a URI, 
but I'm not sure what's required to create a meaningful context.  If my 
resource has no need of Context, is it OK to just use Context() to create a 
context object? 

--Chuck

-Original Message-
From: Jerome Louvel [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 01, 2007 12:10 PM
To: discuss@restlet.tigris.org
Subject: RE: Unit testing for Resource


I don't have examples but you need to call either the constructor with three 
parameters (Context, Request, Response) or use the default on and then call 
init(Context,Request,Response).

Your main concern should be to create meaningful Context, Request and Response 
instances. Then, invoking getRepresentation() manually should produce the 
expected results.

Best regards,
Jerome  

> -Message d'origine-----
> De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : jeudi 1 
> février 2007 16:59 À : discuss@restlet.tigris.org Objet : Unit testing 
> for Resource
> 
> 
> Anyone have example of unit tests for Resource subclasses?
> 
> I'm trying to figure out what all needs to be set up before I can do 
> things like invoke a Resource's getRepresentation method.
> 
> --Chuck
> 
> 
> Chuck Hinson
> Gestalt LLC
> phone: 610.994.2833
> IM: chucking24 (Yahoo)
>  

Unit testing for Resource

[Chuck Hinson]

Anyone have example of unit tests for Resource subclasses?

I'm trying to figure out what all needs to be set up before I can do
things like invoke a Resource's getRepresentation method.

--Chuck

--------
Chuck Hinson
Gestalt LLC
phone: 610.994.2833
IM: chucking24 (Yahoo)