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