commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [jci] Handling compilation errors
Date Tue, 23 Aug 2005 07:37:22 GMT
Torsten Curdt <tcurdt <at>> 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:
> 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?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message