Re: How do I get the contents of POST variables?

2009-06-19 Thread Schley Andrew Kutz
I thought that the entity is what I should be looking at, thanks!

I know that they are different, but some frameworks already provide a  
single call to fetch the data, and I have found it useful in the past.

-- 
-a

Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein

On Jun 19, 2009, at 5:08 AM, Thierry Boileau wrote:

 Hello,

 if entity is the Representation sent via the POST request, you can
 parse it with a Form as follow:
 Form form = new Form(entity);

 If you want to get the cookies values, just call request#getCookies.

 For sure, there is a real distinction between the query part of an URI
 and the content of POSTed entity.
 The query is part of the identifier of the resource. An entity sent  
 via
 a POST is a set of data that the resource is asked to take into  
 account
 in order to act on its current state.
 It seems preferable keep this distinction.

 best regards,
 Thierry Boileau
 I can get GET variables via the getQueryAsForm method for a resource
 reference, but how do I get POST variables? Also, it would be nice to
 have a getVariable() method that returned a series comprised of GET,
 POST, and COOKIE keys and values.

 Thanks!



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

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


Premature EOF / Broken Pipe

2009-06-19 Thread Timothy Aanerud
Hi,
I'm having a communications problem between a client/server application both 
using Restlet 1.1.1 (and since upgraded to 1.1.5).  The client and server are 
both running on Fedora 10, OpenJDK-6 build 14.

The client posts a status resource message to the server to exchange status 
information at regular intervals.   The message send works most of the time.  
But, some times I'll get an exception on both the server and client side.  

The client side throws a Premature EOF IOException while trying to parse the 
response entity as Sax; while the server side sees an IOException with the 
message Broken Pipe.  (stack traces are attached using Restlet 1.1.1)

If the client sends the status resource message once every three minutes, I'll 
hardly ever get this exception pair.  If I send it every 10 seconds, the error 
rate is ~ 3%.  At 5 second intervals, the error rate is in the 25-50% range.

I was first seeing this error going over a wide area connection, but the error 
will occur on my local area network too.

I upgraded to Restlet-1.1.5 from 1.1.1 but that didn't help. :-(

Could HTTP caching be biting me here? The POST data doesn't change much from 
message to message.

I'm running out of ideas as to what to look at next for the cause of this 
problem.INFO: Starting the HTTP client
Jun 18, 2009 7:54:02 AM com.noelios.restlet.http.HttpClientCall 
getResponseEntity
INFO: The length of the message body is unknown. The entity must be handled 
carefully and consumed entirely in order to surely release the connection.
ERROR:  'Premature EOF'
javax.xml.transform.TransformerException: java.io.IOException: Premature EOF
at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:724)
at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317)
at 
org.restlet.resource.SaxRepresentation.parse(SaxRepresentation.java:189)
at 
com.atilabs.rtikiosk.server.StatusResponseHandler.init(StatusResponseHandler.java:24)
at 
com.atilabs.rtikiosk.server.StatusTransaction.parseResponse(StatusTransaction.java:48)
at com.atilabs.rtikiosk.server.Server$1.run(Server.java:122)
Caused by: java.io.IOException: Premature EOF
at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556)
at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600)
at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411)
at 
com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915)
at 
com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302)
at 
com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1719)
at 
com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipSpaces(XMLEntityScanner.java:1469)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$TrailingMiscDriver.next(XMLDocumentScannerImpl.java:1373)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:624)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:486)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:810)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:740)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:110)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208)
at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:641)
at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:712)
... 5 more
-
java.io.IOException: Premature EOF
at 
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556)
at 
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600)
at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at 
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411)
at 
com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915)
at 
com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302)
at 

RE: Premature EOF / Broken Pipe

2009-06-19 Thread Timothy Aanerud
As a test, I moved the client code to a Windows XP machine.  With a five second 
update rate it fails regularly too, with the same exceptions and stack traces.

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


RE: 2.0m3 and content negotiation

2009-06-19 Thread Jerome Louvel
Hi Bruno,

I was surprised to get your email so I've tried a similar test with SVN
trunk (no change in this area since 5104) and it works just fine. I never
get 406 because the conneg algorithm always try to fall-back on one of the
variants if it exists.

The test file uses is attached. 

Regarding annotation values, we can't unfortunately use constant class
instances, only primitive types and enumerations... 

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 : news [mailto:n...@ger.gmane.org] De la part de Bruno Harbulot
Envoyé : jeudi 18 juin 2009 14:37
À : discuss@restlet.tigris.org
Objet : Re: 2.0m3 and content negotiation

Hi Jerome,

I've just upgraded to revision 5104. (I've have looked in details at the 
changes in the code.)

I'm still not clear what should work with annotations. The simple 
test-case I'm using tries to do content-type negotiation between 
text/plain and application/xml.


public class TestResource extends ServerResource {
 @Override
 public void doInit() throws ResourceException {
 setNegotiated(true);
 }

 @Get(xml)
 public Representation toXml() {
 return new OutputRepresentation(MediaType.APPLICATION_XML) {
 /* ... */
 }
 }
}



Making a GET request with Accept: text/plain produces a 406 Not 
Acceptable (which makes sense).
However, I get the same error with Accept: text/xml, application/xml.
I do get a successful response (200 with the XML representation 
intended) with Accept: */* (however, there's nothing being negotiated 
since there's only @Get(xml) here).



I believe the problem comes from the fact that 
ServerResource.getAvailableVariants(...) assumes that 'Representation' 
implies the media type is going to be application/octet-stream.


This example works as intended when declaring the return type to be 
DomRepresentation instead of Representation:

public class TestResource extends ServerResource {
 @Override
 public void doInit() throws ResourceException {
 setNegotiated(true);
 }

 @Get(xml)
 public DomRepresentation toXml() {
 return /* some DomRepresentation */
 }
}


It seems a bit restrictive not to allow to use Representation and to 
expect a specific subclass (as there are more potential media types than 
subclasses of Representation).



Regarding the annotation parameters and media types, perhaps it would be 
useful to allow for both the extension and the actual media types, for 
example @Get(extension = txt) and @Get(mediatype = MediaType.TEXT_PLAIN).


Best wishes,

Bruno.


Jerome Louvel wrote:
 Hi Bruno,
 
 Thanks for looking into this part of the code base. 
 
 As said in other emails, many enhancements and refactorings were done
 recently on ServerResource, ConverterService and content negotiation. 
 
 Previously, annotation values weren't taken into account, leading to
strange
 results as you observed. They are now taken into account to result
 representation, only media types for now based on extensions declared in
 MetadataService.
 
 The ConverterService has been enhanced to allow better selection of
 ConverterHelpers via a scoring logic. Previously, a converter such as
 XStream could convert anything to representation and could prevent other
 (more specific) converters from being selected. I think that the target
 variant is now better taken into account by existing converters.
 
 Could you have another look at the code and let me know what you think of
 the changed recently made?  
 
 Best regards,
 Jerome Louvel
 --
 Restlet ~ Founder and Lead developer ~ http://www.restlet.org
 Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 


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

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

TestServerResource.java
Description: Binary data