Le 1 mai 05, à 22:46, Sylvain Wallez a écrit :
...So, I think it's really time to do some cleanup and remove these
tags everywhere...
Fine with me
IIRC Bertrand ran a script to extract the current tags to build a
credits file. Bertrand, any information on this?
I did save the @author info in
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=34283.
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=34283.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Today I've had a look at continuation invalidation. I found following code
fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations Sorted Set.
// do we really want to do this?
if (parent.getChildren().size() 2) {
expirations.remove(parent);
}
Reinhard Poetz wrote:
Today I've had a look at continuation invalidation. I found following
code fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations Sorted
Set.
// do we really want to do this?
if (parent.getChildren().size() 2) {
Leszek Gawron wrote:
Reinhard Poetz wrote:
Today I've had a look at continuation invalidation. I found following
code fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations
Sorted Set.
// do we really want to do this?
if
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 39
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Today I've had a look at continuation invalidation. I found following
code fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations
Sorted Set.
// do we really want to do this?
if
Leszek Gawron wrote:
Reinhard Poetz wrote:
If I'm right I think of making the ContinuationsManagerImpl
inheritable (currently some protected methods and constructors prevent
this) so that the expiration strategy can be overriden. comments?
objections?
No problem here.
we should change the
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Mon May 2 06:32:24 2005
New Revision: 165628
URL: http://svn.apache.org/viewcvs?rev=165628view=rev
Log:
Protocols can be defined on a per sitemap configuration
Modified:
Daniel Fagerstrom wrote:
Did you merge in the Excalibur code but without implementing ThreadSafe
or are there more changes?
Upps, yes, that's what I started with and then I changed it to the
correct behaviour. I just added the missing ThreadSafe. Thanks! :)
I had some problems getting the
Upayavira,
As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :) I
wasn't sure what to do with this doc in 2.2. I also am not clear how
much of it will be accurate in 2.2.
I'll try to take a look at some point
Geoff Howard wrote:
Upayavira,
As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :) I
wasn't sure what to do with this doc in 2.2. I also am not clear how
much of it will be accurate in 2.2.
I'll try to take a
Geoff Howard wrote:
Upayavira,
As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :) I
wasn't sure what to do with this doc in 2.2. I also am not clear how
much of it will be accurate in 2.2.
I'll try to take a
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
I had some problems getting the root context right when working on the
BlockManager which I solved by redefining the source resolver in the
block manager's own service manager. So I'm interested in some more
details about exactly what
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Today I've had a look at continuation invalidation. I found
following code fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations
Sorted Set.
// do we really want to do this?
if
Bertrand Delacretaz wrote:
Le 1 mai 05, à 22:46, Sylvain Wallez a écrit :
...So, I think it's really time to do some cleanup and remove these
tags everywhere...
Fine with me
IIRC Bertrand ran a script to extract the current tags to build a
credits file. Bertrand, any information on this?
I did
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
If I'm right I think of making the ContinuationsManagerImpl
inheritable (currently some protected methods and constructors
prevent this) so that the expiration strategy can be overriden.
comments? objections?
No problem here.
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Today I've had a look at continuation invalidation. I found
following code fragment in the ContinuationManagerImpl:
// REVISIT: This places only the leaf nodes in the expirations
Sorted Set.
// do we really
Leszek Gawron wrote:
Vadim Gritsenko wrote:
If you want to tinker with ContinuationsManagerImpl, take a look at:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111323704203839
Strange I missed that post ..
Unsynchronized access to WebContinuationsHolder from
invalidateContinuations()
Daniel Fagerstrom wrote:
Ok, I studied the code in more detail, besides merging in the excalibur
source resolver you get the service manager from the current sitemap
instead of from the service method, is there anything more?
No.
The problem I had still remain, the context from the
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 1 mai 05, à 22:46, Sylvain Wallez a écrit :
...So, I think it's really time to do some cleanup and remove these
tags everywhere...
Fine with me
IIRC Bertrand ran a script to extract the current tags to build a
credits file. Bertrand, any
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 1 mai 05, à 22:46, Sylvain Wallez a écrit :
...So, I think it's really time to do some cleanup and remove these
tags everywhere...
Fine with me
IIRC Bertrand ran a script to extract the current tags to build a
credits
Hi all,
We discussed more that one year ago the removal of @author tags in our
source files (see [1] and [2]) but although the consensus was to remove
them, we never actually did it. Now most if not all new classes added
since then have no @author tag, leading to a strange situation where
old
Leszek Gawron wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
snip/
Are there any problems if a parent continuation is removed before
its children, except that the user can't jump back?
The execution state of a continuation is dependent on it's parent
state. So although we may trash parent
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
The problem I had still remain, the context from the defining sitemap
rather than the using sitemap is still used. I could modify the code to
use the context from the EnvironmentHelper instead.
What exactly do you need? The Context object or
Sylvain Wallez wrote:
Hi all,
We discussed more that one year ago the removal of @author tags in our
source files (see [1] and [2]) but although the consensus was to
remove them, we never actually did it. Now most if not all new classes
added since then have no @author tag, leading to a strange
Sylvain Wallez wrote:
So I propose to remove @author tags with people names from all our
source files.
+1
Additionally, if you agree with removing names, do you want source files
to have:
[ x ] no @author tag at all,
[ ] @author The Cocoon development team
[ ] @author . (something else)
Sylvain Wallez wrote:
Hi all,
We discussed more that one year ago the removal of @author tags in our
source files (see [1] and [2]) but although the consensus was to remove
them, we never actually did it. Now most if not all new classes added
since then have no @author tag, leading to a strange
On Lun, 2 de Mayo de 2005, 16:52, Sylvain Wallez dijo:
So I propose to remove @author tags with people names from all our
source files.
+1
Additionally, if you agree with removing names, do you want source files
to have:
[+0] no @author tag at all,
[+0] @author The Cocoon development
Sorry if this shows up twice, but I posted it two hours ago and it still
hasn't hit the list...
Original Message
Subject: Re: [VOTE] Removing author tags
Date: Mon, 02 May 2005 16:28:11 -0700
From: Ralph Goers [EMAIL PROTECTED]
To: dev@cocoon.apache.org
References: [EMAIL
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
So I propose to remove @author tags with people names from all our
source files.
+1
Well, I'm not really sure how to vote on this. I've pasted an email
from Larry Rosen to the Apache Legal list that seems to say that the
Cocoon source files should
Wow. it finally showed up. I wonder where it went in the meantime?
Ralph Goers wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
So I propose to remove @author tags with people names from all our
source files.
+1
Well, I'm not really sure how to vote on this. I've pasted an email
from
On Lun, 2 de Mayo de 2005, 18:28, Ralph Goers dijo:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
So I propose to remove @author tags with people names from all our
source files.
+1
Well, I'm not really sure how to vote on this. I've pasted an email
from Larry Rosen to the Apache
Le 2 mai 05, à 23:52, Sylvain Wallez a écrit :
..So I propose to remove @author tags with people names from all our
source files.
+1
Additionally, if you agree with removing names, do you want source
files to have:
[X ] no @author tag at all,
-Bertrand
smime.p7s
Description: S/MIME
35 matches
Mail list logo
