JAM - examples
Queue<Long> queue = new MessageQuery<Long>(new Parser<Long>() {
@Override
public Long parse(String string) {
return Long.parseLong(string);
}
})
.get("hundred");
...an we get back a Queue of Long, because JAM retrieves the messages from subscribers which query the backing sources - and hence JAM supports to retrieve the messages from several subscribers and serveral sources at once. If we have just one source, we can simply poll once:
Long value = queue.poll().longValue();
Since you can retrieve any data type, this approach can be used nicely beyond the classical purpose of messages for instance to implement a parameterization of a system. In that regard we might want to retrieve a list of values and not just a single value...
hundred=99|100|101
...which works same easy with JAM...
Queue<List<Long>> queue = new MessageQuery<Long>(new Parser<Long>() {
@Override
public Long parse(String string) {
return Long.parseLong(string);
}
})
.list("hundred");
...we just get back List(s) inside the Queue:
List<Long> list = queue.poll();
Probably, even complex messages are not the (only) reason to employ JAM. Let's have a look at the creation of our own announcement types first and then generic ways without specialized announcement type to announce arbitrary objects instantly.
An announcement must be implemented along with its counterpart: the respective subscriber interface. Both are tightly coupled. We implement a consumer and an announcement type to announce objects of the type java.lang.Long:
public interface LongConsumer extends Consumer {
void accept(Topic topic, LongOffer offer) throws Throwable;
}
public class LongOffer extends OfferBase<Long, LongConsumer> {
private static final long serialVersionUID = -8728103319320242516L;
public LongOffer(Long content) {
super(content);
}
@Override
public void offerTo(Topic topic, LongConsumer consumer) throws Throwable {
consumer.accept(topic, this);
}
@Override
public Class<LongConsumer> getSubscriberType() {
return LongConsumer.class;
}
}
The consumer interface does not define any operation and we are free to define our own operation(s) (usually named "accept").
In the constructor of the LongOffer we can just pass the main content (here a Long) to the superclass, which manages the content for some purposes. Beside that main content, we can add as many additional (but unmanaged) properties as we like for our own purposes.
The offerTo method uses our self-defined operation ("accept") on the LongConsumer interface, passing itself to the LongConsumer.
Seiten |