Pull to refresh
3
0.3
Send message

Судя по тому, что вы говорите про Karaf, вы не знаете что такое OSGI, как оно работает, и что я имел ввиду, говоря про его поддержку.

Разъясняю: Karaf - это ядро/движок. К нему нужны бандлы, без них он никому не нужен. А бандлы перестали делать как раз, наверное, в году 2010.

Евли у вас все самописное, как например Eclipse, то все прекрасно. А если вам нужно что-то из современных библиотек и технологий - то тут все печально.

У меня тоже был опыт работы с OSGI. Например Spring поддерживается версии 3 - это 2010 год. То есть на технологию забили уже 14 лет. Ни одна современная бибилотека не поддерживает OSGI. Попытка что-то использовать выливается в перманентное сражение, и не факт что успешное. Да и OSGI, по моему мнению, стоит рассматривать как динамические сервисы И написание бандлов и вообще использование этой технологии стоит рассматривать именно так. Если у вас нет динамики - оно вам не нужно. А с учетом того, что сейчас бал правят микросервисы и даже application server - уже тоже не в почете, то что говорить о OSGI.

Поэтому перед использованием, следует не 10 а 1000 раз подумать, и выбрать что-то другое.

Наверное нужно объяснение в чем проблема:

Обычно для валидации поля валидатор пишется на нем. Но если у вас есть зависимые поля, то по стандарту можно написать только валидатор класса. И тут возникает противоречие - зачем писать валидаторы на полях, если нужно писать еще и валидатор класса - это порезать логику валидации на два куска - и все из-за того что зависимый валидатор на поле написать нельзя.

Моя попытка написания такого валидатора закончилась неудачно. Для такого валидатора нужно получить сам объект. В самом стандарте это сделать нельзя, поэтому нужно опираться на конкретную реализацию - это уже плохо. В реализации гибернейта вроде как можно получить объект, но через такие гланды, и то не всегда: оно выглядит так коряво, что лучше все-таки писать валидатор класса.

Стандарт такого не позволяет - есть только валидатор класса. Но это спорный вопрос, есть по этому куча вопросов, объяснений и жалоб в интернете.

Я про яву. Вроде как в с# зеленые потоки накрылись медным тазом. Ну может скопируют с явы во второй заход.

Ну например если код не старый, тот же tomcat - то выхлоп очень даже ничего. А synchronized - прокололись, но уже как я понимаю, уже думают как все под капотом починить.

Ответ на несклько выше коментариев, которые говорят, что реализация "под капотом" это плохо.

Стоит сразу сказать, что переключение контекста имеет смысл только при внешенем общении - сейчас это диск и сеть. То есть мы уже знаем внутри каких функций возможно переключение. И возникает закономерный вопрос, а зачем эту функцию во всех местах программы явно обмазывать асинхронщиной - это тупо дубликация кода. Легче написать небольшой планировщик потоков, а внутри требемых функций - переключение. Это дает - меньше ошибок, проще код (он становится синхронным), универсальность (не зависимо от типов тредов).

Плюс, уже есть реальные реализации, которые показывают, что это возможно. И работает оно очень даже неплохо.

Также стоит указать на антипаттерн, когда "кишки наружу" - "заражение асинхронщиной", когда из- за вызова одной асинхронной функции в глубине кода требуется все синхронные функции сделать асинхронные.

Сейчас из-за блока synchronized не может виртуальный трид сняться с реального. Ну так уже давно пишут - не используйте synchronized а используйте другие примитивы. А во всем остальном (и по тестам) - это успех.

Стоит сказать, что ваша идея уже реализована в java 21 - virtual threads.

Так спор и возник, из-за предположения, что доменная модель хранится в бд. Но это не так - доменная модель отдельно, хранилище и его структура отдельно. И есть трансляция из одного в другое - и это не обязательно sql. Поэтому во всех книжках, на всех графиках это разделяют. То что иногда оно одинаково в каких-то местах - это бонус но не правило.

А если вам нужна история по объектам, то идилия соответствия рушится тоже очень быстро. И если вы использовали в проектировании эту идиллию, то в результате у вас настает момент, когда структура хранения начинает протекать на другие абстракции.

Вы ошибаетесь. Например в event sourcing - поток событий и там никакой сериализации доменных объектов нет.

Ваша основная ошибка - апи дает доступ к доменной модели а не к базе где оно хранится. Притом формат хранения часто отличается от доменной модели. И конвертация запроса из одной модели в другую, это не просто перенос условий в where. Отсюда и вывод - зачем sql если его невозможно потом использовать. Тогда нужно что - то попроще - rest, graphql. Да еще и безопасность - тут вообще попроще - это безопачнее.

Для того чтобы стать монополистом, Apple выпиливала любую конкуренцию. И в какой-то момент государство должно вмешаться, умерить прыть компании.

То что показано - это OLE (COM). И оно же ActiveX - который сначала усиленно продвигали а потом усиленно выпиливали. И из-за этого легаси размеры операционки все время увеличиваются. :)

Тут только борьба с более успешным конкурентом...

В статье оверинжиниринг какой-то....

Встретили 1 - прибавли к счетчику 1, встретили 0 сравнили счетчик с макс значением и обнулили счетчик...

С выходом Java 21 - Virtual Threads - использование реактивного стека теперь под большим вопросом. Смысл его теперь только в ограниченных случаях.

Но подождите, это классический парадокс Рассела!

После строки

'ACCESS_TOKEN_LIFETIME': timedelta(days=30)

читать перестал.

Можно ж в SQL написать .... ((:val IS NULL) OR (column = :val)).... В функцию передаем или null или значение.

Information

Rating
1,847-th
Registered
Activity