[
https://issues.apache.org/jira/browse/IVY-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494568
]
Xavier Hanin commented on IVY-496:
----------------------------------
Indeed, the first point is a no brainer, the second one is more problematic.
Let's try to see the purpose of this message accumulation: Ivy follows some
kind of best effort strategy when dealing with problems, instead of a fail
first. This means that when an error occurs, Ivy may do many other things
after. Therefore we try to output all error messages as a summary.
In the light of this, I think we should try to make sure sure the sumup method
is called at the end of any operation. I think it's important to call it not
only from the Ant perspective, but also from command line or when used as an
API.
For the moment the calls from the conflict managers are only made as a
workaround to what can be considered as a bug, because in case of any other
exception error messages are lost.
The problem is to identify the entry points, in which case we could make sure
to call sumup at the end of any entry point (or maybe if an entry point can use
another one, we should better increment a counter each time we enter the Ivy
API, decrement it whenever we exit (either with a normal return or an
exception), and check if the counter is 0 after decrementation, output the
messages.
This is not too difficult to implement, but will really clutter the code unless
we use some kind of AOP for this purpose. I'm not sure if this can really be a
solution in Ivy case, maybe there are AOP frameworks which doesn't require
anything at runtime (using bytecode manipulation). This is something that may
deserve investigation.
Another point that the Message class raise is that it isn't thread safe. And
this is a shame since it is used statically. We should make it thread safe, and
also put the problems lists in IvyContext, to isolate problems by thread.
Therefore I think we can requalify this to a bug, and upgrade it to a major
priority.
> Refactor Message class
> ----------------------
>
> Key: IVY-496
> URL: https://issues.apache.org/jira/browse/IVY-496
> Project: Ivy
> Issue Type: Wish
> Components: Core
> Affects Versions: unspecified
> Reporter: Gilles Scokart
> Priority: Minor
>
> The class Message does to much things. Namely,
> - It implements a kind default MessageImpl as fallback when no MessageImpl
> are defined (use System.err).
> - It accumulate warnings and errors until sumupProblems is invoked
> For the first point, Message should be refactored to use the
> DefaultMessageImpl by default.
>
> The second point is more problématic. The accumation of warnings/error in
> Message itself make the unit test more difficult to isolate (warning/error
> messages are kept between tests). Moreover, at runtime, I fear that there is
> a risk of silently (I should say 'verbosly') ignores errors and warnings
> messages when sumupProblems is not invoked (for example because of an
> exception or, just because this method is not invoked at all).
>
> When searching to who invoke sumupProblems, I found only resolverManager and
> conflict manager. So I'm not sure what is the best refactoring aproach :
> - Should we put the accumultation in the AntMessageImpl, and invoke
> sumupProblems from the ant task (the same that put AntMessageImpl as the
> implementation to use)
> - Or should we move the accumulation of errors/warning into a dedicated class
> used by the code invked by the resolveManager/confiltManager.
> WDYT?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
