Spaces in Media Type Parameters?

2009-08-04 Thread Alex Milowski
I just ran across an issue with media type parameters on the Content-Type header
that have spaces.  I assumed that quoted values would be OK but I get an
exception from Restlet.

My assumption was I could send:

Content-Type: application/docbook+xml; version='my version 1.0'

but the space character inside the quoted parameter value
seems to be disallowed.

This is allowed:

Content-Type: application/docbook+xml; version='my%20version%201.0'


In addition, the system throws an exception and I get a 500 response.  I would
think there would be a more graceful way of handling such an error (e.g 400
Bad request).

--Alex Milowski

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


Re: Guidance on Atom/APP in Restlet

2009-08-04 Thread Alex Milowski
Sorry to jump in so late on this thread...

On Fri, Jul 17, 2009 at 11:32 AM, Tim Peierlst...@peierls.net wrote:
 Some rambling newbie Restlet design questions:
 Background: I'm in the preliminary stages of a ground-up redesign of an
 existing non-Restlet application. I'm (naturally) convinced that Restlet is
 the way to go for this redesign, and I'm pretty sure I want the UI to be
 GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get
 cracking on a Restlet-Guice extension before too long, or not, depending on
 how you define too.)
 My analysis of the existing application keeps leading me to the Atom
 Publishing Protocol, because the key elements of that application feel
 like collections of publishable/updatable resources (and collections of such
 collections). It doesn't fit the canonical examples of APP, however, which
 leads to my first questions: Does anyone know of APP being used successfully
 outside of the usual document/news item examples that everyone uses to
 explain it? If so, what criteria would you use to determine whether APP is
 really appropriate to my resource design?

I use the APP for all kinds of applications.  I use it as a basic storage
and retrieval mechanism.  Of course, I use a lot of advanced features
found inside Atomojo for querying feeds and that is most certainly
outside of the APP as a protocol.


 I'm sort of hoping the answer is a resounding yes to this, in which case my
 second question is: If I want to design my application around APP but I
 don't intend to use a file-based storage system like eXist, what does
 Atomojo have for me that the Restlet Atom extension doesn't? Is there
 something else that I should know about?

I think you are a bit confused about what Atomojo has to offer.  First of all,
there is a server that supports the APP and provides different storage
mechanisms.  There are currently two storage mechanisms: files and the
eXist XML database.  I've considered writing an Amazon S3 storage
back end but I haven't quite gotten to it yet.  Basically, storage is something
that you can change in the server.

The server itself maintains an index and supports different kinds of
metadata and query services independent of the storage used.  You can
use these services to build applications--which is what I do.

Atomojo also provides:

   * a Java client for interacting with the APP
   * a Javascript client for doing the same
   * a web server component that uses configures itself using
 atom feeds (a special wrap-up of Restlet)
   * some other application components for building
 web applications.

Much of this still needs documentation.  :(

--Alex Milowski

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


RE: A simple URI problem

2009-08-04 Thread TKM
duh.  thank you.  


webpost wrote:
 
 url-pattern/​myResource/*/url​-pattern
 
 router.attach(​/myResource/building​s, BuildingsResource.class); 
 
 That looks to me that you URL to buildings is http://localhost/
 myResource/myResource/building​s. With myResource part duplicated.
 
 /Filip
 
 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377470
 
 

-- 
View this message in context: 
http://n2.nabble.com/A-simple-URI-problem-tp3363341p3377346.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

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


RE: Re: JAX RS ExceptionMappers by MessageBodyWriter

2009-08-04 Thread Nicolas Rinaudo
Actually, come to think of it, what I'm talking about *should* be possible.

I just ran a test and if I throw any sort of exception in a writeTo method, the 
status code received by the client is a generic 500. RESTlet somehow manages to 
catch the error and deal with it (maybe it caches headers until the first byte 
of the response has been written?).

Since RESTlet appears to be capable of dealing with such errors, should it not 
also try to find a relevant ExceptionMapper before triggering a generic 500 
error?

I apologise if I'm talking rubbish here, maybe I'm missing something obvious.

Nicolas

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


Re: Server connector parameters ignored when configuring from Spring

2009-08-04 Thread Evgeny Shepelyuk
Hello again

Can anyone asnwer smth about my issue ?

 Hello,

 While developing my restlet application i faced following problem.
 Im using restlet 2.0m3 with Jetty server connector and configuring my
 server from Spring.
 This is snippet of XML file


   bean id=springComponent  
 class=org.restlet.ext.spring.SpringComponent
 init-method=start
   property name=clientsList
   list
   valuehttp/value
   /list
   /property
   property name=server
   bean class=org.restlet.ext.spring.SpringServer 
 id=springServer
   constructor-arg value=http 
 type=java.lang.String/
   constructor-arg value=4343 type=int/
   property name=parameters
   map
   entry key=acceptorThreads 
 value=20/
   entry key=acceptQueueSize 
 value=400/
   entry key=maxThreads 
 value=800/
   /map
   /property
   /bean
   /property
   property name=defaultTarget ref=springRouter/
   /bean


 The expected behaviour of passing the parameters to underlying jetty
 instance has not occurred.
 While debugging and researchign source code i found following in class
 JettyServerHelper
 method  public SeriesParameter getHelpedParameters() always returns
 empry parameters because method getHelped() returns null.

 Can anyone give me a hand and explain if this is a bug or i'm configuring
 server connector incorrectly ?





-- 
Regards,
Evgeny Shepelyuk

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


Encoding setup for compression

2009-08-04 Thread Johnson
hi,

I am using restlet 1.1.5 to practise compression, it contains some steps like:

1. client send a request to server and tells server what compression formats 
can be supported.
2. server accepts the request and check these compression forats such as gzip, 
then compress the representation ans send back to client.

my question is just that how server notify client what format has been used in 
the server side?

I can not find any functionality in response class.

Thanks and Regards,

Johnson

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


RE: Patch for JAX-RS extension on GAE

2009-08-04 Thread Jerome Louvel
Hi Martin,

Thanks again, your patch has been applied. It would be nice if you could
test it with the new edition packaging that is available for the 2.0
snapshots and soon for 2.0 M4.

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


-Message d'origine-
De : Martin Krasser [mailto:krass...@googlemail.com] 
Envoyé : dimanche 26 juillet 2009 07:29
À : discuss@restlet.tigris.org
Objet : Patch for JAX-RS extension on GAE

Hi,

first of all, I want to say that Restlet is a great framework. Really enjoy
working with it.

For issue 818

http://restlet.tigris.org/issues/show_bug.cgi?id=818

I attached a patch that gets the JAX-RS extension running on GAE. A
description of the patch was added as comment. It would be great if this
patch could make it into 2.0-M4.

Regards,
Martin

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

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


RE: Question about 'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)'

2009-08-04 Thread Jerome Louvel
Hi Marcelo,

Good point, I've just made this change in SVN trunk to catch all throwables.

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


-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : vendredi 24 juillet 2009 15:51
À : discuss@restlet.tigris.org
Objet : RE: Question about
'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)'

Hi Jerome,

[disclaimer]I haven't seen the changes you made to the code in
SVN.[/disclaimer]

That catch won't do the work because the throwable I am getting
(NoClassDefFoundError) is not an exception.

I wonder if it makes sense to replace the catch-Exception by a
catch-Throwable or, if you prefer to be less aggressive ;-), keep the
catch-Exception and add a catch-LinkageError.

Cheers,
Marcelo

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

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


Is Representation in acceptRepresentation == Request.getEntity() ?

2009-08-04 Thread Paul J. Lucas
If I am implementing:

public void acceptRepresentation( Representation rep ) {
// ...
}

Is using that rep exactly the same as if I had instead done:

Representation rep1 = getRequest().getEntity();

?  Is the rep being passed to acceptRepresentation() just a  
convenience?

- Paul

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


Re: Checking for Request Entity

2009-08-04 Thread Avi Flax
On Tue, Jul 28, 2009 at 05:34, webp...@tigris.org wrote:


 Dont know why getRequest().isEntit​yAvailable() returns true, however
 getRequest().getEntity().getMediaType() return null if the request entity is
 missing.


OK, thanks, that's helpful. I'd still like to understand the behavior
though. Can anyone help?

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