I'm trying to produce my own Context implementation in Tomcat 5.0.28, while otherwise keeping as many of the standard classes as possible. It's not much fun; a couple of classes in catalina.core have package visibility, and several others refer to StandardContext explicitly. However, quite reasonably, StandardContext is not designed for subclassing - many/most of its variables are private, and some crucial decision points are buried deep within private methods that do many other things.
None of this is a surprise, as Tomcat is intended to be a reference implementation of the specs, and what I'm doing isn't a part of that. All fair enough! It does make things very difficult when you want something that is like StandardContext but with a couple of differences, as *either* you have to copy most of catalina (with appropriate maintenance headaches) *or*: - You have to copy the entire implementation of StandardContext, as it is not designed for subclassing; - You have to put your copied class in the catalina.core package, so that it has access to the classes with package visibility; - You *still* have to make your copied class be a subclass of StandardContext, as otherwise the explicit references to StandardContext elsewhere in Catalina cause errors. - You are then trying to deal with StandardContext's calls to super() in methods that you have to keep in your subclass (they refer to your local variables), where your subclass and StandardContext both try to do the same thing. Is there a case for making it easier to create non-standard Contexts in Tomcat? Possibilities might include: 1. Construct an interface for the internal contract of a Context, and make StandardContext implement that interface. This breaks the dependency on implementation inheritance. This, to me, is the key one, as it means that a copy of StandardContext can work. Arguably, it's also good design practice. 2. Possibly relax the visibility on the package-specific classes. Less useful - they've got package visibility for good reason, and it's possible to get round this issue in other ways. 3. Possibly refactor StandardContext in a couple of places to bring key decision points into their own methods that can be overridden by subclasses. Least useful, I think. I've seen plenty of comments from the Tomcat maintainers that mods to Tomcat that don't help it to achieve its goal of being a reference implementation won't be considered. I suspect that all of these mods fall outside Tomcat's goal, but I want to run the first one - the interface separation - past them, simply to confirm or deny that. I'd be happy to contribute the interface and mods for 5.0 and/or 5.5, but want to check first whether it's worth doing, or whether the maintainers will simply vote it out of the codebase. Comments welcome. - Peter -- Peter Crowther, Director, Melandra Limited John Dalton House, 121 Deansgate, Manchester M3 2AB t: +44 (0)161 828 8736 f: +44 (0)161 832 5683 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]