Re: Mime type filtering.

[Dave Pawson]

Thanks Rob, Rhett.

2009/2/6 Rob Heittman :
> Hi Dave!  (Shout out from fop-dev back in the day)
>
> If you are using the Accept: header in your client
Yes, thats the criterion I'm using.


> ... and using the Restlet
> Resource model on the server ... just write your responding code in your
> override of represent(Variant variant).
>
> if(variant.getMediaType().equals([the MediaType you speak])){
>   // do stuff;
> } else {
>   // return the error status;
> }

I'm guessing this is where I'd need to handle the 406?
Or use Rhetts idea and extend resource.

OK, It's doable. I need to study the API a bit more.


>
> I just spotted this example blog that does pretty much what you want:
> http://www.2048bits.com/2008/06/creating-simple-web-service-with.html

Thanks for that, looks good.

I couldn't find much in http://tomcat.apache.org/tomcat-6.0-doc/api/index.html
to help me get the header so I'll move this work over to restlets.

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1117494

Re: feedback on restlet

[Raif S. Naffah]

hello dude,

this is not the best sort of email one can hope getting any help for.  if 
it's really an advertisement for a new project, then congratulations but 
pls. next time re-word the subject line accordingly.

if on the other hand, this is a real cry for help and an earnest desire to 
contribute for improving the code then consider the following aspects which 
you may have overlooked --if you haven't you didn't make it clear enough in 
your email:

* GET and POST parameters:  Restlet abstract the HTTP request in a Request 
object --a subclass of Message-- both live in the org.restlet.data package.  
if you look at the source (or the javadocs) you'll see a wealth of methods 
that should be able to suit many and varying needs; e.g.: getEntity() which 
returns a Representation, and getEntityAsXxx() methods.  having obtained, 
for example a Form instance (from getEntityAsForm()) you can then have in 
your concrete Resource type something that would materialize a Data Access 
Object (DAO) for the object type represented by this Resource in a way 
similar to the following:

public class MyObjectResource extends Resource {

  public MyObjectDAO getDAO(Form f) {
final MyObjectDAO result = new MyObjectDAO();
result.setNickname(form.getFirstValue("nickname"));
result.setFirstName(form.getFirstValue("firstName"));
...
return result;
  }
}

* Asynchronous communication:  Restlet does not impose any communication 
model or technology.  how the call arrives to a Restlet Connector is in a 
way orthogonal to how it is dealt with.  if you're like me convinced of the 
value of REST and its "stateless" nature, then leaving this out of the 
concerns of the library / framework could only be beneficial.  my opinion is 
that if your application really needs something like that build a layer that 
sits outside and in front of any REST-ful tier.

* Should have option to run as webapp:  Restlet already allows you to do 
that.  in addition it allows you to run your Server application outside any 
J2EE WebApp Containers --see the Grizzly and Simple Extensions.

* Use Jetty for standalone:  i presume you meant for Server standalone, 
since with Restlet you can build Clients as well as Servers that communicate 
in a REST-ful manner.  i personally don't like being herded to use one type 
of software however good it is --and Jetty is definitely a first grade piece 
of software.  but if you think that this could facilitate the adoption of 
Restlet and REST in general, nothing prevents you from exploring the Servlet 
and Jetty Extensions and identifying any weaknesses and submitting 
improvements.

* Too Complex:  this is like Beauty; it's in the eye of the beholder!  i 
would love to see pseudo code that gives concrete examples of how it could 
be made easy --something like Before and After.  seriously, there may be 
areas where you need to wire lots of parameters and objects but the fact 
that at the base line it's flexible to allow you almost complete control on 
how to handle a request-response chain, for me this is an advantage.  that 
said, if you think there are representative Use Cases which would benefit 
from cut down versions or reduced functionality of some classes and 
operations, then may be you can propose either new classes to offer this 
functionality or ultimately a new Extension (RestletMadeEasy?) that would 
benefit developers with such needs.  if the API exposed by these classes is 
appealing i'm sure developers would move to adopt it.  of course you can go 
and write such a beast from scratch, or you can build it on top of Restlet.  
your choice.


On Sat February 7 2009 05:24:39 code dude wrote:
> Hi folks ,
>
> I used restlet on one my projects which live since one year , i fond
> RESTLET to be too complex and confusing also it lacks some features like
> (i maynot be aware if features might exist)
>
>- restlet get or post parameters should be automatically mapped to
> some kind of object
>- asycn communtication should be supported
>- restlet should have option to run as webapp on tomcat or jetty
>- Pl use jetty for standalone
>- its too complex !! too many new concepts , use KISS
>
> so i am writting my own trimmed down RESTLET framework using jetty
> continuations , I hope opensource when its done
>
> Best Regards,
>
> Code Dude
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=11
>14069


cheers;
rsn


signature.asc
Description: This is a digitally signed message part.

Re: Mime type filtering.

[Rhett Sutphin]

Hi,

On Feb 6, 2009, at 2:55 PM, Rob Heittman wrote:
> If you are using the Accept: header in your client ... and using the  
> Restlet Resource model on the server ... just write your responding  
> code in your override of represent(Variant variant).
>
> if(variant.getMediaType().equals([the MediaType you speak])){
>   // do stuff;
> } else {
>   // return the error status;
> }


What Rob's saying will work for sure.  You don't even have to handle  
the 406 yourself -- if you extend Resource and override  
represent(Variant), Restlet will automatically send the 406 if the  
represent method returns null.

Rhett

On Feb 6, 2009, at 2:55 PM, Rob Heittman wrote:

> Hi Dave!  (Shout out from fop-dev back in the day)
>
> If you are using the Accept: header in your client ... and using the  
> Restlet Resource model on the server ... just write your responding  
> code in your override of represent(Variant variant).
>
> if(variant.getMediaType().equals([the MediaType you speak])){
>   // do stuff;
> } else {
>   // return the error status;
> }
>
> I just spotted this example blog that does pretty much what you  
> want: http://www.2048bits.com/2008/06/creating-simple-web-service-with.html
>
> On Fri, Feb 6, 2009 at 6:42 AM, Dave Pawson   
> wrote:
> I want to do a GET, specifying that I can accept application/xml+atom
> as a mime type.
>
> At the server end; Unless this is specified (in the header I think -
> my knowledge of http isn't very strong)
> I want the server to reject the GET (error code 406 seems right). Even
> if no mime type is specified,
> I will still refuse the GET.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1114757

Re: Mime type filtering.

[Rob Heittman]

Hi Dave!  (Shout out from fop-dev back in the day)

If you are using the Accept: header in your client ... and using the Restlet
Resource model on the server ... just write your responding code in your
override of represent(Variant variant).

if(variant.getMediaType().equals([the MediaType you speak])){
  // do stuff;
} else {
  // return the error status;
}

I just spotted this example blog that does pretty much what you want:
http://www.2048bits.com/2008/06/creating-simple-web-service-with.html

On Fri, Feb 6, 2009 at 6:42 AM, Dave Pawson  wrote:

> I want to do a GET, specifying that I can accept application/xml+atom
> as a mime type.
>
> At the server end; Unless this is specified (in the header I think -
> my knowledge of http isn't very strong)
> I want the server to reject the GET (error code 406 seems right). Even
> if no mime type is specified,
> I will still refuse the GET.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1114729

RE: Re: How to integrate jetty's ThrottlingFilter

[blackhole]

Tim,

>- Postdecrement of a volatile is not atomic.
>- Calls to "foreign" code in a synchronized block risks deadlock.

you are so right, I noticed this too, but after I sent the mail. Problems did 
arise when decrementing the volatile int.

>- As you suspected, there is no guarantee that afterHandle will be called
>once for every call to beforeHandle.

Just for the record, afterHandle is not called, when uncought exceptions occur.

Will test your version now, thanks a bunch!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1114154

Re: feedback on restlet

[Rob Heittman]

Yes, I think Restlet is definitely not for you.  You listed some "missing
features" that are pretty basic elements in the Restlet first steps tutorial
-- like running a standalone with Jetty or running as a Web application --
things I picked up in the first hour I downloaded Restlet around two years
ago ... so something definitely did not translate to your experience.

Maybe I have a different perspective on simplicity, though:

Restlet doesn't introduce much in the way of "new" concepts, it uses Java to
express the principles of REST, which predate even Fielding's 2000 thesis
which officially named them, being part and parcel of the stateless design
of the Web.  For me (and I admit I am getting to be an old guy, and one who
can recite large sections of RFC 2616) the structure of Restlet is quite
natural and easy, because it accurately reflects the internal architecture
of the Web.

Since I think it is safe to say that the Web has been a reasonably
successful technology, I find it a little sad that its architecture seems
complex and confusing to anyone.  Still, I wish you luck on your simplified
RESTful framework and hope that it successfully reaches a different audience
than Restlet.

- Rob

On Fri, Feb 6, 2009 at 1:24 PM, code dude  wrote:

> Hi folks ,
>
> I used restlet on one my projects which live since one year , i fond
> RESTLET to be too complex and confusing also it lacks some features like (i
> maynot be aware if features might exist)
>
>- restlet get or post parameters should be automatically mapped to some
>kind of object
>- asycn communtication should be supported
>- restlet should have option to run as webapp on tomcat or jetty
>- Pl use jetty for standalone
>- its too complex !! too many new concepts , use KISS
>
> so i am writting my own trimmed down RESTLET framework using jetty
> continuations , I hope opensource when its done
>
> Best Regards,
>
> Code Dude
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1114157

feedback on restlet

[code dude]

Hi folks ,

I used restlet on one my projects which live since one year , i fond RESTLET
to be too complex and confusing also it lacks some features like (i maynot
be aware if features might exist)

   - restlet get or post parameters should be automatically mapped to some
   kind of object
   - asycn communtication should be supported
   - restlet should have option to run as webapp on tomcat or jetty
   - Pl use jetty for standalone
   - its too complex !! too many new concepts , use KISS

so i am writting my own trimmed down RESTLET framework using jetty
continuations , I hope opensource when its done

Best Regards,

Code Dude

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1114069

RE: DOM formatting

[Cliff Binstock]

I would concur.  The default should probably be false.  However, I still
think the feature is very useful:  there’s a lot to be said for having the
default return readable.

 

Also, I know I suggested ‘indent’, but it should probably be ‘auto-format’
or ‘pretty-print’ or some such:  ‘indent’ sounds like it should be a number
(e.g., indent 4 characters).

 

Cliff Binstock
Coyote Reporting

  _  

From: remidewi...@gmail.com [mailto:remidewi...@gmail.com] On Behalf Of Rémi
Dewitte
Sent: Friday, February 06, 2009 4:02 AM
To: discuss@restlet.tigris.org
Subject: Re: DOM formatting

 

Jérôme,

I have the feeling that defaulting it to true is not really the right thing
to do. I think you don't need very often to have the XML output in a
fashionable way and it will by default consume more resources for nothing.
Because most of the time xml is not meant to be consumed by humans (except
debugging).

Moreover, IE or FF are both able to display XML trees. 
If you use curl to test your XML Restlet, just do somthing like this : 
curl url | xmllint --format -
And you are done.

Rémi

On Fri, Feb 6, 2009 at 12:54, Jerome Louvel 
wrote:

Hi Cliff,

 

Good suggestion. I've just added this "indent" property to DomRepresentation
in SVN trunk. Its value is true by default.

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com

 


 

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoyé : vendredi 6 février 2009 00:40
À : discuss@restlet.tigris.org
Objet : RE: DOM formatting

Stephen,

 

Thanks … for the input … still seems like it should be more trivial [
DomRepresentation#setIndent(boolean), perhaps ]

 

Cliff Binstock
Coyote Reporting

  _  

From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] 
Sent: Thursday, February 05, 2009 1:41 PM
To: discuss@restlet.tigris.org
Subject: Re: DOM formatting

 

Hi,

Have you considered subclassing DomRepresentation and overriding its
createTransformer() method to set the output properties you want (in your
case, OutputKeys.INDENT to yes)?  I had a case where I had to modify some
properties of the XML being produced, and I found that the easiest way to do
it was to subclass the representation in this way.

On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock
 wrote:

The DOMRepresentation, writes out the DOM as-is.  Certainly this is great in
most cases.

 

However, it would be nice if there was "pretty-print" option that provided
easy-to-look at XML.  Of course, I can (and probably will) run the DOM
through my own transformation to pretty-print, but it seems like use case
might be a common desire.

My current use case is building a Document with Elements, but no Text nodes,
so the resultant XML is one unreadable line.

 

If there is an existing trivial way to do this, great.  If not, consider
this a feature request.

 

Thanks!

 

Cliff Binstock

Coyote Reporting

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1113782

RE: DOM formatting

[Jerome Louvel]

Hi Rémi,
 
That sounds like valid concerns. I've changed the default to 'false'.
 
Thx,
Jérôme

  _  

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : vendredi 6 février 2009 13:02
À : discuss@restlet.tigris.org
Objet : Re: DOM formatting


Jérôme,

I have the feeling that defaulting it to true is not really the right thing to 
do. I think you don't need very often to have the XML output in a fashionable 
way and it will by default consume more resources for nothing. Because most of 
the time xml is not meant to be consumed by humans (except debugging).

Moreover, IE or FF are both able to display XML trees. 
If you use curl to test your XML Restlet, just do somthing like this : 
curl url | xmllint --format -
And you are done.

Rémi


On Fri, Feb 6, 2009 at 12:54, Jerome Louvel  wrote:


Hi Cliff,
 
Good suggestion. I've just added this "indent" property to DomRepresentation in 
SVN trunk. Its value is true by default.
 


Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com
 

 
  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoyé : vendredi 6 février 2009 00:40
À : discuss@restlet.tigris.org
Objet : RE: DOM formatting



Stephen,

 

Thanks … for the input … still seems like it should be more trivial [ 
DomRepresentation#setIndent(boolean), perhaps ]

 

Cliff Binstock
Coyote Reporting


  _  


From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] 
Sent: Thursday, February 05, 2009 1:41 PM
To: discuss@restlet.tigris.org
Subject: Re: DOM formatting

 

Hi,

Have you considered subclassing DomRepresentation and overriding its 
createTransformer() method to set the output properties you want (in your case, 
OutputKeys.INDENT to yes)?  I had a case where I had to modify some properties 
of the XML being produced, and I found that the easiest way to do it was to 
subclass the representation in this way.

On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock 
 wrote:

The DOMRepresentation, writes out the DOM as-is.  Certainly this is great in 
most cases.

 

However, it would be nice if there was "pretty-print" option that provided 
easy-to-look at XML.  Of course, I can (and probably will) run the DOM through 
my own transformation to pretty-print, but it seems like use case might be a 
common desire.

My current use case is building a Document with Elements, but no Text nodes, so 
the resultant XML is one unreadable line.

 

If there is an existing trivial way to do this, great.  If not, consider this a 
feature request.

 

Thanks!

 

Cliff Binstock

Coyote Reporting

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1112274

Re: How to integrate jetty's ThrottlingFilter

[Tim Peierls]

Henry,
A few problems with this code:

   - Postdecrement of a volatile is not atomic.
   - Calls to "foreign" code in a synchronized block risks deadlock.
   - As you suspected, there is no guarantee that afterHandle will be called
   once for every call to beforeHandle.

Here's an untested, uncompiled version that addresses these problems:

import org.restlet.*;
import java.util.concurrent.Semaphore;

public class ThrottlingFilter extends Filter {

private final Semaphore permits;

public ThrottlingFilter(int maxRunningRequests) {
this.permits = new Semaphore(maxRunningRequests);
}

@Override protected int doHandle(Request request, Response response) {
if (!permits.tryAcquire()) {
response.setStatus(Status.SERVER_ERROR_SERVICE_UNAVAILABLE);
return Filter.STOP;
}
try {
return super.doHandle(request, response);
} finally {
permits.release();
}
}
}

--tim


On Thu, Feb 5, 2009 at 5:10 AM,  wrote:

> > Basically, you need to create an org.restlet.Filter subclass
> >that will contains some throttling configuration properties.
>
> Here's a first quick sketch (only limiting the amount of running requests):
> 
> It throws 503 status codes when too many requests are running at the same
> time.
>
> This only works, when after each and every request the filter's afterHandle
> is called. Is there any situation, where beforeHandle of a request is
> issued, but the afterHandle is skipped (except for the case where
> beforeHandle does not return CONTINUE, obviously)?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1108535

RE: Default Routes

[blackhole]

So it turns out WebLogic is adding "index.jsp" to my URIs, which of course 
routes to the "/{year}" Resource instead of default "/".  Thanks for the help!  
Now just have to figure out how to make WebLogic behave :)

> did you check that requets to "/" are without parameters. If it's a 
> webservice and you use a browser, it can add some default paremeter, which 
> makes router to go to Special Resource.
> I had a similar problem. check your log.
> 
> Regards,
> Ruben
> 
> 
> 
> 
> postmas...@tigris.org 
> 28/01/2009 22:52
> Por favor, responda a
> discuss 
> 
> 
> Para
> discuss@restlet.tigris.org
> cc
> 
> Asunto
> RE: Default Routes
> 
> 
> 
> 
> 
> 
> Sorry, had a typo in my original post.  I tried:
> 
> router.attach("/", DefaultResource.class);
> router.attach("/{year}", SpecialResource.class);
> 
> And all requests to "/" still go to the special resource.  This seems like 
> a pretty standard configuration so I'm not sure why it's behaving this 
> way.  Surely people use "/" all the time without problems, so am I 
> forgetting to set something else?  Here's my entire code for createRoot():
> 
> Router router = new Router(getContext());
> router.attach("/", DefaultResource.class);
> router.attach("/{year}", SpecialResource.class);
> return router;
> 
> Straight from the tutorial really.  Ive also tried setting the 
> defaultMatchingMode to BEST, FIRST, and LAST, and all have the same 
> behavior.
> 
> As for your suggestion with making param match alpha_num, is there a way 
> to do this with restlets or would I just supply a regex?  In the latter 
> case, how would the resource get the parameter since it's not named?
> 
> Thanks,
> 
> Mike
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1064629

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1108985

war:// performance

[blackhole]

Hello,

I was experimenting with loading resources from a servlet war today, using the 
war:// client in 1.2-M1:
router.attach("/", new Directory(getContext, "war:///"));

I noted that fetching a static resource took an exceptionally long time (curl 
http://localhost:8080/index.xhtml):
reslet + unexploded war: 0.7 seconds
reslet + exploded war: 0.15 seconds

I tested with both Tomcat and Jetty, and saw the same results. Profiling 
demonstrates that nearly all of the time is spent in ServletContext's 
getResourcePaths(), called from ServletWarEntity's constructor.

These results surprised me, so I thought I'd e-mail to ask -- is there 
something I'm doing wrong?

Thanks!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1110461

Re: DOM formatting

[Rémi Dewitte]

Jérôme,

I have the feeling that defaulting it to true is not really the right thing
to do. I think you don't need very often to have the XML output in a
fashionable way and it will by default consume more resources for nothing.
Because most of the time xml is not meant to be consumed by humans (except
debugging).

Moreover, IE or FF are both able to display XML trees.
If you use curl to test your XML Restlet, just do somthing like this :
curl url | xmllint --format -
And you are done.

Rémi

On Fri, Feb 6, 2009 at 12:54, Jerome Louvel wrote:

>  Hi Cliff,
>
> Good suggestion. I've just added this "indent" property to
> DomRepresentation in SVN trunk. Its value is true by default.
>
>  Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>  --
> *De :* Cliff Binstock [mailto:cliff.binst...@coyotereporting.com]
> *Envoyé :* vendredi 6 février 2009 00:40
> *À :* discuss@restlet.tigris.org
> *Objet :* RE: DOM formatting
>
>  Stephen,
>
>
>
> Thanks … for the input … still seems like it should be more trivial [
> DomRepresentation#setIndent(boolean), perhaps ]
>
>
>
> Cliff Binstock
> Coyote Reporting
>   --
>
> *From:* Stephen Groucutt [mailto:stephen.grouc...@gmail.com]
> *Sent:* Thursday, February 05, 2009 1:41 PM
> *To:* discuss@restlet.tigris.org
> *Subject:* Re: DOM formatting
>
>
>
> Hi,
>
> Have you considered subclassing DomRepresentation and overriding its
> createTransformer() method to set the output properties you want (in your
> case, OutputKeys.INDENT to yes)?  I had a case where I had to modify some
> properties of the XML being produced, and I found that the easiest way to do
> it was to subclass the representation in this way.
>
> On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock <
> cliff.binst...@coyotereporting.com> wrote:
>
> The DOMRepresentation, writes out the DOM as-is.  Certainly this is great
> in most cases.
>
>
>
> However, it would be nice if there was "pretty-print" option that provided
> easy-to-look at XML.  Of course, I can (and probably will) run the DOM
> through my own transformation to pretty-print, but it seems like use case
> might be a common desire.
>
> My current use case is building a Document with Elements, but no Text
> nodes, so the resultant XML is one unreadable line.
>
>
>
> If there is an existing trivial way to do this, great.  If not, consider
> this a feature request.
>
>
>
> Thanks!
>
>
>
> Cliff Binstock
>
> Coyote Reporting
>
>
>
>
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1112256

RE: DOM formatting

[Jerome Louvel]

Hi Cliff,
 
Good suggestion. I've just added this "indent" property to DomRepresentation in 
SVN trunk. Its value is true by default.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com
 

 
  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoye : vendredi 6 fevrier 2009 00:40
A : discuss@restlet.tigris.org
Objet : RE: DOM formatting



Stephen,

 

Thanks . for the input . still seems like it should be more trivial [ 
DomRepresentation#setIndent(boolean), perhaps ]

 

Cliff Binstock
Coyote Reporting

  _  

From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] 
Sent: Thursday, February 05, 2009 1:41 PM
To: discuss@restlet.tigris.org
Subject: Re: DOM formatting

 

Hi,

Have you considered subclassing DomRepresentation and overriding its 
createTransformer() method to set the output properties you
want (in your case, OutputKeys.INDENT to yes)?  I had a case where I had to 
modify some properties of the XML being produced, and I
found that the easiest way to do it was to subclass the representation in this 
way.

On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock 
 wrote:

The DOMRepresentation, writes out the DOM as-is.  Certainly this is great in 
most cases.

 

However, it would be nice if there was "pretty-print" option that provided 
easy-to-look at XML.  Of course, I can (and probably
will) run the DOM through my own transformation to pretty-print, but it seems 
like use case might be a common desire.

My current use case is building a Document with Elements, but no Text nodes, so 
the resultant XML is one unreadable line.

 

If there is an existing trivial way to do this, great.  If not, consider this a 
feature request.

 

Thanks!

 

Cliff Binstock

Coyote Reporting

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1112206

Mime type filtering.

[Dave Pawson]

Requirement:

I'm setting up a private service, using restlets under Tomcat.
No browser interaction, just a data endpoint for my own use (and to
learn a little more about restlets).

I want to do a GET, specifying that I can accept application/xml+atom
as a mime type.

At the server end; Unless this is specified (in the header I think -
my knowledge of http isn't very strong)
I want the server to reject the GET (error code 406 seems right). Even
if no mime type is specified,
I will still refuse the GET.



Jerome pointed me to  extension to MIME type mappings:
http://www.restlet.org/documentation/snapshot/api/org/restlet/service/MetadataService.html


Is this the best way to do this kind of filtering please?
Or use a Tomcat filter?


regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1112159