Это был сарказм.
Из заявления следует, что признали ошибкой то, что добавили ярлычок без разрешения. Видимо, в дальнейшем таких «ошибок» постараются совершать меньше.
Когда дома нас не устраивают обои, кровать, сантехника, мы делаем ремонт. Улучшаем нашу жизнь дома.
Когда на работе нас что-то не устраивает — почему не вести себя так же?
Наверно потому, что хозяина бизнесаквартиры всё устраивает. А если постояльцам не нравятся правила проживания — могут съехать на другую квартиру.
Гипотетическая проблема. Всё не предусмотришь. В данном случае вероятность такого исхода довольно мала.
Хотелось бы писать хорошо структурированный код с хорошей архитектурой и тестами. Но реальность такова, что бизнесу нужен результат. И нужно найти золотую середину между стоимостью, качеством и временем разработки.
Да, смысл меняется. Если точно знаешь, данный вариант лучше и не отнимет времени — нет смысла не сделать.
По конкретному случаю: Ну вот использовал здесь один разраб hashMap. Времени лишнего не потратил, но и на конечный результат не повлиял. Другой не задумался на решением или не знал другого варианта и использовал List. Результат — тот же. Но ведь время более квалифицированного разраба дороже?
И другое дело, если список _действительно_ большой и результат имеет значение.
А потом ещё окажется, что для удовлетворительного решения данный проблемы вообще не важны эти 2.5 наносекунды. Где-то там же идёт вызов веб-сервиса и потери в первом случае нивелируются.
Потому что «Преждевременная оптимизация — корень всех зол» (с)
Играть за одним компом было неинтересно — все видели, что у тебя есть, куда ты идёшь и что делаешь — никакой интриги. По сети играть не позволяло отсутствие компов у некоторых участников.
Поэтому был найден следующий выход: играли у товарища, у которого комп находился в небольшой комнате. Пока один ходит, другие сидят в соседней комнате. И в этот момент игра приобрела доселе отсутствующий, но крайне интересный политический оттенок) Пока один ходит — двое других о чём-то договариваются, делятся информацией, строят планы. Интриги, скандалы, предательства, взаимные обиды… это было круто!
Но всё-равно большое спасибо за советы. Я просто предполагал, что должен быть какой-то простой способ получения бина динамически, т.к. мне это не кажется какой-то экзотической задачей.
Да, это может быть возможным решением, если код немного доработать. Класс BeanResolver будет выглядеть так:
@Component
public class BeanResolver {
private static Boolean EXECUTED = false;
public String execute(Exchange exchange) {
if (EXECUTED) {
EXECUTED = false;
return null;
} else {
EXECUTED = true;
return "bean:" + ((Agent) exchange.getProperty("master")).getBean();
}
}
}
Здесь проблема в том, что элемент .dynamicRouter() выполняется циклично до тех пор, пока выражение для определения бина не вернёт null. camel.apache.org/dynamic-router.html
В данном случае придётся запилить статическую переменную, которая будет следить за тем, чтобы роут выполнился только один раз.
В данном случае проще воспользоваться тем примером, что я скидывал выше:
Но оба решения у меня не получилось использовать для .transacted(«myBeanName»)
Этот элемент принимает только название бина в виде строки. Я пробовал передавать метод, который возвращает строку, но не могу получить объект exchange в методе.
По идее, в этом случае роут должен отработать правильно и если просто указать:
.bean("testBean1")
В случае с динамическим получением бина проблема будет выглядеть так:
Есть 2 объекта — MasterObject1 и MasterObject2, реализующих общий интерфейс.
// Первый основной роут
fromF("timer://mainRoute1?period=5s")
// устанавливаем в свойство "master" объект, который содержит имя целевого бина
.process(exchange -> exchange.setProperty("master", MasterObject1))
.toF("direct:actionRoute")
;
// Второй основной роут
fromF("timer://mainRoute2?period=5s")
.process(exchange -> exchange.setProperty("master", MasterObject2))
.toF("direct:actionRoute")
;
// Роут, в котором нужно выполнить бизнес-логику, инкапсулированную в конкретном бине объекта
fromF("direct:actionRoute")
// а здесь пробуем получить бин из объекта, который ранее положили в свойство
.bean("${exchangeProperty[master].getMyBeanName()}")
;
Нет, exchangeProperty возвращает ValueBuilder. Я его не могу привести к кастомному типу.
Вообще, я нашёл способ выполнить бин по названию из свойств самого сообщения:
Но есть 2 проблемы.
1. По-моему, костыльно. Я думаю, должен быть какой-то «правильный» способ получить название бина из свойств сообщения.
2. Один из роутов мне нужно выполнить с транзакцией:
.transacted("customTransactionPolicy")
, где customTransactionPolicy — имя кастомного бина, который так же меняется в зависимости от того, какое сообщение пришло в роут.
Вот здесь мне не удалось никак подставить нужный бин.
Вопрос по работе с бинами в роутах.
Начну с описания проблемы, которую нужно решить.
В процессе обработки сообщения нужно выполнить определённую бизнес-логику. Бизнес-логика инкапсулирована в бине. В качестве di-контейнера используется spring.
Сделать это можно, например, так:
.bean("myBeanName")
Далее, в контейнере хранится несколько объектов одного класса, отличающиеся названием бина ну и, соответственно, преобразованием сообщения. В сообщении в свойствах хранится название бина, который должен его обработать.
Теперь суть вопроса: как в роуте указать, какой именно бин нужно выполнить?
Т.е. что-то типа такого:
И в момент горения пятых точек пухлых топ-менеджеров один из них вспоминает, что приходил недавно недовольный клиент и возмущался их первоклассной системой безопасности, на которую было запилено так много бюджетных енотов. Кого же теперь находчивые руководители будут прикладывать к своему больному месту, чтобы остудить накал страстей?
Ну, в целом, не факт, что то, что представлено на видео — пульт управления рядового модератора.
Видимо, были нарушены настройки ролей, и для каждого пользователя вывалились вообще все доступные опции для разных категорий сотрудников.
Для себя я решил, что это связано с образом жизни — умственная деятельность с небольшой подвижностью.
А вывод такой я сделал в результате непреднамеренного, но кардинального изменения своего образа жизни — отслужил в армии. Так вот во-время учёбы я действительно постоянно не высыпался, подолгу не засыпал и постоянно просыпался. Зато в армии с постоянной физической активностью засыпать я стал моментально и в любых положениях. Особенно в караулах — иногда приходилось спать по полчаса каждый час. Никаких мыслей перед сном — лёг и сразу забылся.
Из заявления следует, что признали ошибкой то, что добавили ярлычок без разрешения. Видимо, в дальнейшем таких «ошибок» постараются совершать меньше.
Наверно потому, что хозяина
бизнесаквартиры всё устраивает. А если постояльцам не нравятся правила проживания — могут съехать на другую квартиру.Хотелось бы писать хорошо структурированный код с хорошей архитектурой и тестами. Но реальность такова, что бизнесу нужен результат. И нужно найти золотую середину между стоимостью, качеством и временем разработки.
По конкретному случаю: Ну вот использовал здесь один разраб hashMap. Времени лишнего не потратил, но и на конечный результат не повлиял. Другой не задумался на решением или не знал другого варианта и использовал List. Результат — тот же. Но ведь время более квалифицированного разраба дороже?
И другое дело, если список _действительно_ большой и результат имеет значение.
Потому что «Преждевременная оптимизация — корень всех зол» (с)
Поэтому был найден следующий выход: играли у товарища, у которого комп находился в небольшой комнате. Пока один ходит, другие сидят в соседней комнате. И в этот момент игра приобрела доселе отсутствующий, но крайне интересный политический оттенок) Пока один ходит — двое других о чём-то договариваются, делятся информацией, строят планы. Интриги, скандалы, предательства, взаимные обиды… это было круто!
Здесь проблема в том, что элемент .dynamicRouter() выполняется циклично до тех пор, пока выражение для определения бина не вернёт null.
camel.apache.org/dynamic-router.html
В данном случае придётся запилить статическую переменную, которая будет следить за тем, чтобы роут выполнился только один раз.
В данном случае проще воспользоваться тем примером, что я скидывал выше:
Писать меньше, но всё-равно костыльно.
Но оба решения у меня не получилось использовать для .transacted(«myBeanName»)
Этот элемент принимает только название бина в виде строки. Я пробовал передавать метод, который возвращает строку, но не могу получить объект exchange в методе.
По идее, в этом случае роут должен отработать правильно и если просто указать:
В случае с динамическим получением бина проблема будет выглядеть так:
Есть 2 объекта — MasterObject1 и MasterObject2, реализующих общий интерфейс.
Вот проблема именно в этом месте:
Имя бина неизвестно на момент загрузки роута.
Вообще, я нашёл способ выполнить бин по названию из свойств самого сообщения:
Но есть 2 проблемы.
1. По-моему, костыльно. Я думаю, должен быть какой-то «правильный» способ получить название бина из свойств сообщения.
2. Один из роутов мне нужно выполнить с транзакцией:
, где customTransactionPolicy — имя кастомного бина, который так же меняется в зависимости от того, какое сообщение пришло в роут.
Вот здесь мне не удалось никак подставить нужный бин.
Начну с описания проблемы, которую нужно решить.
В процессе обработки сообщения нужно выполнить определённую бизнес-логику. Бизнес-логика инкапсулирована в бине. В качестве di-контейнера используется spring.
Сделать это можно, например, так:
Далее, в контейнере хранится несколько объектов одного класса, отличающиеся названием бина ну и, соответственно, преобразованием сообщения. В сообщении в свойствах хранится название бина, который должен его обработать.
Теперь суть вопроса: как в роуте указать, какой именно бин нужно выполнить?
Т.е. что-то типа такого:
Т.о. имеем роут, который динамически получает из сообщения название бина и выполняет его. При получении разных сообщений выполняем разные бины.
Видимо, были нарушены настройки ролей, и для каждого пользователя вывалились вообще все доступные опции для разных категорий сотрудников.
А вывод такой я сделал в результате непреднамеренного, но кардинального изменения своего образа жизни — отслужил в армии. Так вот во-время учёбы я действительно постоянно не высыпался, подолгу не засыпал и постоянно просыпался. Зато в армии с постоянной физической активностью засыпать я стал моментально и в любых положениях. Особенно в караулах — иногда приходилось спать по полчаса каждый час. Никаких мыслей перед сном — лёг и сразу забылся.