сразу представил себе дашборды и тд)

Если человек не осилил структурированные логи, то тут только глаза помогут. В крайнем случае grep

grep вообще сила

)

всем привет, у меня есть класс с кастомной миграцией для liquibase (4.0.0), в котором  я вывожу логи debug и info уровней, Liquibase запускаю через jar. Во время миграций одна третья либа очень сильно срет DEBUG логами, можно ли как-то изменить уровень логов для класса из сторонней либы? —logLevel влияет только на логи самого liquibase. Спасибо.

если spring boot, то там можно по группе резать логи прямо через конфиг приложения(application.yml)

а jar

не увидел сори

там через дополнительный конфиг можно по идее порезать

да, с бутом проблем нет

попробуй java -jar -Dlog4j.configurationFile=.../log4j2.xml(с настроенным логером) liquibase.jar
но не уверен что будет работать

Зависит от либы, которая пишет логи. Если там logback, например, то добавляем logback.xml и пишем туда конфиг. Потом при запуске java -Dlogback.config=<файл>.xml -jar liquibase.jar

спасибо, попробую

/stat@combot

Total messages: 393246

Вопросы по android разработки сюда?

Как вам? Наткнулся на такой кусок кода

boolean isRedeemable = details.getSuccess();

    if (isFalse(isRedeemable))
    {
      // @formatter:off
      isRedeemable = emptyIfNull(details.getErrors()).stream()
          .noneMatch(error -> isFalse(allowedErrors.contains(error)));
      // @formatter:on
    }

    return isRedeemable;

Все что в if разве не легче заменить на

(allowedErrors).containsAll(details.getErrors())

?

Проще, но как можно удержаться, если java 8 со стримами вышла!

совсем недавно вышла...

Всем привет.

Конкарренси — не самая моя сильная сторона, поэтому просьба сильно не кидаться тапками. Я изложу кое какие размышления — поправьте меня пожалуйста, если где ошибся?

Дилемму, с которой я столкнулся, можно описать следующим гистом: https://gist.github.com/skapral/60c041771bf633cbe0befa009be82db1. В реале все вышло несколько сложнее, но гист передает суть.

Есть вычисление B, результат которого зависит от двух A. И B, и А должны быть мемоизированны при первом обращении, и должна быть гарантия что вычисление каждого из doHeavyLifting методов происходит не более одного раза, вне зависимости от того, где и сколько раз их вызвали. При этом клиентская сторона может потенциально вызвать их в рандомном порядке и конкуррентно (сэмулированно в мэйне). Если раннать мэйн из гиста, он будет виснуть с некоторой вероятностью (если B пойдет вычисляться раньше чем обе A, будет дэдлок на ConcurrentHashMapе, даже если тред один).

То что нельзя вкладывать computeIfAbsentы --- я в курсе, вопрос не об этом, в примере вложенные компуты присутствуют только для иллюстрации проблемы. Вопрос в альтернативе.

На данный момент решение видится таким образом: https://gist.github.com/skapral/8545692990383adad26596b2874e6098.

Нет ли каких либо косяков? Можно ли считать memoizedCalculation потокобезопасным? Может можно было решить проще? Я что-то упускаю?