Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Craig R. McClanahan wrote: Internal references from one package to another (say, org.apache.catalina.realm to org.apache.catalina.core) are much less desireable. ... 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. Currently, AuthenticatorBase depends on StandardContext. It's not some deep dependency. AuthenticatorBase just wants to set its debug level to be the same as its Context. There's an instanceof check before the cast, so AuthenticatorBase doesn't actually require that its parent be a StandardContext, but it does require that StandardContext exists. It produces a 'mystery dependency' that is invisible from the outside. I may be preaching to the converted, but mystery dependencies are bad. They make the code brittle and hard to understand. They lead to spaghetti. I reported the dependency as a bug (with a patch) and the bug was changed to a feature request. I suppose it depends on how you look at it. It's certainly a bug for me. There are a couple of ways to fix the problem: 1) Delete the offending code. Easiest, and in this case probably reasonable. You'll lose the debug-setting propagation, but you can always set that manually. It's for debugging so presumably you're messing with the settings any case. My patch did this, I'd like to see it applied. 2) Move setDebug() up to the Context or Container level. They all implement setDebug() anyway, right? And it doesn't break compatibility with old code. Med/long term, this would probably be a good solution. 3) Create a Debug interface. Pretty much everything in Catalina has set/getDebug() methods, not just Containers. But it's overkill. Each new class or interface adds conceptual overhead to the system. I don't think it's worth it. Whether you like the idea of something like MimimalTomcat or not, I suspect writing it will turn up some problems (and solutions) that will improve all of the Catalina code. While we're on the subject of interfaces, what is Context.findRoleMapping() for? I've got it stubbed out in MinimalTomcat, but I'd like to know what I'm stubbing out. It used to be used in HttpRequestBase.isUserInRole(), but the call was replaced by a call to Context.findSecurityRole(). -- 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]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, February 25, 2002 11:18 PM
Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
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.
This is the one that really bit me in porting ApacheConfig to 4.x. And,
as
a result, the 4.x ApacheConfig suffers from the same problem of making
assumptions about the order of method calls. Saying that they might
not
always be clearly stated in the method JavaDocs is a gross
understatement.
Roughly half the time, the start event is fired at the beginning
(allowing
Listeners to change the config), and half the time it is fired at the
end
(allowing Listeners to react to the config). IMHO, the 3.3 event model
is
an improvement: where you have an init event (fired at the beginning
of
the start method), and a start event (fired at the end of the start
method).
It's not random, actually. The start event is sent to the listeners at the
end of the ContainerBase.start method, which is right after all the
children
have been started.
The only problem is with the server and service, where the start event is
sent before (so it's not really useful except to configure things).
Adding a before-start event and before-stop event is doable IMO.
You've basically confirmed what I said above. StandardHost
StandardContext are subclasses of ContainerBase. StandardServer and
StandardService aren't. 50/50. While I (personally) like what the current
4.x API forces me into (which I currently use complex 'sed' scripts to
achieve with 3.3's ApacheConfig), I think that I'm in a very small minority.
If it were possible to have a single Listener on the Server to do everything
(and, even better, only when asked to [@see jkconf in 3.3]), I think that
the ${Server}Config classes would be more popular. I've never pressed for
this for the simple reason that JK2 has it's own auto-config, and changing
the API in the 4.0 branch is dangerous. I just assumed that it would
resolve itself with the release of 4.1.
Remy
--
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]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Bill Barker wrote: Date: Mon, 25 Feb 2002 23:00:07 -0800 From: Bill Barker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 25, 2002 6:25 PM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 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. This is the one that really bit me in porting ApacheConfig to 4.x. And, as a result, the 4.x ApacheConfig suffers from the same problem of making assumptions about the order of method calls. Saying that they might not always be clearly stated in the method JavaDocs is a gross understatement. Roughly half the time, the start event is fired at the beginning (allowing Listeners to change the config), and half the time it is fired at the end (allowing Listeners to react to the config). IMHO, the 3.3 event model is an improvement: where you have an init event (fired at the beginning of the start method), and a start event (fired at the end of the start method). When looking at what it took to set up Catalina's connectors for the run as root scenario, we came to the same conclusion -- ideally, Lifecycle should have included an init() method, and probably a destroy() method as well. At the time we looked, there would have been roughly 40 classes that would need the new methods, plus calls to them in a bunch more, so we chickened out and only implemented init() on the connectors themselves. I'm game to look at this more broadly, but the number of changes required to implement it is pretty significant. As I said, this is IMHO. Attempts to start a flame-war will be quietly ignored. +1. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 8:31 AM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 When looking at what it took to set up Catalina's connectors for the run as root scenario, we came to the same conclusion -- ideally, Lifecycle should have included an init() method, and probably a destroy() method as well. At the time we looked, there would have been roughly 40 classes that would need the new methods, plus calls to them in a bunch more, so we chickened out and only implemented init() on the connectors themselves. I'm game to look at this more broadly, but the number of changes required to implement it is pretty significant. I don't see any great need to re-factor core. All I was suggesting was two events, to make it easier to write Listeners to add functionality. As I stated in another message, there is no reason to do this just for ApacheConfig, since its functionality will be replaced in a few months (when JK2 rolls out). As I said, this is IMHO. Attempts to start a flame-war will be quietly ignored. +1. Craig -- 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]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 5:35 PM To: [EMAIL PROTECTED] Subject: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Aaron Smuts wrote: Date: Mon, 25 Feb 2002 17:58:27 -0500 From: Aaron Smuts [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. TomKitten? :-) Craig -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 5:35 PM To: [EMAIL PROTECTED] Subject: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- 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]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Aaron Smuts wrote: I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. I detest housecats, but I suppose that's not really the point :-) I'm not sure my is generally useful. The basic approach probably is, but maybe not the code. I personally don't really need all the run-time event stuff (not the servlet-spec events, the Catalina internal events). I don't need JSP. I don't need run-time parsing of the config server.xml and web.xml files. I don't need the full-on security architecture (so I don't need facades and I don't need SecurityManager code). I don't need (but kinda want) the JMX management interfaces. Etc. The code I've written is only useful if you're eliminating the exact same set of things I am. Otherwise, you bloat out until you're full-on Catalina again. (OTOH, projects like Galeon managed to find generally useful subsets of Mozilla, so there's an existence proof that such a thing is possible.) But if I'm the only one use Catalina as a framework instead of as a monolithic servlet container, it isn't going to work. There's too much pressure on developers to 'cheat' and tightly couple all the implementation classes. It's just easier that way. Right now, MinimalTomcat basically can't use anything within o.a.catalina.core, but eventually all the packages will be tightly linked unless there's some sort of incentive not to. -- 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]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 6:58 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 Aaron Smuts wrote: I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. I detest housecats, but I suppose that's not really the point :-) You're no friend of mine then. :) I'm not sure my is generally useful. The basic approach probably is, but maybe not the code. I personally don't really need all the run-time event stuff (not the servlet-spec events, the Catalina internal events). I don't need JSP. I don't need run-time parsing of the config server.xml and web.xml files. I don't need the full-on security architecture (so I don't need facades and I don't need SecurityManager code). I don't need (but kinda want) the JMX management interfaces. Etc. Sounds about like what I need. I need an engine to serve a simple servlet embedded in a cache server so I can clear the caches and monitor the regions. The code I've written is only useful if you're eliminating the exact same set of things I am. Otherwise, you bloat out until you're full-on Catalina again. (OTOH, projects like Galeon managed to find generally useful subsets of Mozilla, so there's an existence proof that such a thing is possible.) But if I'm the only one use Catalina as a framework instead of as a monolithic servlet container, it isn't going to work. There's too much pressure on developers to 'cheat' and tightly couple all the implementation classes. It's just easier that way. Right now, MinimalTomcat basically can't use anything within o.a.catalina.core, but eventually all the packages will be tightly linked unless there's some sort of incentive not to. Sounds like you'll have trouble when the parent package changes. You need something new and separate. Aaron -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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. 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. 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? In any case, tomorrow I'll whip up a sourceball of the current MinimalTomcat code and stick it out on the net somewhere. -- 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]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Remy Maucherat wrote: Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). For my purposes, it's ok to assume 1.2, so that's not an issue. If Tomcat 4 isn't meant to be used like I'm using it, then I don't really understand the point of the generic interfaces in o.a.catalina. If StandardContext is the only possible Context implementation, what's the justification for a generic Context interface? The current architecture requires an awful lot of casts, and if the only configuration allowed is: StandardEngine/StandardHost/StandardContext/StandardWrapper then most of them are unnessary. What's the point of going through hoops with the generic interfaces if you know the exact types in advance? I understand that project goals can change, but the design of the apis (not to mention the javadocs) do seem to strongly imply that something like MinimalTomcat should be legit. -- 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]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 25, 2002 5:29 PM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). The main problem that I would see is that you'd have to tweak some classes to get TC 3.3 to run disk-less. Otherwise, yes, Costin has done a lot of work towards letting you run TomKitten 3.3 on your toaster. Remy -- 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]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Aaron Smuts wrote: What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. You can probably use tomcat3.3: - it's small - about 1M ( excluding the parser, 800k if you don't include the jasper compiler - you'll still support precompiled jsps ). You can probably cut more if you remove unused modules. - it's fast - IMHO it's one of the fastest servlet containers around - it's simple - as simple as we were able to make it ( but no simpler :-). Almost anything can be replaced, including the servlet implementation ( facade ), loaders, loggers, connectors. In addition it'll run with almost any VM ( including GCJ/native, kaffe, with some changes J2ME ) and it's reasonably easy to embed it. It doesn't have features - except serving servlets as fast as it can. If you want features - probably you need something else. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 25, 2002 6:25 PM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 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. This is the one that really bit me in porting ApacheConfig to 4.x. And, as a result, the 4.x ApacheConfig suffers from the same problem of making assumptions about the order of method calls. Saying that they might not always be clearly stated in the method JavaDocs is a gross understatement. Roughly half the time, the start event is fired at the beginning (allowing Listeners to change the config), and half the time it is fired at the end (allowing Listeners to react to the config). IMHO, the 3.3 event model is an improvement: where you have an init event (fired at the beginning of the start method), and a start event (fired at the end of the start method). As I said, this is IMHO. Attempts to start a flame-war will be quietly ignored. 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
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. This is the one that really bit me in porting ApacheConfig to 4.x. And, as a result, the 4.x ApacheConfig suffers from the same problem of making assumptions about the order of method calls. Saying that they might not always be clearly stated in the method JavaDocs is a gross understatement. Roughly half the time, the start event is fired at the beginning (allowing Listeners to change the config), and half the time it is fired at the end (allowing Listeners to react to the config). IMHO, the 3.3 event model is an improvement: where you have an init event (fired at the beginning of the start method), and a start event (fired at the end of the start method). It's not random, actually. The start event is sent to the listeners at the end of the ContainerBase.start method, which is right after all the children have been started. The only problem is with the server and service, where the start event is sent before (so it's not really useful except to configure things). Adding a before-start event and before-stop event is doable IMO. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
