kolenchits86: вопрос в том, что Вы хотите в итоге получить. Коллекцию ProjectAttributeCategoryDictionary для Project'а? Если да, то почему бы ее прямо из Project'а не взять?
В чем конкретно сложность-то? Я тут вижу некий класс с полями station и url, а сам JSON - это сериализованная Map>. Сериализовать map'у может и GSON, и Jackson и вообще кто угодно.
akass: про контроль версий не проверял, обычно пользовался внешними инструментами. А использование методов/свойств/прочего вроде как по Shift+F12 находится, не?
Да. Контекст такие вопросы самостоятельно решать не может, т.к., в общем случае, изменений может быть много, они могут быть сложно между собой связаны (скажем, сохраняется целый граф объектов) и т.п. Контекст сам не сможет понять, какие из этих изменений в случае ошибок можно/нужно "выкинуть", а какие - нет.
Не вижу, почему бы благородному дону не использовать общий кеш :) Серьезно, у этих сервисов наверняка будет общая БД; если к ней добавится общий же кеширующий слой (на базе какого-нибудь Redis, например), то я лично в этом ни малейшего криминала не усматриваю.
Eugene: будете смеяться, но даже так делал :) Пока что реализовал желаемое через PropertyEditor'ы (не так удобно, но для сельской местности сойдет). Придется, видимо, плотно раскуривать конфиг по-новой, что-то там явно погнулось.
Таким путем тоже уже ходил. Собственно, когда делал прототип с помощью Spring Boot, так и поступил: просто сделал конвертер компонентом, и все действительно подцепилось. Потом перенес наработку в основной проект - и ничего не работает. Где-то какой-то настройки не хватает, но никак не соображу, где именно.
Скажем так, у меня там соответствие между значениями енума и строковыми константами не такое очевидное; здесь я просто упростил, чтобы не отвлекало. Так что конвертер все-таки нужен.
Hellarazor: что-то я тут элементов .value не вижу. И значений уже три на каждый див, а не одно. Впрочем, неважно, суть-то та же: перебираем span'ы, с помощью text() достаем из них значения, сравниваем, красим при необходимости.