[jira] Created: (IVY-496) Refactor Message class

["Gilles Scokart (JIRA)" <ji...@apache.org>]

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.

[jira] Commented: (IVY-496) Refactor Message class

["Xavier Hanin (JIRA)" <ji...@apache.org>]

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