Hello!
I am not sure what has been done about this so far, but we are still
experiencing some not-so-great behavior from the CachingPipeline:
We have some pipelines which take a long time to complete processing, like
generating a homepage from many different sources. We see that if a second
Hello,
About http://issues.apache.org/jira/browse/COCOON-1715
What is the best way to deal with this? Add servlet.jar in
the Loader's classpath when running the CLI? Or remove the
continuations-manager from cocoon.xconf by creating a new optional
flow block?
Your feedback will
* Max Pfingsthorn:
We see that if a second request for exactly the same pipeline
comes in before the first request is done, it takes again as
long because the first pipeline did not put its result in the
cache yet and it is recomputed.
Same here.
First I thought putting an empty
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on getting
the dependencies through the service manager in the program code. But
OSGi declarative services support declarative component
Jean-Baptiste Quenot wrote:
Hello,
About http://issues.apache.org/jira/browse/COCOON-1715
What is the best way to deal with this? Add servlet.jar in
the Loader's classpath when running the CLI? Or remove the
continuations-manager from cocoon.xconf by creating a new
[
http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12365255
]
Jean-Baptiste Quenot commented on COCOON-1681:
--
Apparently, what is causing the two isValid() invocations is that you use
map:aggregate along with a cocoon:
Max Pfingsthorn wrote:
Hello!
I am not sure what has been done about this so far, but we are still
experiencing some not-so-great behavior from the CachingPipeline:
We have some pipelines which take a long time to complete processing, like
generating a homepage from many different
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Monday, February 06, 2006 11:35
To: dev@cocoon.apache.org
Subject: Re: making pipelines wait for each other
Max Pfingsthorn wrote:
Hello!
...
WDYT? Would that solve it? Is there a better way?
I
About the [1]imageop contribution, could someone explain how I can
add a block in Cocoon 2.1? Does it involve adding the new block
in gump.xml? Does the build depend on gump.xml directly, or is
there an intermediate step required?
Please find attached the current patch against gump.xml.
Le 6 févr. 06, à 10:44, Max Pfingsthorn a écrit :
...We see that if a second request for exactly the same pipeline comes
in before the first request is done, it takes again as long because
the first pipeline did not put its result in the cache yet and it is
recomputed. This is quite obvious,
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on
getting the dependencies through the service manager in the program
code. But OSGi declarative services support
I think this topic has been discussed several times, so you might want
to search through the archives to see what others did say about it.
I had a look and the only thing I found was a conversation in the beginning of
2004 about eventcaching and the CachedSource [1]. Unico started it back
[ http://issues.apache.org/jira/browse/COCOON-1238?page=all ]
Jean-Baptiste Quenot closed COCOON-1238:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Committed, thanks!
See
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Monday, February 06, 2006 12:06
To: dev@cocoon.apache.org
Subject: Re: making pipelines wait for each other
Le 6 févr. 06, à 10:44, Max Pfingsthorn a écrit :
...We see that if a second request for
[ http://issues.apache.org/jira/browse/COCOON-1681?page=all ]
Jean-Baptiste Quenot closed COCOON-1681:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Committed, thanks!
See
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on
getting the dependencies through the service manager in the program
code. But OSGi
[ http://issues.apache.org/jira/browse/COCOON-1715?page=all ]
Jean-Baptiste Quenot closed COCOON-1715:
Fix Version: 2.1.9-dev (current SVN)
Resolution: Fixed
Fixed in 2.1. Loader now recognizes two additional system properties:
*
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on
getting the dependencies through the service manager in the
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 56
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 56
I am trying to build trunk. First I got the latest from svn.
I tried must doing maven and maven install but I get a failure
saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT cannot
be found in the repository and can't be located in any repository. What
do I need to do?
Sorry. The commands below should be mvn and mvn install.
Ralph Goers wrote:
I am trying to build trunk. First I got the latest from svn.
I tried must doing maven and maven install but I get a failure
saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT
cannot be found in the
Ralph Goers schrieb:
I am trying to build trunk. First I got the latest from svn.
I tried must doing maven and maven install but I get a failure
saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT cannot
be found in the repository and can't be located in any repository. What
hi devs
i checked out cocoon 2.1.x and get following build error.
init-tasks:
Created dir: /home/simon/src/cocoon-2.1.x-test/tools/anttasks
Compiling 5 source files
to /home/simon/src/cocoon-2.1.x-test/tools/anttasks
Created dir: /home/simon/src/cocoon-2.1.x-test/tools/loader
Compiling 1 source
* Doug Chestnut:
Hi simon, just noticed this as well. This should fix it:
-verbose = Boolean.parseBoolean(verboseProperty);
+verbose = Boolean.valueOf(verboseProperty).booleanValue();
Mea culpa,
Indeed parseBoolean is only available in JDK 1.5.
I committed your
Well darn. I tried to check out trunk at work so I could recreate the log,
but I can't get a successful checkout. At work I am behind a firewall and
checkouts only work when using https. Can somebody fix this - or tell me
how?
Fetching external item into
Ralph Goers wrote:
Well darn. I tried to check out trunk at work so I could recreate the log,
but I can't get a successful checkout. At work I am behind a firewall and
checkouts only work when using https. Can somebody fix this - or tell me
how?
Fetching external item into
OK. Under the assumption that I don't need that I reran it again. Here is
the output.
rago2483[/projects/cocoon/trunk] export MAVEN_HOME=/opt/maven-2.0.2/
rago2483[/projects/cocoon/trunk] export PATH=/opt/maven-2.0.2/bin:$PATH
rago2483[/projects/cocoon/trunk] export
Ralph Goers wrote:
[INFO] Failed to resolve artifact.
GroupId: org.apache.cocoon
ArtifactId: cocoon-plugins
Version: 1.0-SNAPSHOT
cocoon-plugins is the parent pom of cocoon-deployer-minimal-webapp. It's
not referenced from any other pom so i guess this is a leftover of the
latest module
Reinhard Poetz wrote:
Do we need any svn:externals in trunk? I don't think they are
required.
The archetype svn:external links to the static data from the cocoon webapp.
If nobody objects, I will remove it.
Please move it back to the whiteboard instead. I still believe
archetypes will
Are you trying to tell me that it isn't needed and it should be removed?
Jorg Heymans said:
Ralph Goers wrote:
[INFO] Failed to resolve artifact.
GroupId: org.apache.cocoon
ArtifactId: cocoon-plugins
Version: 1.0-SNAPSHOT
cocoon-plugins is the parent pom of
Agile Partners is growing yet again ...
About 80% of our work revolves around Cocoon. We're based in the U.S., and
our current projects are in the New York City / New Jersey area. We're
looking to add one or more full-time contractors with Cocoon / XSLT /
CForms / Ajax skills, see
Agile Partners is growing yet again ...
About 80% of our work revolves around Cocoon. We're based in the U.S., and
our current projects are in the New York City / New Jersey area. We're
looking to add one or more full-time contractors with Cocoon / XSLT /
CForms / Ajax skills
Sorry, I
Jorg Heymans wrote:
Reinhard Poetz wrote:
Do we need any svn:externals in trunk? I don't think they are
required.
The archetype svn:external links to the static data from the cocoon webapp.
If nobody objects, I will remove it.
Please move it back to the whiteboard instead. I still
34 matches
Mail list logo
