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
Berin Loritsch wrote, On 02/09/2003 19.11:
Geoff Howard wrote:
...
Could someone (Berin?) give an estimate of what the damage would be
even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy components are handled as expected with
Nicola Ken Barozzi wrote:
Berin Loritsch wrote, On 02/09/2003 19.11:
Geoff Howard wrote:
...
Could someone (Berin?) give an estimate of what the damage would be
even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy
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
Carsten Ziegeler wrote:
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.
Immediately after that work can start on the migration.
Berin, you mention above in 3) that the configuration format
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
Berin Loritsch wrote:
Carsten Ziegeler wrote:
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.
Immediately after that work can start on the migration.
Berin, you mention above in 3) that the
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
this:
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
Geoff Howard wrote:
Ok, then I'll be +1. But this raises a point which is for some reason
contentious on the list the last few days:
Wouldn't it be better not to do this change on the 2.1.x line? I am
assuming that this change would break back-compatibility in some points
at least of
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
Berin Loritsch wrote:
Vadim Gritsenko 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 happy to do the
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.
Vadim Gritsenko 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 happy to do the work.
+1 from me.
+1,
31 matches
Mail list logo
