Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured

[Joerg Heinicke <jo...@gmx.de>]

> 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.
> 
> We could also make use of a factory pattern here.

And instead of a CPHandler instance you pass a CPHandlerFactory?

Sounds good.

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured

[Joerg Heinicke <jo...@gmx.de>]

> Any suggestion how to handle that otherwise?

Continueing this topic in the other thread 'Handling compilation errors':
http://marc.theaimsgroup.com/?t=112455648300002&r=1&w=4

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured

[Torsten Curdt <tc...@apache.org>]

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

One of the problems I see here is that
the compilers *does* need information
like an error count. Removing it from the
interface does sound clean in the first
place ...but it clearly violates the
KISS principle.

Any suggestion how to handle that otherwise?

My current cocoon integration work
also triggered some other thoughts
but I haven't had much time to think
this through. And I've only a few busy
days left until I leave for 3 weeks
of vacation :-D (anyone been to
costa rica before?) I'll see what I can
do beforehand ...but for sure I'll
have made up my mind afterwards ;)

cheers
--
Torsten

Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured

[Joerg Heinicke <jo...@gmx.de>]

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