Stefano Mazzocchi wrote:
:) Sounds good to me. Now what do you think of using the
things from
Avalon that are good (for us)? Now, I think, some of the interfaces (for logging, contextualization, initialization) are good
and we could
directly use them instead of building just a clone of them.
There are two issues here, Carsten. One is about the present and another is about the future. Present indicates that reusing what's available is great, future indicates that if we keep dependencies on
org.apache.avalon.* namespace we either end up forking it or, more likely, we have potential classloading collision issues in the future with things that avalon might produce.
remember the rhino classloading problem with weblogic? same thing.
Sure.
I strongly suggest that we start with org.apache.cocoon.* to avoid these problems down the road (including, yes, gump problems)
Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from Avalon interfaces to Cocoon
interfaces which are more or less the same but just use a different
package. In that case these components run in Cocoon but not in any
other container anymore that provides Avalon compatibility. And
that's imho bad. Not every project uses Cocoon, so it's absolutely preferable to have components that I can use in several projects.
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 the idea of a class-granular component is bullshit. APIs do that for you. want a portable parser? use JAXP. want a portable xslt transformer? use JAXP. want a object repository? use JCR.
The valuable component oriented paradigm is at the webapp level and there is no way you can reuse cocoon blocks in a container that is not cocoon.
At the class level, avalon components are normally a class thin wrapper around an API. And, if not, they soon migrate until they become that! It's not exactly something I would scream and yell if I had to rewrite in different containers.
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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
