> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36261 > > > > wait a sec ...let's discuss that on the list first. > > while I agree that it makes sense to remove > > the counting from the problem handler interface > > I am not too sure I like the other changes too much.
Off-list you talked about possibly introducing a lifecycle to the CompilationProblemHandler. IMO their purpose is to different to get a common lifecycle. Many purposes do not even need a lifecycle at all (e.g. logging the compilation problems, or (as in my adapter to XSP) delegating the problem to Cocoon. The so-called CompilationProblemCounter (in the patch) is a special case for the CompilingListener, so the CL should also care about its lifecycle, not the compilers. There are even other lifecycles conceivable - shall the compilers manage all of them? I have the Avalon interfaces in mind ... ;-) At the end this means I like the idea of having a most simple CompilationProblemHandler interface with just the one method (also as in the DiagnosticListener of JSR 199). The classes registering the handlers have to care about the rest, they know their purpose. Remains the question of passing the handlers to the compilers. Passing a factory is not possible I think as the registering classes might need access to the handlers like the CompilingListener needs to reset the error counter. At the end I come back to my patch - with details debatable of course ;-) WDYT? Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
