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 <paul.n.g...@gmail.com> 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 <tabish...@gmail.com> 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/ > > > > >
