Giacomo Pati wrote:
Ok, I've checked whether the jetty-start.jar can help simplify the
cocoon.sh/cocoon.bat combo. I've come to the conclution that either the
jetty-start.jar nor our Loader class will be able to overcome the pain
to maintain 2 separate start scripts for the two main OS
The windows script now runs again, but does not have JMX support yet and
commons logging is started in debug mode, so you'll get a lot of
messages on startup of Cocoon - but at least it runs :)
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
Il giorno 29/dic/05, alle ore 23:45, Sylvain Wallez ha scritto:
Ears aren't deaf, but on vacation :-)
Going to be deaf in a couple of days due to firecrackers anyway ;)
I don't understand why you need a ThreadLocal. Isn't a class member
good enough?
How would a class member work with
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ]
Ugo Cei updated COCOON-1726:
Attachment: patch.txt
Handling of 404s.
Don't crash with a NPE if some headers missing.
Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ]
Ugo Cei updated COCOON-1726:
Attachment: (was: patch.txt)
Implementation of Source that supports conditional GETs
---
Key:
Just as reminder:
a) please add all changes to a status.xml (of course there are
exceptions like fixing typos etc.)
b) Starting with 2.2 we have separate status files for each block, so if
you're changing something in a block, add it to the status.xml of that
block and not in the global
Ugo Cei wrote:
Il giorno 29/dic/05, alle ore 23:45, Sylvain Wallez ha scritto:
I don't understand why you need a ThreadLocal. Isn't a class member
good enough?
How would a class member work with multiple threads?
I see. This is because the HttpSource is referenced by the
Il giorno 30/dic/05, alle ore 16:09, Sylvain Wallez ha scritto:
I don't understand why you need a ThreadLocal. Isn't a class
member good enough?
How would a class member work with multiple threads?
I see. This is because the HttpSource is referenced by the
HttpSourceValidity, right? Now
We took some thread dumps of our product when it was running normally.
It was interesting in that we still saw in almost every stack trace the
portal calling castor which was in the class loader throwing a
ClassNotFoundException. I then stepped through the sample site and have
discovered that
Hi all,
The W3C recently set up an XML Processing working group[1] whose
primary goal is to define an XML processing language (i.e. pipelines).
AFAIU the group's direction is not to reinvent something new, but to
standardize what already exists, taking as inputs two pipeline languages
that
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected
On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
Hi all,
The W3C recently set up an XML Processing working group[1] whose
primary goal is to define an XML processing language (i.e. pipelines).
Wow, innovation at work! :-)
AFAIU the group's direction is not to reinvent something new, but
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe,
On 12/30/05, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
+ 1 with comments below
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements
Sylvain Wallez wrote:
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
The test m != null is useless, as dispose should never be called
twice. Removes 2 lines :-)
No, it is not useless - if some exception happens during the init phase
of a
OK. I figured out how to use the matches attribute and was able to
verify that it doesn't throw ClassNotFoundExceptions all the time. I'll
do a little load testing next to see what kind of difference it makes on
throughput.
Ralph Goers wrote:
We took some thread dumps of our product when it
Sylvain Wallez wrote:
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
Isn't that the direction we are headed anyway?
Gianugo Rabellino wrote:
I'm also still not completely sold on factories. Indeed, they work and
they're a brilliant solution, but am I the only one smelling hack and
workaround?
I didn't like this when I first saw it either. My thought was to have
the Generator, etc. be thread safe and have
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that it would be
Castor seems to have a lot of useful little hacks - I just found out,
that we can prevent castor from checking for default constructors which
I really needed for 2.2 - it's there, you only have to find out how to
configure it :). Im curious how the matches configuration looks like :)
Carsten
Ralph Goers wrote:
Sylvain Wallez wrote:
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
Isn't that the direction we are headed anyway?
Yes, of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Dec 2005, Carsten Ziegeler wrote:
Date: Fri, 30 Dec 2005 09:21:45 +0100
From: Carsten Ziegeler [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [2.2] Unable to start Cocoon with Win
Giacomo Pati
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Date: Fri, 30 Dec 2005 14:21:07 -0500
From: Vadim Gritsenko [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Carsten Ziegeler
Giacomo Pati wrote:
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection
Ralph Goers wrote:
...
when
bind-xml auto-naming=deriveByClass
is used, Castor starts making up names and trying to load them.
...
I expect, when the resource pool is exceeded the
class loader is completely overstressed and the system comes to a
grinding halt. It doesn't actually stop, but
On 12/30/05, Giacomo Pati [EMAIL PROTECTED] wrote:
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
Other issues that I'm going to dive into are redirects and cache
control. I'm afraid that if we want to make Cocoon into a well-behaved
participant in a Web 2.0 world, we have lots of work to do.
Indeed. My impression is that this work
Vadim Gritsenko wrote:
Ralph Goers wrote:
...
when
bind-xml auto-naming=deriveByClass
is used, Castor starts making up names and trying to load them.
...
I expect, when the resource pool is exceeded the class loader is
completely overstressed and the system comes to a grinding halt. It
I'll check them in as soon as I get some testing done. Shouldn't be too
long.
Carsten Ziegeler wrote:
Castor seems to have a lot of useful little hacks - I just found out,
that we can prevent castor from checking for default constructors which
I really needed for 2.2 - it's there, you only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Date: Fri, 30 Dec 2005 15:06:34 -0500
From: Vadim Gritsenko [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Giacomo Pati
Giacomo Pati wrote:
I'm almost sure that Cocoon 2.2 will stay 1.4 compatible for another
year at least. So an approach with Xdoclet or qdox (see Maven2's
Mojo's) will be the only way to go ATM.
Have a look at http://retrotranslator.sourceforge.net/
Real JDK 1.5 annotations (and more) with
Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge
Sylvain Wallez wrote:
Leszek Gawron wrote:
I have an impression that messages widget should clear for every for
redisplay but:
fd:form xmlns:fd=http://apache.org/cocoon/forms/1.0#definition;
xmlns:i18n=http://apache.org/cocoon/i18n/2.1;
On Dec 30, 2005, at 12:09 PM, Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements
On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of
Torsten Curdt wrote:
On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface
cocoon-block-forms-compile:
Compiling 7 source files to
C:\cocoon\BRANCH_2_1_X\build\cocoon\blocks\forms\dest
C:\cocoon\BRANCH_2_1_X\src\blocks\forms\java\org\apache\cocoon\forms\util\JavaScriptHelper.java:60:
On Saturday 31 December 2005 11:47, Berin Loritsch wrote:
Also note that Pico can work with setter injection
as well as constructor injection
So does Spring.
Cheers
Niclas
On Saturday 31 December 2005 02:09, Carsten Ziegeler wrote:
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
Yipee, yet another thread on a new
41 matches
Mail list logo
