либо корс отключай, либо корректно эти методы вызывай

Как пирог построить я его могу и без синглтонов.

@dmsol итак? Зачем мне трушные синглтоны для луковичной/пирожной архитектуры, или что вы там имели ввиду?

да, нужно его выкидывать

Он юзает спринг!!11 Гоните его, насмехайтесь над ним!!

Давайте без толстоты. По существу дискуссия идёт же.

либо корс отключай, либо корректно эти методы вызывай

что значит корректно?

посты работает, геты работаеют

что значит корректно?

Миша, у тебя есть спринг секьюрити?

что ты имеешь в виду?

Ну тебе нужно масштабировать горизонтально приложение, а там есть стейтфул синглтоны

Ну тебе нужно масштабировать горизонтально приложение, а там есть стейтфул синглтоны

я понял про что ты

вообще-то нет

код писать надо без состояния

Миша, у тебя есть спринг секьюрити?

сам я его не ставил, может где-то в буте зарыт

а если ты его завел - ССЗБ

Давайте без толстоты. По существу дискуссия идёт же.

Смысла в ней нет, все останутся при своем мнении, как и всегда

Ну тебе нужно масштабировать горизонтально приложение, а там есть стейтфул синглтоны

опять непонятно, как стейтфул код связан с наличием или отсутствием в проекте спринга

используй внешние кэши

override fun addCorsMappings(registry: CorsRegistry?) { registry!!.addMapping("/**").allowedOrigins("*") }

Ну тебе нужно масштабировать горизонтально приложение, а там есть стейтфул синглтоны

Можно пользоваться sticky sessions. И масштабироваться вне спринга.

override fun addCorsMappings(registry: CorsRegistry?) { registry!!.addMapping("/**").allowedOrigins("*") }

верный конфиг

не взлетает?

нет

код писать надо без состояния

Так а зачем тебе стейтлесс синглтон тогда?

у тебя Котлин?

угу

это как-то мешает?

Можно пользоваться sticky sessions. И масштабироваться вне спринга.

Или редиску юзануть лучше

это как-то мешает?

иногда неожиданные баги всплывают

В общем вопрос масштабирования - это вопрос сбоку.

верный конфиг

причем на тестовом сервере работает, а на проде - нет

причем на тестовом сервере работает, а на проде - нет

попробуй две звездочки

/**

причем на тестовом сервере работает, а на проде - нет

Вот вам пример проблемы спринг конфигурации.

если дергать этот delete из мобильного приложения, т.е. не посылая хедеры типа Origin, то работает

Весьма типичная проблема.

override fun addCorsMappings(registry: CorsRegistry?) { registry!!.addMapping("/**").allowedOrigins("*") }

allowedOrigins - это и есть cors

Сидишь ковыряешь, а что же там не так. Вроде все по доке сделал.

ща

1 момент

можешь вообще его рубануть нафиг, если не нужен: .cors().disable()

Сидишь ковыряешь, а что же там не так. Вроде все по доке сделал.

Вот-вот.

опять непонятно, как стейтфул код связан с наличием или отсутствием в проекте спринга

Никак. Тут писали о масштабируемости и спринг синглтонах, я поэтому и прицепился

можешь вообще его рубануть нафиг, если не нужен: .cors().disable()

а если нужен?

Никак. Тут писали о масштабируемости и спринг синглтонах, я поэтому и прицепился

масштабируемость в коде

это и плюс и минус одновременно

масштабируемость в коде

Понял

а если нужен?

/**

попробуй так

а если нужен?

тогда правильные ориджины пропиши, и у тебя сервис через балансер наружу торчит?

тогда правильные ориджины пропиши, и у тебя сервис через балансер наружу торчит?

через балансер

X-Origin-From пробрасывается корректный?

или в какие там хедеры это упаковывается (не помню уже)

я сейчас пошел на сервак и локально выполнил запрос, та же херня, лоадбалансер никак не мешает

я сейчас пошел на сервак и локально выполнил запрос, та же херня, лоадбалансер никак не мешает

в http-запросе хедер Host указал?

Кароч, ответа я не получил - резюмирую. DI контейнеры по подходам можно разделить на два типа - либо они инфу о том что нужно инжектить ищут в инжект-оунерах (autowired), либо дают какой то DSL для сборки конфигурации (Spring XML, Spring Java). Третьего не дано - где то эта инфу контейнер должен прочитать: я не видел никаких контейнеров которые не относятся к одной из этих двух категорий. Первый путь все каплит к чертям, второй не имеет никакого смысла, лишний оверхед. Контейнер не нужен для SOLID кода.

в http-запросе хедер Host указал?

указан

/**

это куда писать? registry!!.addMapping("/**").allowedOrigins("*")

это куда писать? registry!!.addMapping("/**").allowedOrigins("*")

убери allowedOrigins

Это гадание на кофейной гуще с конфигом спринга?)

Убери то, попробуй так..

убери allowedOrigins

по идее это никак не поможет: `The special value "*" allows all domains. By default, all origins are allowed`

Вот так и работаем со спрингом.

Вот так и работаем со спрингом.

угу, шаг в сторону и непонятно что делать, у меня с ним проблемы стабильно раз в пару месяцев вылезают

по идее это никак не поможет: `The special value "*" allows all domains. By default, all origins are allowed`

а что !! означают?

указан

Хм, тогда хз, что-то с паттерн-матчингом не то, можно попробовать подебажить и посмотреть, че он пытается сравнить и с каким шаблоном

угу, шаг в сторону и непонятно что делать, у меня с ним проблемы стабильно раз в пару месяцев вылезают

Вот об этом же и речь как раз.

Весь холивар. При этом люди продолжают говорить, что со спрингом все в порядке и даёт он больше, чем отнимает (вот тут довольно спорный момент).

ERROR: S client not available

а что !! означают?

м? что за !! ?

а, котлиновская штука

registry!!

что делает?

говорит компилятору, что там не null

Спринг-секурити какие-то другие люди писали, его апи сильно отличается от остального фреймворка

а что !! означают?

кинуть npe если null

забавно, почему бы просто не писать без nullable (?)

через балансер

А что ж вы там все и не разруливаете? На уровне балансера/внешнего к прикладу сервера? У нас оно так и сделано. К нам приходит только проверенный запрос от внешнего Apache.

вроде все правильно

вопрос, а нет ли других фильтров?

корсовых в проекте?

зацепка - почему только делит не отрабатывает да еще и на проде

ок, что прописать в nginx, чтобы он дропнул лишние хедеры и сам отвечал на OPTIONS запросы?

есть еще пара фильтров, как они могут повлиять?

зацепка - почему только делит не отрабатывает да еще и на проде

Возможно на проде крутятся совсем другие бины) из профиля production)

есть еще пара фильтров, как они могут повлиять?

если там среди них корс фильтр - он перекрывать может

я кода не вижу всего

на стейдже же работает, есть фильтр авторизации

на стэйдже тоже энджинкс?

есть интерсептор, который добавляет метадату запросу

да

allowedHeaders позволяет указать разрешенные хэдеры

Кароч, ответа я не получил - резюмирую. DI контейнеры по подходам можно разделить на два типа - либо они инфу о том что нужно инжектить ищут в инжект-оунерах (autowired), либо дают какой то DSL для сборки конфигурации (Spring XML, Spring Java). Третьего не дано - где то эта инфу контейнер должен прочитать: я не видел никаких контейнеров которые не относятся к одной из этих двух категорий. Первый путь все каплит к чертям, второй не имеет никакого смысла, лишний оверхед. Контейнер не нужен для SOLID кода.

Далее - вкрадце. EE подход (Сервисы обменивающиеся DTO) - говно, из-за лютого темпорал каплинга и слабой сплоченности методов внутри сервисов. Исключение - микросервисы. Runtime-retention аннотации - говно. В отличие от класса в коде, аннотация связана с исполняющим кодом неочевидно. Они создают иллюзию простоты, типа мы код меньше пишем, на самом деле результат с точки зрения поддерживаемости может быть непредсказуем. Они могут и скаплить все нахрен, сломать инкапсуляцию, SOLID похерить. Дебажить муторно. Разрабатывать действительно быстрее, но поддерживать - нет. Инфраструктура Spring, это наверное единственный условно позитивный момент. Почему только эту инфраструктуру надо было разукрашивать голимой магией, не особо понятно. Но да, есть кошерные вещи, типа того же реактора. Аргументировать не вижу смысла, вам все равно смотрю неинтересно. Но не говорите мне потом что это я неконструктивен.

конфиг отличается только путями к базе

Далее - вкрадце. EE подход (Сервисы обменивающиеся DTO) - говно, из-за лютого темпорал каплинга и слабой сплоченности методов внутри сервисов. Исключение - микросервисы. Runtime-retention аннотации - говно. В отличие от класса в коде, аннотация связана с исполняющим кодом неочевидно. Они создают иллюзию простоты, типа мы код меньше пишем, на самом деле результат с точки зрения поддерживаемости может быть непредсказуем. Они могут и скаплить все нахрен, сломать инкапсуляцию, SOLID похерить. Дебажить муторно. Разрабатывать действительно быстрее, но поддерживать - нет. Инфраструктура Spring, это наверное единственный условно позитивный момент. Почему только эту инфраструктуру надо было разукрашивать голимой магией, не особо понятно. Но да, есть кошерные вещи, типа того же реактора. Аргументировать не вижу смысла, вам все равно смотрю неинтересно. Но не говорите мне потом что это я неконструктивен.

а что в реакторе хорошего?

ща про визардо начнется

=D

а что в реакторе хорошего?

Реактор хотя бы имеет конкретную цель, решает конкретные задачи (реализует реактивный подход со всеми его достоинствами и недостатками). Достоинства/недостатки реактивного подхода обсуждать не возьмусь, на практике мало имел с ним дело

Я два часа не читал, а вы до сих пор ведетесь на его троллинг. Ну емнип

Аргументы то будут в ответ?