You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Babak Vahdat (JIRA)" <ji...@apache.org> on 2012/10/01 14:59:07 UTC
[jira] [Created] (CAMEL-5672) Avoid using the System.out /
System.error PrintStreams for logging
Babak Vahdat created CAMEL-5672:
-----------------------------------
Summary: Avoid using the System.out / System.error PrintStreams for logging
Key: CAMEL-5672
URL: https://issues.apache.org/jira/browse/CAMEL-5672
Project: Camel
Issue Type: Task
Reporter: Babak Vahdat
Assignee: Babak Vahdat
Priority: Trivial
Fix For: 2.11.0
Apparently while unit-testing / integration-testing inside the Camel modules the usage of {{System.out}} / {{System.error PrintStream}} for logging is not a good idea, some reasons for this are:
- In case you make use of {{ConsoleAppender}} inside the module {{camel-xyz}} then you get a mix of unformatted {{System.out}} / {{System.error}} dumps together with the proper logs (having timestamp, thread-name, class-name etc.)
- In case you make use of an appender other than {{ConsoleAppender}} (e.g. {{FileAppender}}) then your logs are scattered, partially being inside {{camel-xyz-test.log}} and the rest being logged inside your console!
- Through the usage of {{log4j}} API ({{slf4j over log4j}}) inside tests (instead of {{System.out}} / {{System.error PrintStream}}) you get much more informations for free (depending on the concrete {{ConversionPattern}} you make use of)
- Last but not least making use of {{System.out}} / {{System.error PrintStream}} inside tests brings outputs like the following (as the surefire-plugin runs) which is just _annoying_:
{code}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
Running org.apache.camel.cdi.XmlRoutesFromURLTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
Running org.apache.camel.cdi.component.properties.PropertiesComponentTest
This is the output of my System.out.println() call...
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.692 sec
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5672) Avoid using the System.out /
System.error PrintStreams for logging
Posted by "Babak Vahdat (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Babak Vahdat updated CAMEL-5672:
--------------------------------
Description:
Apparently while unit-testing / integration-testing inside the Camel modules the usage of {{System.out}} / {{System.error PrintStream}} for logging is not a good idea, some reasons for this are:
- In case you make use of {{ConsoleAppender}} inside the module {{camel-xyz}} then you get a mix of unformatted {{System.out}} / {{System.error}} dumps together with the proper logs (having timestamp, thread-name, class-name etc.)
- In case you make use of an appender other than {{ConsoleAppender}} (e.g. {{FileAppender}}) then your logs are scattered, partially being inside {{camel-xyz-test.log}} and the rest being logged inside your console!
- Through the proper usage of {{slf4j}} API inside tests (instead of {{System.out}} / {{System.error PrintStream}}) you get much more context information for free (depending on the concrete {{log4j ConversionPattern}} you make use of) like the actual thread-name or the class-name etc.
- Last but not least making use of {{System.out}} / {{System.error PrintStream}} inside tests brings outputs like the following (as the surefire-plugin runs) which is just _annoying_:
{code}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
Running org.apache.camel.cdi.XmlRoutesFromURLTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
Running org.apache.camel.cdi.component.properties.PropertiesComponentTest
This is the output of my System.out.println() call...
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.692 sec
{code}
was:
Apparently while unit-testing / integration-testing inside the Camel modules the usage of {{System.out}} / {{System.error PrintStream}} for logging is not a good idea, some reasons for this are:
- In case you make use of {{ConsoleAppender}} inside the module {{camel-xyz}} then you get a mix of unformatted {{System.out}} / {{System.error}} dumps together with the proper logs (having timestamp, thread-name, class-name etc.)
- In case you make use of an appender other than {{ConsoleAppender}} (e.g. {{FileAppender}}) then your logs are scattered, partially being inside {{camel-xyz-test.log}} and the rest being logged inside your console!
- Through the usage of {{log4j}} API ({{slf4j over log4j}}) inside tests (instead of {{System.out}} / {{System.error PrintStream}}) you get much more informations for free (depending on the concrete {{ConversionPattern}} you make use of)
- Last but not least making use of {{System.out}} / {{System.error PrintStream}} inside tests brings outputs like the following (as the surefire-plugin runs) which is just _annoying_:
{code}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
Running org.apache.camel.cdi.XmlRoutesFromURLTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
Running org.apache.camel.cdi.component.properties.PropertiesComponentTest
This is the output of my System.out.println() call...
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.692 sec
{code}
> Avoid using the System.out / System.error PrintStreams for logging
> ------------------------------------------------------------------
>
> Key: CAMEL-5672
> URL: https://issues.apache.org/jira/browse/CAMEL-5672
> Project: Camel
> Issue Type: Task
> Reporter: Babak Vahdat
> Assignee: Babak Vahdat
> Priority: Trivial
> Fix For: 2.11.0
>
>
> Apparently while unit-testing / integration-testing inside the Camel modules the usage of {{System.out}} / {{System.error PrintStream}} for logging is not a good idea, some reasons for this are:
> - In case you make use of {{ConsoleAppender}} inside the module {{camel-xyz}} then you get a mix of unformatted {{System.out}} / {{System.error}} dumps together with the proper logs (having timestamp, thread-name, class-name etc.)
> - In case you make use of an appender other than {{ConsoleAppender}} (e.g. {{FileAppender}}) then your logs are scattered, partially being inside {{camel-xyz-test.log}} and the rest being logged inside your console!
> - Through the proper usage of {{slf4j}} API inside tests (instead of {{System.out}} / {{System.error PrintStream}}) you get much more context information for free (depending on the concrete {{log4j ConversionPattern}} you make use of) like the actual thread-name or the class-name etc.
> - Last but not least making use of {{System.out}} / {{System.error PrintStream}} inside tests brings outputs like the following (as the surefire-plugin runs) which is just _annoying_:
> {code}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
> Running org.apache.camel.cdi.XmlRoutesFromURLTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
> Running org.apache.camel.cdi.component.properties.PropertiesComponentTest
> This is the output of my System.out.println() call...
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.692 sec
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5672) Avoid using the System.out /
System.error PrintStreams for logging
Posted by "Babak Vahdat (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Babak Vahdat resolved CAMEL-5672.
---------------------------------
Resolution: Fixed
Totally spotted 60 java sources making use of {{System.out}} or {{System.error PrintStream}} for logging.
> Avoid using the System.out / System.error PrintStreams for logging
> ------------------------------------------------------------------
>
> Key: CAMEL-5672
> URL: https://issues.apache.org/jira/browse/CAMEL-5672
> Project: Camel
> Issue Type: Task
> Reporter: Babak Vahdat
> Assignee: Babak Vahdat
> Priority: Trivial
> Fix For: 2.11.0
>
>
> Apparently while unit-testing / integration-testing inside the Camel modules the usage of {{System.out}} / {{System.error PrintStream}} for logging is not a good idea, some reasons for this are:
> - In case you make use of {{ConsoleAppender}} inside the module {{camel-xyz}} then you get a mix of unformatted {{System.out}} / {{System.error}} dumps together with the proper logs (having timestamp, thread-name, class-name etc.)
> - In case you make use of an appender other than {{ConsoleAppender}} (e.g. {{FileAppender}}) then your logs are scattered, partially being inside {{camel-xyz-test.log}} and the rest being logged inside your console!
> - Through the proper usage of {{slf4j}} API inside tests (instead of {{System.out}} / {{System.error PrintStream}}) you get much more context information for free (depending on the concrete {{log4j ConversionPattern}} you make use of) like the actual thread-name or the class-name etc.
> - Last but not least making use of {{System.out}} / {{System.error PrintStream}} inside tests brings outputs like the following (as the surefire-plugin runs) which is just _annoying_:
> {code}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
> Running org.apache.camel.cdi.XmlRoutesFromURLTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
> Running org.apache.camel.cdi.component.properties.PropertiesComponentTest
> This is the output of my System.out.println() call...
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.692 sec
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira