tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bullock <>
Subject Re: Catalina on Avalon
Date Sun, 14 Oct 2001 05:34:13 GMT
Don't -1 it.  For each interface in the wrong spot, 
duplicate the interface in the right spot.  Have 
existing implementations of old interfaces also 
implement the new interfaces.  Deprecate the old 
interfaces, advertising their removal in 4.5, or 
some future ( but definite ) date.  This is best-
practice, if the JDK has anything to say about
evolving an interface while maintaining  backwards

That is a technical solution that takes away the 
'backward compatability' concern.

Now, there are other concerns, like:

  - the effort concern
  - the maintenance concern

that might come into play, but possibly creative 
approaches to these may be found too.

However, I would not like to see:

  - the classloader concern

be sidelined.  Tomcat 4.0 is a flagship of 
server-side Java, and it, of all products, needs
to get its stuff right.  Tomcat 3.x has, quite 
frankly, an abysmal history with class-loading-related

Don't think of it in terms of making Avalon happy ...
think of it in terms of Avalon having discovered an
issue generic to all persons who wish to embed

Don't think of it as a pain in the neck either ...
this issue is obviously one that needs to be thought
of 'next time', and as such is deserving of analysis, 
and a quick entry in the 'new project FAQ'.


On Sat, 13 Oct 2001, Craig R. McClanahan wrote:

> On Sat, 13 Oct 2001, Paul Hammant wrote:
> > If those 39 interfaces and classes were moved to a different
> > package (say org.apache.catalina.api), then a split into two jars would
> > be possible and our dreams could come true.
> >
> > Have I convinced of need?
> >
> I can see why you might wish to have the "39 interfaces and support
> classes" packaged in a separate JAR file.  I haven't yet been convinced
> why they should be moved to a different package, which would break 100% of
> the applications that rely on the current package names.
> > Is 4.0.1 beta too touchy a distribution to instigate package migrations
> > on (however trivial) ?
> >
> Definitely.  In fact, I would -1 a package name change on *any* release in
> the 4.0.x family -- backwards-incompatible changes that are this
> substantial are bad news.

David Bullock -   +61 4 0290 1228 (Architect) (President, SA) (Activist) Sun Cert'd Programmer for Java 2 

"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve
that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process". 

View raw message