Cédric Damioli added a comment - 27/May/09 10:46 Closing for allowing import/export of the project in the ametys.org instance

Sébastien Launay (Inactive) added a comment - 13/May/09 13:24 Improvement is working after rebuilding the runtime.

Sébastien Launay (Inactive) added a comment - 13/May/09 13:15 Fixed in revision 514 as this lack of improvement has been a pain in the ass recently!

Sébastien Launay (Inactive) added a comment - 06/Mar/09 11:45 I propose to fix this issue in trunk (2.0).

Cédric Damioli added a comment - 26/Jan/09 11:58 targetting this issue for 2. only

Sébastien Launay (Inactive) added a comment - 28/Oct/08 09:36 From my understanding none quality framework internally logged exceptions if the exception is severe and is rethrown . I understand if the client write dirty code (e.g. catch without logging) that we may lose precious debugging information but IMHO this is not a framework issue but more of a newbie issue . That's why i want to get rid of the double logged exceptions and sensitize developers to prevent these kind of errors . A good reason is also that they tend to ignore red lines in LogFactor because there is too much exceptions and for them it's normal ... I there was less exceptions and better access to them (only one by issue) they IMHO will be more involved with fixing these exceptions.

Raphaël Franchet added a comment - 27/Oct/08 18:08 +1 for the bottom modif (in initialize method) => may happen only at startup -1 for the top modif (in lookup method) => may happen in any badly-written code

Sébastien Launay (Inactive) added a comment - 24/Oct/08 11:22 So i proposed the following patch, for improving logs readability: Index: main/kernel/src/org/ametys/runtime/plugin/component/ThreadSafeComponentManager.java =================================================================== --- main/kernel/src/org/ametys/runtime/plugin/component/ThreadSafeComponentManager.java (revision 323) +++ main/kernel/src/org/ametys/runtime/plugin/component/ThreadSafeComponentManager.java (working copy) @@ -112,9 +112,7 @@ if (role == null) { - String message = "ThreadSafeComponentManager attempted to retrieve component with null role."; - getLogger().error(message); - throw new ComponentException(role, message); + throw new ComponentException(role, "ThreadSafeComponentManager attempted to retrieve component with null role."); } T component = _components.get(role); @@ -127,9 +125,7 @@ } catch (Exception e) { - String errorMessage = "Unable to initialize component " + role; - getLogger().error(errorMessage, e); - throw new ComponentException(role, errorMessage, e); + throw new ComponentException(role, "Unable to initialize component " + role, e); } _components.put(role, component); @@ -175,9 +171,7 @@ { if (_initialized) { - String errorMessage = "ComponentManager has already been initialized"; - getLogger().error(errorMessage); - throw new IllegalStateException(errorMessage); + throw new IllegalStateException("ComponentManager has already been initialized"); } synchronized (this) @@ -196,13 +190,8 @@ } catch (Exception e) { - if (getLogger().isErrorEnabled()) - { - getLogger().error("Caught an exception trying to initialize the component " + role, e); - - // Rethrow the exception - throw e; - } + // Rethrow the exception + throw new Exception("Caught an exception trying to initialize the component " + role, e); } } } I can ensure that the resulting exceptions are logged by the caller (aka Cocoon).