See intermixed. On 25 Feb 2002, Christopher K.St.John wrote:
> Date: 25 Feb 2002 17:30:44 -0800 > From: Christopher K.St.John <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 > > Aaron Smuts wrote: > > > > What I'd like would be a Jakarta version of something small > > and simple like the oldest available Jetty version. > > > > I'll take a look. > > > > Sounds like you'll have trouble when the parent package > > changes. You need something new and separate. > > > > Well, the org.apache.catalina package is fairly clean, > and gives the impression that it will stay that way. It > does depend on o.a.c.deploy, but those are mostly little > struct-like utility classes for use during Digestion. > That's correct. The alternative was creating lots of "add" and "set" methods on the Context interface that took tons of parameters, not just one. For things like <security-constraint>, that approach is not really reasonable -- you need a structure no matter what. > It's classes like StandardWrapper that worry me. It > comes very close to being generic, but has a hardcoded > cast of its Context to StandardContext. It looks an > awful lot like the cast was introduced during the > addition of Filters in order to avoid an api change > to the Context interface. Coupling StandardWrapper to > StandardContext isn't necessarily unreasonable, > especially if StandardWrapper was never meant to be > used outside the whole StandardEngine/Host/Context/Wrapper > setup, but it does signal that the Catalina core > classes are not meant to be used outside the normal > Catalina channels. > Within a particular package (org.apache.catalina.core), I don't see a problem with the classes depending on each other's insides -- the package as a whole is designed, as a unit, to provide the required functionality for that package. Internal references from one package to another (say, org.apache.catalina.realm to org.apache.catalina.core) are much less desireable. Most of them were added after the fact, to avoid breaking backwards compatibility. But, it might be time to bite that bullet (see below for more thoughts). > I'm worried that the same sort of thing will happen > with, for example, the realm and authorization packages. > If it does, there's really no point in having MinimalTomcat > use any of the Catalina classes at all except through cut > and paste. > > Can one of the Catalina architects (Craig?) comment? > Is it reasonable to try to use Catalina as a framework > like that? Or am I swimming against the tide? > It would be relatively straightforward to eliminate nearly all of the cross-package references (other than o.a.c to o.a.c.deploy), if we're willing to add the corresponding methods to the interfaces in org.apache.catalina and require all such implementations to support them. Of course, this breaks any existing implementations of things like org.apache.catalina.Context, and -- as the folks working on the web connectors have found -- even small changes like this make it difficult to write code that works on both 4.0.x and the most recent HEAD branch code. Is it appropriate to go through the exercise of identifying the offending cases and defining proposed changes to implement them? Yah, it's definitely time for that to happen. Are we ready to bite the bullet and break backwards compatibility on the o.a.c interfaces in some 4.x release (as opposed to possibly waiting for a 5.0 release)? That's probably something we want to talk more about. An additional, more subtle, cross-package dependency is probably also there -- assumptions about the implemented functionality, or the expected order of method calls, that might not always be clearly stated in the method JavaDocs. We'll want to review the code for these kinds of cases as well. > > In any case, tomorrow I'll whip up a sourceball of the > current MinimalTomcat code and stick it out on the net > somewhere. > > I'd like to see what you've done so far. Craig > -- > Christopher St. John [EMAIL PROTECTED] > DistribuTopia http://www.distributopia.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
