Re: [VOTE][result]Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Thanks for the feedback guys. I will make a notice on the website as well as in the status.xml. Regards, Jeroen Vadim Gritsenko wrote: On Jun 2, 2008, at 5:19 PM, Grzegorz Kossakowski wrote: Jeroen Reijn pisze: Hi all, the vote for dropping JDK 1.3 support for Cocoon 2.1.11+ has been accepted by 12 +1 votes and no negative one. I'm going to move the artifacts into the Apache Maven Maven 1 synch repository in the next couple of days and will send a response to this mailinglist as a confirmation when it has been done. Jeroen, what about announcing this decision? It should (i'd say must) be noted in change log (status.xml). I think result of this vote deserves at least a news item on our front page. That is IMHO not really needed but won't hurt at all, so please add if you want to :) Vadim
Upgrade Cocoon 2.1 to ehcache 1.3
Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. Any objections? Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: BufferedOutputStream
Joerg Heinicke wrote:
Reinhard Pötz reinhard at apache.org writes:
Is my understanding right that the content length header can only be set
as long as you haven't written into the underlying output stream?
Yes, it is. That's why the buffering has to be big enough, i.e. nothing must
have been flushed yet.
What happens when the buffer size is exceeded? Does it mean that the
output is streamed and the content length parameter can't be set?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: BufferedOutputStream
Joerg Heinicke wrote: On 02.06.2008 05:56, Sylvain Wallez wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? For being able to reset the response buffer for error handling. This is also possible with java.io.BufferedOutputStream, if the buffer size is big enough (current default value is 1MB), but then the buffer byte[] is always that big rather than increasing. That's what's happening right now, if you don't specify -1 as buffer size. -1 means complete buffering which on the other hand might lead to OutOfMemoryError [1]. In addition our BOS counts the bytes so that we can use the value to set the content length header. Got it. I'm using a similar technique with a servlet filter providing the response with a ByteArrayOutputStream that gives the size and has the convenient writeTo(OutputStream) method. Now in my case [1] pages are always small and I don't need to put a high limit on the size of the buffer. Sylvain [1] http://bluxte.net/blog/2008-04/29-54-29.html -- Sylvain Wallez - http://bluxte.net
Re: Upgrade Cocoon 2.1 to ehcache 1.3
On Tue, Jun 3, 2008 at 5:00 AM, Andrew Savory [EMAIL PROTECTED] wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. +1 (Please, please) -- Peter Hunsberger
Re: Upgrade Cocoon 2.1 to ehcache 1.3
Andrew Savory wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. +1 from here also. Alec
Re: Upgrade Cocoon 2.1 to ehcache 1.3
Andrew Savory wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. On second thoughts, why not just upgrade to the most recent version. ;-) Alec
Re: Upgrade Cocoon 2.1 to ehcache 1.3
Andrew Savory wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. Any objections? No please do! It sounds like a good improvement! Regards, Jeroen
Re: Upgrade Cocoon 2.1 to ehcache 1.3
Alec Bickerton escribió: Andrew Savory wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. On second thoughts, why not just upgrade to the most recent version. ;-) +1 == 21 February 2008: ehcache-1.4.1 maintenance release BTW, there are also other jars, that might be a worth to update too. Out of hand I recall an issue with the icu.jar. Also eclipse compiler should be updated, etc. :) Best Regards, Antonio Gallardo.
Re: BufferedOutputStream
Reinhard Pötz reinhard at apache.org writes: Is my understanding right that the content length header can only be set as long as you haven't written into the underlying output stream? Yes, it is. That's why the buffering has to be big enough, i.e. nothing must have been flushed yet. What happens when the buffer size is exceeded? Does it mean that the output is streamed and the content length parameter can't be set? If the buffer size is exceeded the output stream is flushed and eventually written to the response. A header like the content-length can no longer be set. That's why Cocoon's BufferedOutputStream was setup to buffer all and everything by default which lead to COCOON-2168 [1] with Cocoon's default setting. With the change to a buffer of 1 MB rather than endless buffering we switched back to java.io.BufferedOutputStream, but this allocates the memory for the buffer immediately. So even with 10 KB pages you always end up with 1 MB byte[]. I intend to fix this in our BufferedOutputStream with an increasing buffer and the two configuration parameters initial buffer size and flush buffer size. Just to make it clear: We talk about default configuration of Cocoon here. You still can enforce complete buffering by setting flush buffer size to -1 again. But it's up to the user to enforce this and potentially run into OOME. It's also up to the users to find a reasonable flush buffer size as it always used to be when they haven't used the endless buffering. Only thing that is going to change is in case of not endless buffering: The full buffer is not allocated immediately but step by step. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
