incubator-ivy-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVY-496) Refactor Message class
Date Wed, 09 May 2007 20:41:15 GMT

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


Mime
View raw message