It's not too late for access control

[Paul Benedict]

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.topic at oracle.com>
wrote:

>
>
> On 14.07.2016 14:31, Robert Muir wrote:
>
>> On Thu, Jul 14, 2016 at 8:22 AM, dalibor topic <dalibor.topic at 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
>