activemq-all jar tight coupling with log4j

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

activemq-all jar tight coupling with log4j

atirumala
In a particular application, logback is being used for the application logging. When the application added dependency on  activemq-all 5.13.1 jar in order to access ActiveMQ, it appears that activemq-all has dependendency on log4j which seem to conflicting the whole logging and made it cumbersome. why is activemq-all tightly dependent on log4j?
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

tabish121@gmail.com
On 03/29/2016 12:30 PM, stak wrote:

> In a particular application, logback is being used for the application
> logging. When the application added dependency on  activemq-all 5.13.1 jar
> in order to access ActiveMQ, it appears that activemq-all has dependendency
> on log4j which seem to conflicting the whole logging and made it cumbersome.
> why is activemq-all tightly dependent on log4j?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
The all jar is a quick way to start messing around with a broker and
client etc but once you reach the point that you seem to have you should
start pulling in the specific dependencies you need like
activemq-broker, activemq-kahadb-store and whatnot.  Odds our you don't
need every single broker feature and custom tailoring will allow you to
use the things you need and leave the rest out.

--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

atirumala
So are you saying that activemq-all.jar is not a production grade jar to be used as a client jar when they want to connect to an external activemq as a client?.  Is the purpose of that jar really only for a quick unit test of sorts?
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

christopher.l.shannon
If you just need to connect as a JMS client, you just need the
activemq-client jar and its transitive dependencies.  If you are using
something like maven then you can add that jar to your pom file and then
exclude dependencies you don't want (in this case log4j).

On Tue, Mar 29, 2016 at 2:43 PM, stak <[hidden email]> wrote:

> So are you saying that activemq-all.jar is not a production grade jar to be
> used as a client jar when they want to connect to an external activemq as a
> client?.  Is the purpose of that jar really only for a quick unit test of
> sorts?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

tabish121@gmail.com
In reply to this post by atirumala
On 03/29/2016 02:43 PM, stak wrote:

> So are you saying that activemq-all.jar is not a production grade jar to be
> used as a client jar when they want to connect to an external activemq as a
> client?.  Is the purpose of that jar really only for a quick unit test of
> sorts?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
There are plenty of folks that use it in production.  The all jar
contains not only client code but broker code, message store code and
much more, hence the 'all' moniker, which is very much overkill if you
are using it just for client purposes.  You need to choose the best tool
for the job and the all jar is not always it.

--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

paulgale
Per the online documentation, using activemq-all is a legitimate way to
connect to a broker. For those that were happily using it up until now,
whether others consider it 'overkill' or not, they are now screwed by this
change. Regardless, stating that one can 'fine tune' dependencies by
switching away from activemq-all is a poor justification for including a
concrete dependency on log4j (or anything else one fancies) within
activemq-all. Doing so prevents those users from using a logging framework
of their choice.

Why not just remove the log4j dependency from activemq-all and keep the
entire codebase logging agnostic, hence the purpose of slf4j? Why is a
dependency on log4j needed outside of a testing context?

Thanks,
Paul

On Tue, Mar 29, 2016 at 3:28 PM, Timothy Bish <[hidden email]> wrote:

> On 03/29/2016 02:43 PM, stak wrote:
>
>> So are you saying that activemq-all.jar is not a production grade jar to
>> be
>> used as a client jar when they want to connect to an external activemq as
>> a
>> client?.  Is the purpose of that jar really only for a quick unit test of
>> sorts?
>>
>>
>>
>> --
>> View this message in context:
>> http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>> There are plenty of folks that use it in production.  The all jar
> contains not only client code but broker code, message store code and much
> more, hence the 'all' moniker, which is very much overkill if you are using
> it just for client purposes.  You need to choose the best tool for the job
> and the all jar is not always it.
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

christopher.l.shannon
Nothing has been changed so I don't know what you are referring to. That
log4j dependency has been included in that jar for a while, since
AMQ-3715.  The main point of that jar file is it is an easy way to spin up
a broker for testing and it is supposed to contain concrete dependencies of
things so that it runs out of the box using a single jar file.

Yes it is a legitimate way to connect to the broker but it doesn't mean
it's the best way.  You are certainly welcome to use activemq-all however
you want but if you do you will get the default dependencies of everything
needed to run including the default versions of spring, camel, log4j, etc
that are included.  Since it is an uber jar nothing can be customized and
that is the idea.  I don't see any reason to change this as people have
been expecting this behavior for  the past 4 years.

In my opinion nothing needs to be done here because there is already a
solution.  You can use individual jars, such as activemq-client, and with
transitive dependencies you can customize what you want in the classpath
very easily if you don't like it.  For example,  activemq-client jar
doesn't have a dependency on log4j (I just double checked) and only slf4j
so you are free to easily plug in whatever implementation of logging you
feel like.



On Tue, Mar 29, 2016 at 3:51 PM, Paul Gale <[hidden email]> wrote:

> Per the online documentation, using activemq-all is a legitimate way to
> connect to a broker. For those that were happily using it up until now,
> whether others consider it 'overkill' or not, they are now screwed by this
> change. Regardless, stating that one can 'fine tune' dependencies by
> switching away from activemq-all is a poor justification for including a
> concrete dependency on log4j (or anything else one fancies) within
> activemq-all. Doing so prevents those users from using a logging framework
> of their choice.
>
> Why not just remove the log4j dependency from activemq-all and keep the
> entire codebase logging agnostic, hence the purpose of slf4j? Why is a
> dependency on log4j needed outside of a testing context?
>
> Thanks,
> Paul
>
> On Tue, Mar 29, 2016 at 3:28 PM, Timothy Bish <[hidden email]> wrote:
>
> > On 03/29/2016 02:43 PM, stak wrote:
> >
> >> So are you saying that activemq-all.jar is not a production grade jar to
> >> be
> >> used as a client jar when they want to connect to an external activemq
> as
> >> a
> >> client?.  Is the purpose of that jar really only for a quick unit test
> of
> >> sorts?
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >>
> >> There are plenty of folks that use it in production.  The all jar
> > contains not only client code but broker code, message store code and
> much
> > more, hence the 'all' moniker, which is very much overkill if you are
> using
> > it just for client purposes.  You need to choose the best tool for the
> job
> > and the all jar is not always it.
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

paulgale
The file log4j.properties in activemq-all was added on 2/12/15 (not sure
what release of ActiveMQ that correlates to). That's the kicker. When we
upgraded recently from 5.11.1 to 5.13.1 is when the problem became
apparent. You can see why. It's a non-trivial exercise to coordinate
multiple teams to switch their client-side jar to be something different.
The schedules of those teams are out of our hands. If it was trivial this
would be moot. Activemq-all was an uber jar at 5.11.1 and this was not an
issue. I didn't think that requesting a log4j.properties file be removed
would such a big ask in order to indulge the wider user community, compared
to the narrower needs of the testing community.  Given the great pain
that's caused by making such a switch the consequences of this change could
have been better publicized with the appropriate warning in the release
notes stating THIS WILL BREAK YOU IN PROD - similar to how the recent
security serialization bug was handled. You guys request feedback - we
provided it. Ignore at will.


On Tue, Mar 29, 2016 at 4:31 PM, Christopher Shannon <
[hidden email]> wrote:

> Nothing has been changed so I don't know what you are referring to. That
> log4j dependency has been included in that jar for a while, since
> AMQ-3715.  The main point of that jar file is it is an easy way to spin up
> a broker for testing and it is supposed to contain concrete dependencies of
> things so that it runs out of the box using a single jar file.
>
> Yes it is a legitimate way to connect to the broker but it doesn't mean
> it's the best way.  You are certainly welcome to use activemq-all however
> you want but if you do you will get the default dependencies of everything
> needed to run including the default versions of spring, camel, log4j, etc
> that are included.  Since it is an uber jar nothing can be customized and
> that is the idea.  I don't see any reason to change this as people have
> been expecting this behavior for  the past 4 years.
>
> In my opinion nothing needs to be done here because there is already a
> solution.  You can use individual jars, such as activemq-client, and with
> transitive dependencies you can customize what you want in the classpath
> very easily if you don't like it.  For example,  activemq-client jar
> doesn't have a dependency on log4j (I just double checked) and only slf4j
> so you are free to easily plug in whatever implementation of logging you
> feel like.
>
>
>
> On Tue, Mar 29, 2016 at 3:51 PM, Paul Gale <[hidden email]> wrote:
>
> > Per the online documentation, using activemq-all is a legitimate way to
> > connect to a broker. For those that were happily using it up until now,
> > whether others consider it 'overkill' or not, they are now screwed by
> this
> > change. Regardless, stating that one can 'fine tune' dependencies by
> > switching away from activemq-all is a poor justification for including a
> > concrete dependency on log4j (or anything else one fancies) within
> > activemq-all. Doing so prevents those users from using a logging
> framework
> > of their choice.
> >
> > Why not just remove the log4j dependency from activemq-all and keep the
> > entire codebase logging agnostic, hence the purpose of slf4j? Why is a
> > dependency on log4j needed outside of a testing context?
> >
> > Thanks,
> > Paul
> >
> > On Tue, Mar 29, 2016 at 3:28 PM, Timothy Bish <[hidden email]>
> wrote:
> >
> > > On 03/29/2016 02:43 PM, stak wrote:
> > >
> > >> So are you saying that activemq-all.jar is not a production grade jar
> to
> > >> be
> > >> used as a client jar when they want to connect to an external activemq
> > as
> > >> a
> > >> client?.  Is the purpose of that jar really only for a quick unit test
> > of
> > >> sorts?
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
> > >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >>
> > >> There are plenty of folks that use it in production.  The all jar
> > > contains not only client code but broker code, message store code and
> > much
> > > more, hence the 'all' moniker, which is very much overkill if you are
> > using
> > > it just for client purposes.  You need to choose the best tool for the
> > job
> > > and the all jar is not always it.
> > >
> > >
> > > --
> > > Tim Bish
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: activemq-all jar tight coupling with log4j

christopher.l.shannon
I didn't realize that config was added recently (looks like 5.12.0).  It
also looks like the dependency jcl-over-slf4j was added as part of that
commit as well so not sure if that is also causing you problems.

I'm not entirely sure why it was just added (probably just to make it easy
to provide for a default logging configuration) but I can ping Dejan, who
made the change, and ask if it could be provided separately if that is the
only thing causing your issue and since it was a recent change in behavior.

Either way, I would still recommend not relying on that jar in the future
so that you have more control over your dependencies.  The documentation
should be updated to make it more obvious the limitations of the
activemq-all jar.  It's mentioned in some places but it isn't as clear as
it could be so I can work on updating that.

On Tue, Mar 29, 2016 at 8:19 PM, Paul Gale <[hidden email]> wrote:

> The file log4j.properties in activemq-all was added on 2/12/15 (not sure
> what release of ActiveMQ that correlates to). That's the kicker. When we
> upgraded recently from 5.11.1 to 5.13.1 is when the problem became
> apparent. You can see why. It's a non-trivial exercise to coordinate
> multiple teams to switch their client-side jar to be something different.
> The schedules of those teams are out of our hands. If it was trivial this
> would be moot. Activemq-all was an uber jar at 5.11.1 and this was not an
> issue. I didn't think that requesting a log4j.properties file be removed
> would such a big ask in order to indulge the wider user community, compared
> to the narrower needs of the testing community.  Given the great pain
> that's caused by making such a switch the consequences of this change could
> have been better publicized with the appropriate warning in the release
> notes stating THIS WILL BREAK YOU IN PROD - similar to how the recent
> security serialization bug was handled. You guys request feedback - we
> provided it. Ignore at will.
>
>
> On Tue, Mar 29, 2016 at 4:31 PM, Christopher Shannon <
> [hidden email]> wrote:
>
> > Nothing has been changed so I don't know what you are referring to. That
> > log4j dependency has been included in that jar for a while, since
> > AMQ-3715.  The main point of that jar file is it is an easy way to spin
> up
> > a broker for testing and it is supposed to contain concrete dependencies
> of
> > things so that it runs out of the box using a single jar file.
> >
> > Yes it is a legitimate way to connect to the broker but it doesn't mean
> > it's the best way.  You are certainly welcome to use activemq-all however
> > you want but if you do you will get the default dependencies of
> everything
> > needed to run including the default versions of spring, camel, log4j, etc
> > that are included.  Since it is an uber jar nothing can be customized and
> > that is the idea.  I don't see any reason to change this as people have
> > been expecting this behavior for  the past 4 years.
> >
> > In my opinion nothing needs to be done here because there is already a
> > solution.  You can use individual jars, such as activemq-client, and with
> > transitive dependencies you can customize what you want in the classpath
> > very easily if you don't like it.  For example,  activemq-client jar
> > doesn't have a dependency on log4j (I just double checked) and only slf4j
> > so you are free to easily plug in whatever implementation of logging you
> > feel like.
> >
> >
> >
> > On Tue, Mar 29, 2016 at 3:51 PM, Paul Gale <[hidden email]>
> wrote:
> >
> > > Per the online documentation, using activemq-all is a legitimate way to
> > > connect to a broker. For those that were happily using it up until now,
> > > whether others consider it 'overkill' or not, they are now screwed by
> > this
> > > change. Regardless, stating that one can 'fine tune' dependencies by
> > > switching away from activemq-all is a poor justification for including
> a
> > > concrete dependency on log4j (or anything else one fancies) within
> > > activemq-all. Doing so prevents those users from using a logging
> > framework
> > > of their choice.
> > >
> > > Why not just remove the log4j dependency from activemq-all and keep the
> > > entire codebase logging agnostic, hence the purpose of slf4j? Why is a
> > > dependency on log4j needed outside of a testing context?
> > >
> > > Thanks,
> > > Paul
> > >
> > > On Tue, Mar 29, 2016 at 3:28 PM, Timothy Bish <[hidden email]>
> > wrote:
> > >
> > > > On 03/29/2016 02:43 PM, stak wrote:
> > > >
> > > >> So are you saying that activemq-all.jar is not a production grade
> jar
> > to
> > > >> be
> > > >> used as a client jar when they want to connect to an external
> activemq
> > > as
> > > >> a
> > > >> client?.  Is the purpose of that jar really only for a quick unit
> test
> > > of
> > > >> sorts?
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> >
> http://activemq.2283324.n4.nabble.com/activemq-all-jar-tight-coupling-with-log4j-tp4710022p4710030.html
> > > >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > > >>
> > > >> There are plenty of folks that use it in production.  The all jar
> > > > contains not only client code but broker code, message store code and
> > > much
> > > > more, hence the 'all' moniker, which is very much overkill if you are
> > > using
> > > > it just for client purposes.  You need to choose the best tool for
> the
> > > job
> > > > and the all jar is not always it.
> > > >
> > > >
> > > > --
> > > > Tim Bish
> > > > twitter: @tabish121
> > > > blog: http://timbish.blogspot.com/
> > > >
> > > >
> > >
> >
>