Another motivation is that when Camel wants to work on JDK9 support, you'll
find that log4j 1.x doesn't work anymore.

On 2 August 2016 at 11:21, Luca Burgazzoli <lburgazz...@gmail.com> wrote:

> My only motivation was to keep the dependencies up to date
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Aug 2, 2016 at 5:50 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> > If it's only for test, what's the motivation?  Is anything broken?  Does
> > anything code directly to the API?
> >
> > On Tue, Aug 2, 2016 at 11:21 AM Matt Sicker <boa...@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.ferr...@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.ib...@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 <nferr...@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 <
> >> lburgazz...@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.ib...@gmail.com>
> >> > > wrote:
> >> > > >> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <
> >> > > lburgazz...@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 <nferr...@redhat.com>
> >> > > > Senior Software Engineer, JBoss Fuse
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Claus Ibsen
> >> > > -----------------
> >> > > http://davsclaus.com @davsclaus
> >> > > Camel in Action 2: https://www.manning.com/ibsen2
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Matt Sicker <boa...@gmail.com>
> >>
>



-- 
Matt Sicker <boa...@gmail.com>

Reply via email to