Как стать автором
Обновить
-5
0.1

Пользователь

Отправить сообщение
Где-то с пол года назад тоже прошёл этот нетривиальный путь публикации своей библиотеки в mavenCentral. Материалов в сети на эту тему много, но большинство уже неактуально, и чтобы продвинуться, приходилось вычленять отовсюду по крупице информации.
Наиболее полный гайд на эту тему я нашёл здесь:
blog.autsoft.hu/publishing-an-android-library-to-mavencentral-in-2019
Но, к сожалению, к тому моменту уже дошёл почти до конца. А может и к счастью.
Сама либа была для kotlin’а, сборка на gradle’е с kotlin dsl.
Ох, только этого ещё не хватало. Мало того, что собственноручно, в здравом уме и твёрдой памяти уничтожили мобильный firefox, так ещё и десктопный добивают. Опять придётся твикать интерфейс, разгребать несовместимости плагинов и исправлять революционные дизайнерские идеи. Хоть бы userChrome.css остался.
И это ещё тратит время разработки.
Ну здесь, видимо, сарказм. Но растянутый так, что принимается за чистую монету.
Да лишь не убрали его вообще. В целях «улучшения качества и простоты обслуживания».
А вы встречали в продакшне откровенно плохие фрагменты кода, переполненные всяческими проблемами?

Как можно? Это же продакшн. Всё вычищено до кристального блеска. От которого иногда кровавые слёзы наворачиваются.
Это был сарказм.
Из заявления следует, что признали ошибкой то, что добавили ярлычок без разрешения. Видимо, в дальнейшем таких «ошибок» постараются совершать меньше.
Они же написали — не будут добавлять на рабочий стол иконку без явного разрешения пользователя.
Когда дома нас не устраивают обои, кровать, сантехника, мы делаем ремонт. Улучшаем нашу жизнь дома.
Когда на работе нас что-то не устраивает — почему не вести себя так же?

Наверно потому, что хозяина бизнесаквартиры всё устраивает. А если постояльцам не нравятся правила проживания — могут съехать на другую квартиру.
Гипотетическая проблема. Всё не предусмотришь. В данном случае вероятность такого исхода довольно мала.
Хотелось бы писать хорошо структурированный код с хорошей архитектурой и тестами. Но реальность такова, что бизнесу нужен результат. И нужно найти золотую середину между стоимостью, качеством и временем разработки.
Да, смысл меняется. Если точно знаешь, данный вариант лучше и не отнимет времени — нет смысла не сделать.
По конкретному случаю: Ну вот использовал здесь один разраб hashMap. Времени лишнего не потратил, но и на конечный результат не повлиял. Другой не задумался на решением или не знал другого варианта и использовал List. Результат — тот же. Но ведь время более квалифицированного разраба дороже?
И другое дело, если список _действительно_ большой и результат имеет значение.
А потом ещё окажется, что для удовлетворительного решения данный проблемы вообще не важны эти 2.5 наносекунды. Где-то там же идёт вызов веб-сервиса и потери в первом случае нивелируются.
Потому что «Преждевременная оптимизация — корень всех зол» (с)
Играть за одним компом было неинтересно — все видели, что у тебя есть, куда ты идёшь и что делаешь — никакой интриги. По сети играть не позволяло отсутствие компов у некоторых участников.
Поэтому был найден следующий выход: играли у товарища, у которого комп находился в небольшой комнате. Пока один ходит, другие сидят в соседней комнате. И в этот момент игра приобрела доселе отсутствующий, но крайне интересный политический оттенок) Пока один ходит — двое других о чём-то договариваются, делятся информацией, строят планы. Интриги, скандалы, предательства, взаимные обиды… это было круто!
Сделают 2 версии браузеров — для России и для остального мира. Первый, как можно догадаться, останется без тора.
Но всё-равно большое спасибо за советы. Я просто предполагал, что должен быть какой-то простой способ получения бина динамически, т.к. мне это не кажется какой-то экзотической задачей.
Да, это может быть возможным решением, если код немного доработать. Класс 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
В данном случае придётся запилить статическую переменную, которая будет следить за тем, чтобы роут выполнился только один раз.

В данном случае проще воспользоваться тем примером, что я скидывал выше:
.routingSlip(simple("bean:${exchangeProperty[master].getBean()}"))

Писать меньше, но всё-равно костыльно.

Но оба решения у меня не получилось использовать для .transacted(«myBeanName»)
Этот элемент принимает только название бина в виде строки. Я пробовал передавать метод, который возвращает строку, но не могу получить объект exchange в методе.
В вашем примере на момент загрузки роута уже известно имя бина — «testBean1»:
Object bean1 = getContext().getRegistry().lookupByName("testBean1");

По идее, в этом случае роут должен отработать правильно и если просто указать:
.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()}")
;



Вот проблема именно в этом месте:
.bean("${exchangeProperty[master].getMyBeanName()}")

Имя бина неизвестно на момент загрузки роута.
Нет, exchangeProperty возвращает ValueBuilder. Я его не могу привести к кастомному типу.
Вообще, я нашёл способ выполнить бин по названию из свойств самого сообщения:
.routingSlip(simple("bean:${exchangeProperty[propertyName].getMyBeanName()}"))

Но есть 2 проблемы.
1. По-моему, костыльно. Я думаю, должен быть какой-то «правильный» способ получить название бина из свойств сообщения.
2. Один из роутов мне нужно выполнить с транзакцией:
.transacted("customTransactionPolicy")

, где customTransactionPolicy — имя кастомного бина, который так же меняется в зависимости от того, какое сообщение пришло в роут.
Вот здесь мне не удалось никак подставить нужный бин.
Вопрос по работе с бинами в роутах.
Начну с описания проблемы, которую нужно решить.
В процессе обработки сообщения нужно выполнить определённую бизнес-логику. Бизнес-логика инкапсулирована в бине. В качестве di-контейнера используется spring.
Сделать это можно, например, так:
.bean("myBeanName")

Далее, в контейнере хранится несколько объектов одного класса, отличающиеся названием бина ну и, соответственно, преобразованием сообщения. В сообщении в свойствах хранится название бина, который должен его обработать.
Теперь суть вопроса: как в роуте указать, какой именно бин нужно выполнить?
Т.е. что-то типа такого:
.bean("${exchangeProperty[propertyName].getMyBeanName()}")

Т.о. имеем роут, который динамически получает из сообщения название бина и выполняет его. При получении разных сообщений выполняем разные бины.
Или другая институтская истина: «Сначала ты работаешь на зачётку, а потом нигде».
И в момент горения пятых точек пухлых топ-менеджеров один из них вспоминает, что приходил недавно недовольный клиент и возмущался их первоклассной системой безопасности, на которую было запилено так много бюджетных енотов. Кого же теперь находчивые руководители будут прикладывать к своему больному месту, чтобы остудить накал страстей?

Информация

В рейтинге
3 203-й
Зарегистрирован
Активность