DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22842.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Sat, Aug 30, 2003 at 08:59:42AM -0400, Geoff Howard wrote:
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container.
This should have little to no impact on component writers. It
boasts faster startup, and it provides easier component definition.
I will be
Vadim Gritsenko wrote:
Marc Portier wrote:
snip/
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
And nobody still answered the question: why passing of parameters into
the function
Sylvain Wallez wrote:
You might need to have access to the response too. In WebDAV world,
as an example, you need to set a whole bunch of headers (Allow:,
DAV:, MS-Author-Via - yuck - and more), and a DASL component needs to
specify the search vocabularies supported. True, you can do it by
Sylvain Wallez wrote:
Example :
wt:widget id=foo
wi:styling type=textarea rows=10/
/wt:widget
The type attribute defines the style type and all other attributes
are dependent on this type (and here, copied as is).
What do you think ?
Including the style element directly rather than referring
bruno 2003/08/31 02:31:55
Added: lib/core util.concurrent-1.3.2-patched.jar
Log:
Same as 1.3.2 version, but with the following method patched in the PooledExecutor
class:
protected synchronized void workerDone(Worker w) {
threads_.remove(w);
if (--poolSize_ == 0
bruno 2003/08/31 02:32:35
Modified:.status.xml
lib jars.xml
Removed: lib/core util.concurrent-1.3.1.jar
Log:
Upgraded util.concurrent.jar
Revision ChangesPath
1.131 +5 -1 cocoon-2.1/status.xml
Index: status.xml
Sylvain Wallez dijo:
[For cocoon-dev] I asked Matt Kruse about the inclusion of his nice
JavaScript calendar popup
(http://www.mattkruse.com/javascript/calendarpopup/) into Cocoon. He
answered very positively, so be prepared to see this in Woody in the
coming days (I have it working on my HD,
On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
Is someone on the Doug Lea list (if there is any) to report this?
I got an answer from him, he provided me with a slightly edited change:
protected synchronized void workerDone(Worker w) {
threads_.remove(w);
if (--poolSize_ == 0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
Cheers,
Reinhard
-Original Message-
From:
Stefano Mazzocchi wrote:
On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote:
Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.
I think you greatly underestimate the complexity of the approach you
Steven Noels wrote:
Sylvain Wallez wrote:
Example :
wt:widget id=foo
wi:styling type=textarea rows=10/
/wt:widget
The type attribute defines the style type and all other
attributes are dependent on this type (and here, copied as is).
What do you think ?
Including the style element directly
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1 for this change in either
On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote:
On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
snip/
I like the way how the Cornerstone Scheduler recently integrated by
Carsten more than the CommandManager way because of its
componentisation. Still, I like to see a Scheduler as a single
Reinhard Poetz wrote:
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
I recently fixed bugs in internal
Nicolas Maisonneuve wrote:
hy ,
i hava some trouble with poolabe interface in cocon..
i made a XMLDB avalon component .
but
if i call the lookup 6 times, 6 instances are created ..
i would use the instances already created .. so in using the avalon
Poolable interface and adding the
Gianugo Rabellino wrote:
Sylvain Wallez wrote:
You might need to have access to the response too. In WebDAV world,
as an example, you need to set a whole bunch of headers (Allow:,
DAV:, MS-Author-Via - yuck - and more), and a DASL component needs
to specify the search vocabularies supported.
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
Bruno Dumon wrote:
On Sun, 2003-08-17 at 23:03, [EMAIL PROTECTED] wrote:
sylvain 2003/08/17 14:03:42
Modified:src/blocks/woody/java/org/apache/cocoon/woody/transformation
WidgetReplacingPipe.java
src/blocks/woody/samples/xsl/html woody-default.xsl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Sun, 31 Aug 2003, Bruno Dumon wrote:
On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote:
On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
snip/
I like the way how the Cornerstone Scheduler recently integrated by
Carsten more than the CommandManager way because of its
componentisation.
[EMAIL PROTECTED] wrote:
mpo 2003/08/26 02:04:39
Added: src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Log:
Adding the new ContinuationsDisposer interface declaring the callback for
implementation specific Clean-up of continuations.
Hey all --
I am working on using user managed distrubuted transactions from flow. I have
Cocoon 2.1, Tomcat 4.1.27, JOTM 1.4.3, and the JSQLConnect JDBC driver. I
believe I have it working and would like to share some things and ask a
question.
The biggest problem I had was the scenario
On Sun, 2003-08-31 at 20:38, Giacomo Pati wrote:
On Sun, 31 Aug 2003, Bruno Dumon wrote:
On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote:
On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
snip/
I like the way how the Cornerstone Scheduler recently integrated by
Carsten more than
On Thu, 2003-08-21 at 14:59, Sylvain Wallez wrote:
(on the topic of the validator function in woody flowscript integration)
Thinking further, I really think we must separate event handler and
application-related-validator. These are really two different concerns.
yep, they should be split.
Sylvain Wallez wrote:
Furthermore, use of attributes ensures uniqueness of styling type, which
is not guaranteed with nested elements.
E.g. what happens if we write :
wt:widget id=foo
wi:styling
textarea rows=10/
password size=20/
/wi:styling
/wt:widget
Will this widget be rendered as a
On Sun, 31 Aug 2003, Bruno Dumon wrote:
On Sun, 2003-08-31 at 20:38, Giacomo Pati wrote:
First, if you look at the Cornerstone Scheduler you'll see that the
ability to define repeated tasks are somehow limited. Business apps can
easily request administration tasks to be run twice a day
Giacomo Pati wrote:
First, if you look at the Cornerstone Scheduler you'll see that the
ability to define repeated tasks are somehow limited. Business apps can
easily request administration tasks to be run twice a day on work days.
To define this with the Cornerstone Scheduler you'll need to
Sylvain Wallez wrote:
Reinhard Poetz wrote:
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
I fixed
Hey thanks for identifying the problem and fixing it. If I don't specify a
mime-type for map:read does it always default to text/html?
From: Sylvain Wallez [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: HTML code shown in browser, not
31 matches
Mail list logo
