on.
-- Andreas
Thanks, Ugo!
Carsten
-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 20, 2004 9:13 AM
To: [EMAIL PROTECTED]
Subject: Re: ECM++
Il giorno 20/ott/04, alle 08:34, Carsten Ziegeler ha scritto:
Should I switch 2.2 to use ECM++ now or do we first want
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work anymore ...
See my reply to that :) - now 2.2 is in development
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work anymore ...
See my reply to that :) - now 2.2 is in
Carsten Ziegeler wrote:
I already committed the first version of ECM++ into the whiteboard.
Now, the question is how do we want to continue?
I already integrated it into 2.2 on my computer. It requires only a few
changes in Cocoon.java and in some treeprocessor classes.
Should I switch 2.2 to use
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
I already committed the first version of ECM++ into the whiteboard.
Now, the question is how do we want to continue?
I already integrated it into 2.2 on my computer. It requires
only a few
changes in Cocoon.java and in some
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
Yes, in general you're right, but readding Composable etc. is
nearly the same work then refactoring XSP which should be very
simple. So I would opt for saving the extra work of readding things.
Sounds reasonable, do what you find best :)
On 20 Oct 2004, at 07:34, Carsten Ziegeler wrote:
Should I switch 2.2 to use ECM++ now or do we first want to write some
tests?
IMO switch now...
Pier
smime.p7s
Description: S/MIME cryptographic signature
Il giorno 20/ott/04, alle 09:33, Carsten Ziegeler ha scritto:
Yes, it's stable now - the code could be optimized a little bit here
and there, but I would do this after we have the tests.
Are we targetting JDK 1.4 for this release? If so, can I change
CascadingRuntimeException to RuntimeException?
Ugo Cei wrote:
Il giorno 20/ott/04, alle 09:33, Carsten Ziegeler ha scritto:
Yes, it's stable now - the code could be optimized a little
bit here
and there, but I would do this after we have the tests.
Are we targetting JDK 1.4 for this release? If so, can I
change
Carsten Ziegeler wrote:
...
Should I switch 2.2 to use ECM++ now
+1
(ECM++ is not buildable standalone, you have to copy the classes into
the Cocoon src directory - but we could add the required libs if needed).
IIUC you will integrate it in the build as a step to be involked before
the Cocoon
Nicola Ken Barozzi wrote:
IIUC you will integrate it in the build as a step to be
involked before the Cocoon build, right?
No, it's just some more classes in the core; we don't have the need
to have a separate jar/product.
Carsten
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2? The Cocoon stable branch is *2.1* and
trunk is the *development branch*, where we can break things. Other
On 20 Oct 2004, at 15:02, Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2?
FWIW, the publishing part of Daisy does this as well. But
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2?
The stable branch of Lenya uses Cocoon 2.1.5. Only the development
branch with an ETA
Steven Noels wrote:
On 20 Oct 2004, at 15:02, Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2?
FWIW, the publishing part of Daisy does
Andreas Hartmann wrote:
Steven Noels wrote:
FWIW, the publishing part of Daisy does this as well. But that
shouldn't refrain people from breaking HEAD since we advise people
only to synchronise SVN when we feel comfortable ourselves, and we
package ship Cocoon in our binary releases rather
Steven Noels wrote:
On 20 Oct 2004, at 15:51, Sylvain Wallez wrote:
But that should not refrain us (cocoon devs) to do what we feel the
need to in the trunk, even if that prevents other projects to update
their snapshots during an unstability period that may exist.
If we end up +1-ing each
that there is no need of a separate jar in the distro.
I do think though that the compilation of ECM++ must be done *before*
the others, so that things remain properly layered.
What about using this?
http://ant-contrib.sourceforge.net/tasks/compilewithwalls.html
--
Nicola Ken Barozzi [EMAIL
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2?
I was not able to backport the @passthrough attribute on mounts to the
2.1 branch :-(
-)
I agree that there is no need of a separate jar in the distro.
I do think though that the compilation of ECM++ must be done *before*
the others, so that things remain properly layered.
I agree, only this way we can be sure that there are no cross-dependencies
between layers.
What about using
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off until we are at least in
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now
[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared that I'll
get on your nerves when something does not work anymore ...
See my reply to that :)
Carsten Ziegeler dijo:
Should I switch 2.2 to use ECM++ now
+1
We can later fix XSP!
Best Regards,
Antonio Gallardo
Ugo Cei wrote:
Il giorno 20/ott/04, alle 09:33, Carsten Ziegeler ha scritto:
Yes, it's stable now - the code could be optimized a little bit here
and there, but I would do this after we have the tests.
Are we targetting JDK 1.4 for this release? If so, can I change
CascadingRuntimeException to
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Hmmm, I'm not sure if I like this.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2? The Cocoon stable branch is *2.1* and
trunk is the *development branch*, where we can
Stefano Mazzocchi wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as
possible and in general do all the big changes on branches.
Hmmm, I'm not sure if I like this.
Quasi-static development, reversible changes, early testers that can
test the
Carsten Ziegeler wrote:
...
The basic idea is to build an own version of ECM
+1
Rub a dub dub
http://www.joelonsoftware.com/printerFriendly/articles/fog000348.html
In Defense of Not-Invented-Here Syndrome
http://www.joelonsoftware.com/printerFriendly/articles/fog07.html
Things You
On 18 Oct 2004, at 10:57, Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is
or modifications from version to version until we reach our
goal. This could e.g. be done by building ECM++ for Cocoon 2.2.
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
On 18 Oct 2004, at 11:57, Carsten Ziegeler wrote:
Thoughts? Comments?
I like. Not for compatibility reasons, but merely for untying us from
the ECM knot. If and when we get to move Cocoon further along the road
of our own thing, at least we will have a stable baseline to fall back
to.
/Steven
Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
the minimum functionality.
Hmmm, I like it. But I
Ugo Cei wrote:
Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and
build a complete container in Cocoon that provides the minimum
Il giorno 18/ott/04, alle 14:14, Carsten Ziegeler ha scritto:
I totally agree, we should have tests. Now, I'm not sure what the
best way to do this is. As I already started :), I think finishing
this first phase, committing it, then adding tests, continuing is
at least for me a little bit easier.
. This could e.g. be done by building ECM++ for Cocoon 2.2.
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
the minimum functionality.
This would be:
- using the same
Le 18 oct. 04, à 11:57, Carsten Ziegeler a écrit :
...I just started with this approach and could finish it in the next
days
if people think it is worth going this way. It would give 2.2 more meat
as well...
I like the idea of having our own version of ECM, and if you have code
already I'd say
Vadim Gritsenko wrote:
Sounds good with the only exception that I'm not sure about
instrumentation vs JMX part. Anybody have ideas how Cocoon
should be integrated with JMX? What management console we
would use then?
I think this is an open topic. The first thing imho is to remove
the
Il giorno 18/ott/04, alle 14:29, Vadim Gritsenko ha scritto:
And what is wrong with that approach (of just using it)? Beside
community issues there were no technical issues which would force us
to move people out of current component management infrastructure.
Right?
Personally, I think there
On Monday 18 October 2004 17:57, Carsten Ziegeler wrote:
But perhaps this idea is totally foolish?
Not at all.
Very pragmatic, well balanced and sensible thing to do.
And it seems you have a lot of support, and if that support is translated in
to coding help, we are all grateful.
Cheers
On Monday 18 October 2004 20:48, Ugo Cei wrote:
As we cannot depend on the Avalon community for mending some of these
deficiencies, I heartily applaud Carsten's effort towards bringing that
code inside, so we can at least try fixing them ourselves.
Small correction; ECM
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be
Sylvain Wallez wrote:
As long as the compatibility layer remains, I don't see what
invites people to migrate to new features. Is it just because
new features will be available? Then having them because of
an updated old container or because of a newer one with a
legacy layer isn't very
are getting more
independent from Avalon/Excalibur without loosing anything.
Yup. That's why I have nothing about forking ECM in our repo. But I hope
to prove it's actually even not necessary.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org
I encourage Carsten to wholeheartedly undertake this task. I really
only have two thoughts.
1. I don't think it is a good idea to keep the same package names for
ECM if they are moved into Cocoon. That could be very confusing. I
realize it would be a lot of work to rename existing classes
Carsten Ziegeler wrote:
I just started with this approach and could finish it in the next days
if people think it is worth going this way. It would give 2.2 more meat
as well.
But perhaps this idea is totally foolish?
Thoughts? Comments?
+1
Seem like a very reasonable way to go, we both takes
Ralph Goers wrote:
I encourage Carsten to wholeheartedly undertake this task. I
really only have two thoughts.
1. I don't think it is a good idea to keep the same package
names for ECM if they are moved into Cocoon. That could be
very confusing. I realize it would be a lot of work
Goers wrote:
I encourage Carsten to wholeheartedly undertake this task. I
really only have two thoughts.
1. I don't think it is a good idea to keep the same package
names for ECM if they are moved into Cocoon. That could be
very confusing. I realize it would be a lot of work to
rename
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future.
Don't know, if this
Reinhard Poetz wrote:
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the
time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the
minor improvements
or modifications from version to version until we reach our
goal. This could e.g. be done by building ECM++ for Cocoon 2.2.
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container
[repost with correct recipient list]
Carsten Ziegeler wrote:
Hi Stephen,
I had a quick glance at your finder stuff but are absolutely clueless
what I should do with it :) I guess from your description that if this
finder is used inside Merlin I can use the ECM configuration files
for defining my
Hi Stephen,
I had a quick glance at your finder stuff but are absolutely clueless
what I should do with it :) I guess from your description that if this
finder is used inside Merlin I can use the ECM configuration files
for defining my components. Is this right?
Is there any sample etc
through the definition of a finder facility - the facility
specifically address dynamic pull-based service activation
(as per ECM and Fortress)
(b) an experimental implementation of a ECM component - in
particular a component that exposes the ServiceManager as
its service
NOT REPLY [Bug 26269] - Memory leak because of the use of
StaticBucketMap and component.toString() in ECM
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=26269.
ANY REPLY MADE TO THIS MESSAGE
/show_bug.cgi?id=26269
Memory leak because of the use of StaticBucketMap and component.toString() in ECM
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
/show_bug.cgi?id=26269
Memory leak because of the use of StaticBucketMap and component.toString() in ECM
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED
/show_bug.cgi?id=26269
Memory leak because of the use of StaticBucketMap and component.toString() in ECM
Summary: Memory leak because of the use of StaticBucketMap and
component.toString() in ECM
Product: Cocoon 2
Version: Current CVS 2.1
From: Berin Loritsch
If we to start migration to Fortress in 2.2. I don't
see a need in
avoiding this reformatting. If we do it in 2.1.2, then yes,
we should
support old config syntax.
Well, when and where can I get started on 2.2?
I hope soon when we have finished the
with
Fortress as long as the components do not expect ECM itself. In 99% of
the cases this is what happens.
2) LogKitManageable. We can create a Lifecycle extension to handle this
one,
but for future reference, this is best handled via a ServiceManager
lookup.
Fortress natively uses
components are handled as
expected with
Fortress as long as the components do not expect ECM itself.
In 99% of
the cases this is what happens.
2) LogKitManageable. We can create a Lifecycle extension to
handle this
one,
but for future reference, this is best handled via
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the commandmanager
issue discussed in the other thread, I will make a 2.1.1 release this week.
The issue can in fact be fixed immediately by changing the way we use
the
Bruno Dumon wrote:
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the
commandmanager
issue discussed in the other thread, I will make a 2.1.1
release this week.
The issue can in fact be fixed immediately by
Carsten Ziegeler wrote:
m_threadPool.waitWhenBlocked();
to
m_threadPool.discardWhenBlocked();
functionally, this shouldn't change anything (I think), and it will
avoid the problem in PooledExecutor completely. If you have some time
available to try this out, that would be great.
Yes, I just
Berin Loritsch wrote:
Carsten Ziegeler wrote:
m_threadPool.waitWhenBlocked();
to
m_threadPool.discardWhenBlocked();
functionally, this shouldn't change anything (I think), and it will
avoid the problem in PooledExecutor completely. If you have some time
available to try this
changes
slightly.
Can you give a short explaination please?
In Cocoon/ECM we have the following constructs:
regular-component
stuff/
/regular-component
database-selector
jdbc name=foo/
j2ee name=bar/
informix name=baz/
/database-selector
Notice that the regular component has no name/id
Berin Loritsch wrote:
SNIP GOOD EXPLAINS/
Thanks Berin for the info, so with Fortress we can finally forget
the double lookups when selectors were used.
Carsten
) that the configuration format changes
slightly.
Can you give a short explaination please?
In Cocoon/ECM we have the following constructs:
regular-component
stuff/
/regular-component
database-selector
jdbc name=foo/
j2ee name=bar/
informix name=baz/
/database-selector
Without a .roles file would we
beware of snips/
Berin Loritsch wrote:
The above in Fortress would be redone as:
jdbc-datasource id=foo/
j2ee-datasource id=bar/
...
In Fortress, you can do things the old ECM way, or you can incorporate
the ID
to get whichever component you want and bypass the selector completely
like
Berin Loritsch wrote:
Geoff Howard wrote:
Berin Loritsch wrote:
In Cocoon/ECM we have the following constructs:
regular-component
stuff/
/regular-component
database-selector
jdbc name=foo/
j2ee name=bar/
informix name=baz/
/database-selector
Without a .roles file would we even have
Geoff Howard wrote:
Great - I think we're all looking forward to this. I'm trying to get a
handle on upgrade path for current users. Sounds like we could acheive
drop-in support for the old cocoon.xconf format complete with my.roles
etc. but could switch the default cocoon.xconf (or
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.
Ugo
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
From: Berin Loritsch
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
On Tue, 2 Sep 2003, Reinhard Poetz wrote:
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
From: Berin Loritsch
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
Giacomo Pati wrote:
What do you think of the Sept, 15th releasing 2.1.1?
Good for me.
Then someone else than me has to do the release. I can either
do it this week til friday or then three weeks later when I'm
back from vacation.
Currently I prefer this week, but if anyone wants to do it
From: Carsten Ziegeler
Giacomo Pati wrote:
What do you think of the Sept, 15th releasing 2.1.1?
Good for me.
Then someone else than me has to do the release. I can either
do it this week til friday or then three weeks later when I'm
back from vacation.
Currently I prefer
with
Fortress as long as the components do not expect ECM itself. In 99% of
the cases this is what happens.
2) LogKitManageable. We can create a Lifecycle extension to handle this one,
but for future reference, this is best handled via a ServiceManager lookup.
Fortress natively uses
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
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
Berin Loritsch wrote, On 29/08/2003 17.25:
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 :-D
--
Nicola Ken
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.
+1
I will be happy to do the work.
+1 - great!
-Bertrand
From: Berin Loritsch
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 from me
the
work.
+1 from me.
+1, but I (still) would like to hear quick comment on Fortress vs
Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has
done
all the work to move to Fortress, it becomes trivial to host
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.
--
They that give up essential liberty to obtain a
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 you.
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.
I'm scared but I trust you.
From: Berin Loritsch
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 from me too :)
J.
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, but I (still) would like
+1
Carsten
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.
, but I (still) would like to hear quick comment on Fortress vs
Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has done
all the work to move to Fortress, it becomes trivial to host in Merlin.
The main things
101 - 189 of 189 matches
Mail list logo
