Automated Cocoon Unit tests failed!
Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20050105.log
Last messages from the log file:
==
[foreach] reader-mime-type.xml:39
Carsten Ziegeler wrote:
Upayavira wrote:
Antonio Gallardo wrote:
If 2.1 will work without this feature = please remove it.
Cleaning the
house is good. ;-)
As is leaving things alone so you don't take the risk of breaking
things :-)
Exactly - and we should try to make sense out of our
Upayavira wrote:
Carsten Ziegeler wrote:
Upayavira wrote:
Antonio Gallardo wrote:
If 2.1 will work without this feature = please remove it.
Cleaning the
house is good. ;-)
As is leaving things alone so you don't take the risk of breaking
things :-)
Exactly - and we should try to make sense
Upayavira wrote:
Carsten Ziegeler wrote:
snip/
Exactly - and we should try to make sense out of our version numbers
especially wrt compatibility.
I think we should be keeping 2.1.X as stable as possible, and be
tidying trunk.
Agree
We therefore need to be thinking about how to get trunk
Sylvain Wallez wrote:
Good analysis. The problem is that trunk has not (or had not before
include) enough distinguishing features to make it really appealing
compared to 2.1. And it therefore doesn't urge us to release it, leading
new features to be added to 2.1 also as we need them on
On Jan 5, 2005, at 6:45 AM, Carsten Ziegeler wrote:
So my plan would be:
1. Decide for one logging api (log4j or commons-logging)
2. Remove the support for all other logging apis
3. Provide a IoC way for logging
4. Slowly move away from LogEnabled
If we still want to provide flexibility, we could
Il giorno 05/gen/05, alle 12:45, Carsten Ziegeler ha scritto:
1. Decide for one logging api (log4j or commons-logging)
+1 for commons-logging
2. Remove the support for all other logging apis
+1
3. Provide a IoC way for logging
4. Slowly move away from LogEnabled
Most of all, I'd like to see the
Jan Hoskens wrote:
Hi,
I have a setup where I have my form definition in a DOM Element. I
used to load Forms.js version 2, because that script did cover this
need. But now I need to pass some bizdata and it seems like this was
missed out in version 2.
Besides this, I've heard that there are
Carsten Ziegeler wrote:
My personal opinion is that we just need these virtual components
and then have the final 2.2 (apart from polishing). Everything else
can go into 2.3.
My perception has been that 2.2 was waiting for real blocks. However,
I believe Sylvain is right. The include feature
Carsten Ziegeler wrote:
So my plan would be:
1. Decide for one logging api (log4j or commons-logging)
2. Remove the support for all other logging apis
3. Provide a IoC way for logging
4. Slowly move away from LogEnabled
If we still want to provide flexibility, we could opt for
commons-logging. In
Hi,
Just a pointer to a thread aout UGLI in Jakarta HttpClient:
http://mail-archives.apache.org/eyebrowse/BrowseList?listName=httpclient-dev
@jakarta.apache.orgby=threadfrom=967502
Bernard
-Original Message-
From: peter royal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 05, 2005
Carsten Ziegeler wrote:
...
If we still want to provide flexibility, we could opt for
commons-logging. In this case, brave users can configure logkit as the
logger for commons-logging and they are happy as well.
Think again before adopting the commons-logging API
Il giorno 05/gen/05, alle 17:13, Nicola Ken Barozzi ha scritto:
-1 for commons-logging
-0 for log4j
+0 for JDK logging (less dependencies)
+1 for UGLI
I've suffered too much with commons-logging configuration to be able
to like it in any way.
OK, you convinced me. +1 for UGLI :-)
Ugo
--
On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
In the past we had several arguments about why logkit is better and so
on but I think most of these arguments are not valid any more.
Well, AFAIU a big one still stands true: security. I really hate the
idea that
On Mie, 5 de Enero de 2005, 10:14, Torsten Curdt dijo:
Most of all, I'd like to see the AbstractLogEnabled class die a quick
and painful death ;-)
Since we are talking...
...what about using e.g. http://just4log.sourceforge.net from
the build system. I *hate* the isBlaEnabled crap (although
On Mie, 5 de Enero de 2005, 10:13, Nicola Ken Barozzi dijo:
Carsten Ziegeler wrote:
...
So my plan would be:
1. Decide for one logging api (log4j or commons-logging)
OK. You convinced me. ;-)
-1 for commons-logging
-0 for log4j
+0 for JDK logging (less dependencies)
+1 for UGLI
OK. You
On Thursday 06 January 2005 00:43, Gianugo Rabellino wrote:
On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
In the past we had several arguments about why logkit is better and so
on but I think most of these arguments are not valid any more.
Well, AFAIU a big
Antonio Gallardo wrote:
...
Please have a look at the Torsten suggestions, looks good too:
http://just4log.sourceforge.net
+1 too.
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love the way this makes one write log messages, it's what we have
in POI,
Maybe just throw away (Abstract)LogEnabled and do constructor injection
instead. Or even relegate Logging to an ordinary service, which is looked up
like any other component.
As much as I like IoC I think logging is one of the reasons for
overcomponentization. ...just because you need a logger
On Mie, 5 de Enero de 2005, 11:19, Nicola Ken Barozzi dijo:
Antonio Gallardo wrote:
...
Please have a look at the Torsten suggestions, looks good too:
http://just4log.sourceforge.net
+1 too.
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love
I don't believe getting rid of (Abstract)LogEnabled should be done in 2.2.
That is so pervasive that it will significantly delay getting a 2.2
release out soon.
Torsten Curdt said:
Maybe just throw away (Abstract)LogEnabled and do constructor injection
instead. Or even relegate Logging to an
So far we have:
-1 on commons-logging (from Nicola)
-1 on log4j (from me)
-1 on jdk logger (from me - same reason as log4j)
and it looks like -1 on UGLI from Torsten.
That leaves logkit and just4log (which I haven't looked at). Unless
someone has something else?
Torsten Curdt said:
Torsten
Why a system property instead of an init-param?
Sylvain Wallez said:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cool! One more reason for releasing 2.2 soon :)
/Daniel
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt [EMAIL PROTECTED] wrote:
snipother loggers/snip
and it looks like -1 on UGLI from Torsten.
Well, I doubt I have to give a -1 with
the given facts... :-P
What's to stop everyone from continuing to just construct the Strings
like they do
On Mie, 5 de Enero de 2005, 14:06, Torsten Curdt dijo:
-1 on log4j (from me)
-1 on jdk logger (from me - same reason as log4j)
Could you give a more detailed explanation
why both are not working for you?
Because Ralph is a brave user ;-)
On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt [EMAIL PROTECTED]
wrote:
snipother loggers/snip
and it looks like -1 on UGLI from Torsten.
Well, I doubt I have to give a -1 with
the given facts... :-P
What's to stop everyone
Because Ralph is a brave user ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110493608032769w=2
ups... missed that one :-)
thanks
--
Torsten
Gianugo Rabellino wrote:
On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
In the past we had several arguments about why logkit is better and so
on but I think most of these arguments are not valid any more.
Well, AFAIU a big one still stands true: security. I really
Nicola Ken Barozzi wrote:
Antonio Gallardo wrote:
...
Please have a look at the Torsten suggestions, looks good too:
http://just4log.sourceforge.net
+1 too.
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love the way this makes one write log messages,
Niclas Hedhman wrote:
There is also a slight issue with Log4J in its dealings with runtime
dependencies and classloading that may hurt future efforts in Cocoon in true
blocks.
I don't know if this is true anymore. Our new kernel is able to use
dependency injection and static factories together
[EMAIL PROTECTED] wrote:
Author: sylvain
Date: Wed Jan 5 09:42:34 2005
New Revision: 124234
URL: http://svn.apache.org/viewcvs?view=revrev=124234
Log:
New lazy mode to load components, which heavily speeds up Cocoon initialization
time
boy, that hero plate of mine is getting *very* shiny :-)
--
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cocoon's initialization time.
Some quick measurement of
Ralph Goers wrote:
So far we have:
-1 on commons-logging (from Nicola)
-1 on log4j (from me)
-1 on jdk logger (from me - same reason as log4j)
and it looks like -1 on UGLI from Torsten.
That leaves logkit and just4log (which I haven't looked at). Unless
someone has something else?
I don't want to
Ralph Goers wrote:
Why a system property instead of an init-param?
Because it's experimental and I wanted a quick switch to compare lazy
and non-lazy modes!
Now if this is to become more mainstream (and I guess it will), that
will for sure be triggered by some init-param.
Sylvain
--
Sylvain
Hi:
I think we are still discussing the topic. It is to early to cast it as
real votes.
just4log is a complement to [log4j | commons-logging | JDK 1.4 Logging ]
if all three are deprecated, then we can not use it. :-(
Unfortunately seems like we will still stall with logkit?
No package is a
On Wed, 5 Jan 2005 14:21:01 -0600 (CST), Antonio Gallardo
[EMAIL PROTECTED] wrote:
On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt [EMAIL PROTECTED]
wrote:
snipother loggers/snip
and it looks like -1 on UGLI from Torsten.
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about using the CCSM acronym
On Mie, 5 de Enero de 2005, 14:56, Peter Hunsberger dijo:
On Wed, 5 Jan 2005 14:21:01 -0600 (CST), Antonio Gallardo
[EMAIL PROTECTED] wrote:
On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt [EMAIL PROTECTED]
wrote:
snipother
On Mie, 5 de Enero de 2005, 15:02, Jean Pierre LeJacq dijo:
On Wed, 5 Jan 2005, Stefano Mazzocchi wrote:
Ralph Goers wrote:
So far we have:
-1 on commons-logging (from Nicola)
-1 on log4j (from me)
-1 on jdk logger (from me - same reason as log4j)
and it looks like -1 on UGLI from
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a
lazy-loading strategy for components. Using this strategy, a
component is loaded (including it's class) only when looked up. This
heavily reduces Cocoon's initialization time.
logger.debug(User with {} entered wrong query string [{}]., id,
query);
very pythonish. I like it :-)
...but only with jdk 1.5 :-/
cheers
--
Torsten
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core
Antonio Gallardo wrote:
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when
Antonio Gallardo wrote:
On Mie, 5 de Enero de 2005, 15:01, Sylvain Wallez dijo:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Also, CSM can be confused with CocoonServiceManager which is in
o.a.c.components.container (which is a subclass of CCSM).
howzabout CCM = Cocoon Component Manager... or is there a confusion hazard
vs. Avalon's
I think that's my point? If you want to sub in three things do it as
normal String building and ignore the parameters substitution. Or use
2 parameters and one Java variable directly in the String... Nothing
has gone away with UGLI, you just get some extra methods you can
ignore if you want?
Mark Lundquist wrote:
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Also, CSM can be confused with CocoonServiceManager which is in
o.a.c.components.container (which is a subclass of CCSM).
howzabout CCM = Cocoon Component Manager... or is there a confusion
On Wed, 05 Jan 2005 22:30:16 +0100, Torsten Curdt [EMAIL PROTECTED] wrote:
I think that's my point? If you want to sub in three things do it as
normal String building and ignore the parameters substitution. Or use
2 parameters and one Java variable directly in the String... Nothing
has
Torsten Curdt wrote:
Maybe just throw away (Abstract)LogEnabled and do constructor
injection instead. Or even relegate Logging to an ordinary service,
which is looked up like any other component.
As much as I like IoC I think logging is one of the reasons for
overcomponentization. ...just
Nicola Ken Barozzi wrote:
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love the way this makes one write log messages, it's what we
have in POI, and is very convenient.
Ceki wrote:
As noted in my previous message, UGLI also supports parameterized
On Wed, 05 Jan 2005 15:42:08 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Nicola Ken Barozzi wrote:
Antonio Gallardo wrote:
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
How so? What am I missing?
As noted in my previous message, UGLI also
On Wed, 05 Jan 2005 22:42:57 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Mark Lundquist wrote:
-Original Message-
howzabout CCM = Cocoon Component Manager... or is there a confusion hazard
vs. Avalon's ComponentManager?
Hey, read carefully, this is *Service* Manager. If
I cannot have a direct dependency on any logging implementation that does
not let me replace it. We use our own logging framework that, believe it
or not, is somewhat more advanced.
As far as I'm concerned, Cocoon can use log4j or the JDK logger as long as
it is done through an abstraction
Sylvain Wallez said:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about
On Jan 5, 2005, at 4:59 PM, Ralph Goers wrote:
As far as I'm concerned, Cocoon can use log4j or the JDK logger as
long as
it is done through an abstraction layer. While I am not necessarily
thrilled with the logkit logger and its configuration, I am happy that
I
can just declare my own class
Carsten Ziegeler wrote:
From time to time I'm thinking about how to simplify (if possible)
logging in Cocoon, so here we go again.
Currently we are using logkit for logging. It seems that we are more
or less the only project using logkit; everyone else is either
using log4j or commons-logging.
We
Il giorno 05/gen/05, alle 21:56, Antonio Gallardo ha scritto:
1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
true, then UGLI is not a serious proposal. Should be discarded. It is
only
a bad produced syntax sugar. I must admit, the idea with more
parameters
is really cool.
On Wed, 5 Jan 2005 23:40:52 +0100, Ugo Cei [EMAIL PROTECTED] wrote:
Il giorno 05/gen/05, alle 21:56, Antonio Gallardo ha scritto:
1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
true, then UGLI is not a serious proposal. Should be discarded. It is
only
a bad
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=32838.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
We are not using logkit: we are using Avalon Logger, and the default
configuration shipped with Cocoon use the LogKit implementation of
Avalon Logger (you say the same below).
true
Why do we really need logkit? I honestly don't know.
Because it's not bloated?
well ...I think keeping an
Keeping it simple... we all kinda want log4j but don't want to link
directly to the implementation... UGLI is the lightweight frontend that
gives us log4j with pluggability [1].
Note that log4j version 1.3 and later support UGLI directly as log4j
itself is implemented in terms of the UGLI
(was: Splitting xconf files step 2: the sitemap)
Although the Cocoon sitemap is a really cool innovation it is not
entierly without problems:
* Sitemaps for large webapps easy becomes a mess
* It sucks as a map describing the site [1]
* It doesn't give that much support for cool URLs [2]
In
very pythonish. I like it :-)
...but only with jdk 1.5 :-/
Not AFAIK.
[1] http://logging.apache.org/log4j/docs/ugli.html
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ULogger.java?rev=1.2view=markup
Two paramters ...and variable arguments lists
are only supported
On Thursday 06 January 2005 08:54, Daniel Fagerstrom wrote:
Good post !
But you shouldn't require your user to remember
different URLs for different clients, thats a task for server driven
content negotiation.
Using .html is not especially future proof, should all links become
invalid when
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a lazy-loading
strategy for components. Using this strategy, a component is loaded
(including it's class) only when looked up. This heavily reduces
Cocoon's initialization time.
Cool!
What about the
Sylvain Wallez wrote:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now if
we compare it to the original ECM. Lots and lots of things have changed.
Furthermore, ECM stands for Excalibur Component Manager when this is
the Cocoon Core Service Manager.
So what about using
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi all,
I (once again) did some refactoring in ECM++ to implement a
lazy-loading strategy for components. Using this strategy, a
component is loaded (including it's class) only when looked up. This
heavily reduces Cocoon's initialization time.
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Folks,
Naming ECM++ what's in org.apache.cocoon.core seems a bit weird now
if we compare it to the original ECM. Lots and lots of things have
changed. Furthermore, ECM stands for Excalibur Component Manager
when this is the Cocoon Core Service
69 matches
Mail list logo
