I'll raise this subject over in the Log4J community where I am also active. Just note 1.x is EOL and is no longer maintained. Moving to 2.x is a whole redesign and the two are not compatible (neither binary nor configuration wise). 2.x is way better but it's not drop-and-replace. If you have a dependency on Log4J 1.x and cannot move forward for whatever reason, I think the only relief you will have is to patch yourself, a patch from your EE server provider, or ping the Log4J community to do an OOB patch.
Cheers, Paul On Thu, Jul 14, 2016 at 8:10 AM, dalibor topic <dalibor.to...@oracle.com> wrote: > > > On 14.07.2016 14:31, Robert Muir wrote: > >> On Thu, Jul 14, 2016 at 8:22 AM, dalibor topic <dalibor.to...@oracle.com> >> wrote: >> >>> >>> >>> I'd suggest moving on [1] to a maintained version of that dependency, >>> such >>> as 2.6.x currently seems to be. >>> >> >> I'm not complaining about the issue: I'm simply trying to put things >> in perspective, communicate a bit of a reality check as to what is >> going to happen. *tons* of libraries depend on log4j 1.x, it may even >> be more widely used than guava. >> > > It's pretty close, yeah: > > https://mvnrepository.com/artifact/com.google.guava/guava/usages: 7490 > https://mvnrepository.com/artifact/log4j/log4j/usages : 7439 > > The migration to the next version seems to have > > https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages > : 859 > > so it looks like it's getting adopted a little bit faster than log4j 1.x > originally was. > > We try to do the right thing and fix the issues we encounter, when >> testing java 9, and send patches where they should go. >> > > Thank you for doing that hard work! > > But it is hard >> when the software is unmaintained, or stubborn (e.g. >> https://github.com/aws/aws-sdk-java/pull/718) >> > > In general, awareness of the importance of planning to adopt future > revisions of one's dependencies seems to be very low across the open source > development spectrum, with very few exceptions (Linux distro rebuilds with > latest GCC versions, etc.), often leading to ad-hoc decision making in many > projects about such upgrades, which is fueled in turn by the lack of > reliable release or support roadmaps from their open source dependencies. > > With respect to the JDK and the Java community specifically, I think > things have got a bit better then they were a few years ago, thanks to the > work Rory and his collaborators like yourself are doing on raising > awareness of upcoming JDK changes through the Quality Outreach efforts, but > as you say, there is still a long way to go, and we could always use more > collaborators. ;) > > cheers, > dalibor topic > > -- > <http://www.oracle.com> Dalibor Topic | Principal Product Manager > Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 > <tel:+491737185961> > > ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 München > Registergericht: Amtsgericht München, HRA 95603 > > Komplementärin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher > > <http://www.oracle.com/commitment> Oracle is committed to developing > practices and products that help protect the environment >
