Torsten Curdt <tcurdt <at> apache.org> writes: > > (BTW, this use case shows a different lifecycle for the handler and > > is another signal for removing lifecycle specific stuff from the handler > > interface.) > > Well, to me it's a clear example why a > lifecycle would make sense!
Of course, but it is a different lifecycle (reset on retrieving the errors) than for the simple error counter I sent in the patch (reset on beginning a compilation) or the loggers (no reset at all). If you don't want to ignore the different lifecycles (by mapping them to one, don't know if it is really possible) you have to address them all. And there are more conceivable than the mentioned ones. (copied from other thread: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=112475150924518&w=4) > One of the problems I see here is that the compilers *does* need information > like an error count. Removing it from the interface does sound clean in the > first place ...but it clearly violates the KISS principle. At the moment it is just the CompilingListener as far as I see. And it does not even need a count, a boolean switch "error occured" would be sufficient. The use case of Don also does not need a count, it just needs a container (probably a list) for the compilation errors. Let's come to cleanliness vs. KISS. Where does the removal of the counting stuff violate KISS? The CompilingListener is the one to be informed about occured errors. So why should it not be the one to reset the error counter when it is no longer interested in the older errors, but wants to start next compilation cycle? And why should it not register a CompilationProblemHandler that does exactly that job? But if the CompilingListener registers the CPH and handles its lifecycle there is no need to add the lifecycle methods to the interface. So KISS is more about holding the interface clean and simple. > > For the integration into web frameworks: Do you need the > > CompilingClassLoader? > > Isn't the Compiler sufficient? At least for XSP in Cocoon the > > reload is handled > > by Cocoon. > > Which is actually bad bad bad! > We had major problems with that. > > The lastmodified check is a big > performance bottleneck. If you > go for a synchronous check you > would have to check it on every > request. > > We worked around that by caching > it for a certain amount of time. > Beforehand XSP pages did just not scale. > > An asynchronous approach will > help with the SoC and scaleability. > > ...implementation that with XSP > turned out to be no piece of cake > and noone ended up doing it. > IIRC there was a discussion with > Berin long long(!) time ago. Probably before my time ;-) Ok, I see your point. But XSP actually works still synchron, doesn't it? Do you want to switch it? Or are your integration efforts more about the general CompilingClassLoader and javaflow stuff? Regards, Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
