DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
On 20.10.2004 20:07, Carsten Ziegeler wrote:
IMHO it is simply wrong to continue a script in a sitemap where it
hasn't been declared - and as soon as the flow script tries to
address relative resources it won't work anyway.
But
Leszek Gawron wrote:
Is there any sense to bind continuations to the sitemap? Vadim?
Yes, I really think so. IMHO it is simply wrong to continue
a script
in a sitemap where it hasn't been declared - and as soon as
the flow
script tries to address relative resources it won't
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
IIUC you will integrate it in the build as a step to be involked
before the Cocoon build, right?
No, it's just some more classes in the core; we don't have
the need to
have a separate jar/product.
I
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off
Andreas Hartmann wrote:
Just one more question for my understanding:
Lenya 1.4 will probably be released in spring or summer next year.
We're planning to do a major clean-up of the code base.
(See also thread Switch to Cocoon 2.2 for Lenya 1.4-dev on
lenya-dev (the archive seems to be
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
[...]
Assumed we start development with Cocoon 2.1.* now, would
this mean that we will release against the 2.1 branch? It
looks like Cocoon 2.2 will really be quite different, so it
will probably be hard to upgrade Lenya. Will the 2.1 branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Does anybody have an idea what's going on here? I remember the problem of losing
the component manager in July/August last year. Could this be the reason why the
CallContext object was introduced?
Find more infos on this issue at
http://issues.apache.org/bugzilla/show_bug.cgi?id=31649.
Any
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] wrote:
True! However, if there is a form to be filled in, some questions will be
answered beforehand, thus eliminating several mails back and forth.
Some of the questions:
- how can I see that Cocoon was used?
- why did you use Cocoon?
- how much time did the project take?
-
Vadim Gritsenko wrote:
Just an idea; can we move ALL libraries to lib/optional, and
copy them into the WEB-INF/lib on as-needed basis, i.e. if
block included which needs a library, only then librariy is
copied over? This should be possible using the info from gump.xml...
This way we
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
This evening I'm going to integrate ECM++ into the current 2.2 codebase.
I've already done this locally and it seems to work very well, it even
seemed to be a little bit faster than with the old ECM - but this could
be some hallucination...
Anyway, I will move the code from the whiteboard to the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Il giorno 21/ott/04, alle 12:10, Carsten Ziegeler ha scritto:
This evening I'm going to integrate ECM++ into the current 2.2
codebase.
Go for it!
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Le 21 oct. 04, à 11:54, Upayavira a écrit :
...If we have needs for running our own stuff, e.g. having the latest
Cocoon samples usable from the Cocoon website, we should make a
request to the infrastructure team for a VM for ourselves, as soon as
they have done the necessary hardware
On Tue, 19 Oct 2004, Stefano Mazzocchi wrote:
Giacomo Pati wrote:
On Tue, 28 Sep 2004, Bertrand Delacretaz wrote:
Le 28 sept. 04, à 04:12, Stefano Mazzocchi a écrit :
Bertrand Delacretaz wrote:
...The performance part comes mainly from the front-end apache2
mod_cache. Simply adding the right HTTP
Bertrand Delacretaz wrote:
Le 21 oct. 04, à 11:54, Upayavira a écrit :
...If we have needs for running our own stuff, e.g. having the latest
Cocoon samples usable from the Cocoon website, we should make a
request to the infrastructure team for a VM for ourselves, as soon as
they have done the
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Just an idea; can we move ALL libraries to lib/optional, and
copy them into the WEB-INF/lib on as-needed basis, i.e. if
block included which needs a library, only then librariy is
copied over? This should be possible using the info from
Hi all,
I've had problems downloading files over HTTPS with IE. This is a know
bug in IE, and there is also a known work-around. If the headers
Cache-control = no-cache and Pragma = no-cache are available, IE has
problems with downloading the content. The content is all the content
that is not
Hi team,
I need your advice on the best way to fix a problem when using Cocoon on
Tomcat caused by DELI that I do not encounter when running Cocoon on
Jetty. Therefore I would like your advice as solving the problem seems
to require an understanding of the differences between servlet engines
that
Andreas Hartmann wrote:
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly*
Having our own live Cocoon instance(s) could make all the difference
in the way we do our docs, so if there's an opportunity I think we
should make it happen.
I'd say go for this, although I won't be able to help (I never really got
past the phase where a Red Hat or Suse installation
On Thursday 21 October 2004 21:40, Stefano Mazzocchi wrote:
As for continous integration, Gump is your friend, so you should
not have to worry about that.
Provided we can get Gump all the way up and beyond Cocoon :o)
Soon there...
Cheers
Niclas
--
+--//---+
/
Upayavira wrote:
[EMAIL PROTECTED] wrote:
True! However, if there is a form to be filled in, some questions will be
answered beforehand, thus eliminating several mails back and forth.
Some of the questions: - how can I see that Cocoon was used?
- why did you use Cocoon? - how much time did the
Unico Hommes wrote:
What
about having only one repository location for blocks? I am so tired of
all the duplicate effort we have to do for each and every change to
blocks. It shouldn't be neccessary.
There probably isn't a small amount of work involved to get it working
Me thinks it is enough
Niclas Hedhman wrote:
On Thursday 21 October 2004 21:40, Stefano Mazzocchi wrote:
As for continous integration, Gump is your friend, so you should
not have to worry about that.
Provided we can get Gump all the way up and beyond Cocoon :o)
Soon there...
you can bet your ass we will! :-)
--
Stefano
Butler, Mark H (Labs Bristol) wrote:
Hi team,
I need your advice on the best way to fix a problem when using Cocoon on
Tomcat caused by DELI that I do not encounter when running Cocoon on
Jetty. Therefore I would like your advice as solving the problem seems
to require an understanding of the
Hi Stefano
Actually Patrick logged it as a server bug with the Apache Tomcat team,
but they weren't very impressed see
http://issues.apache.org/bugzilla/show_bug.cgi?id=31806
I suspect its not so much a bug, more a feature of two different teams
interpreting the servlet specs differently :)
Butler, Mark H (Labs Bristol) wrote:
Hi team,
I need your advice on the best way to fix a problem when using Cocoon on
Tomcat caused by DELI that I do not encounter when running Cocoon on
Jetty. Therefore I would like your advice as solving the problem seems
to require an understanding of the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes wrote:
Carsten Ziegeler wrote:
2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks?
yes
3. Separate blocks build system from core build system and let one drive
the other.
Comments?
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can
I am having an intermittent error thrown, and i really dont see what is
causing it... I must be missing a concept for the auth framework here..
anyone have any ideas? the error is only thrown once - the first time an
authenticated user attempts to access the page. after the error, if the
user
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Reinhard Poetz wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks?
yes
3. Separate blocks build system from core build system and let one
drive the other.
Comments?
Some thoughts I want to share:
goal: move towards real blocks -
Butler, Mark H (Labs Bristol) wrote:
Hi Stefano
Actually Patrick logged it as a server bug with the Apache Tomcat team,
but they weren't very impressed see
http://issues.apache.org/bugzilla/show_bug.cgi?id=31806
I suspect its not so much a bug, more a feature of two different teams
interpreting
Unico Hommes wrote:
Ok ok, I get the hint ;-)
Oh, that wasn't targetted at you, Unico, but if you have time... :)
But before I decide to do any work
there is another issue with the blocks build system I'm dying
to resolve. What about having only one repository location
for blocks? I
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
FYI, I have root access on brutus.apache.org (the machine that runs
gump) and we could start to proxy_pass from cocoon.apache.org on to brutus.
The machine is a dual xeon, 4Gb of ram, SCSI disks, runs JDK 1.4.2 and
I'm looking for a place to run Cocoon unit tests.
Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we have 55
blocks right now)
Vadim
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
IIRC, Nicola already started an effort for an updated build system that
features an
Carsten Ziegeler wrote:
Unico Hommes wrote:
Ok ok, I get the hint ;-)
Oh, that wasn't targetted at you, Unico, but if you have time... :)
I didn't really feel that it was. It just seems opportune that I take up
the issue since I raised it. I'll see what I can do.
But before I decide
Carsten Ziegeler wrote:
then do a painless 2.1.6 release and then spend energy on
this issue. I personally don't want to delay a 2.1.6 release
just because of a broken build system etc.
I agree, first the release (and sync) and then the change in the build system.
--
Reinhard
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes wrote:
That is true. Is there anything holding back a 2.1.6 release btw?
Apart from the syncing there is only one test that fails according to Vadim.
So, as soon as we have synced we can release.
Carsten
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to /repos/asf/cocoon/trunk/core .
IMO
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to
Upayavira wrote:
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional
requirement that blocks and core directory don't overlap. Eclipse
cannot deal with overlapping projects. So that would mean that the
2.2 core move to
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we
have 55 blocks right now)
Let me
Upayavira wrote:
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to
Nicola Ken Barozzi wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused
later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we
have 55
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
import file=../common-block-build.xml
then there is not really more to maintain, but you
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
import file=../common-block-build.xml
then there is not really more to maintain, but
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
import file=../common-block-build.xml
then there is not really more to maintain, but
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 21 Oct 2004, at 04:22, Vadim Gritsenko wrote:
Store:
Clean out here writes stuff out into the persistent store,
if stuff is Serializable.
Transient store:
Clean out here removes stuff completely, hence the
name: transient.
Persistent store:
Janitor does not touch this store at all. No
On 21 Oct 2004, at 06:52, Bertrand Delacretaz wrote:
Le 20 oct. 04, à 22:21, Pier Fumagalli a écrit :
...Bertrand,
did you look at that action I posted few months ago which we're
using on VNUNET.COM?
map:action name=cache-5
src=org.apache.cocoon.acting.HttpCacheAction
Le 21 oct. 04, à 17:56, Pier Fumagalli a écrit :
...I found a couple of bugs on mod_cache, though, that prevent pages
to be cached... Did you observe the same problem?
I didn't, but I might have missed it since I didn't do a very precise
analysis.
I tested by setting the virtual host to DEBUG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31649.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I don't want to take this discussion into Bugzilla, so I'll continue it
here.
Ok, I noticed you minimized the resources. My idea.
Re the dynamic selection list. It basically requires a list of already
selected players (which in fact duplicates the effort done in on-save-form),
but I'm at a loss
Fresh ./build.sh clean ./build.sh of cocoon svn trunk head
produces this error for me (and is confirmed by tonyc on #cocoon):
Internal Server Error
Message: This version of Cocoon does not handle sitemap version 1.0 at
file:/home/tim/pkg/svn/cocoon/cocoon/build/webapp/sitemap.xmap
Description:
On 21.10.2004 20:23, [EMAIL PROTECTED] wrote:
Author: reinhard
(add dreamteam application by Helma van der Linden (issue 31813)
Added: cocoon/trunk/src/blocks/forms/samples/dreamteam/sitemap.xmap
==
--- (empty file)
+++
Pier Fumagalli wrote:
On 21 Oct 2004, at 04:22, Vadim Gritsenko wrote:
Store:
Clean out here writes stuff out into the persistent store,
if stuff is Serializable.
Transient store:
Clean out here removes stuff completely, hence the
name: transient.
Persistent store:
Janitor does not touch
On Friday 22 October 2004 02:55, Joerg Heinicke wrote:
Can you please take care about the properties (probably binary vs.
text). If the commit messages have a free line after each line with
text, there is something wrong.
for FILE in `find . -name *.java` ; do
svn propset svn:eol-style
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] dijo:
Having our own live Cocoon instance(s) could make all the difference
in the way we do our docs, so if there's an opportunity I think we
should make it happen.
I'd say go for this, although I won't be able to help (I never really got
past the phase where a Red Hat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I think this is related to my latest changes in preparing the trunk for
ecm++.
I'm currently in the process of adding ecm++ to the trunk, so it should
work soon again.
Carsten
Tim Larson [EMAIL PROTECTED] wrote:
Fresh ./build.sh clean ./build.sh of cocoon svn trunk head
produces this error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31649.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Thu, Oct 21, 2004 at 09:33:27PM +0200, Carsten Ziegeler wrote:
I think this is related to my latest changes in preparing the trunk for
ecm++.
I'm currently in the process of adding ecm++ to the trunk, so it should
work soon again.
No problem, just please drop a note here when you think it
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31649.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Now you can try again - some things work now...at least the samples pages
come up.
XSP is definitly not working right now and SitemapConfigurableComponents
aren't working as well (this affects global variables and the authentication
framework and therefore the portals etc.). But apart from that
Guys,
I tend to enter the result of this discussion in Bugzilla, or maybe someone
takes over and puts it directly in the docs, we'll see. For now I just want
to do an inventory of questions we'd like to be answered in a link request.
Here's a proposal for the text, [[ my comments between brackets
Hiya,
This does indeed cause problems now that true persistence is working.
Given that no space is actually recovered from the persistent store
(even when items are invalid) the disk-cache grows - even across
shutdown /startup cycles. I guess the store janitor will need to be
modified to enable
Corin Moss wrote:
Hiya,
This does indeed cause problems now that true persistence is working.
Given that no space is actually recovered from the persistent store
(even when items are invalid) the disk-cache grows - even across
shutdown /startup cycles. I guess the store janitor will need to be
Hiya,
This probably works for the FilesystemStore, but both the JCS and
EHCache stores use their own store file - so everything is cached within
one big binary file - which means that something else has to take over
the deleting cycle. Also add to this that when you use event based
caching you
[EMAIL PROTECTED] wrote:
Author: vgritsenko
Date: Thu Oct 21 17:24:59 2004
New Revision: 55287
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/CocoonComponentManager.java
Log:
Add synchronization to EnvironmentDescription methods.
Required in cases when Sources are
Upayavira wrote:
Bertrand Delacretaz wrote:
Upayavira a écrit :
...If we have needs for running our own stuff, e.g. having the latest
Cocoon samples usable from the Cocoon website, we should make a
request to the infrastructure team for a VM for ourselves, as soon as
they have done
David Crossley wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Upayavira a écrit :
...If we have needs for running our own stuff, e.g. having the latest
Cocoon samples usable from the Cocoon website, we should make a
request to the infrastructure team for a VM for ourselves, as
95 matches
Mail list logo
