. Currently it is possible (and very nice) to provide a
parent ServiceManager to Cocoon. Just want to keep that type of
functionality.
-pete
--
peter royal
On Jun 6, 2005, at 9:29 AM, Vadim Gritsenko wrote:
The only difference is the boot phase of Cocoon. We currently use
LogKit hardcoded there as well; this dependency will be removed. This
allows to run Cocoon without the logkit.jar.
Assuming boot phase uses servlet context logger; +1
+1
[X] there is a chance I gonna make it
-pete
On Mar 18, 2005, at 5:19 PM, Antonio Gallardo wrote:
Try to switch to ehcache. I hear some ratings to the slowness of jcs
cache
(the default cache system in in 2.1.5.1). BTW in 2.1.6 I think the
default
cache system is ehcache, one more reason to move to 2.1.6 ;_).
he's already using
On Feb 11, 2005, at 1:51 AM, [EMAIL PROTECTED] wrote:
+ | NOTE: not all subcategories are defined in this file. Not
defined
+ | subcategories will be created automatically and they will
inherit
+ | the settings of the parent subcategory. When defining a
subcategory
+ |
On Jan 6, 2005, at 3:10 AM, Carsten Ziegeler wrote:
the only difference is that we move away from LogEnabled
and that we directly use an existing logging api.
I'd be vehemently -1 on a change to tie cocoon to a concrete logging
api. I like how it only depends on a logging abstraction at the
On Jan 6, 2005, at 9:46 AM, Carsten Ziegeler wrote:
Hmm, I'm a little bit lost in this thread :(
The easiest thing of course would be to just leave everything as it is
and move to a different subject. But using a logging framework that
noone else uses just feels not right for me.
Has anyone a
On Jan 6, 2005, at 5:27 PM, Stefano Mazzocchi 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.
Why can't you write a log4j appender that talks to your system?
I'm not trying to be dense, I'm just trying to understand.
You
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
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
On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote:
With that said, a usable taglib-driven system already exists. Jelly.
If you need taglibs, go with that. No need to re-invent something
different in cocoon.
Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't
that good. See
On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote:
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic
tags nor know how to debug something in
On Oct 30, 2004, at 6:17 AM, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the
On Oct 29, 2004, at 4:41 AM, Carsten Ziegeler wrote:
Yesterday, I wrote a simple replacement which I checked into 2.2:
a simple background thread is initialized that sleeps for a
configured period of time, checks the continuations, sleeps etc.
Now, this solution should work.
The question is now,
On Oct 24, 2004, at 9:45 AM, Giacomo Pati wrote:
In the end when we think of real blocks we need another solution
anyways -
this could be JMX or something else, but it's most likely that it
won't be
IIRC JMX isn't able to visualize behaviour over time (i.e. concurrent
useage of a component over
On Oct 8, 2004, at 3:43 PM, WHIRLYCOTT wrote:
I'm one of the authors of Whirlycache
(http://whirlycache.dev.java.net/) and I'm looking at providing a
Store implementation so that it can be used in Cocoon. Is it correct
that the only interface that we need to implement is
On Sep 28, 2004, at 7:27 PM, Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html
Pier
wow, what do you think it would take to create a CocoonServletNG?
not too much, since we're already event based. maybe treat each
pipeline component
On Sep 8, 2004, at 9:44 AM, URDINA Michal wrote:
I created ear file with about 6 war files. All war files are cocoon
web applications and thus have same WEB-INF/lib directories. The ear
file has apx. 100MB due to duplicity of libraries in WEB-INF/lib's. It
seems reasonable to me to pull up
On Sep 8, 2004, at 11:17 AM, URDINA Michal wrote:
The problem arise only when one web application calls other web
application to generate its output (via getRequestDispatcher.include()
- crosscontext must be enabled). Then both webapps use the same static
field instance in the same thread. And
On Jul 21, 2004, at 7:28 PM, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Since I'm getting more and more bored with my daytime job, I ended up
doing something:
http://wiki.apache.org/cocoon/ButterflyManifesto
Comments are welcome, flames /dev/null.
have you considered picocontainer at all? i would
+1 to remove restrictions on existing objects.
+0 to add cocoon.avalonContext.
On Jun 9, 2004, at 2:50 PM, Berin Loritsch wrote:
included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but
because Cocoon 2.1.5 includes the header
?xml version=1.0 encoding=ISO-8859-1 ?
at the top, MSIE (version 6) renders it as XML. If that header were
not there, everything would be
On Jun 4, 2004, at 4:32 AM, Steven Noels wrote:
- Vadim Gritsenko
+1
-pete
On May 27, 2004, at 9:05 AM, Carsten Ziegeler wrote:
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
current logkit.xml for LogKit).
+1
As long as Cocoon is based on a non-static logging
On Apr 22, 2004, at 12:30 AM, leo leonid wrote:
and what about calling a function
map:when test=invalid-continuation
map:call function=restart
...
/map:call
/map:when
or a saved continuation ?
duh :)
that works perfectly. thanks!
-pete
Yes, resurfacing a topic from last year,
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105231353428562w=2
.. a change I voted -1 on at the time, no less!
He's my current situation, and afaik, a redirect in handle-errors is
what I need, but I may be wrong.
For a particular segment of my
On Apr 20, 2004, at 12:22 PM, Tony Collen wrote:
If a URL with an invalid continuation ID is invoked, I would like to
take the user to the start of the process rather than displaying an
error page. AFAIK, this needs a redirect-to in the handle-errors
block. I can think of several ways of
On Mar 19, 2004, at 1:53 AM, Carsten Ziegeler wrote:
And: if noone volunteers, I can do the move to ECM over the weekend.
So, please cast your votes - and please, now flame wars about Avalon
this time. Thanks.
+1, flip back to ECM.
-pete
On Jan 22, 2004, at 10:58 AM, Antonio Gallardo wrote:
1- Cocoon will don't throw any exception when this happen.
-1
2- Log the event at INFO level.
-0
3- Log the event at DEBUG level.
+1 (and into its own special logger too)
-pete
On Jan 14, 2004, at 1:10 PM, Jorg Heymans wrote:
How is setting a breakpoint different from inserting a logging
statement? Breakpoint locations need to be carefully chosen as well
with strategy. Ofcourse if you get it wrong you don't loose much
time, just reset and rerun, no recompiling
On Jan 2, 2004, at 6:08 PM, Hunsberger, Peter wrote:
show and makes perfect sense in the flow script. So I coded a flow
script with statements like:
cocoon.sendPage( run/_page/ + collection, {
layout_type_preference : list } );
It seems to me that this really needs to be refactored into some
On Dec 9, 2003, at 4:32 PM, Vadim Gritsenko wrote:
More i18n related classes - XMLResourceBundleFactory and
XMLResourceBundle.
I'd like to remove all XPath business from these classes (as it was
not used anyway) and commit simplier (and faster) SaxBuffer-based
implementation with fixed
On Nov 4, 2003, at 2:28 AM, Sylvain Wallez wrote:
Jelly is not currently used in Cocoon. The idea is interesting, but it
also means a rewrite of a large part of the sitemap engine, and
doesn't give an immediate answer to the mixing between components and
container outlined by Berin.
To further
On Nov 4, 2003, at 1:12 PM, Unico Hommes wrote:
I've done what Peter suggested. It was a minimal change in Cocoon class
and SitemapLanguage class. I've also verified that Fortress also makes
the LoggerManager available from the ServiceManager. I believe we
should
fix this now instead of later and
On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
Anyhoo, the basic solution is to either build a tree/graph of pure
components
or a tree/graph of pure beans. Either solution will work. We need to
get rid
of the need for the LifecycleHelper type class. I would lean more
toward the
bean
On Nov 2, 2003, at 7:00 PM, Ugo Cei wrote:
Groovy looks very interesting indeed. What it currently lacks WRT
Rhino-based Javascript is continuations. The really important part of
Cocoon's Flowscript is continuations, not the Javascript syntax. If it
had continuations I might consider switching
On Oct 31, 2003, at 12:32 PM, Unico Hommes wrote:
Is this the way it's done in Fortress too? I vaguely remember it passes
the LoggerManager in the Context object? I would prefer the way
Fortress
exposes the LoggerManager for consistency with 2.2.
I'm unsure of how exactly Fortress handles the
On Oct 29, 2003, at 6:41 AM, Vadim Gritsenko wrote:
No problem at all; for compatibility reasons it makes sense to revert
the change. Unico, do you know what change caused this?
I believe I am the guilty person :)
In the removal of LogKitManager / LogKitManageable, the sitemap no
longer has a
Currently, the CallFunctionNode returns redirector.hasRedirected() as
its result during processing. Its redirector is an instance of a
ForwardRedirector.
Inside a flowscript, you can do cocoon.redirectTo to redirect the user
to a new page, but that redirects using the environment directly, not
On Tuesday, September 9, 2003, at 03:30 PM, Joerg Heinicke wrote:
Ok, done. The vote for the change was unambiguous. Please review my
commits and change the code if necessary.
Done. your changes mirrored mine for the most part, and I just layered
a few more on top (complete eviction of
Anyone opposed to removing the usage of the LogKitManagable interface
from HEAD?
The impact is that Loggable components would no longer be able to
receive a logger, and on the flipside, Log4J support will be much
easier to implement as all logging-impl specific code is then in
CocoonServlet,
On Tuesday, September 9, 2003, at 12:34 PM, Joerg Heinicke wrote:
Hello Peter,
we already have this:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106215953707243w=2
and this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730.
If it's wished I can do the change again and commit it
On Thursday, July 31, 2003, at 01:18 PM, Geoff Howard wrote:
Since we coordinate with Excalibur, can't we just ask if it is ready
for a bugfix release?
Berin? Peter Royal?
thread started on [EMAIL PROTECTED] to get you a release :)
-pete
On Thursday, July 31, 2003, at 02:07 PM, Berin Loritsch wrote:
Resource: http://gump.covalent.net/log/index.html
(Note that this is the only GUMP server with today's results so far)
Good news: The Excalibur XMLUtils and Store are no longer breaking
Cocoon's GUMP
run.
Bad news: Jing
44 matches
Mail list logo
