You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Luca Burgazzoli <lb...@gmail.com> on 2016/08/02 12:42:30 UTC
Log4j 2
Hello,
as log4j 1.2 is EOL since a year, would it make sense to move to log4j 2 ?
---
Luca Burgazzoli
Re: Log4j 2
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
In my opinion it makes sense.
Thanks!
--
Andrea Cosentino
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Tuesday, August 2, 2016 2:42 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
Hello,
as log4j 1.2 is EOL since a year, would it make sense to move to log4j 2 ?
---
Luca Burgazzoli
Re: Log4j 2
Posted by Matt Sicker <bo...@gmail.com>.
https://issues.apache.org/jira/browse/LOG4J2-905
This looks relevant.
On 18 August 2016 at 10:51, Luca Burgazzoli <lb...@gmail.com> wrote:
> I'll ask the log4j guys, thx for spotting this.
>
> ---
> Luca Burgazzoli
>
>
> On Thu, Aug 18, 2016 at 5:37 PM, Antonin Stefanutti
> <an...@stefanutti.fr> wrote:
> > Hi Luca,
> >
> > I’ve just encountered an issue when using the date function that gets
> substituted by Log4j 2 and causes the exception below to be thrown.
> >
> > It happens in a number of situations:
> > - when a route definition containing the date function get logged (in
> DEBUG level)
> > - when an advice is being applied (in INFO level)
> > - ...
> >
> > This is described in: http://stackoverflow.com/
> questions/27103400/log4j2-how-to-disable-date-lookup-log4j-
> throws-exception
> >
> > Invalid date format: [now:hh:mm:ss a], using default java.lang.IllegalArgumentException:
> Illegal pattern character 'n'
> > at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> > at java.text.SimpleDateFormat.initialize(SimpleDateFormat.
> java:634)
> > at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> > at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> > at org.apache.logging.log4j.core.lookup.DateLookup.formatDate(
> DateLookup.java:64)
> > at org.apache.logging.log4j.core.lookup.DateLookup.lookup(
> DateLookup.java:57)
> > at org.apache.logging.log4j.core.lookup.Interpolator.lookup(
> Interpolator.java:159)
> > at org.apache.logging.log4j.core.lookup.StrSubstitutor.
> resolveVariable(StrSubstitutor.java:1046)
> > at org.apache.logging.log4j.core.lookup.StrSubstitutor.
> substitute(StrSubstitutor.java:963)
> > at org.apache.logging.log4j.core.lookup.StrSubstitutor.
> substitute(StrSubstitutor.java:853)
> > at org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(
> StrSubstitutor.java:408)
> > at org.apache.logging.log4j.core.pattern.
> MessagePatternConverter.format(MessagePatternConverter.java:73)
> > at org.apache.logging.log4j.core.pattern.PatternFormatter.
> format(PatternFormatter.java:38)
> > at org.apache.logging.log4j.core.layout.PatternLayout$
> PatternSerializer.toSerializable(PatternLayout.java:294)
> > at org.apache.logging.log4j.core.layout.PatternLayout.toText(
> PatternLayout.java:195)
> > at org.apache.logging.log4j.core.layout.PatternLayout.encode(
> PatternLayout.java:180)
> > at org.apache.logging.log4j.core.layout.PatternLayout.encode(
> PatternLayout.java:57)
> > at org.apache.logging.log4j.core.appender.
> AbstractOutputStreamAppender.directEncodeEvent(
> AbstractOutputStreamAppender.java:120)
> > at org.apache.logging.log4j.core.appender.
> AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.
> java:113)
> > at org.apache.logging.log4j.core.appender.
> AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:104)
> > at org.apache.logging.log4j.core.config.AppenderControl.
> tryCallAppender(AppenderControl.java:155)
> > at org.apache.logging.log4j.core.config.AppenderControl.
> callAppender0(AppenderControl.java:128)
> > at org.apache.logging.log4j.core.config.AppenderControl.
> callAppenderPreventRecursion(AppenderControl.java:119)
> > at org.apache.logging.log4j.core.config.AppenderControl.
> callAppender(AppenderControl.java:84)
> > at org.apache.logging.log4j.core.config.LoggerConfig.
> callAppenders(LoggerConfig.java:390)
> > at org.apache.logging.log4j.core.config.LoggerConfig.
> processLogEvent(LoggerConfig.java:375)
> > at org.apache.logging.log4j.core.config.LoggerConfig.log(
> LoggerConfig.java:359)
> > at org.apache.logging.log4j.core.config.LoggerConfig.log(
> LoggerConfig.java:349)
> > at org.apache.logging.log4j.core.config.
> AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStra
> tegy.java:63)
> > at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:
> 146)
> > at org.apache.logging.log4j.spi.AbstractLogger.logMessage(
> AbstractLogger.java:1993)
> > at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(
> AbstractLogger.java:1852)
> > at org.apache.logging.slf4j.Log4jLogger.info(Log4jLogger.
> java:179)
> > at org.apache.camel.builder.AdviceWithTasks$4.task(
> AdviceWithTasks.java:354)
> > at org.apache.camel.model.RouteDefinition.adviceWith(
> RouteDefinition.java:280)
> >
> > Antonin
> >
> >> On 12 Aug 2016, at 10:17, Luca Burgazzoli <lb...@gmail.com>
> wrote:
> >>
> >> I've migrated also spark, spark-rest, hbase and sip,
> >> Thx to Vitalii fot the tip about log4j-over-slf4j.
> >>
> >> The only module that relies on log4j is now camel-itest-karaf
> >>
> >> ---
> >> Luca Burgazzoli
> >>
> >>
> >> On Wed, Aug 10, 2016 at 5:33 PM, Luca Burgazzoli <lb...@gmail.com>
> wrote:
> >>> Code merged and finger crossed
> >>> Please report any issue
> >>>
> >>> ---
> >>> Luca Burgazzoli
> >>>
> >>>
> >>> On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>>> Hi
> >>>>
> >>>> Yeah sure sounds good that all this works will pay of and we will be
> >>>> migrated for 2.18 release.
> >>>>
> >>>> On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <
> lburgazzoli@gmail.com> wrote:
> >>>>> tests/camel-itest --> works
> >>>>> tests/camel-itest-karaf --> need to keep log4j because of pax
> logging
> >>>>> tests/camel-itest-spring-boot --> migrated
> >>>>>
> >>>>> I've pushed some new bits with some fixes to my branch as well as
> some fixes
> >>>>> for few test in camel-itest-karaf about system packages needed by
> Ignite and
> >>>>> Drools.
> >>>>>
> >>>>> I'm almost ready to rebase from master and the merge my work if you
> do not
> >>>>> have any objection.
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---
> >>>>> Luca Burgazzoli
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>>>>> Hi Luca
> >>>>>>
> >>>>>> Its a lot of changes but it looks good.
> >>>>>>
> >>>>>> I think its maybe only the maven archetypes that may need a bit of
> >>>>>> manual testing to see if the generated projects are all compiling
> and
> >>>>>> working as expected.
> >>>>>>
> >>>>>> I noticed on master branch (not yours) that the blueprint archetype
> do
> >>>>>> not log to the console when you run mvn camel:run goal. This is
> likely
> >>>>>> a general problem where we may need to tweak the run goal to
> automatic
> >>>>>> include some kind of logging out of the box (or include the test
> >>>>>> scoped src/test/resources/log4j properties) or whatever it takes.
> >>>>>>
> >>>>>> I suggest you run the tests in
> >>>>>>
> >>>>>> tests/camel-itest
> >>>>>> tests/camel-itest-karaf
> >>>>>> tests/camel-itest-spring-boot
> >>>>>>
> >>>>>> to see if they are still all working.
> >>>>>>
> >>>>>> However great work to migrate all that. Then we can get this in the
> >>>>>> 2.18 release.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <
> lburgazzoli@gmail.com> wrote:
> >>>>>>> I've pushed the latest bit of the migration in my branch.
> >>>>>>> Except for the mentioned components, everything else should have
> been migrated.
> >>>>>>>
> >>>>>>> I really appreciate if someone could help testing a little bit
> with a
> >>>>>>> focus on tooling, examples and tests.
> >>>>>>>
> >>>>>>> ---
> >>>>>>> Luca Burgazzoli
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <
> lburgazzoli@gmail.com> wrote:
> >>>>>>>> I do not remember now but some problems come from the test
> >>>>>>>> dependencies we use (like microcluster, etc)
> >>>>>>>> Need to digg into the issue more once the majority of the
> migration will be done
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>> Luca Burgazzoli
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <
> claus.ibsen@gmail.com> wrote:
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>> Ah sounds good the migration goes so well, and that there is
> only a
> >>>>>>>>> few components that may be stuck on log4j 1.x. But those 3rd
> party
> >>>>>>>>> libraries may migrate to log4j v2 or some other logging api
> (slf4j-api
> >>>>>>>>> etc) in the future.
> >>>>>>>>>
> >>>>>>>>> Though a bit surprising that Apache Spark is locked down on
> log4j v1.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <
> lburgazzoli@gmail.com> wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> I've setup my own branch
> >>>>>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/
> CAMEL-10224-log4j2)
> >>>>>>>>>> were I'm doing some test to migrate to log4j2.
> >>>>>>>>>> So far migrating the properties was not an issue and automated
> through a script.
> >>>>>>>>>>
> >>>>>>>>>> The following component can't be migrate as they have some code
> based on log4j:
> >>>>>>>>>> - camel-spark
> >>>>>>>>>> - camel-spark-rest
> >>>>>>>>>> - camel-sip
> >>>>>>>>>> - camel-hbase
> >>>>>>>>>>
> >>>>>>>>>> For other components I found that log4j.properties was used
> also to
> >>>>>>>>>> perform some test (i.e. a file to serve in jetty9).
> >>>>>>>>>>
> >>>>>>>>>> All the remaining component and caml-core have been tested an
> >>>>>>>>>> successfully migrated.
> >>>>>>>>>> I still need to migrate examples, tooling and so on.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> Luca Burgazzoli
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com>
> wrote:
> >>>>>>>>>>> We have a ticket to track migration issues:
> >>>>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
> >>>>>>>>>>>
> >>>>>>>>>>> On 2 August 2016 at 12:24, James Carman <
> james@carmanconsulting.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Now, that's a motivation I can get behind! :)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com>
> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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 <
> lburgazzoli@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 <
> >>>>>>>>>>>> james@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 <
> 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 <nf...@redhat.com>
> >>>>>>>>>>>>>>>>>>> Senior Software Engineer, JBoss Fuse
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Claus Ibsen
> >>>>>>>>>>>>>>>>>> -----------------
> >>>>>>>>>>>>>>>>>> http://davsclaus.com @davsclaus
> >>>>>>>>>>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Claus Ibsen
> >>>>>>>>> -----------------
> >>>>>>>>> http://davsclaus.com @davsclaus
> >>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Claus Ibsen
> >>>>>> -----------------
> >>>>>> http://davsclaus.com @davsclaus
> >>>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Claus Ibsen
> >>>> -----------------
> >>>> http://davsclaus.com @davsclaus
> >>>> Camel in Action 2: https://www.manning.com/ibsen2
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
I'll ask the log4j guys, thx for spotting this.
---
Luca Burgazzoli
On Thu, Aug 18, 2016 at 5:37 PM, Antonin Stefanutti
<an...@stefanutti.fr> wrote:
> Hi Luca,
>
> I’ve just encountered an issue when using the date function that gets substituted by Log4j 2 and causes the exception below to be thrown.
>
> It happens in a number of situations:
> - when a route definition containing the date function get logged (in DEBUG level)
> - when an advice is being applied (in INFO level)
> - ...
>
> This is described in: http://stackoverflow.com/questions/27103400/log4j2-how-to-disable-date-lookup-log4j-throws-exception
>
> Invalid date format: [now:hh:mm:ss a], using default java.lang.IllegalArgumentException: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.apache.logging.log4j.core.lookup.DateLookup.formatDate(DateLookup.java:64)
> at org.apache.logging.log4j.core.lookup.DateLookup.lookup(DateLookup.java:57)
> at org.apache.logging.log4j.core.lookup.Interpolator.lookup(Interpolator.java:159)
> at org.apache.logging.log4j.core.lookup.StrSubstitutor.resolveVariable(StrSubstitutor.java:1046)
> at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:963)
> at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:853)
> at org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(StrSubstitutor.java:408)
> at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:73)
> at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
> at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:294)
> at org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:195)
> at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:180)
> at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
> at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:120)
> at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:113)
> at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:104)
> at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:155)
> at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:128)
> at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:119)
> at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
> at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:375)
> at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
> at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:349)
> at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1993)
> at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852)
> at org.apache.logging.slf4j.Log4jLogger.info(Log4jLogger.java:179)
> at org.apache.camel.builder.AdviceWithTasks$4.task(AdviceWithTasks.java:354)
> at org.apache.camel.model.RouteDefinition.adviceWith(RouteDefinition.java:280)
>
> Antonin
>
>> On 12 Aug 2016, at 10:17, Luca Burgazzoli <lb...@gmail.com> wrote:
>>
>> I've migrated also spark, spark-rest, hbase and sip,
>> Thx to Vitalii fot the tip about log4j-over-slf4j.
>>
>> The only module that relies on log4j is now camel-itest-karaf
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Aug 10, 2016 at 5:33 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> Code merged and finger crossed
>>> Please report any issue
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> Yeah sure sounds good that all this works will pay of and we will be
>>>> migrated for 2.18 release.
>>>>
>>>> On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>> tests/camel-itest --> works
>>>>> tests/camel-itest-karaf --> need to keep log4j because of pax logging
>>>>> tests/camel-itest-spring-boot --> migrated
>>>>>
>>>>> I've pushed some new bits with some fixes to my branch as well as some fixes
>>>>> for few test in camel-itest-karaf about system packages needed by Ignite and
>>>>> Drools.
>>>>>
>>>>> I'm almost ready to rebase from master and the merge my work if you do not
>>>>> have any objection.
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> Hi Luca
>>>>>>
>>>>>> Its a lot of changes but it looks good.
>>>>>>
>>>>>> I think its maybe only the maven archetypes that may need a bit of
>>>>>> manual testing to see if the generated projects are all compiling and
>>>>>> working as expected.
>>>>>>
>>>>>> I noticed on master branch (not yours) that the blueprint archetype do
>>>>>> not log to the console when you run mvn camel:run goal. This is likely
>>>>>> a general problem where we may need to tweak the run goal to automatic
>>>>>> include some kind of logging out of the box (or include the test
>>>>>> scoped src/test/resources/log4j properties) or whatever it takes.
>>>>>>
>>>>>> I suggest you run the tests in
>>>>>>
>>>>>> tests/camel-itest
>>>>>> tests/camel-itest-karaf
>>>>>> tests/camel-itest-spring-boot
>>>>>>
>>>>>> to see if they are still all working.
>>>>>>
>>>>>> However great work to migrate all that. Then we can get this in the
>>>>>> 2.18 release.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>> I've pushed the latest bit of the migration in my branch.
>>>>>>> Except for the mentioned components, everything else should have been migrated.
>>>>>>>
>>>>>>> I really appreciate if someone could help testing a little bit with a
>>>>>>> focus on tooling, examples and tests.
>>>>>>>
>>>>>>> ---
>>>>>>> Luca Burgazzoli
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>>> I do not remember now but some problems come from the test
>>>>>>>> dependencies we use (like microcluster, etc)
>>>>>>>> Need to digg into the issue more once the majority of the migration will be done
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Luca Burgazzoli
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Ah sounds good the migration goes so well, and that there is only a
>>>>>>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>>>>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>>>>>>> etc) in the future.
>>>>>>>>>
>>>>>>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've setup my own branch
>>>>>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>>>>>>> were I'm doing some test to migrate to log4j2.
>>>>>>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>>>>>>
>>>>>>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>>>>>>> - camel-spark
>>>>>>>>>> - camel-spark-rest
>>>>>>>>>> - camel-sip
>>>>>>>>>> - camel-hbase
>>>>>>>>>>
>>>>>>>>>> For other components I found that log4j.properties was used also to
>>>>>>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>>>>>>
>>>>>>>>>> All the remaining component and caml-core have been tested an
>>>>>>>>>> successfully migrated.
>>>>>>>>>> I still need to migrate examples, tooling and so on.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Luca Burgazzoli
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>> We have a ticket to track migration issues:
>>>>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>>>>>>
>>>>>>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <lb...@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 <
>>>>>>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>>>>>>>>>>>>>> Senior Software Engineer, JBoss Fuse
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Claus Ibsen
>>>>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>>>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Log4j 2
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
Hi Luca,
I’ve just encountered an issue when using the date function that gets substituted by Log4j 2 and causes the exception below to be thrown.
It happens in a number of situations:
- when a route definition containing the date function get logged (in DEBUG level)
- when an advice is being applied (in INFO level)
- ...
This is described in: http://stackoverflow.com/questions/27103400/log4j2-how-to-disable-date-lookup-log4j-throws-exception
Invalid date format: [now:hh:mm:ss a], using default java.lang.IllegalArgumentException: Illegal pattern character 'n'
at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
at org.apache.logging.log4j.core.lookup.DateLookup.formatDate(DateLookup.java:64)
at org.apache.logging.log4j.core.lookup.DateLookup.lookup(DateLookup.java:57)
at org.apache.logging.log4j.core.lookup.Interpolator.lookup(Interpolator.java:159)
at org.apache.logging.log4j.core.lookup.StrSubstitutor.resolveVariable(StrSubstitutor.java:1046)
at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:963)
at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:853)
at org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(StrSubstitutor.java:408)
at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:73)
at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:294)
at org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:195)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:180)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:120)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:113)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:104)
at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:155)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:128)
at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:119)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:375)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:349)
at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1993)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852)
at org.apache.logging.slf4j.Log4jLogger.info(Log4jLogger.java:179)
at org.apache.camel.builder.AdviceWithTasks$4.task(AdviceWithTasks.java:354)
at org.apache.camel.model.RouteDefinition.adviceWith(RouteDefinition.java:280)
Antonin
> On 12 Aug 2016, at 10:17, Luca Burgazzoli <lb...@gmail.com> wrote:
>
> I've migrated also spark, spark-rest, hbase and sip,
> Thx to Vitalii fot the tip about log4j-over-slf4j.
>
> The only module that relies on log4j is now camel-itest-karaf
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Aug 10, 2016 at 5:33 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Code merged and finger crossed
>> Please report any issue
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Yeah sure sounds good that all this works will pay of and we will be
>>> migrated for 2.18 release.
>>>
>>> On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> tests/camel-itest --> works
>>>> tests/camel-itest-karaf --> need to keep log4j because of pax logging
>>>> tests/camel-itest-spring-boot --> migrated
>>>>
>>>> I've pushed some new bits with some fixes to my branch as well as some fixes
>>>> for few test in camel-itest-karaf about system packages needed by Ignite and
>>>> Drools.
>>>>
>>>> I'm almost ready to rebase from master and the merge my work if you do not
>>>> have any objection.
>>>>
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> Hi Luca
>>>>>
>>>>> Its a lot of changes but it looks good.
>>>>>
>>>>> I think its maybe only the maven archetypes that may need a bit of
>>>>> manual testing to see if the generated projects are all compiling and
>>>>> working as expected.
>>>>>
>>>>> I noticed on master branch (not yours) that the blueprint archetype do
>>>>> not log to the console when you run mvn camel:run goal. This is likely
>>>>> a general problem where we may need to tweak the run goal to automatic
>>>>> include some kind of logging out of the box (or include the test
>>>>> scoped src/test/resources/log4j properties) or whatever it takes.
>>>>>
>>>>> I suggest you run the tests in
>>>>>
>>>>> tests/camel-itest
>>>>> tests/camel-itest-karaf
>>>>> tests/camel-itest-spring-boot
>>>>>
>>>>> to see if they are still all working.
>>>>>
>>>>> However great work to migrate all that. Then we can get this in the
>>>>> 2.18 release.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>> I've pushed the latest bit of the migration in my branch.
>>>>>> Except for the mentioned components, everything else should have been migrated.
>>>>>>
>>>>>> I really appreciate if someone could help testing a little bit with a
>>>>>> focus on tooling, examples and tests.
>>>>>>
>>>>>> ---
>>>>>> Luca Burgazzoli
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>> I do not remember now but some problems come from the test
>>>>>>> dependencies we use (like microcluster, etc)
>>>>>>> Need to digg into the issue more once the majority of the migration will be done
>>>>>>>
>>>>>>> ---
>>>>>>> Luca Burgazzoli
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Ah sounds good the migration goes so well, and that there is only a
>>>>>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>>>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>>>>>> etc) in the future.
>>>>>>>>
>>>>>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I've setup my own branch
>>>>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>>>>>> were I'm doing some test to migrate to log4j2.
>>>>>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>>>>>
>>>>>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>>>>>> - camel-spark
>>>>>>>>> - camel-spark-rest
>>>>>>>>> - camel-sip
>>>>>>>>> - camel-hbase
>>>>>>>>>
>>>>>>>>> For other components I found that log4j.properties was used also to
>>>>>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>>>>>
>>>>>>>>> All the remaining component and caml-core have been tested an
>>>>>>>>> successfully migrated.
>>>>>>>>> I still need to migrate examples, tooling and so on.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Luca Burgazzoli
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>> We have a ticket to track migration issues:
>>>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>>>>>
>>>>>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <lb...@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 <
>>>>>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>>>>>>>>>>>>> Senior Software Engineer, JBoss Fuse
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Claus Ibsen
>>>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
I've migrated also spark, spark-rest, hbase and sip,
Thx to Vitalii fot the tip about log4j-over-slf4j.
The only module that relies on log4j is now camel-itest-karaf
---
Luca Burgazzoli
On Wed, Aug 10, 2016 at 5:33 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Code merged and finger crossed
> Please report any issue
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Yeah sure sounds good that all this works will pay of and we will be
>> migrated for 2.18 release.
>>
>> On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> tests/camel-itest --> works
>>> tests/camel-itest-karaf --> need to keep log4j because of pax logging
>>> tests/camel-itest-spring-boot --> migrated
>>>
>>> I've pushed some new bits with some fixes to my branch as well as some fixes
>>> for few test in camel-itest-karaf about system packages needed by Ignite and
>>> Drools.
>>>
>>> I'm almost ready to rebase from master and the merge my work if you do not
>>> have any objection.
>>>
>>>
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> Hi Luca
>>>>
>>>> Its a lot of changes but it looks good.
>>>>
>>>> I think its maybe only the maven archetypes that may need a bit of
>>>> manual testing to see if the generated projects are all compiling and
>>>> working as expected.
>>>>
>>>> I noticed on master branch (not yours) that the blueprint archetype do
>>>> not log to the console when you run mvn camel:run goal. This is likely
>>>> a general problem where we may need to tweak the run goal to automatic
>>>> include some kind of logging out of the box (or include the test
>>>> scoped src/test/resources/log4j properties) or whatever it takes.
>>>>
>>>> I suggest you run the tests in
>>>>
>>>> tests/camel-itest
>>>> tests/camel-itest-karaf
>>>> tests/camel-itest-spring-boot
>>>>
>>>> to see if they are still all working.
>>>>
>>>> However great work to migrate all that. Then we can get this in the
>>>> 2.18 release.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>> I've pushed the latest bit of the migration in my branch.
>>>>> Except for the mentioned components, everything else should have been migrated.
>>>>>
>>>>> I really appreciate if someone could help testing a little bit with a
>>>>> focus on tooling, examples and tests.
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>> I do not remember now but some problems come from the test
>>>>>> dependencies we use (like microcluster, etc)
>>>>>> Need to digg into the issue more once the majority of the migration will be done
>>>>>>
>>>>>> ---
>>>>>> Luca Burgazzoli
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Ah sounds good the migration goes so well, and that there is only a
>>>>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>>>>> etc) in the future.
>>>>>>>
>>>>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've setup my own branch
>>>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>>>>> were I'm doing some test to migrate to log4j2.
>>>>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>>>>
>>>>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>>>>> - camel-spark
>>>>>>>> - camel-spark-rest
>>>>>>>> - camel-sip
>>>>>>>> - camel-hbase
>>>>>>>>
>>>>>>>> For other components I found that log4j.properties was used also to
>>>>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>>>>
>>>>>>>> All the remaining component and caml-core have been tested an
>>>>>>>> successfully migrated.
>>>>>>>> I still need to migrate examples, tooling and so on.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Luca Burgazzoli
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>> We have a ticket to track migration issues:
>>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>>>>
>>>>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>>>>
>>>>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> > 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 <lb...@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 <
>>>>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>>>>>>> > > >> > >
>>>>>>>>>> > > >> > >
>>>>>>>>>> > > >> > >
>>>>>>>>>> > > >> > > --
>>>>>>>>>> > > >> > > Claus Ibsen
>>>>>>>>>> > > >> > > -----------------
>>>>>>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>>>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>>> > > >> > >
>>>>>>>>>> > > >> >
>>>>>>>>>> > > >>
>>>>>>>>>> > > >>
>>>>>>>>>> > > >>
>>>>>>>>>> > > >> --
>>>>>>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>>>>>>> > > >>
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > --
>>>>>>>>>> > Matt Sicker <bo...@gmail.com>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> http://davsclaus.com @davsclaus
>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
Code merged and finger crossed
Please report any issue
---
Luca Burgazzoli
On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah sure sounds good that all this works will pay of and we will be
> migrated for 2.18 release.
>
> On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> tests/camel-itest --> works
>> tests/camel-itest-karaf --> need to keep log4j because of pax logging
>> tests/camel-itest-spring-boot --> migrated
>>
>> I've pushed some new bits with some fixes to my branch as well as some fixes
>> for few test in camel-itest-karaf about system packages needed by Ignite and
>> Drools.
>>
>> I'm almost ready to rebase from master and the merge my work if you do not
>> have any objection.
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi Luca
>>>
>>> Its a lot of changes but it looks good.
>>>
>>> I think its maybe only the maven archetypes that may need a bit of
>>> manual testing to see if the generated projects are all compiling and
>>> working as expected.
>>>
>>> I noticed on master branch (not yours) that the blueprint archetype do
>>> not log to the console when you run mvn camel:run goal. This is likely
>>> a general problem where we may need to tweak the run goal to automatic
>>> include some kind of logging out of the box (or include the test
>>> scoped src/test/resources/log4j properties) or whatever it takes.
>>>
>>> I suggest you run the tests in
>>>
>>> tests/camel-itest
>>> tests/camel-itest-karaf
>>> tests/camel-itest-spring-boot
>>>
>>> to see if they are still all working.
>>>
>>> However great work to migrate all that. Then we can get this in the
>>> 2.18 release.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> I've pushed the latest bit of the migration in my branch.
>>>> Except for the mentioned components, everything else should have been migrated.
>>>>
>>>> I really appreciate if someone could help testing a little bit with a
>>>> focus on tooling, examples and tests.
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>> I do not remember now but some problems come from the test
>>>>> dependencies we use (like microcluster, etc)
>>>>> Need to digg into the issue more once the majority of the migration will be done
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> Hi
>>>>>>
>>>>>> Ah sounds good the migration goes so well, and that there is only a
>>>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>>>> etc) in the future.
>>>>>>
>>>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've setup my own branch
>>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>>>> were I'm doing some test to migrate to log4j2.
>>>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>>>
>>>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>>>> - camel-spark
>>>>>>> - camel-spark-rest
>>>>>>> - camel-sip
>>>>>>> - camel-hbase
>>>>>>>
>>>>>>> For other components I found that log4j.properties was used also to
>>>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>>>
>>>>>>> All the remaining component and caml-core have been tested an
>>>>>>> successfully migrated.
>>>>>>> I still need to migrate examples, tooling and so on.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Luca Burgazzoli
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>> We have a ticket to track migration issues:
>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>>>
>>>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>>>
>>>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> > 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 <lb...@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 <
>>>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>>>>>> > > >> > >
>>>>>>>>> > > >> > >
>>>>>>>>> > > >> > >
>>>>>>>>> > > >> > > --
>>>>>>>>> > > >> > > Claus Ibsen
>>>>>>>>> > > >> > > -----------------
>>>>>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>> > > >> > >
>>>>>>>>> > > >> >
>>>>>>>>> > > >>
>>>>>>>>> > > >>
>>>>>>>>> > > >>
>>>>>>>>> > > >> --
>>>>>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>>>>>> > > >>
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Matt Sicker <bo...@gmail.com>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah sure sounds good that all this works will pay of and we will be
migrated for 2.18 release.
On Wed, Aug 10, 2016 at 3:26 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> tests/camel-itest --> works
> tests/camel-itest-karaf --> need to keep log4j because of pax logging
> tests/camel-itest-spring-boot --> migrated
>
> I've pushed some new bits with some fixes to my branch as well as some fixes
> for few test in camel-itest-karaf about system packages needed by Ignite and
> Drools.
>
> I'm almost ready to rebase from master and the merge my work if you do not
> have any objection.
>
>
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi Luca
>>
>> Its a lot of changes but it looks good.
>>
>> I think its maybe only the maven archetypes that may need a bit of
>> manual testing to see if the generated projects are all compiling and
>> working as expected.
>>
>> I noticed on master branch (not yours) that the blueprint archetype do
>> not log to the console when you run mvn camel:run goal. This is likely
>> a general problem where we may need to tweak the run goal to automatic
>> include some kind of logging out of the box (or include the test
>> scoped src/test/resources/log4j properties) or whatever it takes.
>>
>> I suggest you run the tests in
>>
>> tests/camel-itest
>> tests/camel-itest-karaf
>> tests/camel-itest-spring-boot
>>
>> to see if they are still all working.
>>
>> However great work to migrate all that. Then we can get this in the
>> 2.18 release.
>>
>>
>>
>>
>>
>> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> I've pushed the latest bit of the migration in my branch.
>>> Except for the mentioned components, everything else should have been migrated.
>>>
>>> I really appreciate if someone could help testing a little bit with a
>>> focus on tooling, examples and tests.
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> I do not remember now but some problems come from the test
>>>> dependencies we use (like microcluster, etc)
>>>> Need to digg into the issue more once the majority of the migration will be done
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> Hi
>>>>>
>>>>> Ah sounds good the migration goes so well, and that there is only a
>>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>>> etc) in the future.
>>>>>
>>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I've setup my own branch
>>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>>> were I'm doing some test to migrate to log4j2.
>>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>>
>>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>>> - camel-spark
>>>>>> - camel-spark-rest
>>>>>> - camel-sip
>>>>>> - camel-hbase
>>>>>>
>>>>>> For other components I found that log4j.properties was used also to
>>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>>
>>>>>> All the remaining component and caml-core have been tested an
>>>>>> successfully migrated.
>>>>>> I still need to migrate examples, tooling and so on.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Luca Burgazzoli
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>> We have a ticket to track migration issues:
>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>>
>>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>>
>>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> > 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 <lb...@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 <
>>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>>>>> > > >> > >
>>>>>>>> > > >> > >
>>>>>>>> > > >> > >
>>>>>>>> > > >> > > --
>>>>>>>> > > >> > > Claus Ibsen
>>>>>>>> > > >> > > -----------------
>>>>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>> > > >> > >
>>>>>>>> > > >> >
>>>>>>>> > > >>
>>>>>>>> > > >>
>>>>>>>> > > >>
>>>>>>>> > > >> --
>>>>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>>>>> > > >>
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Matt Sicker <bo...@gmail.com>
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
tests/camel-itest --> works
tests/camel-itest-karaf --> need to keep log4j because of pax logging
tests/camel-itest-spring-boot --> migrated
I've pushed some new bits with some fixes to my branch as well as some fixes
for few test in camel-itest-karaf about system packages needed by Ignite and
Drools.
I'm almost ready to rebase from master and the merge my work if you do not
have any objection.
---
Luca Burgazzoli
On Wed, Aug 10, 2016 at 8:45 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi Luca
>
> Its a lot of changes but it looks good.
>
> I think its maybe only the maven archetypes that may need a bit of
> manual testing to see if the generated projects are all compiling and
> working as expected.
>
> I noticed on master branch (not yours) that the blueprint archetype do
> not log to the console when you run mvn camel:run goal. This is likely
> a general problem where we may need to tweak the run goal to automatic
> include some kind of logging out of the box (or include the test
> scoped src/test/resources/log4j properties) or whatever it takes.
>
> I suggest you run the tests in
>
> tests/camel-itest
> tests/camel-itest-karaf
> tests/camel-itest-spring-boot
>
> to see if they are still all working.
>
> However great work to migrate all that. Then we can get this in the
> 2.18 release.
>
>
>
>
>
> On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> I've pushed the latest bit of the migration in my branch.
>> Except for the mentioned components, everything else should have been migrated.
>>
>> I really appreciate if someone could help testing a little bit with a
>> focus on tooling, examples and tests.
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> I do not remember now but some problems come from the test
>>> dependencies we use (like microcluster, etc)
>>> Need to digg into the issue more once the majority of the migration will be done
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> Ah sounds good the migration goes so well, and that there is only a
>>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>>> etc) in the future.
>>>>
>>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>>
>>>>
>>>>
>>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I've setup my own branch
>>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>>> were I'm doing some test to migrate to log4j2.
>>>>> So far migrating the properties was not an issue and automated through a script.
>>>>>
>>>>> The following component can't be migrate as they have some code based on log4j:
>>>>> - camel-spark
>>>>> - camel-spark-rest
>>>>> - camel-sip
>>>>> - camel-hbase
>>>>>
>>>>> For other components I found that log4j.properties was used also to
>>>>> perform some test (i.e. a file to serve in jetty9).
>>>>>
>>>>> All the remaining component and caml-core have been tested an
>>>>> successfully migrated.
>>>>> I still need to migrate examples, tooling and so on.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> We have a ticket to track migration issues:
>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>>
>>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>>
>>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> > 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 <lb...@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 <
>>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>>>> > > >> > >
>>>>>>> > > >> > >
>>>>>>> > > >> > >
>>>>>>> > > >> > > --
>>>>>>> > > >> > > Claus Ibsen
>>>>>>> > > >> > > -----------------
>>>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>> > > >> > >
>>>>>>> > > >> >
>>>>>>> > > >>
>>>>>>> > > >>
>>>>>>> > > >>
>>>>>>> > > >> --
>>>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>>>> > > >>
>>>>>>> > >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Matt Sicker <bo...@gmail.com>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Luca
Its a lot of changes but it looks good.
I think its maybe only the maven archetypes that may need a bit of
manual testing to see if the generated projects are all compiling and
working as expected.
I noticed on master branch (not yours) that the blueprint archetype do
not log to the console when you run mvn camel:run goal. This is likely
a general problem where we may need to tweak the run goal to automatic
include some kind of logging out of the box (or include the test
scoped src/test/resources/log4j properties) or whatever it takes.
I suggest you run the tests in
tests/camel-itest
tests/camel-itest-karaf
tests/camel-itest-spring-boot
to see if they are still all working.
However great work to migrate all that. Then we can get this in the
2.18 release.
On Tue, Aug 9, 2016 at 6:12 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> I've pushed the latest bit of the migration in my branch.
> Except for the mentioned components, everything else should have been migrated.
>
> I really appreciate if someone could help testing a little bit with a
> focus on tooling, examples and tests.
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> I do not remember now but some problems come from the test
>> dependencies we use (like microcluster, etc)
>> Need to digg into the issue more once the majority of the migration will be done
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Ah sounds good the migration goes so well, and that there is only a
>>> few components that may be stuck on log4j 1.x. But those 3rd party
>>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>>> etc) in the future.
>>>
>>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>>
>>>
>>>
>>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> I've setup my own branch
>>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>>> were I'm doing some test to migrate to log4j2.
>>>> So far migrating the properties was not an issue and automated through a script.
>>>>
>>>> The following component can't be migrate as they have some code based on log4j:
>>>> - camel-spark
>>>> - camel-spark-rest
>>>> - camel-sip
>>>> - camel-hbase
>>>>
>>>> For other components I found that log4j.properties was used also to
>>>> perform some test (i.e. a file to serve in jetty9).
>>>>
>>>> All the remaining component and caml-core have been tested an
>>>> successfully migrated.
>>>> I still need to migrate examples, tooling and so on.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>> We have a ticket to track migration issues:
>>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>>
>>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>
>>>>>> Now, that's a motivation I can get behind! :)
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> > 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 <lb...@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 <
>>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>>> > > >> > >
>>>>>> > > >> > >
>>>>>> > > >> > >
>>>>>> > > >> > > --
>>>>>> > > >> > > Claus Ibsen
>>>>>> > > >> > > -----------------
>>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>> > > >> > >
>>>>>> > > >> >
>>>>>> > > >>
>>>>>> > > >>
>>>>>> > > >>
>>>>>> > > >> --
>>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>>> > > >>
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Matt Sicker <bo...@gmail.com>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
I've pushed the latest bit of the migration in my branch.
Except for the mentioned components, everything else should have been migrated.
I really appreciate if someone could help testing a little bit with a
focus on tooling, examples and tests.
---
Luca Burgazzoli
On Tue, Aug 9, 2016 at 2:59 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> I do not remember now but some problems come from the test
> dependencies we use (like microcluster, etc)
> Need to digg into the issue more once the majority of the migration will be done
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Ah sounds good the migration goes so well, and that there is only a
>> few components that may be stuck on log4j 1.x. But those 3rd party
>> libraries may migrate to log4j v2 or some other logging api (slf4j-api
>> etc) in the future.
>>
>> Though a bit surprising that Apache Spark is locked down on log4j v1.
>>
>>
>>
>> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> Hello,
>>>
>>> I've setup my own branch
>>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>>> were I'm doing some test to migrate to log4j2.
>>> So far migrating the properties was not an issue and automated through a script.
>>>
>>> The following component can't be migrate as they have some code based on log4j:
>>> - camel-spark
>>> - camel-spark-rest
>>> - camel-sip
>>> - camel-hbase
>>>
>>> For other components I found that log4j.properties was used also to
>>> perform some test (i.e. a file to serve in jetty9).
>>>
>>> All the remaining component and caml-core have been tested an
>>> successfully migrated.
>>> I still need to migrate examples, tooling and so on.
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>> We have a ticket to track migration issues:
>>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>>
>>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>>
>>>>> Now, that's a motivation I can get behind! :)
>>>>>
>>>>>
>>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> > 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 <lb...@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 <
>>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>>> > > >> > >
>>>>> > > >> > >
>>>>> > > >> > >
>>>>> > > >> > > --
>>>>> > > >> > > Claus Ibsen
>>>>> > > >> > > -----------------
>>>>> > > >> > > http://davsclaus.com @davsclaus
>>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>>> > > >> > >
>>>>> > > >> >
>>>>> > > >>
>>>>> > > >>
>>>>> > > >>
>>>>> > > >> --
>>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>>> > > >>
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Matt Sicker <bo...@gmail.com>
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
I do not remember now but some problems come from the test
dependencies we use (like microcluster, etc)
Need to digg into the issue more once the majority of the migration will be done
---
Luca Burgazzoli
On Tue, Aug 9, 2016 at 8:35 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Ah sounds good the migration goes so well, and that there is only a
> few components that may be stuck on log4j 1.x. But those 3rd party
> libraries may migrate to log4j v2 or some other logging api (slf4j-api
> etc) in the future.
>
> Though a bit surprising that Apache Spark is locked down on log4j v1.
>
>
>
> On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Hello,
>>
>> I've setup my own branch
>> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
>> were I'm doing some test to migrate to log4j2.
>> So far migrating the properties was not an issue and automated through a script.
>>
>> The following component can't be migrate as they have some code based on log4j:
>> - camel-spark
>> - camel-spark-rest
>> - camel-sip
>> - camel-hbase
>>
>> For other components I found that log4j.properties was used also to
>> perform some test (i.e. a file to serve in jetty9).
>>
>> All the remaining component and caml-core have been tested an
>> successfully migrated.
>> I still need to migrate examples, tooling and so on.
>>
>>
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>>> We have a ticket to track migration issues:
>>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>>
>>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>>> Now, that's a motivation I can get behind! :)
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> > 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 <lb...@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 <
>>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>>> > > >> > >
>>>> > > >> > >
>>>> > > >> > >
>>>> > > >> > > --
>>>> > > >> > > Claus Ibsen
>>>> > > >> > > -----------------
>>>> > > >> > > http://davsclaus.com @davsclaus
>>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>>> > > >> > >
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >> --
>>>> > > >> Matt Sicker <bo...@gmail.com>
>>>> > > >>
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Matt Sicker <bo...@gmail.com>
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Ah sounds good the migration goes so well, and that there is only a
few components that may be stuck on log4j 1.x. But those 3rd party
libraries may migrate to log4j v2 or some other logging api (slf4j-api
etc) in the future.
Though a bit surprising that Apache Spark is locked down on log4j v1.
On Mon, Aug 8, 2016 at 7:53 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Hello,
>
> I've setup my own branch
> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
> were I'm doing some test to migrate to log4j2.
> So far migrating the properties was not an issue and automated through a script.
>
> The following component can't be migrate as they have some code based on log4j:
> - camel-spark
> - camel-spark-rest
> - camel-sip
> - camel-hbase
>
> For other components I found that log4j.properties was used also to
> perform some test (i.e. a file to serve in jetty9).
>
> All the remaining component and caml-core have been tested an
> successfully migrated.
> I still need to migrate examples, tooling and so on.
>
>
>
>
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
>> We have a ticket to track migration issues:
>> https://issues.apache.org/jira/browse/LOG4J2-1473
>>
>> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> Now, that's a motivation I can get behind! :)
>>>
>>>
>>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> > 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 <lb...@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 <
>>> james@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 <bo...@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...@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 <nf...@redhat.com>
>>> > > >> > > > Senior Software Engineer, JBoss Fuse
>>> > > >> > >
>>> > > >> > >
>>> > > >> > >
>>> > > >> > > --
>>> > > >> > > Claus Ibsen
>>> > > >> > > -----------------
>>> > > >> > > http://davsclaus.com @davsclaus
>>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>>> > > >> > >
>>> > > >> >
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> --
>>> > > >> Matt Sicker <bo...@gmail.com>
>>> > > >>
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Matt Sicker <bo...@gmail.com>
>>> >
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Vitalii Tymchyshyn <vi...@tym.im>.
You can also try log4j over slf4j. This one has stubs for appender classes.
Best regards, Vitalii Tymchyshyn
Пн, 8 серп. 2016 15:42 користувач Luca Burgazzoli <lb...@gmail.com>
пише:
> That was what I tried at first but it is not enough because in some deps or
> utilities they use i.e. base appender classes that the is not provided by
> the log4j-1.2-api.
>
> I will detail the issue later this week.
>
> On Monday, 8 August 2016, Matt Sicker <bo...@gmail.com> wrote:
>
> > Can you add log4j-1.2-api to migrate those? We're working with Hadoop and
> > Spark right now to upgrade them to 2.x at least, so a future release from
> > them will fix that.
> >
> > On 8 August 2016 at 12:53, Luca Burgazzoli <lburgazzoli@gmail.com
> > <javascript:;>> wrote:
> >
> > > Hello,
> > >
> > > I've setup my own branch
> > > (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
> > > were I'm doing some test to migrate to log4j2.
> > > So far migrating the properties was not an issue and automated through
> a
> > > script.
> > >
> > > The following component can't be migrate as they have some code based
> on
> > > log4j:
> > > - camel-spark
> > > - camel-spark-rest
> > > - camel-sip
> > > - camel-hbase
> > >
> > > For other components I found that log4j.properties was used also to
> > > perform some test (i.e. a file to serve in jetty9).
> > >
> > > All the remaining component and caml-core have been tested an
> > > successfully migrated.
> > > I still need to migrate examples, tooling and so on.
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > Luca Burgazzoli
> > >
> > >
> > > On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <boards@gmail.com
> > <javascript:;>> wrote:
> > > > We have a ticket to track migration issues:
> > > > https://issues.apache.org/jira/browse/LOG4J2-1473
> > > >
> > > > On 2 August 2016 at 12:24, James Carman <james@carmanconsulting.com
> > <javascript:;>>
> > > wrote:
> > > >
> > > >> Now, that's a motivation I can get behind! :)
> > > >>
> > > >>
> > > >> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <boards@gmail.com
> > <javascript:;>> wrote:
> > > >>
> > > >> > 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 <lburgazzoli@gmail.com
> > <javascript:;>>
> > > >> 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 <
> > > >> james@carmanconsulting.com <javascript:;>
> > > >> > >
> > > >> > > 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 <boards@gmail.com
> > <javascript:;>>
> > > >> 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 <javascript:;>>
> > > >> > 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 <javascript:;>>
> > > >> > > >> 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 <javascript:;>
> > > >> > > >
> > > >> > > >> > > 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 <javascript:;>
> > > >> > > >> > >
> > > >> > > >> > > > 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 <javascript:;>>
> > > >> > > >> > > wrote:
> > > >> > > >> > > >> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <
> > > >> > > >> > > lburgazzoli@gmail.com <javascript:;>>
> > > >> > > >> > > >> 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 <javascript:;>>
> > > >> > > >> > > > 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 <javascript:;>>
> > > >> > > >>
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Matt Sicker <boards@gmail.com <javascript:;>>
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <boards@gmail.com <javascript:;>>
> > >
> >
> >
> >
> > --
> > Matt Sicker <boards@gmail.com <javascript:;>>
> >
>
>
> --
>
> ---
> Luca Burgazzoli
>
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
That was what I tried at first but it is not enough because in some deps or
utilities they use i.e. base appender classes that the is not provided by
the log4j-1.2-api.
I will detail the issue later this week.
On Monday, 8 August 2016, Matt Sicker <bo...@gmail.com> wrote:
> Can you add log4j-1.2-api to migrate those? We're working with Hadoop and
> Spark right now to upgrade them to 2.x at least, so a future release from
> them will fix that.
>
> On 8 August 2016 at 12:53, Luca Burgazzoli <lburgazzoli@gmail.com
> <javascript:;>> wrote:
>
> > Hello,
> >
> > I've setup my own branch
> > (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
> > were I'm doing some test to migrate to log4j2.
> > So far migrating the properties was not an issue and automated through a
> > script.
> >
> > The following component can't be migrate as they have some code based on
> > log4j:
> > - camel-spark
> > - camel-spark-rest
> > - camel-sip
> > - camel-hbase
> >
> > For other components I found that log4j.properties was used also to
> > perform some test (i.e. a file to serve in jetty9).
> >
> > All the remaining component and caml-core have been tested an
> > successfully migrated.
> > I still need to migrate examples, tooling and so on.
> >
> >
> >
> >
> >
> > ---
> > Luca Burgazzoli
> >
> >
> > On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <boards@gmail.com
> <javascript:;>> wrote:
> > > We have a ticket to track migration issues:
> > > https://issues.apache.org/jira/browse/LOG4J2-1473
> > >
> > > On 2 August 2016 at 12:24, James Carman <james@carmanconsulting.com
> <javascript:;>>
> > wrote:
> > >
> > >> Now, that's a motivation I can get behind! :)
> > >>
> > >>
> > >> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <boards@gmail.com
> <javascript:;>> wrote:
> > >>
> > >> > 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 <lburgazzoli@gmail.com
> <javascript:;>>
> > >> 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 <
> > >> james@carmanconsulting.com <javascript:;>
> > >> > >
> > >> > > 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 <boards@gmail.com
> <javascript:;>>
> > >> 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 <javascript:;>>
> > >> > 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 <javascript:;>>
> > >> > > >> 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 <javascript:;>
> > >> > > >
> > >> > > >> > > 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 <javascript:;>
> > >> > > >> > >
> > >> > > >> > > > 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 <javascript:;>>
> > >> > > >> > > wrote:
> > >> > > >> > > >> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <
> > >> > > >> > > lburgazzoli@gmail.com <javascript:;>>
> > >> > > >> > > >> 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 <javascript:;>>
> > >> > > >> > > > 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 <javascript:;>>
> > >> > > >>
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Matt Sicker <boards@gmail.com <javascript:;>>
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Matt Sicker <boards@gmail.com <javascript:;>>
> >
>
>
>
> --
> Matt Sicker <boards@gmail.com <javascript:;>>
>
--
---
Luca Burgazzoli
Re: Log4j 2
Posted by Matt Sicker <bo...@gmail.com>.
Can you add log4j-1.2-api to migrate those? We're working with Hadoop and
Spark right now to upgrade them to 2.x at least, so a future release from
them will fix that.
On 8 August 2016 at 12:53, Luca Burgazzoli <lb...@gmail.com> wrote:
> Hello,
>
> I've setup my own branch
> (https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
> were I'm doing some test to migrate to log4j2.
> So far migrating the properties was not an issue and automated through a
> script.
>
> The following component can't be migrate as they have some code based on
> log4j:
> - camel-spark
> - camel-spark-rest
> - camel-sip
> - camel-hbase
>
> For other components I found that log4j.properties was used also to
> perform some test (i.e. a file to serve in jetty9).
>
> All the remaining component and caml-core have been tested an
> successfully migrated.
> I still need to migrate examples, tooling and so on.
>
>
>
>
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
> > We have a ticket to track migration issues:
> > https://issues.apache.org/jira/browse/LOG4J2-1473
> >
> > On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> >> Now, that's a motivation I can get behind! :)
> >>
> >>
> >> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
> >>
> >> > 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 <lb...@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 <
> >> james@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 <bo...@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...@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 <nf...@redhat.com>
> >> > > >> > > > Senior Software Engineer, JBoss Fuse
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > --
> >> > > >> > > Claus Ibsen
> >> > > >> > > -----------------
> >> > > >> > > http://davsclaus.com @davsclaus
> >> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
> >> > > >> > >
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Matt Sicker <bo...@gmail.com>
> >> > > >>
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Matt Sicker <bo...@gmail.com>
> >> >
> >>
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
Hello,
I've setup my own branch
(https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10224-log4j2)
were I'm doing some test to migrate to log4j2.
So far migrating the properties was not an issue and automated through a script.
The following component can't be migrate as they have some code based on log4j:
- camel-spark
- camel-spark-rest
- camel-sip
- camel-hbase
For other components I found that log4j.properties was used also to
perform some test (i.e. a file to serve in jetty9).
All the remaining component and caml-core have been tested an
successfully migrated.
I still need to migrate examples, tooling and so on.
---
Luca Burgazzoli
On Tue, Aug 2, 2016 at 10:10 PM, Matt Sicker <bo...@gmail.com> wrote:
> We have a ticket to track migration issues:
> https://issues.apache.org/jira/browse/LOG4J2-1473
>
> On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
>
>> Now, that's a motivation I can get behind! :)
>>
>>
>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>>
>> > 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 <lb...@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 <
>> james@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 <bo...@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...@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 <nf...@redhat.com>
>> > > >> > > > Senior Software Engineer, JBoss Fuse
>> > > >> > >
>> > > >> > >
>> > > >> > >
>> > > >> > > --
>> > > >> > > Claus Ibsen
>> > > >> > > -----------------
>> > > >> > > http://davsclaus.com @davsclaus
>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>> > > >> > >
>> > > >> >
>> > > >>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Matt Sicker <bo...@gmail.com>
>> > > >>
>> > >
>> >
>> >
>> >
>> > --
>> > Matt Sicker <bo...@gmail.com>
>> >
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Matt Sicker <bo...@gmail.com>.
We have a ticket to track migration issues:
https://issues.apache.org/jira/browse/LOG4J2-1473
On 2 August 2016 at 12:24, James Carman <ja...@carmanconsulting.com> wrote:
> Now, that's a motivation I can get behind! :)
>
>
> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
>
> > 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 <lb...@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 <
> james@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 <bo...@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...@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 <nf...@redhat.com>
> > > >> > > > Senior Software Engineer, JBoss Fuse
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Claus Ibsen
> > > >> > > -----------------
> > > >> > > http://davsclaus.com @davsclaus
> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker <bo...@gmail.com>
> > > >>
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by James Carman <ja...@carmanconsulting.com>.
Now, that's a motivation I can get behind! :)
On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker <bo...@gmail.com> wrote:
> 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 <lb...@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 <james@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 <bo...@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...@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 <cl...@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 <nf...@redhat.com>
> > >> > > > Senior Software Engineer, JBoss Fuse
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Claus Ibsen
> > >> > > -----------------
> > >> > > http://davsclaus.com @davsclaus
> > >> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >>
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Log4j 2
Posted by Matt Sicker <bo...@gmail.com>.
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 <lb...@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 <bo...@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...@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 <cl...@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 <nf...@redhat.com>
> >> > > > Senior Software Engineer, JBoss Fuse
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Claus Ibsen
> >> > > -----------------
> >> > > http://davsclaus.com @davsclaus
> >> > > Camel in Action 2: https://www.manning.com/ibsen2
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
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 <bo...@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...@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 <cl...@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 <nf...@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 <cl...@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 <nf...@redhat.com>
>> > > > Senior Software Engineer, JBoss Fuse
>> > >
>> > >
>> > >
>> > > --
>> > > Claus Ibsen
>> > > -----------------
>> > > http://davsclaus.com @davsclaus
>> > > Camel in Action 2: https://www.manning.com/ibsen2
>> > >
>> >
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
Re: Log4j 2
Posted by James Carman <ja...@carmanconsulting.com>.
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 <bo...@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...@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 <cl...@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 <nf...@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 <cl...@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 <nf...@redhat.com>
> > > > Senior Software Engineer, JBoss Fuse
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
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 <bo...@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...@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 <cl...@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 <nf...@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 <cl...@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 <nf...@redhat.com>
>> > > Senior Software Engineer, JBoss Fuse
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>> >
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Matt Sicker <bo...@gmail.com>.
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...@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 <cl...@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 <nf...@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 <cl...@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 <nf...@redhat.com>
> > > Senior Software Engineer, JBoss Fuse
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j 2
Posted by Nicola Ferraro <ni...@gmail.com>.
I logged a Jira: https://issues.apache.org/jira/browse/CAMEL-10217
On Tue, Aug 2, 2016 at 4:35 PM, Claus Ibsen <cl...@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 <nf...@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 <lb...@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 <cl...@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 <nf...@redhat.com>
> > Senior Software Engineer, JBoss Fuse
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
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 <nf...@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 <lb...@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 <cl...@gmail.com> wrote:
>> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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 <nf...@redhat.com>
> Senior Software Engineer, JBoss Fuse
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Nicola Ferraro <nf...@redhat.com>.
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 <lb...@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 <cl...@gmail.com> wrote:
> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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 <nf...@redhat.com>
Senior Software Engineer, JBoss Fuse
Re: Log4j 2
Posted by Luca Burgazzoli <lb...@gmail.com>.
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 <cl...@gmail.com> wrote:
> On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Aug 2, 2016 at 2:55 PM, Vitalii Tymchyshyn <vi...@tym.im> wrote:
> Well, best practice is to use a logging facade like slf4j and not some
> logging implementation, like logback or log4j.
>
Camel uses slf4j-api as the logging facade
> P.S. I will be grateful if someone tell me if this message can be seen
>
Yep
> Best regards, Vitalii Tymchyshyn
>
> Вт, 2 серп. 2016 08:53 користувач Claus Ibsen <cl...@gmail.com> пише:
>
>> Oh and if any migration is needed, then maybe logback is an
>> alternative than log4j v2?
>> http://logback.qos.ch
>>
>>
>> On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by James Carman <ja...@carmanconsulting.com>.
I see no reason to change the logging implementation for tests. If it
ain't broke, don't fix it.
On Tue, Aug 2, 2016 at 9:00 AM James Carman <ja...@carmanconsulting.com>
wrote:
> +1, I'd rather use some form of a facade (homegrown, slf4j, etc.)
>
> On Tue, Aug 2, 2016 at 8:55 AM Vitalii Tymchyshyn <vi...@tym.im> wrote:
>
>> Well, best practice is to use a logging facade like slf4j and not some
>> logging implementation, like logback or log4j.
>>
>> P.S. I will be grateful if someone tell me if this message can be seen
>>
>> Best regards, Vitalii Tymchyshyn
>>
>> Вт, 2 серп. 2016 08:53 користувач Claus Ibsen <cl...@gmail.com>
>> пише:
>>
>> > Oh and if any migration is needed, then maybe logback is an
>> > alternative than log4j v2?
>> > http://logback.qos.ch
>> >
>> >
>> > On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <cl...@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
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>> >
>>
>
Re: Log4j 2
Posted by James Carman <ja...@carmanconsulting.com>.
+1, I'd rather use some form of a facade (homegrown, slf4j, etc.)
On Tue, Aug 2, 2016 at 8:55 AM Vitalii Tymchyshyn <vi...@tym.im> wrote:
> Well, best practice is to use a logging facade like slf4j and not some
> logging implementation, like logback or log4j.
>
> P.S. I will be grateful if someone tell me if this message can be seen
>
> Best regards, Vitalii Tymchyshyn
>
> Вт, 2 серп. 2016 08:53 користувач Claus Ibsen <cl...@gmail.com>
> пише:
>
> > Oh and if any migration is needed, then maybe logback is an
> > alternative than log4j v2?
> > http://logback.qos.ch
> >
> >
> > On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <cl...@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
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
Re: Log4j 2
Posted by Vitalii Tymchyshyn <vi...@tym.im>.
Well, best practice is to use a logging facade like slf4j and not some
logging implementation, like logback or log4j.
P.S. I will be grateful if someone tell me if this message can be seen
Best regards, Vitalii Tymchyshyn
Вт, 2 серп. 2016 08:53 користувач Claus Ibsen <cl...@gmail.com> пише:
> Oh and if any migration is needed, then maybe logback is an
> alternative than log4j v2?
> http://logback.qos.ch
>
>
> On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <cl...@gmail.com> wrote:
> > On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
Oh and if any migration is needed, then maybe logback is an
alternative than log4j v2?
http://logback.qos.ch
On Tue, Aug 2, 2016 at 2:50 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Log4j 2
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Aug 2, 2016 at 2:42 PM, Luca Burgazzoli <lb...@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