Torsten Curdt <tcurdt <at> apache.org> writes: > I think we are facing two questions: > > 1. Keep the ProblemHandler across compilations (and add a lifecycle) or > re-create the object
Hmm, this also depends :) For the error counter there is no problem to create one on every compilation cycle. But for the external ones passed as parameter you might want to use always the same. But probably this can be hidden in a ProblemHandlerFactory with a method getProblemHandler(). This would also externalize the lifecycle handling - which is what I would like to see ;) > 2. Is there really a usecase where you don't need the compilation result in a > ProblemHandler? I don't know if I understand the question correctly, but a ProblemHandler not handling problems makes no sense. But a ProblemHandler might not store the result of the complete compilation cycle, but handle the problems immediately like the loggers. > > 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? > > Exactly! (Did you switch sides? ;) Not that I was aware of :) > The CL would call reset/clear on the handler. My reasoning here was if the CL instantiates its handler it also knows the type of it and can handle its specific lifecycle. ErrorCounter counter = new ErrorCounter(); // implements CPH interface ... counter.reset(); compile(.., counter); > Another idea would be to keep the > compilation result inside the > CompilingListener and just delegate > problems to the external ProblemHandler. > > Not sure if I like that though. Me too. > > Probably before my time Ok, I see your point. But XSP actually > > works still synchron, doesn't it? > > Yes ..as I said - we worked around that restriction by caching the access. Ok, and in the rest of Cocoon? Isn't lastmodified used nearly everywhere? Or is just the consequence: the compilation process. > > Do you want to switch it? Or are your integration efforts > > more about the general CompilingClassLoader and javaflow stuff? > > Well, it came to mind ...but I don't think I would do it. I am not using XSP > anymore. Most people consider it more or less legacy now anyway. So why change > what's not broken. Exactly. I just wondered. Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
