commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured
Date Sat, 20 Aug 2005 01:14:33 GMT
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message