Re: Log4j 2
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 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 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 >> 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 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 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 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 >> wrote: >> >>> Now, that's a motivation I can get behind! :) >>> >>> >>> On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker 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 >>> 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 >>> 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 >>> > 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.i
Re: Log4j 2
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 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 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 >> 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 >>> 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 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 > 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 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 >>> wrote: >>> Now, that's a motivation I can get behind! :) On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker 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 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 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/br
Re: Log4j 2
Code merged and finger crossed Please report any issue --- Luca Burgazzoli On Wed, Aug 10, 2016 at 4:14 PM, Claus Ibsen 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 > 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 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 >>> 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 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 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 >> 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 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 wrote: > Now, that's a motivation I can get behind! :) > > > On Tue, Aug 2, 2016 at 12:38 PM Matt Sicker 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 > 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
[GitHub] camel pull request #1115: [CAMEL-10233] Lazy load ModelJAXBContextFactory in...
GitHub user jamesnetherton opened a pull request: https://github.com/apache/camel/pull/1115 [CAMEL-10233] Lazy load ModelJAXBContextFactory in SpringCamelContext You can merge this pull request into a Git repository by running: $ git pull https://github.com/jamesnetherton/camel CAMEL-10233 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1115 commit d06ee9866c4315119eedab01b75b509342c1f848 Author: James Netherton Date: 2016-08-10T16:23:12Z [CAMEL-10233] Lazy load ModelJAXBContextFactory in SpringCamelContext --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Camel.trunk.notest - Build # 2839 - Still Failing
The Apache Jenkins build system has built Camel.trunk.notest (build #2839) Status: Still Failing Check console output at https://builds.apache.org/job/Camel.trunk.notest/2839/ to view the results.
