Спасибо за замечание! Обновили статью, добавили описание методов контроллера, цепочку вызова и команду по запуску сервисов через javaagent. Надеемся, это поможет вам и другим читателям)
Мы в выводах написали как раз, что после инцидента ввели мораторий на релизы в пятницу и предпраздничные дни. Но у клиента есть сезонность в бизнесе, поэтому ему было важно опубликовать обновления именно в новый год.
Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами ? Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! ? К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.
Добрый день! Спасибо за уточнение. Действительно, на момент написания статьи в 2020 году версия 2.0 была только анонсирована. Поэтому мы упоминаем о скором добавлении параллельного запуска, но не учитываем его при сравнительном анализе с другими фреймворками.
Спасибо! Чтобы обмениваться, multithreading и асихнронка уже используют общую память. Для обмена между процессами можно использовать очереди (Queue) или каналы данных (pipe).
Решить проблему с Deadlock могут помочь 2 правила:
Так как Deadlock — это взаимная блокировка, т.е. захват в прямом и обратном направлении в разных потоках, отсюда вытекает правило. Если в процессах нужно захватывать Lock, то делаем это всегда в одном порядке (направлении).
И второе правило — освобождаем блокировки в обратном порядке их захвата, подобно стеку. Первым захватили — последним отпустили.
По мнению автора: Заниматься поддержкой версий при независимом деплое идеологически неверно. Должна быть обратная совместимость, раз мы пошли этой дорогой. И это не то же самое, что проверка типа. Версия может поменяться, но типы остаться прежними. Как разработчикам AppShell узнать сигнатуры методов, чтоб локально все компилилось, если объединяемся в рантайме? Только чтение документации к МФ-ам, а тут могут быть и человеческие ошибки. Допустим мы компилим под флаг strictNullChecks, передаем null в метод, который оказывается не умеет работать с null. Без тайпингов компиляция не отловит ошибки. Поэтому и предложен "замороченный" вариант с одновременной сборкой МФ-а и сборкой тайпингов под пакет
В рантайме мы можем типизировать с помощью утиной типизации. Не очень удобно, громоздко, для декларативного подхода нужно json валидаторы писать или использовать либы. Но по сути все кастомные тайп гарды так и работают. Опять же ошибки всплывут в рантайме, просто мы сможем их качественней обработать
Можно попробовать составить d.ts файлы на основе сборки МФ-ов. Файлы эти нпм пакетами доставлять в основное приложение. Именно этот вариант вы и описали, как я понял. Но тогда надо будет при каждом деплое МФ-а пересобрать основное приложение с учетом потенциально изменившихся типов. При этом версии этих пакетов надо менять, ведь они зафиксированы в package-lock. Апать пакет и комить новый резолв зависимостей через ci, чтоб разработчики могли потом подтянуть изменения и узнать, что да как там в новой версии. Способ компромиссный, но по-своему хлопотный
Автоматизированный подход может помочь взять лучшее от этих двух подходов: простоту типизации и независимость команд, но надо учесть массу нюансов.
Разберем npm пакеты. В package.json можно указать диапазон версий, что даст возможность апать пакет и триггерить сборку главного приложения. Но в package-lock.json зафиксирована конкретная версия пакета, которая работала на момент ручной интеграции или обновления пакета разработчиком. Опасно удалять этот файл и ставить зависимости заново, так как могут быть зарезолвлены иные версии сторонних зависимостей. Можно точечно обновить пакет и сделать комит через CI, чтобы разработчики могли отребейзиться и увидеть изменения в зависимостях, но в этом случае большая ответственность возлагается на DevOPS-инженеров.
С сабмодулями Git проще, поэтому это решение выглядит рабочим. Можно сделать git submodule foreach "git checkout master", а затем дергать сборку, но здесь может быть появиться блок со стороны разработки. Не всем нравится разработка через сабмодули, так как она приводит к сильной связности кода и проект ощущается монолитом. Когда проект достаточно большой, то хочется большей изоляции фич друг от друга.
Спасибо за замечание! Обновили статью, добавили описание методов контроллера, цепочку вызова и команду по запуску сервисов через javaagent. Надеемся, это поможет вам и другим читателям)
С проблемой нехватки слотов у архитекторов/senior мы тоже сталкивались. Но процедура проходит по новым процессам железно, не отменяем.
А замечание про выкатку на ограниченную аудиторию дельное. Спасибо!)
Мы в выводах написали как раз, что после инцидента ввели мораторий на релизы в пятницу и предпраздничные дни. Но у клиента есть сезонность в бизнесе, поэтому ему было важно опубликовать обновления именно в новый год.
Спасибо за внимательность! Исправили
Действительно, было такое. Заменили
Спасибо за оценку и дополнение! Добавили его в материал
Спасибо за внимательность! Да, аутентификация. Поправили
Добрый день! Подключить фильтр можно в ConfigureServices следующим образом:
services.AddSwaggerGen(options =>{options.OperationFilter<SourceHeaders>();});Добрый день! Мы добавили в статью новый раздел «Версионность», где рассказали, как настроить Swagger для работы с разными версиями API
Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами ? Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! ?
К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.
Добрый день! Спасибо за уточнение. Действительно, на момент написания статьи в 2020 году версия 2.0 была только анонсирована. Поэтому мы упоминаем о скором добавлении параллельного запуска, но не учитываем его при сравнительном анализе с другими фреймворками.
Параллельный запуск был добавлен после публикации материала в версии 2.0-M4 (2020-11-01). До сих пор это версия 2.3, в документации указана с пометкой WARNING как experimental feature: https://spockframework.org/spock/docs/2.3/release_notes.html#_2_0_m4_2020_11_01
Спасибо!
Чтобы обмениваться, multithreading и асихнронка уже используют общую память.
Для обмена между процессами можно использовать очереди (Queue) или каналы данных (pipe).
Решить проблему с Deadlock могут помочь 2 правила:
Так как Deadlock — это взаимная блокировка, т.е. захват в прямом и обратном направлении в разных потоках, отсюда вытекает правило. Если в процессах нужно захватывать Lock, то делаем это всегда в одном порядке (направлении).
И второе правило — освобождаем блокировки в обратном порядке их захвата, подобно стеку. Первым захватили — последним отпустили.
По мнению автора:
Заниматься поддержкой версий при независимом деплое идеологически неверно. Должна быть обратная совместимость, раз мы пошли этой дорогой. И это не то же самое, что проверка типа. Версия может поменяться, но типы остаться прежними. Как разработчикам AppShell узнать сигнатуры методов, чтоб локально все компилилось, если объединяемся в рантайме? Только чтение документации к МФ-ам, а тут могут быть и человеческие ошибки. Допустим мы компилим под флаг strictNullChecks, передаем null в метод, который оказывается не умеет работать с null. Без тайпингов компиляция не отловит ошибки. Поэтому и предложен "замороченный" вариант с одновременной сборкой МФ-а и сборкой тайпингов под пакет
Уточните, что имелось в виду:
В рантайме мы можем типизировать с помощью утиной типизации. Не очень удобно, громоздко, для декларативного подхода нужно json валидаторы писать или использовать либы. Но по сути все кастомные тайп гарды так и работают. Опять же ошибки всплывут в рантайме, просто мы сможем их качественней обработать
Можно попробовать составить d.ts файлы на основе сборки МФ-ов. Файлы эти нпм пакетами доставлять в основное приложение. Именно этот вариант вы и описали, как я понял. Но тогда надо будет при каждом деплое МФ-а пересобрать основное приложение с учетом потенциально изменившихся типов. При этом версии этих пакетов надо менять, ведь они зафиксированы в package-lock. Апать пакет и комить новый резолв зависимостей через ci, чтоб разработчики могли потом подтянуть изменения и узнать, что да как там в новой версии. Способ компромиссный, но по-своему хлопотный
Автоматизированный подход может помочь взять лучшее от этих двух подходов: простоту типизации и независимость команд, но надо учесть массу нюансов.
Разберем npm пакеты. В package.json можно указать диапазон версий, что даст возможность апать пакет и триггерить сборку главного приложения. Но в package-lock.json зафиксирована конкретная версия пакета, которая работала на момент ручной интеграции или обновления пакета разработчиком. Опасно удалять этот файл и ставить зависимости заново, так как могут быть зарезолвлены иные версии сторонних зависимостей. Можно точечно обновить пакет и сделать комит через CI, чтобы разработчики могли отребейзиться и увидеть изменения в зависимостях, но в этом случае большая ответственность возлагается на DevOPS-инженеров.
С сабмодулями Git проще, поэтому это решение выглядит рабочим. Можно сделать git submodule foreach "git checkout master", а затем дергать сборку, но здесь может быть появиться блок со стороны разработки. Не всем нравится разработка через сабмодули, так как она приводит к сильной связности кода и проект ощущается монолитом. Когда проект достаточно большой, то хочется большей изоляции фич друг от друга.
Спасибо за подробные дополнения!