Re: Testing strategies
I'm not trying to talk you out of the current Restlet design, but I would rather have it described as the result of some tough design decisions on trade-offs concerning evolvability and implementation inheritance, not as classes are better than interfaces in APIs. This is a better description of the subject indeed, and one that reflects the design process that took place to design the v1 of the Restlet API. For example, the initial versions had interfaces for all the artifacts. Feed-back, discussions, readings led me to reconsider this approach. I'm open to try a different path for the design of the v2 of the API. At this point, we will have more experience on our problem domain and we will be able to afford more radical changes. I had pushed a little bit against the move away from interfaces. I didn't like it but I understood that a design goal of Restlet was to converge onto an API through experience rather than try to get it right up front. Given that poorly charted territory was being navigated, I felt this was a helpful approach. I am glad to hear Jerome, that you are willing to reconsider the decision about interfaces. Stated differently, maybe when the convergence is over, it will be much safer to move to interfaces. The nearly immutable nature of interfaces won't be such an issue since the API questions will have mostly been answered. Sean
Re: [newbie] Start using 1.1 SNAPSHOT - Maven Repo ?
Jerome Louvel contact at noelios.com writes: Hi all, Maybe should also publish snapshots in the Maven repository? If we do so, we should follow the Maven naming conventions for version numbers. Note: we don't internally use Maven to build Restlet code base, but we know how to publish Maven artifacts. Best regards, Jerome We at Overstock.com would love it if you put 1.1 snapshots into the Maven repository. We have to do some really ugly gyrations to use 1.1m1 (current) in our Maven environment. BTW, I'm new to Maven 2 but I think it much preferable to ant, esp. for Restlet development. The jar dependency problem expressed recently is much less an issue with Maven 2 dependency management. Sean
Re: JSON represenation based on json-lib from http://json-lib.sourceforge.net/
Jerome Louvel contact at noelios.com writes: Hi Evgeny, I've updated the related RFE Improve support for JSON http://restlet.tigris.org/issues/show_bug.cgi?id=131 I'm a bit reluctant to upgrade due to the fact that it requires two additional dependencies (jakarta commons-beanutils 1.7.0 and ezmorph 1.0.3) compared to the current list of Restlet dependencies... People already complain about the current size of the distribution. I hope to have a more modular distribution in the future (core package and optional downloads), but probably not for 1.1. Beside that it seems like a very cool enhancement, with support for streaming. I've updated the RFE to plan for it in Restlet 1.2. Jerome, I'm trying to work with JsonRepresentation right now and I find it insufficient. The constructor JSONObject(Object) is key. W/o it, the value of this representation is extremely diminished. Dare I say useless for any but the most trivial cases. If there is any way this could be pushed into 1.1 (in the next milestone) it would make the difference between me being able to use JSON on a project and not. Yes the dependencies grow but it's really worth it in this case. If additional dependencies are becoming a problem, then it might make sense to consider a different approach to packaging Restlet. Maybe 'subsystems' like JSON, JAXB, etc, could be distributed separately with the appropriate related jars. People would download each subsystem or feature they want to use. Sean
Re: [docs] Poll for participation and input.
Sean Landis sean.landis at gmail.com writes: IMO, it is not intended to be read in one shot like a book but more feature by feature depending on the user needs (beside the first introductory chapters). I agree with this as long as the feature descriptions are very detailed. I think a good general approach to structuring feature descriptions would be to describe the primary usage(s) of the feature up front, followed by descriptions of the more esoteric features. I wrote this wrong. It should read: ...followed by descriptions of the more esoteric facets of the feature. The idea being I can go to the feature I'm interested in, read the first few paragraphs, and understand the key concepts and usage. If the feature is rich, I can continue to read for more detail on the finer points. For example, in describing Router, the use of the Route and modes might be explained later in the section because they are more specialized. That way the typical user can get an answer quickly. Not every feature is rich enough to support this approach, but it seems to me there are many features in Restlet that are simple to use in the typical case but that have many nuances for advanced cases. Sean
Re: [docs] Poll for participation and input.
Jerome Louvel contact at noelios.com writes: Hi all, I agree that the reference manual shouldn't be a repeating of the Javadocs but go beyond and around them: - explain design choices - describe usage contexts - show sample code to copy and paste IMO, it is not intended to be read in one shot like a book but more feature by feature depending on the user needs (beside the first introductory chapters). I agree with this as long as the feature descriptions are very detailed. I think a good general approach to structuring feature descriptions would be to describe the primary usage(s) of the feature up front, followed by descriptions of the more esoteric features. That way the typical user can get an answer quickly. Not every feature is rich enough to support this approach, but it seems to me there are many features in Restlet that are simple to use in the typical case but that have many nuances for advanced cases. Sean
Re: HEAD not well supported?
Jerome Louvel contact at noelios.com writes: Hi all, Thanks for the quality of the feed-back. I feel like I'm now grasping all aspects of the problem and can propose a solution: 1) Split the Resource class into an abstract Handler class and a Resource subclass Hi Jerome, What is the motivation of the Handler class? I have no problem with it, I just want to understand. Is it merely to be explicit about lower level API and higher level, or is there more to it? 4) Resource offers a higher-level API that, as Tim said, is easier to use to map to domain objects, handles content negotiation, conditional methods. - handleGet() is implemented based on the variants property, the getPreferredVariant() and getRepresentation(Variant) methods - handlePost() is implemented by calling an acceptRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handlePut() is implemented by calling a storeRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handleDelete() is implemented by calling a deleteAll() or delete() or removeAll() or remove(). I like the idea of mapping well to the REST terminology. Feed-back welcome. It seems alright but there's enough there that I hesitate to endorse whole- heartedly without trying it out. That's when I usually can establish my comfort level best. Best regards, Jerome Sean
Another MediaType surprise
In my resource, I fully expected the following to work:
if (entity.getMediaType().equals(MediaType.APPLICATION_JSON)) {
but I was surprised to discover that it did not because a parameter
had been set for character encoding on the request and the
MediaType.equals() is implemented to look at those. That makes no sense to me.
Then I discovered the workaround:
if (entity.getMediaType().equals(MediaType.APPLICATION_JSON, true)) {
The additional argument says to ignore parameters. So the two concerns I
have are:
1) MediaType.equals() should compare media types only and that should be
the default.
2) If some other capability is required, call it something other than equals.
I guess another question would be, why was the encoding set in the first place?
Sean
Re: HEAD not well supported?
Tim Peierls tim at peierls.net writes: There's a false parallel here that I don't think should be encouraged by providing parallel names. getRepresentation takes a Variant argument, handleGet does not; post takes a Representation argument, handlePost does not. If anything, I'd argue for names that were *less* parallel, Breaking a false parallel would be fine too. As log as it is no more misleading than the current ;-)
Re: HEAD not well supported?
Jerome Louvel contact at noelios.com writes: ... It could also clarify things by renaming post(Rep.) to postRepresentation(Rep.) to be more consistent with getRepresentation(Variant) namine and to reduce the confusion with lower-level Uniform handle* methods. What do you think? What is your ideal design for the Resource class? 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. Sean
Re: HEAD not well supported?
Erik Hetzner erik.hetzner at ucop.edu writes: At Mon, 8 Oct 2007 17:35:00 + (UTC), Sean Landis sean.landis at gmail.com wrote: [...deleted...] I'd say that Restlet meets the requirements of the spec and that's good. Although I still think it would be better to leverage Uniform entirely and it seems awkward to me that HEAD is an exception. My understanding of REST is that HEAD is part of the uniform interface and therefore should be supported in the same way, and to the same extent as the rest of the HTTP methods. I was very surprised when HEAD did not conform to the programming model in place for the uniform interface and I suspect others would be too. I don’t understand what you mean here by uniform interface. Uniform interface in REST refer to inter-application semantics, not intra-application. And it doesn’t, to my understanding, mean that HEAD GET must have identical semantics, rather that the semantics of a GET or HEAD request be the same for all resources. Am I misunderstanding you here? I don't know if Jerome's comment clarified so I'll follow up. The Resource class partially supports methods that map to a uniform interface (GET,PUT, POST, DELETE, HEAD, OPTIONS). The confusion is that, although there is put(), post(), and delete(), there is no head() (or options() or get() for that matter). There is an allowGet() method, but no get(), which seems even more strange. OPTIONS seems to have been entirely left out. (BTW, I am using p. 97 of RESTful Web Services as my definition of the uniform interface). My point is that the internal implementation of the uniform interface ought to be consistent. The head thing is very confusing because, not only is there no head() but there is behind-the-scenes magic that removes the content. (Based on what's been stated about curl behavior, it sounds like there are cases where content might be desired?) 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
Determining preferred media type from browsers
When a request from a browser to a Restlet application is processed, the request will have many accepted media types. It appears that Restlet scores the accepted media types to prefer APPLICATION_XML and TEXT_XML over TEXT_HTML. This makes it difficult to have a resource support TEXT_HTML and APPLICATION_XML as the resource cannot distinguish between requests originating from a browser or a web service client in the case where the client is sending an XML representation such as via JaxbRepresentation. Are we misusing meida types? Or are the preferred scores correct? It seems a browser should prefer TEXT_HTML over any XML. Thanks, Sean
Re: HEAD not well supported?
Jerome Louvel contact at noelios.com writes: Hi all, I'm a bit late in the discussion it seems :) Let me try to explain how the support for HEAD was designed in Restlet. Following the definition of HEAD from the HTTP spec [1], I got convinced that HEAD was only a special GET and nothing more: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. In order to fulfill this requirement, the framework expects you (Resource and any Restlet/Filter/etc.) to return the exact same response as you would for the similar GET request. The trick is that at the HTTP server connector level, we never send back the response's entity content for HEAD requests. Regarding my previous comments regarding a test using curl; it appears curl is hung up on the fact that content length has a value and there is no entity. I did determine that Restlet does remove the content. Sorry for being misleading on that point. I'd say that Restlet meets the requirements of the spec and that's good. Although I still think it would be better to leverage Uniform entirely and it seems awkward to me that HEAD is an exception. My understanding of REST is that HEAD is part of the uniform interface and therefore should be supported in the same way, and to the same extent as the rest of the HTTP methods. I was very surprised when HEAD did not conform to the programming model in place for the uniform interface and I suspect others would be too. Sean
Re: [docs] Poll for participation and input.
Marc Portier mpo at outerthought.org writes: Some of my TOC additions embedded, feel free to comment... (incorporated the suggestions from issue 21 and those made in this thread already) I also added a big section on doing reslet based development as I think there is a big difference in listing 'what it is and does' versus 'how one should combine things to solve typical problems' other suggestions? regards, -marc= [...deleted...] I was just about to follow up on the original TOC saying that it looked too much like a reference manual. I think you are right on, Marc, in suggesting to include a beefy amount of 'how to'. My personal preference for Java projects is to only focus on how to and let the JavaDoc worry about what it is. but maybe that's too extreme. I'm thinking about the DRY principle here.
Re: Thread-safety in Guard
Funny you should ask! I can highly recommend Java Concurrency in Practice by Brian Goetz, Josh Bloch, Joe Bowbeer, David Holmes, Doug Lea, and me (Tim Peierls). My recommendation is probably biased by the fact that I helped write it, but we've had a lot of good feedback. --tim It is a great book - probably destined to be a classic. Thanks Tim and the rest. The Restlet build uses some good tools to help maintain quality. I'd add another. In appendix A of Java Concurrency in Practice, Annotations for Concurrency is introduced. The primary premise for these - I think - is that JavaDoc doesn't do a good job at expressing the concurrency constraints of the code. Not only are these great for documentation purposes, but FindBugs does some checking based on these. Sean
Re: HEAD not well supported?
In Summary... It sounds like folks are in agreement that HEAD is not properly supported but I haven't heard from Jerome or Thierry, etc. What do you guys think?
Re: [docs] Poll for participation and input.
Jerome Louvel contact at noelios.com writes: Hi Sean, Thanks for proposing to give a hand. Also, I'd like to share again the links in Marc's email as they didn't get recognized in my email client: [1] http://restlet.tigris.org/servlets/ReadMsg?listName=discussmsgNo=3063 [2] http://restlet.tigris.org/issues/show_bug.cgi?id=21 As an example of reference documentation I suggest: http://www.springframework.org/docs/reference/index.html As an example of collaborative doc edition I like: http://www.djangobook.com/en/beta/ Best regards, Jerome Jerome, I am a little confused. Are you proposing these two as alternatives, or are you proposing both a reference and a book? The collaborative tool used for Django looks interesting. Or is that what you are pointing out? Sean
Re: HEAD not well supported?
So is HEAD too obscure to garner any interest? Sean
Re: HEAD not well supported?
John D. Mitchell jdmitchell at gmail.com writes: On 10/3/07, Sean Landis sean.landis at gmail.com wrote: So is HEAD too obscure to garner any interest? I think it's probably a good default to have allowHead == true and default to having handleHead() call handleGet() but head should be fully supportable as you say. FWIW, John That would be a good solution. Backward compatible too. Sean
Re: HEAD not well supported?
Erik Hetzner erik.hetzner at ucop.edu writes: I don’t understand what the issue is here? Can you not override handleHead? Yes you could but there's already a programming model for dealing with HTTP methods. One could argue handle*() methods could be final for example. Why exclude HEAD from that model? Why should you special case getRepresentation? Because HEAD shouldn't necessarily return a representation. The representation should be the same. No, a very common use case is to use HEAD to get meta-data about a resource to decide whether to call GET. For example, if the representation could be extremely large. Presumably (correct me if I’m wrong, Restlet authors) when sending a response to a head request back to the client the server simply won’t make a call to get the actual content of the representation. In almost every way the response to the HEAD request should be the same to a GET, so it makes sense to share the logic. Are you saying there's some place in Restlet where the entity is striped out in the case of HEAD? You might be right, although I didn't see it. Regardless, that makes unreasonable assumptions about the intent for HEAD. Also, intuitively allowHead is a bit redundant, since any resource that allows a GET really should allow a HEAD. That was John's point which I agree with. Default is true. Sean best, Erik Hetzner
Re: HEAD not well supported?
Erik Hetzner erik.hetzner at ucop.edu writes: Are you saying there's some place in Restlet where the entity is striped out in the case of HEAD? You might be right, although I didn't see it. Regardless, that makes unreasonable assumptions about the intent for HEAD. I don’t know; it just seems to me that the place for the optimization which doesn’t call the code that returns the content of the response when we have a HEAD instead of a GET belongs there, not in a special case in your Resource. Here's an interesting follow-up. I have a resource that only implements GET and returns Ok. As the code implies, a HEAD request will do just like GET. When I run: curl --request head my-url It blocks until timeout and then prints: curl: (18) transfer closed with 2 bytes remaining to read So it seems the esteemed tool, curl, totally expects HEAD to not return any content. Sean
HEAD not well supported?
I was implementing HEAD on a resource and couldn't figure out how to do it so I looked at the source for Resource.handleHead() and was surprised to see it calls handleGet(). My understanding of HEAD is that it provides all but the entity. That seems to imply that that getRepresentation() needs to check what method is used and special case HEAD somehow. That is awkward and inconsistent with the rest of the method handling paradigm. One solution is to provide allowHead() and head(). It might make sense to implement head() by calling getRepresentation() but this approach doesn't require it and fits better with the current method handling style. Sean
Re: issue with org.restlet.Client
Nicolas ncapdevila at overstock.com writes: [...all deleted...] Does anyone have any ideas on this? This seems like a serious bug but we are not able to figure it out. Any help appreciated. Sean
1.1 milestone confusion
I followed the link recently posted to the roadmap. I was surprised to find that the 1.1m1 milestone page does not include issue 289 for JaxbRepresentation. Examining the issue though, shows it is targeted for 1.1m1. Not sure why the discrepancy but I thought someone would like to know.
Re: Problem building Restlet source
Thierry Boileau thboileau at gmail.com writes: Hello, Thanks Sean and Alex for reporting and contributing. I've integrated the patch and fixed another compilation pb with the wadl extension. After some tests, the entire build script seems ok. best regards, Thierry Boileau Hi Thierry, I checked out the trunk just now: svn checkout http://restlet.tigris.org/svn/restlet/trunk restlet --username X And I don't see the change in org.restlet.ext.jabx.JaxbRepresentation. Did I misunderstand your post? Thanks, Sean
Re: Problem building Restlet source
Thierry Boileau thboileau at gmail.com writes: Hi Sean, actually, I think I have to read your post... best regards, Thierry Boileau To clarify, this is related to my last entry in issue 289 about throwing exceptions. Sean
JaxbRepresentation.getObject swallows exceptions
In 1.1 beta, the implementation of JaxbRepresentation.getObject swallows exceptions. This is a critical error because callers have no way of responding to errors in the XML passed in, even if an ValidationEventHandler is used. The caller will go along assuming there's no problem until it tries to use the return value. The problem is being tracked under issue # 289.
Re: Problem building Restlet source
Alex, Thanks for the patch. Unfortunately the build appears to be in a very bad state. A unit test fails, so I had to run the rest of the targets by hand. The resulting distro doesn't work at all.
POST w/o an entity not allowed?
We are creating a web service as follows:
http://host/inventoryManager/{product_id}?adjust={n}
This will adjust inventory for a particular product. RESTfully, this should be a
POST. We have all the scoping info in the URI in a form recommended by
RESTful Web Services in the case of an algorithmic resource.
Unfortunately, Restlet does not allow POST with an empty body, or a body with
zero length. The test occurs in Message.isEntityAvailable() and is called
in the POST case from Request.isEntityAvailable.
I haven't seen anywhere that it is unRESTful to have an empty entity. Is this
a W3C constraint? Or just a RESTlet constraint? Does it make sense?
Re: POST w/o an entity not allowed?
Adam Taft adam at adamtaft.com writes: [... deleted ...] I'm assuming you're using a web browser client, because an adjustment to an existing resource would imply PUT, right? But, as we know, PUT/DELETE sucks on web browsers. The operation is not idempotent so it cannot be PUT.
Re: POST w/o an entity not allowed?
Jerome Louvel contact at noelios.com writes: This is indeed an edge case, but there isn't anything in HTTP spec that prevents you from POSTing without an entity. I've changed the Resource class to accept those requests, just logging a trace (FINE level) for debugging purpose. As it is an API contract change, I have only committed this to SVN trunk. Jerome, This is good to hear. Thanks. BTW, we hope to have Restlet 1.1 M1 released in the coming weeks: http://www.restlet.org/about/roadmap I look forward to the JAXB support!
Re: Passing Objects
Caroline Grima carolineg at ccbilleu.com writes: Is there a way to pass complex objects and ints from the client to a restlet? Thanks. Caroline Hi Caroline, The typical way in web services is to marshal objects into an XML structure and then unmarshal them on the server. There are many approaches for this, the most infamous being SOAP which also encompasses remote method call semantics (unRESTful). In RESTful applications, there are a variety of ways to go: JSON and JAXB are two I am familiar with. Restlet 1.1 beta has JaxbRepresentation and JAXB is the technology I'm most familiar with. Sean
Re: Proposal for ResourceFactory
Hi Jon, Jon Lachelt jon.lachelt at hp.com writes: I would like to propose an enhancement to the Router class. I’ll start by admitting that I am fairly new to the RESTlets API and to this forum. A proposal similar to this may have been discussed already, or I may be missing something in the API that works more like I want. ... I made the same argument a while back (Sorry no ref because I can't figure how to search gmane). The answer was that the Finder is technically a factory and you can create your own Finder and use it as a factory in the way you describe. At first I was disappointed in the answer mostly because of syntax: If it's a factory, call it one. But it does work. Hope that helps, Sean
Re: Proposal for ResourceFactory
BTW, the seach field is in the lower left corner of he Gmane page. Regards, -Jon Boy, do I feel silly :-) Really, thanks. Sean
Restlet developers wanted
With permission from Jerome, I am posting a job opportunity. Overstock.com is looking for people with strong Restlet experience. We have several Senior Developer positions and one Architect position open. This is your chance to leverage your special ability in Restlet to build sophisticated real-world web services. Overstock.com is located in Salt Lake City, Utah where there is a wealth of opportunity. The Salt Lake City area is perfect for people who live an active lifestyle and also appreciate the benefits of a middle sized U.S. city. Most people are happily surprised when they get to know Utah. If you are interested, please send a resume to [EMAIL PROTECTED] Regards, Sean
Re: Second 1.1 beta 1 snapshot
- Added JAXB 2.0 and StAX 1.0 libraries. Hi Jerome, Is there a reason that JAXB 2.1.3 wasn't used? Thanks, Sean
Re: Commons Logging
... Sean Landis, if you're reading this, could you possibly give more details about your JdkLoggingToLog4jBridge solution?? Maybe this information could be appended to the RFE? Oh no, I've been discovered! Our legal has loosened up a bit lately. I've posted JdkLoggingToLog4jBridge.java in the RFE (issue 179). Sean
Re: Passing data on requests
What kind of identifiers..? Credentials? Unique client ID and unique call id. Sean
Passing data on requests
I have a need to pass a couple of identifiers along with requests of every method type (GET, PUT, DELETE, POST). Is there a recommended way to do this? Thanks, Sean
Re: Passing data on requests
Sean Landis sean.landis at gmail.com writes: I have a need to pass a couple of identifiers along with requests of every method type (GET, PUT, DELETE, POST). Is there a recommended way to do this? I should add these requirements. The service needs to be called from both Java and C/C++. So I'd like to know what is the best way that supports both of these clients. What I see as options now are: RequestWrapper - but this seems to tie me to a Java-only solution. Modify the message attributes - If this is more friendly to C/C++ clients, I do not know how to use it there. Headers?
WADL Restlet
I'm posting for two reasons. First, can people share what good (or bad) they see in WADL; what it is good for. Second, what, if any, relationship would make sense for Restlet and WADL? Thanks, Sean
Re: Example using XmlRepresentation?
Jared Nedzel jnedzel at broad.mit.edu writes: Sean: I've been meaning to take a closer look at JAXB. Is your code open-source by any chance? Jared, I'm afraid not, but it is pretty straightforward. The JaxbRepresentation does just what the DOM rep does. If given an xmlRep in construction, it unmarshals it into a JAXB content tree. If given a tree, it just holds it. The write() method marshals the tree to the provided output stream. The filter needs to be parameterized at construction with package and schema information (the latter for validation as I recall). The beforeHandle() creates a JaxbRepresentation as sets it to the request entity. The afterHandle() marshals a JaxbRepresentation into a string or xml rep. There are some tricky bits if you are doing validation and if you want to pool marshallers for performance and thread safety. Sorry I can't post code. Sean
Re: Defining Methods
Hi Jerome,
Jerome Louvel contact at noelios.com writes:
Hi Sean,
I don't think that there is a consensus on this point in the REST community.
Some think that we should only rely on GET/POST as the other methods are not
well supported by browsers. We Restlet, you can always rely on the tunnel
service to dynamically change the method of request, by adding a
?method=DELETE query.
I should have mentioned that this is a web service so browsers don't need to
be involved. Does that change anything?
Also, WebDAV already defines extension methods like MOVE:
http://www.webdav.org/specs/rfc2518.html#http.methods.for.distributed.author
ing
Some don't like the MOVE method because the origin server may not be in
control of the target URI namespace. I like it if you restrict its usage to
target URI that you control (or return an error).
MOVE is clearly interesting because simply doing a GET/DELETE/PUT sequence
isn't equivalent and as performant, especially when a resource has multiple
representations.
Now, for other methods like CANCEL, we would need to understand its meaning
to be able to say whether it reduce the uniformity of the REST interface or
whether is adds a useful method to it.
The result of a CANCEL is that an invoice is canceled in the DB but still
available. I don't think it is a useful new method in the sense that MOVE
is. I see 'cancel' as a resource state change that should be a POST
(although we don't need to post any data). A
DELETE doesn't seem right since we aren't deleting the invoice, just marking
it as canceled.
Others don't see it that way. I don't see CANCEL adding any new behavior so
it's hard for me to justify.
More detail. We have three operations on an invoice (that is created
elsewhere).
1. Get invoice (GET)
2. Compute canceled invoice and return the savings
3. Cancel invoice
From a purely URI perspective, all I need is:
router.attach(/orders/invoices/{invoiceId}, InvoiceResource.class);
But the limited number of methods gets in my way. I think 1 2 should be a
GET and 3 should be a POST.
I could define a new URI, say,
router.attach(/orders/invoices/{invoiceId}/cancel, InvoiceResource.class);
but that seems unfortunate.
Any suggestions?
Thanks,
Sean
Knowing that you can always tunnel those methods via a POST in Restlet
should help in such a debate!
Best regards,
Jerome
-Message d'origine-
De : news [mailto:news at sea.gmane.org] De la part de Sean Landis
Envoyé : jeudi 12 avril 2007 00:55
À : discuss at restlet.tigris.org
Objet : Defining Methods
Restlet has the ability to define our own Methods, say MOVE,
or CANCEL.
I'm in a debate that is essentially arguing the merits of defining an
application-specific Method, say CANCEL, vs. falling back on POST.
I thought of 3 positions.
1. Only use the 4 core Methods and if that isn't enough, define a new
URI. Problem is that this is equivalent to making the URI a verb.
2. Always define application-specific Methods. Be totally
clear about what
the application is trying to do.
3. Use the 4 methods whenever possible but add app-specific
Methods when it
makes sense. Problem I have with this is defining When it
makes sense.
Any and all opinions appreciated.
Sean
Re: Bug in bookmark example
Hi Thierry, Thierry Boileau thboileau at gmail.com writes: Hello Sean, the example code has been updated in the SVN repository. Thanks for reporting this issue. I think there is still a bug. Try adding a user and two bookmarks. Shutdown the server and then restart it. One of the bookmarks seems to disappear. Sean
VirtualHost JavaDoc
I noticed the javadoc for the VirtualHost class talk about regular expression matching. Isn't URI Template matching done now? It would also be helpful to explain what hostRef, resourceRef, and serverInfo are. Sean
Re: Newbie question on the Resource changes in RC3
Hi Jerome, Jerome Louvel contact at noelios.com writes: Hi again, To facilitate the creation of Finder subclasses, I've exposed the resourceClass property with a getter. I've also extracted the Resource creation logic from Finder.findTarget() into a Finder.createResource() method. By default, findTarget() invokes createResource(), but this should facilitate the implementation of pooling mechanisms if required. Finally, I've added a finderClass property on Router that will automatically create the right Finder instance for you when calling attach(/uri/..., myResource.class). Changes are already in SVN. Thanks for this, it should meet all the requirements I suggested. This approach may more tightly couple Resource with Router and Finder than would the factory approach...I don't know if that's a problem. It also requires one to subclass finder rather than provide a factory reference. I personally prefer extension through delegation over subclassing. (See Effective Java, Item 14: Favor composition over inheritance). Regardless of philosophy, this is a powerful addition. Thanks again! Sean
Re: Newbie question on the Resource changes in RC3
Hi Jerome, Hi Jerome, Jerome Louvel contact at noelios.com writes: Hi again, To facilitate the creation of Finder subclasses, I've exposed the resourceClass property with a getter. I've also extracted the Resource creation logic from Finder.findTarget() into a Finder.createResource() method. By default, findTarget() invokes createResource(), but this should facilitate the implementation of pooling mechanisms if required. Finally, I've added a finderClass property on Router that will automatically create the right Finder instance for you when calling attach(/uri/..., myResource.class). Changes are already in SVN. I had a chance to look at the new code and I'm afraid these changes are not as helpful as I'd hoped. The original problem was that I couldn't parameterize Resources with my state because construction of resources was controlled by the Finder which only understood two constructor signatures. With the above changes, I now have control over construction of resources by extending Finder and overriding createResource(). The problem is that I can't parameterize the Finder because, just like with Resource before, Finder construction is not under my control. I cannot say: new Finder(context, myState); The Router insists on it's known constructor forms so I can't set state. I still think the right answer is to allow use of a resource factory. So a way to do this is to add a constructor, Finder(Context context, ResourceFactory factory) The code in createResource checks for and uses the factory, else it does what it does now. In Router, add: attach(String uriPattern, ResourceFactory factory) attachDefault(ResourceFactory factory); I think that does it. Sean
Re: Newbie question on the Resource changes in RC3
Why does Router insist on instantiating a Finder anyway? Finders aren't instantiated on a per call basis. Why not just allow to set the Finder instance in the router? Sean
RC4 bug in create*
I think there is a bug in Finder.createResource() and Router.createFinder().
Both have some code like this:
try {
constructor = getTargetClass().getConstructor(Context.class,
Request.class, Response.class);
if (constructor != null) {
result = (Resource) constructor.newInstance(getContext(),
request, response);
} else {
... do something assuming the right constructor was not found.
The problem is that if the right constructor isn't found, a
NoSuchMethodException is thrown. I don't think the else clause will
ever get executed.
Sean
Re: Newbie question on the Resource changes in RC3
Hi Jerome,
Jerome Louvel contact at noelios.com writes:
Hi all,
Thanks for exploring this recurring issue. I realize that the current
approach isn't flexible enough in many case. So, I have restored the default
constructor and added a new 'init(Context, Request, Response) method that
gets invoke by the other constructor.
This clearly adds much needed flexibility. Thanks.
Also, the Finder class will now look for a default constructor if the normal
one isn't available and will call 'init' after the instantiation in this
case. This should make everyone happy.
I can't decide if I'm happy based on the description of the change. I am
unclear how this helps my issue. I have application level state the
resource requires.
I don't see how the above changes resolve that issue.
One solution would be to add Finder(Context context, ResourceFactory factory).
interface ResourceFactory {
public Resource createResource(Class? extends Resource targetClass);
}
That would allow me to say something like:
public class MyApplication extends Application implements ResourceFactory {
private State state = ...
...
public Resource createResource(Class? extends Resource targetClass) {
// Create the targetClass and initialize it with my state.
...
return r;
}
Then in Finder, the factory gets called to create an instance that I can
initialize. Then finder calls Resource.init(...).
I'm not sure if this is the best solution but hopefully it makes clear
the capability I'm interested in.
Sean
Re: Newbie question on the Resource changes in RC3
Hi Jerome, Jerome Louvel contact at noelios.com writes: Thanks for detailing your requirements with concrete code. I think you can already cover your need for application level state (shared by all Resources and Restlets) by leveraging Context's attributes: I considered that and looked for a better way. Passing application data via context is a dangerous practice: - Namespace collisions - Tight coupling through convention - Not type safe - Difficult to maintain - Difficult to debug This is one of the reasons we don't use JSP. Restlet is a strong project that promotes good practices. I think it would be wise to continue that in all respects. Promoting the use of contexts for data passing is counter to that. That's not to say there isn't utility in contexts. I just think Restlet application developers should be discouraged from using contexts and, whenever possible, be provided with a safe alternative. Sean
Re: Newbie question on the Resource changes in RC3
A couple other notes about the idea of a Application-defined ResourceFactory. It must be thread-safe. It provides inversion of control. It allows me to decide policy regarding Resource allocation (one-per-call, thread-safe stateless, singleton, pooling, etc). The more I think about it, the more I think this is a really good hook to have in addition to the basic attach(..., Resource.class). Sean
Re: Problem with multiple virtual hosts
This was the issue. Thanks Thierry. Thierry Boileau thboileau at gmail.com writes: Sean, I forget : can you try to define the JAR_URI with the file path and not the file URI (check the constructor ;) ), such as : I don't intend to make any excuses for my inability to read JavaDoc correctly, but this does beg a question. Should Directory and FileRepresentation constructors be consistent since they are dealing with similar things. Should they both take a URI or should they both take a File/path? BTW, I was getting exceptions occassionally but they were getting thrown later in the pipeline when getRepresentation was being called. I was confused by that, and wrote it off as a result of canceling the download. I was further confused by caching which I hadn't accounted for. Basically, I was just confused :-) But the lesson here for me is to use the FileRepresentation constructor that accepts a File because File construction will fail fast and in the application code. Sean public static final String JAR_URI = //home/slandis/restlet-1.0rc3/lib/org.restlet.jar; Best regards, Thierry Sean Landis a écrit : Pardon, It did sort of work... When I selected http://wasatch:8182/jar I got a download dialog but: 1) the name of the file was jar, not org.restlet.jar, 2) The file that gets 'downloaded' is empty. Sean
Problem with multiple virtual hosts
I wanted to set up something like is shown in the tutorial component diagram
where there are VirtualHost A and B and Application 1, 2, and 3. I'm using
RC3 and my code looks like this:
public class ComponentServer {
public static final String DOC_URI
file:home/slandis/restlet-1.0rc3/docs/api/;
public static final String JAR_URI
file:home/slandis/restlet-1.0rc3/lib/org.restlet.jar;
public static void main(String[] args) throws Exception {
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
component.getClients().add(Protocol.FILE);
VirtualHost vh1 = new VirtualHost(component.getContext());
vh1.setHostDomain(localhost);
Application application1 = new Application(component.getContext()) {
@Override public Restlet createRoot() {
Directory directory = new Directory(getContext(), DOC_URI);
return directory;
}
};
VirtualHost vh2 = new VirtualHost(component.getContext());
vh2.setHostDomain(wasatch);
Application application2 = new Application(component.getContext()) {
@Override public Restlet createRoot() {
Restlet jarRestlet = new Restlet(getContext()) {
@Override public void handle(Request request, Response response) {
FileRepresentation frep = new FileRepresentation(JAR_URI,
MediaType.APPLICATION_JAVA_ARCHIVE, 1000);
response.setEntity(frep);
}
};
return jarRestlet;
}
};
vh1.attach(/docs, application1);
component.getHosts().add(vh1);
vh2.attach(/jar, application2);
component.getHosts().add(vh2);
component.start();
}
I can access /docs but /jar is not resolved. I get:
The server has not found anything matching the request URI
I tried looking at the code but got lost trying to figure out the dispatching
of the handle() method to the handler. I kept going in circles and never
could find where the servers list was being used.
Any help appreciated.
Sean
Re: Problem with multiple virtual hosts
Thierry Boileau thboileau at gmail.com writes: Hello Sean, did you try to set the status after setting the entity of the response? Best regards Thierry Hi Thierry, I just tried that without success. I added: response.setStatus(Status.SUCCESS_OK); after setting the entity. I also tried changing the media type to TEXT_PLAIN which did not work either. Sean
Re: Problem with multiple virtual hosts
Pardon, It did sort of work... When I selected http://wasatch:8182/jar I got a download dialog but: 1) the name of the file was jar, not org.restlet.jar, 2) The file that gets 'downloaded' is empty. Sean
Re: Struggling with recent changes
Thanks Vincent, Your explanations helped. I like the expansion of the role of Resource. Sean
Struggling with recent changes
I seem to have missed something fundamental regarding the recent changes. It now appears one must create a Resource to handle the dispatching of post, etc. We have several web services that previously dispatched to a Handler that implemented handlePost. I am unclear what to do with this Resource requirement. It seems, at least for us, the complexity of using Restlet has increased dramatically. Please tell me I'm missing something. Sean
Re: Using Virtual Hosts
Jerome Louvel contact at noelios.com writes: Hi Jerome, Hi all, In addition to Thierry answer, I would like to indicate that a virtual host is defined along three properties: - request's hostRef (equivalent to HTTP's Host header) - request's resourceRef (equivalent to HTTP's resource URI, prepended with Host header for relative URIs) - response's serverInfo (listening IP address and port) This is helpful. Hopefully it can be integrated in the JavaDoc. I have also reintroduced the sample application, totally refactored to used the latest features in 1.0 RC1, at: http://www.restlet.org/sample And this will be a good addition. Regards, Sean Best regards, Jerome
Bug in Directory handler
I found a bug in the Directory handler. It generates correct XML for the top level items, but if you click on a directory in a browser, then next level links are unusable. Here's what's generated by clicking on the 'jmx' link: htmlbody h1Listing of directory /jmx/h1 a href=http://localhost:8182/;../abr/ a href=http://localhost:8182/jmxjmx_examples;../jmxjmx_examples/abr/ /body/html I've entered bug #233 that contains a proposed fix. Sean
Server warning
I'm seeing a warnding from the server that I can't figure out how to get rid of: Dec 5, 2006 2:57:03 PM com.noelios.restlet.http.HttpServerCall parseHostWARNING: Couldn't find the mandatory Host HTTP header. I'm using ServerServlet if that matters. Thanks, Sean
Re: Connection reuse again
Jerome Louvel contact at noelios.com writes: Hi Sean, No problem, the support of Apache HTTP Client was needed anyway. To test the other connector, you just need to replace the com.noelios.restlet.ext.httpclient_3.1.jar file by the com.noelios.restlet.ext.net.jar one in your classpath. It seems I need com.noelios.restlet.ext.net.jar in either case, else I get a CNFE. Anyway, when I remove com.noelios.restlet.ext.httpclient_3.1.jar from my client's classpath, I do see that the connection is persistent. Performance-wise, it appears the apache client is about 5% faster but my testing is crude. Sean
Connection reuse again
I am using the new apache http client and I'm seeing strange behavior. I am sending 50 messages to the server in rapid succession. Using the 'ethereal' tool, I examined the TCP traffic. What I saw was that occasionally the connection would get reused once, that is, two calls would occur before the connection was closed. In the other cases, I think 45, the connection was closed after the first call. At the TCP level, the close is requested by the client. I had one theory that I couldn't confirm. I saw that com.noelios.restlet.ext.httpclient.HttpClientHelper in stop() calls closeIdleConnections() on the connection manager and it appears to me that call is not immediate but may take some time. I guessed that there might be a race between that call completing and my requests, so occasionally I won and sometime two calls got through. But I could not find anyplace where the stop() method would be called. Any ideas on what is going on and how I could get the connection to stay open? Regards, Sean
Re: Connection reuse again
Sean Landis sean.landis at gmail.com writes: I am using the new apache http client and I'm seeing strange behavior. I am sending 50 messages to the server in rapid succession. Using the 'ethereal' tool, I examined the TCP traffic. What I saw was that occasionally the connection would get reused once, that is, two calls would occur before the connection was closed. In the other cases, I think 45, the connection was closed after the first call. I figured out my problem. I was reviewing a link Jerome had referred me to, http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html and saw this: Do not abandon a connection by ignoring the response body. Doing so may results in idle TCP connections. That needs to be garbage collected when they are no longer referenced. I added: tmp = reply.getOutput(); and connections remained open. Sean
Re: C++ clients?
Jerome Louvel contact at noelios.com writes: Hi Sean, Maybe I'm not understanding your question correctly. A Restlet container communicates with other components using connectors (like HTTP servers). So, if your C++ clients can use a normal HTTP client library, it should work fine. Best regards, Jerome Hi Jerome, You understood. I'm new to web protocol programming so that's why the question may seem funny. Thanks, Sean
FAQ and examples error?
It looks like an example might require updating. In the FAQ I see: 5. How can I get the raw HTTP headers if I really need to? Even though the org.restlet.data.Request and org.restlet.data.Response classes provide a convenient and protocol-neutral way to manipulate the information contained in standard HTTP headers, it is sometimes necessary to access to the raw header values or to add non-standard headers. For this purpose, we use special request and response attributes, see details in Javadocs of the Message.getAttributes() method. There is also a sample code in the distribution that illustrates how to get raw headers and how to add non-standard ones, see the com.noelios.restlet.example.misc.HeadersTest class in the src directory. Message.getAttributes() returns a MapModel, but the cited example is using ParameterLists. I think the example is out of date. Also, I require some clarification. Is it not allowed (or not recommended) to use the method in the example to set standard headers? I think it is clearly stated that it is alright to set non-standard headers but not clear enough regarding standard headers. Thanks, Sean
Re: Keeping a client connection open
Hi Jerome, Jerome Louvel contact at noelios.com writes: Other thoughts? I think your suggestion is a good one. Thanks, Sean
Re: Keeping a client connection open
Hi Jerome, Hi Sean, I would have expected the other behavior as the JDK keeps HTTP connections alive by default. There is a system property to change this behavior, you may want to play with it and see what happen: http.keepAlive (default: true) http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html In this other document they have an interesting paragraph: http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html Thanks, I will check these out. What makes a connection reusable? ... This sounds like voodoo :-( I don't want to have to step all the way down to socket level or some such. So, you may want to ensure that all your request entities (representations) have their size property precisely set. Also, feel free to have a look at the implementation classes (just two) to see if our usage of HttpURLConnection could be improved. So if I can stay within the confines of the Restlet world and still get connection reuse, that would be great. I'll play with it and report back what I find. Regards, Sean
Keeping a client connection open
I noticed that using a Client, that the connection is opened and closed for every call. I have a web service client that would like to hold the connection open across a series of requests. I can't see how to do that. I'm using the ServerServlet, in case that matters. Thanks, Sean
Re: Handlers for search urls
Hi Vincent, Vincent vincent.lari at yahoo.ca writes: Hi Piyush, /accounts/search/less_than/1 /accounts/search/greater_than/1 /accounts/search/between/1/2 The issue I have with this approach is that it doesn't allow to mix several search criteria (balance_less_than=2000status=active). I'd like to have: 1) /accounts/1234 - retrieve an individual account 2) /accounts?balance_less_than=2000status=active -search That's why I was hoping creating my restlets like so: attach(/accounts/[0-9]+$, new GetAccountHandler()) attach(/accounts?[.]+$, new SearchAccountHandler()) would work. Now, following your idea, I could do: attach(/accounts/search?[.]+$, new SearchAccountHandler()) and access it with /accounts/search?balance_less_than=2000status=active But it kind of bothers me to have to have to specify the action twice (the http GET method and the 'search' portion of the url). and restlets that support that class because they understand the URLs .. Well, it turns out restlets only understand the base of the URLs. We had a similar issue and I think this is an area where the REST philosophy is somewhat stressed. We thought of putting the search criteria on the URI but in our case, we could easily overrun the length restrictions because we have so many criteria. We decided to make a web service, use a POST and put the criteria in the XML. Then the URI could be /accounts/search which is pretty easy to deal with. I'd be interested in hearing more on this topic. Sean -Vincent.
Address already in use (b19)
I am having trouble transitioning to b19. I am using the ServerServlet to
integrate with Tomcat.
I have a class that extends Application and has the following:
public JDomApplication(Context context) {
super(context);
}
@Override public Restlet createRoot() {
// Create our restlets.
final Restlet sayHelloHandler = createSayHelloHandler();
final Restlet sayGoodbyeHandler = createSayGoodbyeHandler();
final Restlet failureHandler = createFailureHandler();
final Restlet partialFailureHandler = createPartialFailureHandler();
final Restlet invalidDomHandler = createInvalidDomHandler();
final Restlet xsdRestlet = new XsdRestlet(SCHEMA_PATH);
final Filter jdomFilter = new JDomFilter(NAMESPACE, SCHEMA_PATH, true);
// Create a root Router.
Router router = new Router(getContext());
// Add the first level routing targets.
router.getScorers().add(/hello[/]*?$, xsdRestlet);
router.getScorers().add(hello/*, jdomFilter);
// Create the hello router.
Router helloRouter = new Router(getContext());
jdomFilter.setNext(helloRouter);
// Attach the handlers.
helloRouter.attach(sayhello$, sayHelloHandler);
helloRouter.attach(saygoodbye$, sayGoodbyeHandler);
helloRouter.attach(failure$, failureHandler);
helloRouter.attach(partialfailure$, partialFailureHandler);
helloRouter.attach(invaliddom$, invalidDomHandler);
// Return the root router.
return router;
}
When I try to access this service, I get the following exception and trace:
Oct 25, 2006 2:41:49 PM org.restlet.Restlet init
WARNING: Unable to start the Restlet
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
com.noelios.restlet.ext.simple.HttpServerHelper.start(HttpServerHelper.java
:54)
at org.restlet.Server.start(Server.java:265)
at org.restlet.Restlet.init(Restlet.java:117)
at org.restlet.Server.handle(Server.java:181)
at com.noelios.restlet.impl.ServerHelper.handle(ServerHelper.java:96)
at
com.noelios.restlet.impl.http.HttpServerHelper.handle(HttpServerHelper.java:
87)
at
com.noelios.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
n.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext
.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext
Valve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
ava:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon
text.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCont
xt.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveConte
xt.java:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCont
ext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j
ava:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCon
text.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.jav
a:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
onnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:684)
at java.lang.Thread.run(Thread.java:595)
Re: Beta 19 and fluent builders
Dave Pawson dave.pawson at gmail.com writes: and maintainability are very important. We use the fluent style in other projects it has served us well. It seems to resonate here. May I suggest this is a personal preference too? Absolutely. After all, style is it's last name. ;-) Sean regards
Re: Breaking Call into Request and Response (Was: Allow Header)
Hi Jerome, Jerome Louvel contact at noelios.com writes: Hi Sean, I've just checked in SVN the modification for Call split and Allow support. All unit tests pass but I haven't done thorough testing. Also Servlet adapter is still broken. My work depends on the Servlet adapter but I wouldn't be able to do anything this weekend anyway. Sorry. Sean Testing over the week-end is very welcome as I'll try to finish/release on Monday if possible. Best regards, Jerome
Re: Breaking Call into Request and Response (Was: Allow Header)
Jerome Louvel contact at noelios.com writes: Hi all, I share the same concern as Piyush. There are now about 34 methods in the Call class, corresponding to about 20 properties. ... If there is no major opposition, I will try to integrate this change to beta 19. Any comment? I'm torn between the accumulating weight of the Call and the significance of this change. I think it is probably a good idea to do it. Certainly sooner is better than later. Around here, people are comfortable with Request/Response so it probably will go over fine. Related to this, is there any guess as to when the API will become stable? Thanks, Sean
Re: Handling PUT, POST and DELETE
I appreciate the fact that Resources can delete themselves and that makes sense when a resource isn't a participant in a containment hierarchy. Likewise, support for containment of resources is important because many resources are modeled that way. Locking into one or the other is too limiting. Making specific accomodation in the API for both would lead to modality which is bad. An API that allows implementation of both models, without specifically committing to either, feels right to me. Sean
Re: Surprising interaction between Call status and output
Jerome Louvel contact at noelios.com writes: Hi Sean, I've fixed the issue in SVN. Thanks for the feed-back! Best regards, Jerome Thanks Jerome. I was hoping to get this change so I checked out the HEAD and tried to build and got the following: test: [junit] Running com.noelios.restlet.test.NoeliosTestSuite [junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 0.593 sec BUILD FAILED /home/slandis/RestletDev/restlet/build.xml:528: Test com.noelios.restlet.test.NoeliosTestSuite failed Is the SVN currently unstable, or am I missing a step? Thanks, Sean -Message d'origine- De : news [mailto:news at sea.gmane.org] De la part de Sean Landis Envoyé : vendredi 29 septembre 2006 20:40 À : discuss at restlet.tigris.org Objet : Surprising interaction between Call status and output I have a web service (under Tomcat using the ServerServlet) that accepts post requests and returns a response. If the service encounters an error, I desire to set the Call status and provide my own XML in a StringRepresentation. If I don't set the status, my XML is returned fine. If I set the status to say, CLIENT_ERROR_BAD_REQUEST, then the output becomes: htmlheadtitleApache Tomcat/5.0 - Error report/titlestyle!--H1 etc. I want my output, not this. Is there any way to avoid the overwrite? I don't think this is a good feature as it makes assumptions about the use case. Thanks, Sean
Converting a DomRepresentation to StringRepresentation
I have an application that contains a filter that converts incoming XML into a DomRepresenation so that it can be manipulated later as a document. Then, on the return, a document comes to the afterHandler() and I want to transform that into XML to return to the client. How do I easily get the write() output from the DomRepresentation into a StringRepresentation? Sean
