Adding custom codec to rxjava vertx EventBus - java

I am using vertx-rx-java
I have two verticles which communicate which each other using EventBus, one of the verticles returns complex object as the result, to do so I created custom MessageCodec and wanted to register it in EventBus.
In standard io.vertx.core.eventbus.EventBus there is a method registerCodec which gives possibility to register custom codecs for this EventBus.
However since I am using io.vertx.rxjava.core.Vertx, by calling vertx.eventBus() I receive io.vertx.rxjava.core.eventbus.EventBus, which doesn't have such method. What is the purpose of removing this method from rxjava EventBus, is it considered bad practice to use custom codecs whens using rxjava? If so, what is the recommended approach?
The only way to add custom codec I found is to call eventBus.getDelegate():
EventBus eb = vertx.eventBus();
((io.vertx.core.eventbus.EventBus) eb.getDelegate()).registerCodec(new StringMessageCodec());

Short answer appears it has not been supported. Hoewever this has changed recently (August) on the unreleased master branch; see they removed #GenIgnore from EventBus here. However, that is not yet in the release 3.5.3. Presumably this change will go out in one of the next releases.

Related

How to create producer in String Cloud Stream Functional Model (v3.1+)?

How can I create producer in Spring Cloud Stream Functional Model?
The following version is deprecated now.
#Output(OUTPUT)
MessageChannel outbound();
I know that it is possible to achieve by java Supplier functional class, but it will send message every one second. I don't need it to send every second. I am going to replace REST API with with Kafka.
Are there any ways to do that?
Use the StreamBridge - see Sending data to an arbitrary output.
Here we autowire a StreamBridge bean which allows us to send data to an output binding effectively bridging non-stream application with spring-cloud-stream. Note that preceding example does not have any source functions defined (e.g., Supplier bean) leaving the framework with no trigger to create source bindings, which would be typical for cases where configuration contains function beans. So to trigger the creation of source binding we use spring.cloud.stream.source property where you can declare the name of your sources.
If you want to trigger a stream from an external Kafka topic, you can also bind a spring cloud steam processor’s input to that topic. The stream bridge provides a layer of abstraction that may be cleaner, I.e., your non-stream application does not use the Kafka API directly.

How to collect a coroutine flow in java?

I'm developing an Android library,
When the user receives a push notification it may contain deep links, that I need to return to the app.
I did in kotlin with no problem.
This is the function that is called when it needs to send the deep links
fun getDeepLinkFlow(): Flow<HashMap<String, String>?> = flow {
emit(deepLinks)
}
And in my kotlin test app I managed to use with no problems as well, using like this.
GlobalScope.launch(coroutineContext) {
SDK.getDeepLinkFlow().collect { deepLinks ->
println(deepLinks)
}
}
But now, there's a RN project that whant to use the lib, in order to do that we are doing a RN module that joins the iOS code and the Android code. But it uses java.
So, how can I use the collect from Coroutines on a Java code? or what could I do differently?
Coroutines/Flow is inherently awkward to use from Java since it relies on transformed suspend code to work.
One possible solution is to expose an alternative way of consuming the Flow to your java code. Using the RxJava integration library you can expose a compatible Flowable that the java side can consume.
I've decided to change the way deep links were used and start using the ViewModel with a liveData instead.

spring mvc: the difference between DeferredResult and ListenableFuture?

Spring MVC lets controllers return DeferredResult and ListenableFuture (which is implemented by ListenableFutureTask) to do async response. What's the difference? When should I use each of them?
They are conceptually similar to each other and can be used interchangeably as a controller's method result, thanks to ListenableFutureReturnValueHandler that adapts the second to the first one.
However, both DeferredResult class and ListenableFuture interface come from two different worlds:
First from org.springframework.web.context.request.async package added in version 3.2.
Second from org.springframework.util.concurrent package available since 4.0.
Moreover, they were added for different needs. While the first one provides a base and complete functionality for providing controller's result asynchronously, the second one allows you in addition to bridge your implementation with already existing classes/frameworks, like for example ExecutorService framework (see ListenableFutureTask).
So the bottom line is, use the DeferredResult class when it's enough for you to implement further processing on your own or ListenableFuture when you'd like to use ExecutorService-like frameworks.
DeferredResult is an alternative to Callable that allows you to produce a result. You can also extend DeferredResult to associate additional data or behavior, in case you need to access some data later without needing additional data structures. But that's about it.
ListenableFuture future comes in handy when you need to add callbacks to the asynchronous task. Guava's ListenableFuture actually allows for composition, which I don't see Spring's ListenableFuture to do.
For that you'd rather use CompletableFuture, which is also supported by Spring.
You can compose futures very simply, check this out: http://www.deadcoderising.com/java8-writing-asynchronous-code-with-completablefuture/

Event Bus equivalent in iOS

Heard about java 'publish-subscribe' style communication between components without requiring the components to explicitly be aware of each other, which is Event bus.It seems that using event bus we can communicate between different classes very easily with less coding needed.I know that NSNotifications in iOS also do this. NSNotification is not a replacement here.Please let me know apart form delegation pattern what is a good solution in iOS which is a good replacement for EventBus for communication between classes.?
With Swift you can use SwiftEventBus. It's just a nice wrapper around NSNotificationCenter and DispatchQueue.
Register to an event:
SwiftEventBus.onMainThread(target, name: "someEventName") { result in
// UI thread
// Do something when the event occurr
}
Trigger an event:
SwiftEventBus.post("someEventName")
And if you need to customize it, the source code is short, clear and easy to understand.
I think you can use NSNotificationCenter for this, I read your comment about it is one-to-many and it's true by default but you can specify from which object do you want to receive messages like this:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(someSelector:)
name:#"MyPersonalNotification"
object:someOtherObject];
Here you will receive the MyPersonalNotification in someSelector: only when someOtherObject post it. This made the communication one-to-one.
Also you can use the Key-Value Observing API but I personally found it somewhat uncomfortable.
Have a look at tolo.
The functionality is somewhat similar to an event bus and it has one big advantage over NSNotification as you don't have to unregister when deallocating (like in iOS9).

Java equivalent of Cocoa NSNotification?

I am writing a Java application using SWT widgets. I would like to update the state of certain widgets upon a certain event happening (for example, updating the data model's state).
Is there something in Java similar to Cocoa's NSNotificationCenter, where I can register an object to listen for notification events and respond to them, as well as have other objects "fire off" a notification?
Ok, suppose that for example, you want parts of your program to be notified when your Loader starts a scan, and when it finishes a scan (don't worry about what a Loader is, or what a scan is, these are examples from some code I have lying around from my last job). You define an interface, call it "ScanListener", like
public interface ScanListener
{
public void scanStarted();
public void scanCompleted();
}
Now the Loader defines a method for your other code to register for callbacks, like
public void addScanListener(ScanListener listener)
{
listeners.add(listener);
}
The Loader, when it starts a scan, executes the following code
for (ScanListener listener : listeners)
{
listener.scanStarted();
}
and when it finishes, it does the same thing with listener.scanCompleted();
The code that needs to be notified of these events implements that interface (either themselves, or in an internal class), and calls "loader.addScanListener(this)". Its scanStarted() and scanCompleted() methods are called at the appropriate times. You can even do this with callbacks that take arguments and/or return results. It's all up to you.
What sort of notifications are you looking for? If all you want is for one object to be able to tell anybody else "hey, I've changed, update accordingly", the easiest way is to use the existing Observer interface and Observable class. Or write your own with an interface that defines what you want to get called on the listeners from the one that's changed.
There's no pre-existing per-process service that dispatches events in java that's equivalent to the default NSNotificationCenter. In java, the type of the event is specified by the event object being a particular type (which also means that the notification method depends on that type) rather than using a string. Prior to generics, writing a general event dispatcher and receiver that is also typesafe isn't really possible (witness the proliferation of *Event classes and *EventListener interfaces in the AWT and Spring libraries).
There are some facilities for event dispatch. As Paul mentioned, there's java.util.Observable, which as you point out, requires subclassing. There's also java.beans.PropertyChangeSupport, which could be useful depending on your situation.
You could also write one yourself. The source for PropertyChangeSupport is likely available in the openjdk, and you could look at the abandoned Apache Commons Event project. Depending on your needs, you may have to worry about stuff like threading, seralization, memory leaks (ensuring deregistration or using weak references), and concurrent modification (iterate over a copy of your list of listeners, as a listener may decide to unregister itself in response to a change).
Now that generics exist in Java, a generic event dispatch library would be possible; however, I haven't come across any. Anyone?
There's actually a facility built in to Java that does exactly what you want, but it's not something you may have considered, and, to be honest, it is likely a bit heavyweight for what you want.
That said, however, it does exist.
It's JMX.
You create MBeans, and then others can register for events from those MBeans. The MBean can then send of a Notification.
I personally wouldn't consider using it for this case (I'd just pound out my own), but the facility is there and it well defined and documented.
Not Java, but the IPython project has a notification center written in Python here that you could use as a template for a Java version.
In Java this would be a provider firing notifications to its listeners. But Java does not offer the loose coupling you get with Cocoa's NSNotification because in Java providers and subscribers must have references to each other. Compare for this chapter 18 in "Learn Objective-C for Java Developers".
There is an implementation of IOS NSNotificationCenter in Java.
You can find sources code in :
This Github project

Categories

Resources