tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <>
Subject Re: Catalina on Avalon
Date Sun, 14 Oct 2001 12:06:09 GMT
David & Craig,

Yes I agree, given explanations, that we can't change before a major 
release.  I like the migration solution expecially as it's to do with 
interfaces and multiple inheritance (of sorts) works there.  I am not 
sure if the classloader might still barf if it can't resolve all hard 
wired references though.

We could just seperate into seperate jars at this moment in time, but I 
suspect that "package sealing" might be an issue.  I'm not experienced 
in that..

As it happens I've duplicated the pertinent interfaces to a non-Catalina 
place and used refelction (at great pain) to invoke the actual APIs :-( 
 It works, but exception tracking sucks as reflection is in the way.


- Paul H

>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