I'm not sure if this will help you, but in case of a PUT, you already
know the url, issuing a GET to the same url
should (by your implementation) return the same entity body you
presented in the PUT. If you want to retrieve a 'more informative'
representation (i.e. including the 'internal' id),
Hi Jean-Philippe,
Technically speaking, to return a representation from a PUT/POST you can just
access to the response's entity from the
store/acceptRepresentation method:
getResponse().setEntity(myEntity);
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~
Hi Cliff,
It seems like doing what you propose would overlap with the normal content
negotiation which should be driven by client preferences.
If you want to return the same representation as both application/xhtml+xml
and text/xml, if can simply declare the two variants and return the same
Hello,
I created the Directory in that way and it worked, but when I start my server
whows an error whith the first file:
GRAVE: The informa.rest.spring.resources.SpringDirectory class has no Restlet
defined to process calls. Maybe it wasn't properly started.
And it doesn't serve the file
Hello,
I created the Directory in that way and it worked, but when I start my server
whows an error whith the first file:
GRAVE: The informa.rest.spring.resources.SpringDirectory class has no Restlet
defined to process calls. Maybe it wasn't properly started.
And it doesn't serve the file
Hi Chris,
Bruno Harbulot wrote:
Hi Chris,
christian.hai...@gmail.com wrote:
I use Restlet Version 1.1
I tried it this way:
Client client = new Client(new Context(), Protocol.HTTPS);
Context con = client.getContext();
SeriesParameter param1 = con.getParameters();
Hi Taylor,
I agree with you that this is an important core feature. What about if I tell
you that I have just committed the support for represent*() methods in SVN
trunk? :)
Here is the new paragraph in the Javadocs:
In addition, there is a simpler way to declare your variants and return
To illustrate the new feature, here is the test resource class that I used in
the unit test:
public class AutoDetectResource extends Resource {
public Representation representXml() {
return new StringRepresentation(roottest/root,
MediaType.TEXT_XML);
}
public Representation
today I want to try some new feature in snapshot, but the my Nexus server does
not pull Restlet 1.2 snapshot correctly.
I took a look at the repository,
http://maven.restlet.org/org/restlet/org.restlet/1.2-SNAPSHOT/
it shows
org.restlet-1.2-20090114.060036-4121.jar
today I want to try some new feature in snapshot, but the my Nexus server does
not pull Restlet 1.2 snapshot correctly.
I took a look at the repository,
http://maven.restlet.org/org/restlet/org.restlet/1.2-SNAPSHOT/
it shows
org.restlet-1.2-20090114.060036-4121.jar
Hi Daniel,
well, we were warned by users of Buckminster that our snapshot file
names (it was org.restlet-1.2-SNAPSHOT.jar ) were not correct and must
include a time stamp plus an incremental number...
So we updated it...
Now, we understand that each repository must support several versions of
Hi Raif,
Thanks! Your patch has been applied in SVN trunk. I just need to fix the Spring
config file now.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De :
Hi Rhett,
Thanks for the pointer. Actually I wanted to reuse a static Java member, so I
relied on the FieldRetrievingFactoryBean class:
bean id=server class=org.restlet.ext.spring.SpringServer
constructor-arg value=http /
constructor-arg
I tried to test your snapshot but I got some maven issues (can not
automatically download snapshots by Nexus proxy because the file name is not in
xxx-1.2-SNAPSHOT, have to download/copy/rename a bunch of files to my local
repo). After one hour fight with maven dependency and class not found
Hi Paul,
There is no plan yet for such a feature. We do support this extensively over
the Restlet API however. Feel free to enter a RFE for
this in our bug tracker.
JAX-RS 1.0 support has been pretty complete. Zillions of unit tests were
written and should ensure a stable behavior.
Here is
Hi Ruben,
It must be an issue with your component, here is a sample that works:
import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Directory;
import org.restlet.Restlet;
import org.restlet.data.Protocol;
public class SpringDirectory extends Application {
Patch submitted ! :)
Rémi
On Wed, Jan 14, 2009 at 21:31, Jerome Louvel jerome.lou...@noelios.comwrote:
Hi Rémi,
This remark has been made in the past and we have a RFE for this pending:
Add Request#getForwardedAddresses() method
http://restlet.tigris.org/issues/show_bug.cgi?id=668
If
While this is undeniably convenient, it deserves more thought and discussion
before accepting as part of 1.2. I don't think it's a good idea as it
stands.
Item 35 of Josh Bloch's Effective Java (2nd edition) is Prefer annotations
to naming patterns. One of the great strengths of Java is its
Jerome,
I am using the standard content negotiation, and am declaring multiple
variants. The issue is that I have LOTS of variants (HTML, XML, Excel
spreadsheets, and more), and sometimes the variant I return might have NOTHING
to do with the content list requested (Excel, for example, is
19 matches
Mail list logo
