Re: [jci] Handling compilation errors

[Torsten Curdt]

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.

Well ...I think somehow you *always* want
the result of the compilation. The only
difference I can see is handling the
errors immediately or once the compilation
is finished.

Let's come to cleanliness vs. KISS. Where does the removal of the counting stuff

violate KISS?

Well ...if you move something from
an interface into the implementation
space although you need access to
that information anyway ...that's not
KISS ;)

I think we are facing two questions:

1. Keep the ProblemHandler across
   compilations (and add a lifecycle)
   or re-create the object

2. Is there really a usecase where
   you don't need the compilation
   result in a ProblemHandler?

The CompilingListener is the one to be informed about occured

cycle?

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

Exactly! (Did you switch sides? ;)
The CL would call reset/clear on
the handler.

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.

And why should it not register a CompilationProblemHandler that does

KISS is more about holding the interface clean and simple.

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 not restricted to holding
interfaces clean but about the
general approach.

<snip/>

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.

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.

Currently I focus on improving
the RAD with Cocoon with the
Compiling- and ReloadingClassLoader.
Plus hook in javaflow through that
mechanism.

cheers
--
Torsten

PGP.sig
Description: This is a digitally signed message part