Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed
of the deprecated features they use (in the case of Javascript,
there's no compiler warning like in Java).
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
So what about a dedicated o.a.c.util.Deprecation class?
Sylvain
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users
Just a short head up... as you know I moved
the a javaflow implementation over to jakarta
commons.
http://jakarta.apache.org/commons/sandbox/javaflow/
I did a couple of API changes...
http://vafer.org/blog/tcurdt/archives/000179.html
So now the latest trunk version supports continuation
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-block-scratchpad has an issue affecting its community
integration.
This
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
I mean not tied to a class that
Torsten Curdt wrote:
Just a short head up... as you know I moved
the a javaflow implementation over to jakarta
commons.
http://jakarta.apache.org/commons/sandbox/javaflow/
I did a couple of API changes...
http://vafer.org/blog/tcurdt/archives/000179.html
So now the latest trunk version supports
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash the
whole category configuration in logkit.xconf and log everything in a
single file (+ the filter for error.log).
Same here. Let's simplify default config. Some fancy stuff can still be there -
in
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 4:52, Andrew Savory dijo:
On 9 Feb 2005, at 09:20, Carsten Ziegeler wrote:
2) create two blocks for each block that supports xsp: for example a
databases and a databases-xsp block
I suspect this is the easiest option.
Forget to say the
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite
I thought you might be interested... This is for the IntelliJ license.
Original Message
Subject:RE: Open Source developer's license
Date: Thu, 10 Feb 2005 16:01:09 +0300
From: Ilia Dumov [EMAIL PROTECTED]
To: 'Ralph Goers' [EMAIL PROTECTED]
Hi Ralph,
Thank you
Sylvain Wallez wrote:
I mean not tied to a class that provides other features than deprecation
logging. And the Cocoon class provides so much more ;-)
Hence the specific Deprecation class below, which will of course be in
the org.apache.cocoon package hierarchy.
Ok: +1 - I would choose a
Torsten Curdt wrote:
Just a short head up... as you know I moved
the a javaflow implementation over to jakarta
commons.
http://jakarta.apache.org/commons/sandbox/javaflow/
I did a couple of API changes...
http://vafer.org/blog/tcurdt/archives/000179.html
So now the latest trunk version supports
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash
the whole category configuration in logkit.xconf and log everything in
a single file (+ the filter for error.log).
Same here. Let's simplify default config. Some fancy stuff can
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash
the whole category configuration in logkit.xconf and log everything
in a single file (+ the filter for error.log).
Same here. Let's simplify default config.
On Jue, 10 de Febrero de 2005, 10:38, Stefano Mazzocchi dijo:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash
the whole category configuration in logkit.xconf and log everything in
a single file (+ the filter for error.log).
Antonio Gallardo wrote:
On Jue, 10 de Febrero de 2005, 10:38, Stefano Mazzocchi dijo:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash
the whole category configuration in logkit.xconf and log everything in
a single file (+ the filter
Last week Upayavira and I spent some time to overhaul the structure of the
two
document repositories:
- http://brutus.apache.org/docs/build/cocoon-doco-2-2/
- http://brutus.apache.org/docs/build/cocoon-doco-global/
We think that it covers all Cocoon relevant topics and is a good starting point
to
While Upayavira and I were discussing the documentation, we also came
across the
question, where we should put the documentation of blocks within our navigation
structure. To keep things easy for now, we propose following:
- Core blocks
- non-core blocks
- external blocks
*Core blocks* are
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Thu Feb 10 07:00:57 2005
New Revision: 153227
URL: http://svn.apache.org/viewcvs?view=revrev=153227
Log:
pool-min and pool-grow have been removed from pooling long time ago in
excalibur
Same is true for 2.1 branch, AFAIKT,
20 matches
Mail list logo
