Пользовательские события Java со слушателями против реализации на основе JMS? - PullRequest
1 голос
/ 09 апреля 2010

Мое приложение требует, чтобы события запускались на основании определенных действий. Я пытаюсь определить, должен ли я создать свою собственную систему обработки событий, используя Java EventObject с пользовательскими прослушивателями, похожими на Java AWT. Или я должен использовать реализацию JMS? Я думал о решении Apache Qpid или ActiveMQ. В данный момент я изучаю эти варианты, и мне было интересно, есть ли у кого-то опыт работы с Qpid или ActiveMQ, и может ли он дать какой-нибудь совет (например, плюсы, минусы и т. Д.) Кроме того, если у кого-то есть предложения по созданию простой системы обработки событий ... если даже стоит подумать над решением на основе JMS.

Ответы [ 4 ]

2 голосов
/ 09 апреля 2010

Простые прослушиватели событий (используемые в Java AWT) требуют немедленной обработки событий на одной виртуальной машине и, как правило, в одном потоке.

JMS (например, с использованием ActiveMQ) позволяет обрабатывать события позднее (при желании буферизировать сообщения в постоянном хранилище) и в других виртуальных машинах / потоках. Такая гибкость достигается ценой дополнительной сложности и меньшей эффективности.

1 голос
/ 09 октября 2016

2016 Обновление

Altho java-события были добавлены еще в 2006 году, и этот вопрос относится к 2010 году, они все еще как-то «скрытые» функции в Java API, читая вопрос, который я считаю альтернативой, которая делает именно то, что вы хотите, - события Java, но не те, что в событиях AWT Java 6, которые позволяют отделить модули вашего проекта и иметь JML-подобные возможности без сервера, единственным недостатком событий по сравнению с JMS является то, что слушатель должен быть запущен, иначе сообщение будет заблудился.

от: https://dzone.com/articles/java-ee6-events-lightweight

Yo создать сообщение:

public class LogMessage implements Serializable {

    private final String message;
    private final Level level;

    LogMessage(String message, Level level) {
        this.message = message;
        this.level = level;
    }

    public String getMessage() {
        return message;
    }

    public Level getLevel() {
        return level;
    }
}

Вы создаете продюсера:

@Inject Event<LogMessage> event;


event.fire(new LogMessage("Log it baby!", Level.INFO));

и, наконец, вы создаете потребителя:

public class LogListener {
    private static final Logger LOGGER = Logger.getAnonymousLogger();
    public void process(@Observes LogMessage message){
        LOGGER.log(message.getLevel(), message.getMessage());
    }
}

Ознакомьтесь с аннотацией @Observe.

Все это делается синхронно и хорошо, чтобы быть больше jms /, как вы хотите сделать этот процесс асинхронным способом, для этого просто добавьте:

@Stateless
@Asynchronous
public class LogListener {
    private static final Logger LOGGER = Logger.getAnonymousLogger();
    public void process(@Observes LogMessage message){
        LOGGER.log(message.getLevel(), message.getMessage());
    }
}
1 голос
/ 09 апреля 2010

Вы не много говорили о своем приложении, но если вам нужна простая система обработки событий для одной виртуальной машины, взгляните на EventBus .

0 голосов
/ 09 апреля 2010

Хотите ли вы, чтобы все сообщения, которые еще не были обработаны, были сохранены в случае смерти вашего экземпляра JVM? Если это так, вам понадобится внешняя очередь сообщений. Нужно ли другим приложениям публиковать / потреблять те же сообщения, что и это приложение? То же самое.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...