cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Lorenz" <>
Subject Re: Is Cocoon unstable?
Date Wed, 07 Aug 2002 13:33:00 GMT
----- Original Message ----- 
From: "Carsten Ziegeler" <>
To: <>
Sent: Wednesday, August 07, 2002 2:05 PM
Subject: RE: Is Cocoon unstable?

> Jens Lorenz wrote:
> > 
> > I've to agree on this. Instable not with the meaning of crashes
> > but with the meaning of fast changes of API interfaces.
> > 
> > I can even come up with a quite good example.
> > 
> > The move of the Source interface from Cocoon to Excalibur.
> > 
> OK, I agree with you - only partly - because these are changes
> between the 2.0.x series and 2.1. As 2.1-dev is called alpha
> it's not intended for production environments.

You're right. But I would distinguish between production and
development. There are enough improvements for me to use
2.1 for research and development, and use 2.0.3 for production
and projects.
For example inputmodules together with sitemap integration
are a great feature, which also would fit into 2.0.x.
(AFAIR InputModules are in scratchpad for 2.0.x but not
integrated with sitemap, not even with TreeProcessor)

> > For our document managment system we invented and extended
> > Source interface with some extra functionality. So that we
> > could integrate nicely with existing components (generator
> > and reader in particular), but use extended functionality
> > by just doing "instanceof ExtendedSource".
> > 
> > Our source still works with 2.1, but since it is wrapped up
> > in another compatiblity class the instanceof statement fails.
> > Even worse, there is no way to get at our wrapped (old) Source.
> > 
> > One solution we've developed is to create a (JDK 1.3 only)
> > dynamic proxy which replaces the Wrapper classes and still
> > implements all interfaces of the wrapped Source thus allowing
> > it to be used the old and the new way.
> > 
> > Another solution is to develop a new ExcaliburSource, but this
> > way we're unable to use it with 2.0.x. It doesn't even compile.
> > 
> > So essentially we've to maintain two versions. One for 2.0.x and
> > one for 2.1.x. (and that's a PITA)
> Ok, agreed - if you have any suggestions how to improve the wrapper
> classes to avaid such problems, let us know.

Will submit a patch with short description via bugzilla. Probably
needs a bit polish and works only one way, but works as a basis.

> > And the Source is only one example. 
> > Another is Loggable vs. LogEnabled.
> > 
> Loggable still works and will work in 2.1 - so no need to upgrade.

LogEnabled is great since I could use Log4J then and log to the
syslog facility and mail admins upon fatal errors.

> I understand your concerns and know that this is a PITA, but it has
> nothing to do with an unstable 2.0.x series - and that's what I'm
> currently focusing on.

Well, updating an application from one 2.0.x to the next version
took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
to 2.0.2.
And the errors were more subtle than just a missing method during
compilation. Can't remember a particular one though.

> If there are such hard upgrade paths for upgrading to 2.1 (which is
> still alpha, so I stronlgy suggest to not upgrade) then we should
> detect them and provide solutions for it (at least when 2.1 hits beta).


> The wrapper classes for the source objects are one step.

Will come by BugZilla.

> Thanks
> Carsten




jens.lorenz at interface-projects dot de

interface:projects GmbH                             \\|//
Tolkewitzer Strasse 49                              (o o)
01277 Dresden                               ~~~~oOOo~(_)~oOOo~~~~

To unsubscribe, e-mail:
For additional commands, email:

View raw message