Hi all, 1) I have changed the signature of getValue() to declare that it can throw IOExceptions. This prevents the silent eating of those exceptions.
2) I've also added a warning in the Javadocs discouraging the usage of this method as it can lead to OutOfMemoryErrors for large content. 3) Concerning the caching of the string value, I don't this this as a useful of practical solution. If you cache the string value, why not also cache the input stream to we can reuse it several times? Note that some types of representations (like StringRepresentation or FileRepresentation) can easily serve the same content (as a stream/string/channel) several times. For other types, there are two methods that allows you to know if the content eventually needs to be cached: isTransient() and isAvailable(). 4) Caching is an important requirement that we will address later, probably at a higher level (as a CacheFilter or CacheService?). There is a RFE for it already: http://restlet.tigris.org/issues/show_bug.cgi?id=25 Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : vendredi 3 novembre 2006 21:05 > À : discuss@restlet.tigris.org > Objet : Re: toString shouldn't change the object's state > > > > The problem with cache invalidation for muttable objects in a > > multithreaded environment isn't straightforward > > Why would two threads access the same request? > If it's the case, wouldn't we need to add proper > synchronization to the > getStream method anyway? > > public synchronized InputStream getStream() throws IOException > { > InputStream result = this.inputStream; > this.inputStream = null; > setAvailable(false); > return result; > } > > > -Vincent
