thats a valid question, if one would be building a truly restful service, there
should be need for a second parameter.
Most of my calls use one parameter, but I have one Put call, that updates the
Location of a Collection of Entities, that can not be broken of in seperate
calls.
@Put
public
Hi Jerome ,
You're welcome, it's an interesting discussion. Is interrupting the cleanest
way of doing this ? Wouldn't a blocking queue serve better in the context of a
producer/consumer scenario?
On 22 Jun 2012, at 00:31, Jerome Louvel jerome.lou...@restlet.com wrote:
Hi Yan, Ioannis,
This isn't currently supported in Restlet. You could make a feature request
if you could nail down the behavior precisely.
I don't see what's wrong with defining a type for a collection of entities
with a location. It's a resource in your application, so having a class to
represent it sounds like
Hi Ioannis,
Regarding the GC of iterators, I've fixed the one under our control in RF 2.1
and 2.2/master branches yesterday. The second one is inside the NIO selector
code so we can't remove it, which leads to the second solution anyway. I've
also started to implement the notification/wakeup
Hi Philipp,
Im on the same line as Tim on this point, the actual representation that
you will exchange will contain both entities and location, in the same
XML/JSON document. So it seems logical to me to have an equivalent
representation POJO that would contain both as well.
One area
Thank you, Jerome - exactly the root cause(s).
Issue #611 has now been created:
https://github.com/restlet/restlet-framework-java/issues/611
Thanks,
Yan Zhou
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2972653
6 matches
Mail list logo
