После добавления Actuator к проекту, Spring Boot опубликует список доступных бинов
Ну, на самом деле публиковать бины в JMX можно было давно, еще до появления Boot. И достаточно легко. И потом какая-нибудь консоль типа hawtio позволяет их удобно смотреть и рулить ими.
Ну т.е. опять же, в этом и в метриках нет никакой магии — это просто сконфигурированные неким стандартным образом и доступные отдельно вещи (типа metrics.dropwizard.io).
Да мне наплевать, сколько стартует ваше приложение. Я вам вообще не про это — а про то, что файлы проперти это внешний источник данных по отношению к коду. И доверять ему без проверок нельзя. Если у вас приложение падает из-за отсутствия чего-то в файле — это исключительно ваши проблемы. А если у вас претензии к времени старта — так формулируйте их именно так, о чем я вам сразу и написал.
И да, у меня две минуты стартует приложение, в котором порядка 100 спринговых контекстов. Так что проблемы медленного старта тоже как правило не от спринга, а из головы. И решать их надо головой — путем профилирования, выяснения, что именно тормозит, и потом оптимизации, а не путем пустой ругани на фреймворк.
а тут пропертю забыли подсунуть в файл. Вот это удовольствие автор и имел в виду, когда говорил, что в Spring нет compile time safety.
Ну да, ну да. Пропертю в файл забыли — а виноват спринг? Если вы позволяете кому-то настраивать приложение, изменяя что-то в файле (который очевидно не компилируется), то что вы от фреймворка хотите? Да, этот кто-то может ввести строку вместо числа. И что?
Сорри, может вы не то имели в виду — но именно так оно почему-то и выглядит. Нет compile time safety во многих случаях — когда у вас в проекте база, она вам этого не гарантирует, когда у вас вообще любые внешние данные. И никто кроме вас этого гарантировать не может.
например тот же Servlet уже содержит простые средства security.
Вам про OAuth, а вы про сервлеты. Покажете, в каком месте у сервлетов OAuth? :)
Ну и самое главное, что почему-то всегда ускользает в подобных дискуссиях — если автор/комментатор способен реализовать то что есть в спринге самостоятельно, то он достаточно квалифицирован, потому что код спринга достаточно высокого качества. Большинство джунов не в состоянии не только написать такой, но и понять зачастую. Поэтому посты типа "я ненавижу..." следует читать с солидной долей скепсиса. Ну ненавидит, и что? В нашем случае все может быть сильно иначе.
Тут дело такое — с самого начала в J2EE предполагалось, что компоненты может настраивать как программист, так и деплоер. И эта роль была предусмотрена, вместе с сервер-специфичными xml дескрипторами для него.
Я не стану утверждать однозначно, но вполне могу себе представить ситуацию, когда деплоеру нужно сконфигурировать только маппинг. Ну т.е. суть в том, что в других сценариях, про которые мы часто не думаем, может быть удобнее и так и эдак.
Никогда не понимал, в чем эта жуть. Многословно (иногда) — ну может быть. Не так гибко, как конфигурирование в java — очевидно тоже да, код более гибок, чем статический xml.
Маппинг — это отображение url на сервлет. Вот этот сервлет обрабатывает вот такие url. И еще вот такие (потенциально — несколько).
Сервлет — это на минутку, сам сервлет. У него есть параметры (настройки). Любые.
Отношение между маппингом и сервлетом — M:1. Я готов согласиться, что это сделано не идеально удобно (я бы наверное сделал маппинг дочерним элементом для сервлета), но что это непонятно — хм. Это может быть непонятно если человек почему-то новичок в веб технологиях вообще. Или если доки совсем не читать.
Я вам ровно про такой случай и рассказываю. Вы можете не писать на груви (подставьте сюда что угодно другое, кстати, jython, кложа и т.п. вполне для такого же сценария годятся) основную часть приложения — вы просто заменяете баш на один из скриптовых jvm языков. И это получается очень удобно. У меня был случай, когда примерно 1000 строк шелла были переписаны на груви, сократившись при этом раза в три.
Из своего опыта — внутри кода на groovy можно спокойно написать обработчик — потому что это текст. И он будет запускаться ровно как питон или баш. Для именно консольных утилит — это самое то.
#!/какой-то путь/.../groovy — я вот про это, если что
Все остальные продукты как правило все-таки требуют несколько больше настроек, или работают скорее в режиме сервиса, т.е. требуют опять же настройки, чтобы запускаться/останавливаться при перезагрузке ОС в том числе.
Аналогичный вопрос — а зачем? Ну вот зачем нужен dropship, я допустим понимаю. А такой подход — как-то сомнительно. Чего вы хотели добиться по сравнению скажем с произвольно взятым wrapper-ом?
Мы прекрасно получаем уже много лет котировки через QUIK. С Московской биржи. В полностью автоматическом режиме. Наверное, десятки тысяч инструментов примерно, порядка миллионов котировок в день (я точно не мерял).
QUIK не для этого? Ну да, ну да. Расскажите это человеку, чья работа много лет состояла в том, чтобы обеспечивать трейдеров маркет данными.
А что собственно за проблема? Те, кому на самом деле нужно торговать на бирже, так или иначе подключены к ней с целью заводить сделки. Частью большинства торговых терминалов является сервис, о котором вы спрашиваете. С API и всеми делами. Ну т.е. например, QUIK (quik), от той же компании ФИНАМ, чтоб далеко не ходить.
Всех бирж РФ? Ну это вряд ли. Насколько я знаю, единого API не существует в природе. Лучшее на что можно рассчитывать — что данные от всех бирж будут приходить в одном формате, типа FIX/FixML.
А то что тут описано, это какой-то самописный велосипед, непонятно для чего нужный.
Брать котировки со страницы ФИНАМ? Хм. Даже для инструментов, которые там есть, вам никто ничего не гарантирует, потому что вы — не пользователь, а просто никто. Ни по качеству данных, ни по своевременности их предоставления нет никаких гарантий ровным счетом. Даже более того — если не регистрироваться, то вы будете видеть котировки с задержкой 15 минут.
Это во-первых. Во-вторых, там четко написано, что источник данных — например московская биржа (*** Данные предоставлены ПАО Московская Биржа. Перераспространение информации только с разрешения Московской Биржи). Т.е., мы еще и лицензию потенциально нарушаем, а?
И не проще в таком случае с сайта биржи и брать информацию, благо она там есть?
В общем, тут описан подход, который ничуть не менее странный, чем принятие решений на основе «интуиции».
>единая точка входа, он же API Gateway
>поиск сервисов, он же Service Discovery
>одна точка конфигурации, он же Config Service
>центральная точка сбора и анализа логов
>мониторинг
И в итоге мы получаем… получаем… ну например полноценную реализацию OSGI. Где микросервисы — вовсе не автономные непонятно какие процессы, а управляемые объекты в управляемой среде, где есть и поиск/дискавери, и сбор/анализ логов, и мониторинг, и конфигурация, и многое другое.
Ну, на самом деле публиковать бины в JMX можно было давно, еще до появления Boot. И достаточно легко. И потом какая-нибудь консоль типа hawtio позволяет их удобно смотреть и рулить ими.
Ну т.е. опять же, в этом и в метриках нет никакой магии — это просто сконфигурированные неким стандартным образом и доступные отдельно вещи (типа metrics.dropwizard.io).
Да мне наплевать, сколько стартует ваше приложение. Я вам вообще не про это — а про то, что файлы проперти это внешний источник данных по отношению к коду. И доверять ему без проверок нельзя. Если у вас приложение падает из-за отсутствия чего-то в файле — это исключительно ваши проблемы. А если у вас претензии к времени старта — так формулируйте их именно так, о чем я вам сразу и написал.
И да, у меня две минуты стартует приложение, в котором порядка 100 спринговых контекстов. Так что проблемы медленного старта тоже как правило не от спринга, а из головы. И решать их надо головой — путем профилирования, выяснения, что именно тормозит, и потом оптимизации, а не путем пустой ругани на фреймворк.
А спринг тут при чем?
Да хоть через сто лет. Файл это внешние данные. Type safety для них не обеспечивается никогда.
Если у вас от содержимого файла с внешними данными зависит, упадет ли приложение — это точно не проблема фреймворка. Никакого.
Ну да, ну да. Пропертю в файл забыли — а виноват спринг? Если вы позволяете кому-то настраивать приложение, изменяя что-то в файле (который очевидно не компилируется), то что вы от фреймворка хотите? Да, этот кто-то может ввести строку вместо числа. И что?
Сорри, может вы не то имели в виду — но именно так оно почему-то и выглядит. Нет compile time safety во многих случаях — когда у вас в проекте база, она вам этого не гарантирует, когда у вас вообще любые внешние данные. И никто кроме вас этого гарантировать не может.
Хм. Ну вот так-то передергивать не нужно:
Вам про OAuth, а вы про сервлеты. Покажете, в каком месте у сервлетов OAuth? :)
Ну и самое главное, что почему-то всегда ускользает в подобных дискуссиях — если автор/комментатор способен реализовать то что есть в спринге самостоятельно, то он достаточно квалифицирован, потому что код спринга достаточно высокого качества. Большинство джунов не в состоянии не только написать такой, но и понять зачастую. Поэтому посты типа "я ненавижу..." следует читать с солидной долей скепсиса. Ну ненавидит, и что? В нашем случае все может быть сильно иначе.
+1. Спринг на мой взгляд и так не слишком сложен, во всяком случае большая его часть.
Тут дело такое — с самого начала в J2EE предполагалось, что компоненты может настраивать как программист, так и деплоер. И эта роль была предусмотрена, вместе с сервер-специфичными xml дескрипторами для него.
Я не стану утверждать однозначно, но вполне могу себе представить ситуацию, когда деплоеру нужно сконфигурировать только маппинг. Ну т.е. суть в том, что в других сценариях, про которые мы часто не думаем, может быть удобнее и так и эдак.
Никогда не понимал, в чем эта жуть. Многословно (иногда) — ну может быть. Не так гибко, как конфигурирование в java — очевидно тоже да, код более гибок, чем статический xml.
Маппинг — это отображение url на сервлет. Вот этот сервлет обрабатывает вот такие url. И еще вот такие (потенциально — несколько).
Сервлет — это на минутку, сам сервлет. У него есть параметры (настройки). Любые.
Отношение между маппингом и сервлетом — M:1. Я готов согласиться, что это сделано не идеально удобно (я бы наверное сделал маппинг дочерним элементом для сервлета), но что это непонятно — хм. Это может быть непонятно если человек почему-то новичок в веб технологиях вообще. Или если доки совсем не читать.
#!/какой-то путь/.../groovy — я вот про это, если что
Все остальные продукты как правило все-таки требуют несколько больше настроек, или работают скорее в режиме сервиса, т.е. требуют опять же настройки, чтобы запускаться/останавливаться при перезагрузке ОС в том числе.
Мы прекрасно получаем уже много лет котировки через QUIK. С Московской биржи. В полностью автоматическом режиме. Наверное, десятки тысяч инструментов примерно, порядка миллионов котировок в день (я точно не мерял).
QUIK не для этого? Ну да, ну да. Расскажите это человеку, чья работа много лет состояла в том, чтобы обеспечивать трейдеров маркет данными.
Всех бирж РФ? Ну это вряд ли. Насколько я знаю, единого API не существует в природе. Лучшее на что можно рассчитывать — что данные от всех бирж будут приходить в одном формате, типа FIX/FixML.
А то что тут описано, это какой-то самописный велосипед, непонятно для чего нужный.
Брать котировки со страницы ФИНАМ? Хм. Даже для инструментов, которые там есть, вам никто ничего не гарантирует, потому что вы — не пользователь, а просто никто. Ни по качеству данных, ни по своевременности их предоставления нет никаких гарантий ровным счетом. Даже более того — если не регистрироваться, то вы будете видеть котировки с задержкой 15 минут.
Это во-первых. Во-вторых, там четко написано, что источник данных — например московская биржа (*** Данные предоставлены ПАО Московская Биржа. Перераспространение информации только с разрешения Московской Биржи). Т.е., мы еще и лицензию потенциально нарушаем, а?
И не проще в таком случае с сайта биржи и брать информацию, благо она там есть?
В общем, тут описан подход, который ничуть не менее странный, чем принятие решений на основе «интуиции».
У авторов:
>Run programs up to 100x faster than Hadoop MapReduce in memory, or 10x faster on disk.
У вас:
>Hadoop сохраняет данные на жесткий диск на каждом шаге алгоритма MapReduce, а Spark производит все операции в оперативной памяти.
И уверяю вас, это далеко не единственный перл.
>поиск сервисов, он же Service Discovery
>одна точка конфигурации, он же Config Service
>центральная точка сбора и анализа логов
>мониторинг
И в итоге мы получаем… получаем… ну например полноценную реализацию OSGI. Где микросервисы — вовсе не автономные непонятно какие процессы, а управляемые объекты в управляемой среде, где есть и поиск/дискавери, и сбор/анализ логов, и мониторинг, и конфигурация, и многое другое.