You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/07/07 09:16:07 UTC
[RT] Migrating to Fortress
I think its time to think again about migrating to Fortress for 2.2.
By migrating to Fortress I just mean using Fortress as an ECM replacement.
So without using meta-data etc. Fortress is able to use the ECM
configuration,
so from the user pov there shouldn't be a difference.
So, why migrating at all? Fortress has some benefits over ECM. I think
Berin mentioned an improved pooling code etc. We could use setter and
constructor injection if we want etc.
In addition, the development of Fortress will continue over at Excalibur,
so if something interesting will happen there we can benefit from it.
But my main point currently is the use of own lifecycle interfaces. It
seems that perhaps we will someday move away from the Avalon based world
(let's not discuss this here if we will or wont, please!). Even if that
will not happen, we will need additional core functionality that is
not available in Avalon (a different lookup etc.).
With Fortress we can add our own marker interface into the component
lifecycle and for example introduce a (very silly example!)
CocoonLogEnabled interface. If a component implements this, it
gets the Cocoon logger (this is just an example!)
If we need this functionality for blocks in Cocoon 2.3 (or whatever
version), we could start adding the interfaces (when they are solid)
to Cocoon 2.2.x and people can start migrating their components
slowly. So, when the real blocks are out, its much easier to
migrate the code (if required) as this has already happened (for parts).
There shouldn't be any compatibility problems. The only thing I'm not
so sure about is XSP where ComponentHandlers are used. But I'm sure
we will find a solution for that as well.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
Re: [RT] Migrating to Fortress
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Carsten Ziegeler wrote:
>I think its time to think again about migrating to Fortress for 2.2.
>
>
+1 from me
Chris.
RE: [RT] Migrating to Fortress
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> > <>I forgot that if we move to Fortress, we don't need
> selectors anymore.
>
>
> Argh. I just hope that although we no more _need_ them,
> there's a compatibility layer for all the code out there that
> uses selectors.
>
Sure! I said "we don't need selectors anymore" not "selectors
are not supported anymore" :) You can use selectors the way
you used them, but you don't have to anymore.
So, again, a smooth migration path.
Carsten
Re: [RT] Migrating to Fortress
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>I think its time to think again about migrating to Fortress for 2.2.
>
>By migrating to Fortress I just mean using Fortress as an ECM replacement.
>So without using meta-data etc. Fortress is able to use the ECM configuration, so from the user pov there shouldn't be a difference.
>
>
That's good, as transparent migration is a key point.
>There shouldn't be any compatibility problems. The only thing I'm not so sure about is XSP where ComponentHandlers are used. But I'm sure we will find a solution for that as well.
>
>
ComponentHandler is called in JavaProgram to create a pool for instances
of the XSP's Class. If Fortress allows to create a similar abstraction
from a Class object, migration shouldn't be a problem.
I'll also update the TreeProcessor to remove the need for Recomposable
which was actually a misuse of the underlying concept.
> <>I forgot that if we move to Fortress, we don't need selectors anymore.
Argh. I just hope that although we no more _need_ them, there's a
compatibility layer for all the code out there that uses selectors.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Migrating to Fortress
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> I think its time to think again about migrating to Fortress for 2.2.
+1
Best Regards,
Antonio Gallardo
Re: [RT] Migrating to Fortress
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>I think its time to think again about migrating to Fortress for 2.2.
>
>By migrating to Fortress I just mean using Fortress as an ECM replacement.
>
>
I've got no objections to this; hopefully excalibur community takes off
and will support fortress for the time frame we need it.
Vadim
RE: [RT] Migrating to Fortress
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I forgot that if we move to Fortress, we don't need selectors anymore.
Carsten
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Wednesday, July 07, 2004 9:16 AM
> To: Cocoon-Dev
> Subject: [RT] Migrating to Fortress
>
> I think its time to think again about migrating to Fortress for 2.2.
>
> By migrating to Fortress I just mean using Fortress as an ECM
> replacement.
> So without using meta-data etc. Fortress is able to use the
> ECM configuration, so from the user pov there shouldn't be a
> difference.
>
> So, why migrating at all? Fortress has some benefits over
> ECM. I think Berin mentioned an improved pooling code etc. We
> could use setter and constructor injection if we want etc.
> In addition, the development of Fortress will continue over
> at Excalibur, so if something interesting will happen there
> we can benefit from it.
>
> But my main point currently is the use of own lifecycle
> interfaces. It seems that perhaps we will someday move away
> from the Avalon based world (let's not discuss this here if
> we will or wont, please!). Even if that will not happen, we
> will need additional core functionality that is not available
> in Avalon (a different lookup etc.).
> With Fortress we can add our own marker interface into the
> component lifecycle and for example introduce a (very silly
> example!) CocoonLogEnabled interface. If a component
> implements this, it gets the Cocoon logger (this is just an example!)
>
> If we need this functionality for blocks in Cocoon 2.3 (or
> whatever version), we could start adding the interfaces (when
> they are solid) to Cocoon 2.2.x and people can start
> migrating their components slowly. So, when the real blocks
> are out, its much easier to migrate the code (if required) as
> this has already happened (for parts).
>
> There shouldn't be any compatibility problems. The only thing
> I'm not so sure about is XSP where ComponentHandlers are
> used. But I'm sure we will find a solution for that as well.
>
> Carsten
>
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://www.osoco.net/weblogs/rael/
>
>