+1 and welcome!
Joerg
On 28.05.12 10:26, Thorsten Scherler wrote:
He is an ASF committer in Apache Droids and I think he would make a
great addition to our team. He contributes now on a regular base and
lately as well started to dig into many issues that are critical for the
c3 release.
+1
Joerg
On 19.09.2011 23:03, Nathaniel, Alfred wrote:
Hi all,
A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the
minimum Java version from 1.5 to 1.6.
There were a number of advantages identified to be gained by using Java6, which
I don't want to repeat here,
The
You can switch off caching per pipeline. There is a non-caching
pipeline. Please don't ask me for details though - too long ago :-)
Joerg
On 17.02.2011 14:42, Robby Pelssers wrote:
I would like to check out the performance without any caching and check if I
can live with it... if so it will
On 14.12.2009 09:33, Reinhard Pötz wrote:
On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinickejoerg.heini...@gmx.de wrote:
A long time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept (Midi,
HTML, Directory, JSP,
On 13.12.2009 14:58, Reinhard Pötz wrote:
I propose Simone Tripodi as a new Cocoon committer and PMC member.
+1
Joerg
On 13.12.2009 14:44, Reinhard Pötz wrote:
Long time ago (I think when the StAX module was added) we discussed to
have a SAXGenerator which is mainly useful when the pipeline API is
used. It has constructors for File, InputStream, String and Node. See
Oh, you're right :-) I only read your mail on the mailing list, not the
complete issue text.
Joerg
On 05.12.2009 11:04, Jos Snellings wrote:
That is what I did.
On Sat, 2009-12-05 at 09:50 +, Jörg Heinicke (JIRA) wrote:
[
On 14.05.2009 13:51, Christoph Leiter wrote:
Sebastian Rosensteiner wrote:
Sebastian here, one of the students working on cocoon-profiling. We
are about to build a suitable data structure for the profiling data,
and we are now facing the problem that a lot of data we store is
redundant. This
On 05.03.2009 00:33, Grzegorz Kossakowski wrote:
Now I'll give a few words of comments why I find my implementation easier to
follow.
First of all, sitemap processing is divided into a few distinct stages:
1. Sitemap parsing
2. Sitemap reduction
3. Sitemap invocation
3.1 Actions
Original Message
Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
Date: Fri, 23 Jan 2009 13:28:19 +
From: Tony Stevenson pct...@apache.org
Reply-To: commun...@apache.org
To: travel-assista...@apache.org
The Travel Assistance Committee is now
On 18.10.2008 14:25, [EMAIL PROTECTED] wrote:
[java] X [0] 2.1/prepare-mojo.html
BROKEN:
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
(Is a directory)
[java] ^
On 24.09.2008 00:00, Sylvain Wallez wrote:
Yeah. I read this as 3 months after release n+1 is out, release n
becomes closed source. I'm wondering how long it will take for forks to
appear that will provide open source bug fixes to old releases.
I don't think that's n+1 but n: After a new
On 24.09.2008 17:10, Antonio Gallardo wrote:
There is a worst case scenario now: What if they don't collect enough
money from subscriptions and do the next step: remove the 3 months
window or worse go full closed source?
Spring is released with Apache 2 license so we are free to grab and host
On 23.09.2008 13:39, Jeremy Quinn wrote:
I don't see any way of working around this.
What a shame, I guess this rules out putting this functionality into a
system-level sitemap.
That's actually by intention and used to be different. It was Leszek who
changed it [1]. One very good reason
On 23.09.2008 22:43, Peter Hunsberger wrote:
As the number of versions of Spring used in production grows, it is
impossible for us to provide free maintenance for multiple releases
and perform backports of issues. Doing so would unfairly subsidize
conservative customers who want to remain on a
On 22.09.2008 17:12, Jeremy Quinn wrote:
However, it seems I am unable to retrieve a continuation made in one
sitemap, from another sitemap.
Can anyone confirm this?
As far as I remember the continuations are managed per sitemap. You
might have a look at
Benjamin Boksa mailinglists at boksa.de writes:
Hi,
today I ran into a NPE when using ApplicationUtil.isUserInRole(…),
attached is a patch that allows the User instance passed to
isUserInRole(…) to be null.
Hope it is OK to submit a patch like that - if there is a better way
to do
Hey guys,
I'm considering to go to New Orleans. I justed wanted to ask who is
planning to go as well and if anybody wants to share a room.
Cheers,
Joerg
On 03.09.2008 23:37, Joerg Heinicke wrote:
just discovered an exception inside our freshly migrated cocoon 2.2
migration, thrown by the ContinuationManagerImpl:
Exception in thread Timer-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown
On 03.09.2008 21:25, Gabriel Gruber wrote:
just discovered an exception inside our freshly migrated cocoon 2.2
migration, thrown by the ContinuationManagerImpl:
Exception in thread Timer-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown
On 03.09.2008 23:37, Joerg Heinicke wrote:
Exception in thread Timer-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$ValueIterator.next(Unknown Source
On 29.08.2008 07:45, Reinhard Pötz wrote:
URL: http://svn.apache.org/viewvc?rev=689749view=rev
Log:
improve error reporting: print the full stacktrace when the loglevel
is set to INFO or below. Otherwise only print the first 5 lines.
Shouldn't these kind of things be left to the logging
On 28.08.2008 09:47, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Thu Aug 28 00:47:42 2008
New Revision: 689749
URL: http://svn.apache.org/viewvc?rev=689749view=rev
Log:
improve error reporting: print the full stacktrace when the loglevel is set to
INFO or below. Otherwise only print the
Reinhard Pötz reinhard at apache.org writes:
XML NAMESPACES
---
Since I don't see how version numbers could help, I propose
Don't these version numbers just help in the same way as versioned jars
help? It's possible to signal additional functionality or
Hi Richard,
It's actually not possible by design. Matchers, selectors and actions
are evaluated in the pipeline setup phase to find the pipeline
components. Only when the setup is finished the pipeline is executed and
the SAX events sent through the pipeline. That's why you don't have
access
On 21.08.2008 23:53, Reinhard Pötz wrote:
After having already discussed the details, let's make a formal decision
about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
+1 to everything except ...
XML NAMESPACES
---
Corona currently uses
Reinhard Pötz reinhard at apache.org writes:
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
+1
Joerg
Grzegorz Kossakowski grek at tuffmail.com writes:
switching to Java 1.5 as minimal required version
+1
Joerg
Grzegorz Kossakowski grek at tuffmail.com writes:
I would like to propose David Legg as a new Cocoon committer and PMC Member.
+1
Joerg
Torsten Curdt tcurdt at apache.org writes:
I think Corona is a great name. Everyone uses it. People already know
it by now. Let's officially call it Apache Cocoon (Project) Corona.
Everyone will call it Corona anyway. Will that really be a problem?
(Sorry if I missed that thread/post)
Jeremy Quinn jeremy at apache.org writes:
Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor
(the baseclass for all Number Formatting convertors), uses
java.text.DecimalFormat internally, without exposing the class to the
outside (except for one protected Method).
You need to retrieve a component from the ServiceManager, just
instantiating doesn't work.
Joerg
On 21.07.2008 22:59, Gary Larsen wrote:
I'm sorry for my impatient developer posting.
Still not grasping Avalon and Excalibur stuff in 2.1, but it would seem like
it's possible to create a class
On 20.07.2008 14:17, Reinhard Pötz wrote:
First we should define the mission of this subproject.
Corona has two main goals:
1. Become the best platform for RESTful services and
RESTful web applications based on the concept
of pipelines.
2. Provide a generic pipeline Java API with
Torsten Curdt tcurdt at apache.org writes:
The question if those configuration are needed in a generic form in
the API. (I doubt it) As I would expect them to be implementation
specific a configuration callback that sets up the pipeline might be a
way around this?
I guess we are on the
Carsten Ziegeler cziegeler at apache.org writes:
c) Pre and post processing
As the pipeline interfaces are not tied to sax or any other model
(which is ok), there is no explicit notion of indicating that the
processing starts or is finished - the latter is especially
interesting for
On 14.06.2008 09:06, Kamal wrote:
Something I have noticed about the Cocoon documentation is that the
terms pipeline seems to be used to describe a map:match. For example:
Sets the generator for the pipeline.[1]
We know what is meant, but this could be very confusing for a newbie.
Should we
That's why I just wrapped the stuff in comments rather than taking it
out completely :)
Joerg
On 12.06.2008 02:51, Ralph Goers wrote:
Until we need to take advantage of some Java 1.5 feature ;-)
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=666946view=rev
Log:
With minimum
On 11.06.2008 09:17, Andreas Hartmann wrote:
Removed:
cocoon/branches/BRANCH_2_1_X/src/jdk1.3/
cocoon/branches/BRANCH_2_1_X/src/jdk1.4/
now the build fails for me due to the missing directories
(compile-build.xml):
!-- compiles the core --
target name=compile-core
On 09.06.2008 22:40, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Jun 9 19:40:16 2008
New Revision: 665954
URL: http://svn.apache.org/viewvc?rev=665954view=rev
Log:
as a follow-up of COCOON-2168 (http://marc.info/?t=12089986853r=1w=4):
Cocoon's pipeline buffer increases from an
Moving this discussion from users list (for reference [1]) to dev list.
On 06.06.2008 19:02, Alfred Nathaniel wrote:
Warning: I'm stating my own opinion here, nothing official or something like
that.
There are at least three problems with XSP:
1. No active committer is interested in XSP
On 07.06.2008 03:13, Andy Stevens wrote:
Out of interest, have you raised an enhancement request and/or a patch
with the OpenJDK project[1]? It seems to me this increasing buffer
behaviour would be useful more generally...
Done.
Joerg
On 06.06.2008 12:51, Grzegorz Kossakowski wrote:
E.g. if two threads share the same (inherited) instance of ObjectModel
all nasty side-effects of multi-threading should be expected like
parallel modification and loosing of data consistency kept in OM.
How Cocoon used to solve these kind of
InheritableThreadLocal [1] might be one solution. But being not able to
clean up a thread is always a problem in web environment. IIRC Spring
used to use InheritableThreadLocal in RequestContextListener, but they
changed it to standard ThreadLocal for that reason.
I don't know if
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.
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
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.
Joerg
On 29.05.2008 00:06, Joerg Heinicke 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
On 28.05.2008 02:05, Carsten Ziegeler wrote:
I think it's really time now to get 2.1.12 out of the door.
As I'm not involved in Cocoon anymore I would like to step down as the
release manager; imho it makes more sense if someone still working
on/with Cocoon does this job :)
It's really easy,
On 09.05.2008 09:41, Peter Hunsberger wrote:
I think this is rather hard to do. The place where we instantiate the
BufferedOutputStreams (both java.io and o.a.c.util) is
AbstractEnvironment.getOutputStream(int bufferSize). So in order to pass a
second buffer size argument to the
On 08.05.2008 05:39, Lally Singh wrote:
What missing Java sources? They are in
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/src.jar
Hmm, not for me. Directory exists, but no src.jar inside. So where to get
it from?
Came preinstalled on my mac. Did you install the dev
On 08.05.2008 11:53, Bruce Atherton wrote:
My only comment is that I think it would be good to allow the initial
buffer size to be configurable. If you know the bulk of your responses
are greater than 32K, then performing the ramp-up from 8K every time
would be a waste of resources. For
On 08.05.2008 12:16, Antonio Gallardo wrote:
One question, what are supposed to be the default values for both
parameters?
For the initial buffer size I thought of 8K, maybe 16K. It should be a
reasonable size that's not overly large (i.e. unnecessarily reserved
memory) for most of the
On 27.04.2008 23:43, Joerg Heinicke wrote:
2. Does the full amount of the buffer automatically get allocated for
each request, or does it grow gradually based on the xml stream size?
I have a lot of steps in the pipeline, so I am worried about the
impact of creating too many buffers even
On 30.03.2008 02:50, Joerg Heinicke wrote:
Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374
URL: http://svn.apache.org/viewvc?rev=629374view=rev
Log:
Faster implementation.
Saw this one only now ... I'm a bit concerned about the approach.
First, do you really think
On 04.04.2008 11:33, Sylvain Wallez wrote:
With Mac OS X I also have no access to the source code of the JDK.
Which makes me wonder again how to do serious Java development with
Mac OS X. I know a few of you guys are using Mac OS X. How do you do it?
Er... without any problem, and I
On 24.04.2008 16:08, Bruce Atherton wrote:
Thanks for the response. About setting the buffer size, this looks like
it could be what I am looking for. A few questions:
1. Do I have to set the buffer size on each transformer and the
serializer as well as the generator? What about setting it on
On 20.04.2008 02:56, Continuum VMBuild Server wrote:
[INFO] Building Cocoon: JNet
[INFO]task-segment: [clean, install]
[INFO]
On 17.04.2008 19:57, [EMAIL PROTECTED] wrote:
Author: anathaniel
Date: Thu Apr 17 16:57:56 2008
New Revision: 649333
URL: http://svn.apache.org/viewvc?rev=649333view=rev
Log:
Fix compile errors
Modified:
On 18.04.2008 11:36, Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: joerg
Date: Wed Apr 16 20:32:57 2008
New Revision: 648942
URL: http://svn.apache.org/viewvc?rev=648942view=rev
Log:
fix inconsistencies between inline parts and file parts when multiple
fields of the same name
On 15.04.2008 12:23, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Tue Apr 15 09:23:00 2008
New Revision: 648313
URL: http://svn.apache.org/viewvc?rev=648313view=rev
Log:
mv subprojects into trunk
Added:
cocoon/trunk/subprojects/
- copied from r648312, cocoon/subprojects/
Removed:
On 15.04.2008 03:40, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Tue Apr 15 00:40:21 2008
New Revision: 648145
URL: http://svn.apache.org/viewvc?rev=648145view=rev
Log:
lazy initialization
(... have to figure out why an advice around the init() method on servlets
doesn't work as expected)
On 16.04.2008 08:35, Reinhard Poetz wrote:
URL: http://svn.apache.org/viewvc?rev=648313view=rev
Log:
mv subprojects into trunk
Is there a reason for that? When I want to check out Cocoon trunk I
don't want to have all the subprojects of it, do I?
My first idea was to move our subprojects
On 16.04.2008 10:11, Jerry DuVal wrote:
Is this a bug?
Feature :) More an inconsistency than an actual bug. I for myself would
not rely on the correct order of both All.primaryKey and All.foo.
When a MultipartHttpServletRequest parses the values using MultipartParser
it puts the Inline
On 03.04.2008 15:06, Grzegorz Kossakowski wrote:
COCOON BLOCKS
- cocoon-template-impl-1.1.0.jar*
- cocoon-forms-impl-1.1.0.jar*
[*] The 1.0.0 releases are still missing but provided for a version
that hasn't
been mirgrated to Spring. These
On 02.04.2008 11:36, Reinhard Poetz wrote:
I've prepared the artifacts for the release of Cocoon 2.2 final.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
+1 Unfortunately without testing. I planned
On 03.04.2008 23:33, Jörg Heinicke (JIRA) wrote:
With Mac OS X I also have no access to the source code of the JDK.
Which makes me wonder again how to do serious Java development with Mac
OS X. I know a few of you guys are using Mac OS X. How do you do it?
Whenever I start this I get
On 01.04.2008 02:21, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Mar 31 23:21:53 2008
New Revision: 643295
URL: http://svn.apache.org/viewvc?rev=643295view=rev
Log:
Fix synchronization issues in ContinuationsManager implementation.
Refactored version for 2.2 will follow this week ...
On 01.04.2008 08:02, Vadim Gritsenko wrote:
fix threading issue (DateFormat is not thread-safe)
public String getLastAccessTime() {
-return formatter.format(new Date(wc.getLastAccessTime()));
+synchronized (this.formatter) {
+return formatter.format(new
On 20.02.2008 01:42, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374
URL: http://svn.apache.org/viewvc?rev=629374view=rev
Log:
Faster implementation.
Saw this one only now ... I'm a bit concerned about the approach.
First, do you really think
On 28.03.2008 04:55, Torsten Curdt wrote:
The output I showed pointed to
org.apache.cocoon.components.flow.java.Continuation which only seems
to exist in Cocoon 2.1. Nothing unsets the context there.
Hah - well spotted!
Having a look into the code continuations are only handled by
On 30.03.2008 07:35, Torsten Curdt wrote:
There is no need to really obtain that value from the parent. If
handleContinuation would have also the function parameter it could use
the same initialization as in callFuntion.
Yes, if the function name would have been available ... This was beyond
On 30.03.2008 20:08, Jörg Heinicke (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-2109:
--
Affects version (Component): Parent values:
On 30.03.2008 22:19, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Sun Mar 30 19:19:41 2008
New Revision: 642855
URL: http://svn.apache.org/viewvc?rev=642855view=rev
Log:
fix synchronization
Can you please review this [1]? It's too easy to mess this up ... I hope
I did not introduce any
On 27.03.2008 02:25, Steven Dolg wrote:
What I want to see is a concise pipeline API that comes with only
little overhead in terms of its learning curve and its dependencies
on third-party software. Usually this means that we stick with
standard APIs as much as possible - and I think this
On 27.03.2008 04:39, Torsten Curdt wrote:
Sure, here is the hierarchy from bottom to top. At this point, I ran
the test for about five
minutes (running longer would increase the percentage) and the
retained size of the one
ContinuationsManagerImpl object is 58% of the total. The
Torsten Curdt tcurdt at apache.org writes:
Just have a look at the quote from the original. It gives the object
relationships in the memory. BufferedOutputStream takes 50% and is
hold in HttpEnvironment which is hold in TreeProcessorRedirector
which is hold in ContinuationContext. I
On 27.03.2008 10:33, Torsten Curdt wrote:
Just have a look at the quote from the original. It gives the object
relationships in the memory. BufferedOutputStream takes 50% and is
hold in HttpEnvironment which is hold in TreeProcessorRedirector
which is hold in ContinuationContext. I wondered why
On 26.03.2008 03:34, Reinhard Poetz wrote:
I never had the need to implement a Source and for the mentioned
simple cases I wonder where you have to cope with them at all? Cocoon
used to be a framework for non-Java developers ... even if we
introduce a pipeline API as in the examples in this
On 26.03.2008 08:04, Carsten Ziegeler wrote:
What's the advantage of giving our components the responsibility to
deal with strings that represent sources?
Isn't that what components are there for? Encapsulating commonly used
functionality? Why should I extract that to the pipeline *instance*
On 26.03.2008 09:08, Carsten Ziegeler wrote:
and want to add caching to it and therefore have to switch from URL to
Source and from FileGenerator to CachingFileGenerator - sorry, but
that's a mess since this means pretty much rewriting the application
for adding caching. Why is this page so
On 26.03.2008 09:14, Reinhard Poetz wrote:
What I want to see is a concise pipeline API that comes with only little
overhead in terms of its learning curve and its dependencies on
third-party software. Usually this means that we stick with standard
APIs as much as possible - and I think this
On 23.03.2008 06:47, FreddyFlint wrote:
Am new to cocoon and think have managed to install it correctly and
everything but get the following error when I start tomcat
Hey Freddy,
it seems you have a problem with your classpath. If you look at the
following lines
root cause
On 18.03.2008 03:07, footh wrote:
Sure, here is the hierarchy from bottom to top. At this point, I ran the test
for about five
minutes (running longer would increase the percentage) and the retained size of
the one
ContinuationsManagerImpl object is 58% of the total. The
On 25.03.2008 10:53, Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest form,
I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use cases of a pipeline
On 18.03.2008 03:46, Luca Morandini wrote:
I beg to differ: disable your javascript, go to
http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no
Javascript there (at least for the widget types we used).
With JavaScript *enabled* I'm stuck at the front page saying Tutela del
On 18.03.2008 08:15, Luca Morandini wrote:
I beg to differ: disable your javascript, go to
http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see
no Javascript there (at least for the widget types we used).
With JavaScript *enabled* I'm stuck at the front page saying Tutela
del
On 13.03.2008 16:20, Luca Morandini wrote:
This means that Forms must depend on Ajax (Dojo to be more precise)
despite the fact you use Ajax or not.
This is not quite true I think. Forms used to have two different
stylesheets: forms-field-styling.xsl and
forms-advanced-field-styling.xsl.
On 12.03.2008 13:17, Grzegorz Kossakowski wrote:
@Rice: No, this is not a good fix because response must be always
discarded no matter if it's been already comitted or not.
Why do you think so? Why do you want to discard a response which I
carefully crafted in my application? And what would
On 11.03.2008 08:54, Carsten Ziegeler wrote:
We could argue about another default value than -1 though.
Something like 1024^2.
Hmm, not sure if we should change the default value. The idea of this
default was to be sure that error handling works out of the box. If
you have special cases
On 11.03.2008 04:48, Carsten Ziegeler wrote:
We could argue about another default value than -1 though. Something
like 1024^2.
What do others think? Shall we change the default value from buffer
everything (which lead to the OutOfMemoryError [1]) to something more
secure in the sense of
Has something changed with Rhino?
http://cocoon.zones.apache.org/demos/trunk/samples/forms/form1.flow
java.lang.RuntimeException: NOT SUPPORTED
at org.mozilla.javascript.Context.compileImpl(Context.java:2353)
at org.mozilla.javascript.Context.compileReader(Context.java:1310)
at
On 05.03.2008 23:06, Joerg Heinicke wrote:
From what I see from the code (AbstractProcessingPipeline) it is
possible to configure and setup/parameterize a pipeline with
outputBufferSize. This means on both map:pipe and map:pipeline it
should be possible to set an actual buffer size. Only
On 08.03.2008 15:34, Felix Knecht wrote:
ATM we are always talking about Buffered... I'm believe this has to do
with caching the pipelines, right?
So I wonder really why my the issue also occurs in noncaching pipelines?
No, it has to do with the capability of resetting the OutputStream to
On 08.03.2008 15:28, Felix Knecht wrote:
Felix, have you tried outputBufferSize?
Not yet. I didn't even knew how to configure it :-(
Both map:pipe and map:pipeline should work as mentioned here:
http://marc.info/?l=xml-cocoon-devm=120477640924395w=4
Joerg
On 07.03.2008 17:41, Grzegorz Kossakowski wrote:
Yep... But can we start to think about pushing minimal version require for
working with Cocoon? I
know that 2.0.9 is not released yet but it looks like Maven folks are planning
the release already.
I'm very motivated to remove all these crap
On 05.03.2008 23:06, Joerg Heinicke wrote:
We could argue about another default value than -1 though. Something
like 1024^2.
What do others think? Shall we change the default value from buffer
everything (which lead to the OutOfMemoryError [1]) to something more
secure in the sense
On 05.03.2008 11:19, Felix Knecht wrote:
We are encountering this same problem in Cocoon 2.1.11. What is the
status of this issue? Is there a fix for it? It doesn't seem to
exist in Cocoon 2.0.4.
Obviously net yet, otherwise you could see it in the issue tracker.
Maybe
When looking at the history of ResourceReader I also noticed something else:
In rev 155087 [1] Vadim did the following change:
Move response header initialization into the setup phase.
Remove Last-Modified header initialization: this is done in
the environment by request from
Eventually ...
Joerg
Original Message
Subject: [jira] Closed: (MNG-2339) ${project.*} are interpreted in the
wrong place
Date: Wed, 27 Feb 2008 18:56:28 -0600 (CST)
[http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
On 20.02.2008 12:47, Reinhard Poetz wrote:
mvn cocoon:load jetty:run
after reading all the mails again, here are my two favorits:
mvn cocoon:load jetty:run
mvn cocoon:prepare jetty:run
Considering your explanation [1] I slightly prefer cocoon:prepare.
Joerg
[1]
1 - 100 of 1622 matches
Mail list logo
