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 < christopher.l.shan...@gmail.com> 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 <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/ > > > > > > > > >
