camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Burgazzoli <lburgazz...@gmail.com>
Subject Re: Log4j 2
Date Tue, 02 Aug 2016 15:36:53 GMT
Most of the log4j.properties are very simple and they looks like a
copy and paste from an ancient one
I think we can get a relative simple groovy script to do the migration
at least for components and examples.

If you think it is worth give it a try I can do it.

---
Luca Burgazzoli


On Tue, Aug 2, 2016 at 5:21 PM, Matt Sicker <boards@gmail.com> wrote:
> You can use YAML instead of XML or properties files for a nice config
> format. Plus, there's a few log4j 1->2 tools out there already:
> https://issues.apache.org/jira/browse/LOG4J2-1436
>
> On 2 August 2016 at 09:48, Nicola Ferraro <ni.ferraro@gmail.com> wrote:
>
>> I logged a Jira: https://issues.apache.org/jira/browse/CAMEL-10217
>>
>>
>>
>> On Tue, Aug 2, 2016 at 4:35 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>>
>> > Hi
>> >
>> > Yeah some should be removed, but mind that some 3rd party libraries
>> > are using log4j hardcoded as dependency so not all can be removed.
>> >
>> > But I think camel-scr is a mistake to use log4j.
>> >
>> > Its worthwhile I think to take a look which one can be removed or not.
>> > Feel free to log a JIRA and work on this.
>> >
>> > On Tue, Aug 2, 2016 at 4:27 PM, Nicola Ferraro <nferraro@redhat.com>
>> > wrote:
>> > > Doing integration tests I found that some components include logging
>> > > implementations outside the test scope, so I did a fast check:
>> > >
>> > > *for comp in $(ls | grep "camel-" | grep -v ".iml"); do*
>> > > * cd $comp*
>> > > * mvn dependency:tree | grep
>> > > 'log4j\|logback\|slf4j-simple\|slf4j-jdk14\|slf4j-log4j12' | grep -v
>> > test |
>> > > xargs -I line echo "$(pwd) line"*
>> > > * cd ..*
>> > > *done*
>> > >
>> > > Although it is ok for a spring-boot starter to include a logging
>> > > implementation, they should not be included in normal component modules
>> > IMO.
>> > >
>> > > Should these dependencies be removed?
>> > >
>> > >
>> > > The results:
>> > > *./camel/components/camel-atmos [INFO] |  +-
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-gora [INFO] |  +-
>> > > org.slf4j:slf4j-log4j12:jar:1.7.21:compile*
>> > > *./camel/components/camel-gora [INFO] |  -
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-hbase [INFO] |  +-
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-jbpm [INFO] +-
>> > > org.slf4j:slf4j-log4j12:jar:1.7.21:compile*
>> > > *./camel/components/camel-jbpm [INFO] |  -
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-jt400 [INFO] +-
>> > > org.slf4j:slf4j-log4j12:jar:1.7.21:compile*
>> > > *./camel/components/camel-jt400 [INFO] |  -
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-krati [INFO] |  -
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-openshift [INFO] |  -
>> > > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-salesforce [INFO] +-
>> > > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-scr [INFO] +-
>> > > org.slf4j:slf4j-log4j12:jar:1.7.21:compile*
>> > > *./camel/components/camel-scr [INFO] +- log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-spark [INFO] |  +-
>> > log4j:log4j:jar:1.2.17:compile*
>> > > *./camel/components/camel-spark [INFO] |  |  +-
>> > > log4j:apache-log4j-extras:jar:1.2.17:compile*
>> > > *./camel/components/camel-spark-rest [INFO] |  +-
>> > > org.slf4j:slf4j-simple:jar:1.7.21:compile*
>> > > *./camel/components/camel-spring-boot [INFO] |  |  +-
>> > > ch.qos.logback:logback-classic:jar:1.1.7:compile*
>> > > *./camel/components/camel-spring-boot [INFO] |  |  |  -
>> > > ch.qos.logback:logback-core:jar:1.1.7:compile*
>> > > *./camel/components/camel-spring-boot [INFO] |  |  -
>> > > org.slf4j:log4j-over-slf4j:jar:1.7.21:compile*
>> > > *./camel/components/camel-spring-boot-starter [INFO] |  |  +-
>> > > ch.qos.logback:logback-classic:jar:1.1.7:compile*
>> > > *./camel/components/camel-spring-boot-starter [INFO] |  |  |  -
>> > > ch.qos.logback:logback-core:jar:1.1.7:compile*
>> > > *./camel/components/camel-spring-boot-starter [INFO] |  |  -
>> > > org.slf4j:log4j-over-slf4j:jar:1.7.21:compile*
>> > > *./camel/components/camel-zipkin-starter [INFO] |  |  +-
>> > > ch.qos.logback:logback-classic:jar:1.1.7:compile*
>> > > *./camel/components/camel-zipkin-starter [INFO] |  |  |  -
>> > > ch.qos.logback:logback-core:jar:1.1.7:compile*
>> > > *./camel/components/camel-zipkin-starter [INFO] |  |  -
>> > > org.slf4j:log4j-over-slf4j:jar:1.7.21:compile*
>> > > *./camel/components/camel-zookeeper [INFO] |  +-
>> > > log4j:log4j:jar:1.2.17:compile*
>> > >
>> > > On Tue, Aug 2, 2016 at 3:14 PM, Luca Burgazzoli <lburgazzoli@gmail.com
>> >
>> > > wrote:
>> > >
>> > >> Yep, I meant upgrading log4j for test only, run-time should
>> > >> definitively use slf4j-api (or maybe a custom facade)
>> > >>
>> > >> ---
>> > >> Luca Burgazzoli
>> > >>
>> > >>
>> > >> On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <claus.ibsen@gmail.com>
>> > wrote:
>> > >> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <
>> > lburgazzoli@gmail.com>
>> > >> wrote:
>> > >> >> Hello,
>> > >> >>
>> > >> >> as log4j 1.2 is EOL since a year, would it make sense to move
to
>> > log4j
>> > >> 2 ?
>> > >> >>
>> > >> >
>> > >> > We only use it for testing. No runtime dependency.
>> > >> >
>> > >> >
>> > >> > log4j v2 did not support log4j.properties file so any migration
was
>> a
>> > >> > real pain as the log4j xml file format is verbose and clunky to
work
>> > >> > with.
>> > >> >
>> > >> > Only recently they added support for .properties file but I think
>> they
>> > >> > may have changed the syntax slightly (not sure).
>> > >> >
>> > >>
>> >
>> http://stackoverflow.com/questions/22485074/log4j-2-doesnt-support-log4j-properties-file-anymore
>> > >> >
>> > >> >
>> > >> > And I think I read somewhere that log4j v1 has problems with Java
9.
>> > >> >
>> > >> > If migration can be super easy on current 2.18 then it is okay.
>> > >> > Some kind of migration tool that can covert v1 properties to v2
>> > >> > properties then that can be doable.
>> > >> >
>> > >> > But if not then I would like to postpone this to Camel 3.
>> > >> >
>> > >> >
>> > >> >>
>> > >> >> ---
>> > >> >> Luca Burgazzoli
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Claus Ibsen
>> > >> > -----------------
>> > >> > http://davsclaus.com @davsclaus
>> > >> > Camel in Action 2: https://www.manning.com/ibsen2
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Nicola Ferraro <nferraro@redhat.com>
>> > > Senior Software Engineer, JBoss Fuse
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>> >
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com>

Mime
View raw message