You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by bvahdat <ba...@swissonline.ch> on 2011/08/12 16:48:17 UTC

Re: Camel-freemarker

Hi Maximilien,

camel-freemaker's pom.xml seems to be the only one which was missed while
the commons-logging => slf4j migration went live by camel 2.7.x, see [1] for
the details. Nevertheless the code of this component does effectively
logging through slf4j-API (see the code at [2]), so that you should be able
to force this component to log to your prefered logging API, i.e.
JDK-Logging. By all other components is dependency to log4j is of the scope
"test" which doesn't effect camel users like you & me in any way.

On the other hand what I DO NOT understand in most of the poms is the
dependency declared to be like this:

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <scope>test</scope>
    </dependency>


which to my understanding is obsolete, as slf4j-log4j12 has already a
dependency to log4j, namely to the RIGHT version it requires. So I would say
one should remove ALL those DIRECT dependencies to log4j in all poms. The
overhead by this today is that if someday camel upgrades to slf4j-log4j12
version x+1 the log4j should also be upgraded, namely to the version
matching exactly to slf4j-log4j12 version x+1.

Currently camel depends on:

slf4j ===> 1.6.1
slf4j-log4j12 ===> same as slf4j, which makes sense
log4j ===> 1.2.16

And when one looks at [3] he sees that the log4j dependency would already be
given for FREE with the RIGHT version matching to slf4j-log4j12.

But maybe I'm missing something...

Regards, Babak  

[1] https://issues.apache.org/jira/browse/CAMEL-2229
[2]
https://svn.apache.org/repos/asf/camel/trunk/components/camel-freemarker/src/main/java/org/apache/camel/component/freemarker/
[3]
http://repo1.maven.org/maven2/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.pom

--
View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4693550.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-freemarker

Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Aug 14, 2011 at 9:54 PM, bvahdat <ba...@swissonline.ch> wrote:
>> There is no where on the slf4j website that states you must use log4j
> 1.1.x.
>
> I did not claim that to be the case, but my poor English seems to cause the
> people to misunderstand me. So to make it clear what I exactly mean, I
> extended my sample foo project which I posted before in this discussion with
> some code, see  http://camel.465427.n5.nabble.com/file/n4698903/foo.zip
> foo.zip . So simply do the following:
>
> - unzip it.
> - first read my comments in pom.xml
> - then do a 'mvn test -Dtest=DeveloperOwnClassTest' and see the following
> log4j's log statement on the console:  I'm the developer of the foo project
> and am love with the log4j version '1.1.3'
> - now do a 'mvn test -Dtest=FooRouteBuilderTest', and see how testing of the
> FooRouteBuilder route crashes...
>
> Do you see now what I mean?
>

For slf4j-log4j12 you need to use log4j 1.2.x version.
So stop using the old and outdated log4j 1.1.x version.



>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4698903.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel-freemarker

Posted by bvahdat <ba...@swissonline.ch>.
> There is no where on the slf4j website that states you must use log4j
1.1.x. 

I did not claim that to be the case, but my poor English seems to cause the
people to misunderstand me. So to make it clear what I exactly mean, I
extended my sample foo project which I posted before in this discussion with
some code, see  http://camel.465427.n5.nabble.com/file/n4698903/foo.zip
foo.zip . So simply do the following:

- unzip it.
- first read my comments in pom.xml
- then do a 'mvn test -Dtest=DeveloperOwnClassTest' and see the following
log4j's log statement on the console:  I'm the developer of the foo project
and am love with the log4j version '1.1.3'
- now do a 'mvn test -Dtest=FooRouteBuilderTest', and see how testing of the
FooRouteBuilder route crashes...

Do you see now what I mean?



--
View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4698903.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-freemarker

Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Aug 14, 2011 at 11:56 AM, bvahdat <ba...@swissonline.ch> wrote:
> Hi Claus,
>
> Thanks for applying the patch.
>
> Regarding what you already said by this discussion:
>
>> However as we just use it for testing, then we can take a short cut
>> and possible remove the log4j in the pom.xml file. But for the
>> examples we should not, as it can help show best practice to end
>> users, that they can setup log4j dependency and control which version
>> they want to use.
>
> IMHO I think even by examples the direct dependencies to log4j is obsolete
> and should be removed (it gives a wrong feeling to the users, that they
> should do it in the same way, which to me is NOT the best practice), as I
> think the camel users can NOT control which version of log4j they want to
> use IF they instruct camel to use log4j through a direct dependency to
> slf4j-log4j12. The simple foo.zip example I provided before by this
> dicussion proves this fact, see
>
> http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4695940.html
>
> I even think that the camel users should be sensibilized on WIKI or through
> the README.txt of examples that a version clash of log4j could cause
> problems.
>
> I have already a patch available on my workspace for the examples as well
> and could reopen the ticket and provide that as well.
>

No people should be able to pick and chose any log4j version they want
to use, that is compatible with slf4j.
There is no where on the slf4j website that states you must use log4j 1.1.x.

In fact if you look in the javadoc for the log4j appender from sfl4j
it indicate it adapts to the log4j version in use
http://www.slf4j.org/api/org/slf4j/impl/Log4jLoggerAdapter.html

See this FAQ as well
http://www.slf4j.org/faq.html#requirements

In fact slf4j-log4j12.jar indicate its using log4j 1.2.x version.

In the slf4j 1.6.1 parent pom.xml file it indicate its using this
version of log4j
 <log4j.version>1.2.16</log4j.version>

http://search.maven.org/#artifactdetails%7Corg.slf4j%7Cslf4j-parent%7C1.6.1%7Cpom


> Any idea?
>
> Regards, Babak
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4697863.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel-freemarker

Posted by bvahdat <ba...@swissonline.ch>.
Hi Claus,

Thanks for applying the patch.

Regarding what you already said by this discussion:

> However as we just use it for testing, then we can take a short cut 
> and possible remove the log4j in the pom.xml file. But for the 
> examples we should not, as it can help show best practice to end 
> users, that they can setup log4j dependency and control which version 
> they want to use. 

IMHO I think even by examples the direct dependencies to log4j is obsolete
and should be removed (it gives a wrong feeling to the users, that they
should do it in the same way, which to me is NOT the best practice), as I
think the camel users can NOT control which version of log4j they want to
use IF they instruct camel to use log4j through a direct dependency to
slf4j-log4j12. The simple foo.zip example I provided before by this
dicussion proves this fact, see 

http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4695940.html

I even think that the camel users should be sensibilized on WIKI or through
the README.txt of examples that a version clash of log4j could cause
problems.

I have already a patch available on my workspace for the examples as well
and could reopen the ticket and provide that as well.

Any idea?

Regards, Babak

  

--
View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4697863.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-freemarker

Posted by bvahdat <ba...@swissonline.ch>.
Hi Claus,

I created a ticket and provided the patch. Please see also my comment on the
ticket:

https://issues.apache.org/jira/browse/CAMEL-4331

Regards, Babak

--
View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4696497.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-freemarker

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Aug 13, 2011 at 1:17 PM, bvahdat <ba...@swissonline.ch> wrote:
> Claus,
>
>>>>Well frankly it is the other way around. End users should be able to
> specify exactly which log4j version they want to use.
>
> If camel users (2.8.0) instrucht camel to use log4j through slf4j by
> declaring a DIRECT dependency to the slf4j-log4j12, then indeed they will
> get stucked to log4j 1.2.16. See the example here for a version conflict of
> log4j caused through slf4j
> http://camel.465427.n5.nabble.com/file/n4695940/foo.zip foo.zip  and do a
>
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:tree -Dverbose=true
>
> And in maven's output see the line
>
> (log4j:log4j:jar:1.2.16:compile - omitted for conflict with 1.1.3)
>
> And we all know that at RUNTIME the application's routing logic will most
> probably crash with a "NoSuchMethodError" if camel calls a slf4j's
> LOGGER.xyz() method which gets delegated to log4j logging API. However the
> method signature slf4j Logger calls on log4j API was not available at the
> time by log4j API version 1.1.3. On the other hand this was the version the
> developer decided to use! Well in an OSGi environment things would seem
> different, but that's not our concern by this discussion.
>
> @Christian I've never used freemarker but they seem to use a Ant+Ivy build
> and not maven, see https://github.com/freemarker/freemarker. At least their
> maven pom claims to have no dependencies! see
> http://repo1.maven.org/maven2/org/freemarker/freemarker/2.3.18/freemarker-2.3.18.pom
>
> I'll wait to see what Claus thinks before opening a JIRA-ticket. There are
> two fixes I can see
> 1- remove the compile-scope dependency to log4j by camel-freemarker, see
> https://svn.apache.org/repos/asf/camel/trunk/components/camel-freemarker/pom.xml

Ah yeah i dont see a reason to have that. freemarker dont depend on log4j.
I tried removing log4j from the pom.xml and got this tree now:


[INFO] ------------------------------------------------------------------------
[INFO] Building Camel :: Freemarker 2.9-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ camel-freemarker ---
[INFO] org.apache.camel:camel-freemarker:bundle:2.9-SNAPSHOT
[INFO] +- org.apache.camel:camel-core:jar:2.9-SNAPSHOT:compile
[INFO] |  \- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] +- org.freemarker:freemarker:jar:2.3.18:compile
[INFO] +- org.apache.camel:camel-test:jar:2.9-SNAPSHOT:test
[INFO] |  \- org.apache.camel:camel-spring:jar:2.9-SNAPSHOT:test
[INFO] |     +- org.springframework:spring-context:jar:3.0.5.RELEASE:test
[INFO] |     |  +- org.springframework:spring-beans:jar:3.0.5.RELEASE:test
[INFO] |     |  +- org.springframework:spring-core:jar:3.0.5.RELEASE:test
[INFO] |     |  |  \- commons-logging:commons-logging:jar:1.1.1:test
[INFO] |     |  +- org.springframework:spring-expression:jar:3.0.5.RELEASE:test
[INFO] |     |  \- org.springframework:spring-asm:jar:3.0.5.RELEASE:test
[INFO] |     +- org.springframework:spring-aop:jar:3.0.5.RELEASE:test
[INFO] |     |  \- aopalliance:aopalliance:jar:1.0:test
[INFO] |     \- org.springframework:spring-tx:jar:3.0.5.RELEASE:test
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.1:test
[INFO] |  \- log4j:log4j:jar:1.2.16:test
[INFO] \- junit:junit:jar:4.8.1:test
[INFO] ------------------------------------------------------------------------




> 2- remove of all those DIRECT log4j dependencies of the scope test by all
> camel's poms. Please note that this's NOT critical for the camel users, and
> is just relevant while running camel's own test cases. Nevertheless it's not
> nice.
>

Yeah that may be nicer. JIRA and patch is welcome.



> Regards, Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4695940.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel-freemarker

Posted by bvahdat <ba...@swissonline.ch>.
Claus,

>>>Well frankly it is the other way around. End users should be able to
specify exactly which log4j version they want to use.

If camel users (2.8.0) instrucht camel to use log4j through slf4j by
declaring a DIRECT dependency to the slf4j-log4j12, then indeed they will
get stucked to log4j 1.2.16. See the example here for a version conflict of
log4j caused through slf4j 
http://camel.465427.n5.nabble.com/file/n4695940/foo.zip foo.zip  and do a 

mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:tree -Dverbose=true

And in maven's output see the line 

(log4j:log4j:jar:1.2.16:compile - omitted for conflict with 1.1.3)

And we all know that at RUNTIME the application's routing logic will most
probably crash with a "NoSuchMethodError" if camel calls a slf4j's
LOGGER.xyz() method which gets delegated to log4j logging API. However the
method signature slf4j Logger calls on log4j API was not available at the
time by log4j API version 1.1.3. On the other hand this was the version the
developer decided to use! Well in an OSGi environment things would seem
different, but that's not our concern by this discussion.

@Christian I've never used freemarker but they seem to use a Ant+Ivy build
and not maven, see https://github.com/freemarker/freemarker. At least their
maven pom claims to have no dependencies! see
http://repo1.maven.org/maven2/org/freemarker/freemarker/2.3.18/freemarker-2.3.18.pom

I'll wait to see what Claus thinks before opening a JIRA-ticket. There are
two fixes I can see
1- remove the compile-scope dependency to log4j by camel-freemarker, see
https://svn.apache.org/repos/asf/camel/trunk/components/camel-freemarker/pom.xml
2- remove of all those DIRECT log4j dependencies of the scope test by all
camel's poms. Please note that this's NOT critical for the camel users, and
is just relevant while running camel's own test cases. Nevertheless it's not
nice.

Regards, Babak 

--
View this message in context: http://camel.465427.n5.nabble.com/Camel-freemarker-tp4693216p4695940.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-freemarker

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Aug 13, 2011 at 12:18 AM, Christian Müller
<ch...@gmail.com> wrote:
> Hello Babak!
>
> I think you are right. If we define the test dependency "slf4j-log4j12", we
> do not have to declare the dependency to "log4j" (because it's a transitive
> dependency from "slf4j-log4j12"). Could you please open a JIRA for it? Do
> you consider to provide a patch for it?
>

Well frankly it is the other way around. End users should be able to
specify exactly which log4j version they want to use.
As well as they may run in a server which comes pre installed with
log4j in the boot classpath.

slf4j should *not* dictate which log4j version you should use.

However as we just use it for testing, then we can take a short cut
and possible remove the log4j in the pom.xml file. But for the
examples we should not, as it can help show best practice to end
users, that they can setup log4j dependency and control which version
they want to use.


> For camel-freemarker, do you know whether Freemarker use log4j as default
> logging engine so that we have to set this dependency explicitly? If not, I
> think we should change this as well.
>
> Best,
> Christian
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel-freemarker

Posted by Christian Müller <ch...@gmail.com>.
Hello Babak!

I think you are right. If we define the test dependency "slf4j-log4j12", we
do not have to declare the dependency to "log4j" (because it's a transitive
dependency from "slf4j-log4j12"). Could you please open a JIRA for it? Do
you consider to provide a patch for it?

For camel-freemarker, do you know whether Freemarker use log4j as default
logging engine so that we have to set this dependency explicitly? If not, I
think we should change this as well.

Best,
Christian