cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [Kernel22] How to develop a component?
Date Wed, 07 Apr 2004 07:01:45 GMT
"Stefano Mazzocchi" <> wrote:
> I don't buy this.
> The "component portability" argument is moot, it's a myth, you can't 
> even move components from one container to another in avalon and ECM 
> is deprecated, now even fortress is deprecated.
Sorry, but that's not 100% true. You can use your implementations from
ECM in Fortress (and even in Merlin) without *any* changes to your java
"Only" configuration is different.
And sorry, it's not a myth - it's reality. In our company - and I know 
not only here - we are practicing this like three years now. Introduced 
because of Cocoon we are heavily based on Avalon. And the great thing is 
that these Avalon components work in Avalon containers, in Cocoon and in 
some other containers as well without any problems.

If we don't support them in the next versions, well, we not only have to 
rewrite them but we have to maintain different versions. We can't even use 
wrappers due to the class loading problems you mentioned. And that's very

> <SNIP/>
> > Ok, I think if we decide to use our own versions of the interfaces 
> > it will still be possible to do some hacky things and still provide 
> > compatilibity with the Avalon versions.
> There will be an avalon sandbox for legacy code. There is nothing 
> hacky in that.
Sorry, I wasn't clear above: the sandbox is not hacky. What I meant is that
*if* we decide to support the Avalon interfaces only in the sandbox, it
be possible to plugin a hacky solution that allows to use the avalon
even in our blocks without any classloader problems.

To be honest, I still don't buy the classloader problem theory. I'm just
that we should try to support interfaces like Configurable etc. We have own 
classloaders for the blocks anyway, so it shouldn't be that hard, to solve
problem there.
If  classloading is the only reason against these interfaces than I think we
solve it.
And the dependency is very minimal. It's just a dependency against the
framework api version 4.1.5 - a released version. There is no need in
the development of Avalon.


View raw message