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 12:02:32 GMT
Torsten Curdt <tcurdt <at>> 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



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 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.


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

View raw message