Изменение статического поля с помощью отражения внутри уха

Question

Один EAR содержит 2 WAR (WAR1, WAR2). Оба этих WARS имеют JAR-файл зависимостей (JAR1).

JAR1 имеет класс (CLASS1) и является статическим полем private String STATIC1 = "DEFAULT_VAL";, которое работает для WAR2, но не для WAR1. Поэтому я добавил сервис в WAR1 для его изменения:

@Service
public class ModService {
    @PostConstruct
    public void modMyVal() {
        Field declaredField = CLASS1.class.getDeclaredField("STATIC1");
        declaredField.setAccessible(true);
        declaredField.set(this, "NEW_VAL_FOR_WAR1");
    }
}

К моему удивлению, в WAR2 все работает нормально. Я ожидал, что у WAR2 будет NEW_VAL_FOR_WAR1. Оба WAR загружаются в одно и то же ухо, jvm, сервер - они оба зависят от одного и того же jar. Как это статическое поле не изменилось для WAR2?

Несколько других указателей:

• Jar1 предоставляется третьей стороной, поэтому не контролируйте источник.
• Jar1 находится внутри WAR1 / WEB-INF / lib & WAR2 / WEB-INF / lib
• Сервер подключен к сети.
• Я счастлив, что это сработало :). Но любопытно, как это работает внутри, и что спасает мой день.

Answer 1

Tomcat использует разные WebAppClassLoader для загрузки другого контекста веб-приложения. Другими словами, классы из WAR1 отличаются от классов из WAR2, хотя они имеют одинаковый пакет и имя класса.

То есть CLASS1.class в WAR1 отличается от CLASS1.class в WAR2. Конечно, поле установки в WAR1.CLASS1 не повлияет на WAR2.CLASS1.

Answer 2

Обе WAR имеют свой собственный загрузчик классов. Загрузка класса из JAR один раз для каждой WAR дает вам 2 экземпляра Class, поэтому ваши WAR могут видеть «свою версию» переменных-членов вместо общего состояния, как вы ожидали.

Вы также можете себе представить, какие ошибки вы могли бы вызывать с помощью такого рода хакерских атак, поэтому я бы избегал создавать из этого привычку.