Bundle-A binds a package from Bundle-B using declarative services in Eclipse Environment.
Then Bundle-A sends a message to Bundle-B by passing a 'data' and 'a reference of a class object' that should get the response to this message as an argument. Eg. send(data, EgClass_1.this);
Bundle-B should process the message and send the response back to the class in Bundle-A that is awaiting response.
Unfortunately that is not possible in OSGi as it creates a cycle. Two bundles cannot import each other.
I wanted to pass reference to a class object so that Bundle-B can call a method on it to get information rather than passing too many arguments but most importantly so that Bundle-B can keep track of which class instance it should call the callback on. I will have multiple instance of the class & its child classes.
As a work around I separated Bundle_A into two, the interfaces and the implementation classes. This way Bundle_A can bind Bundle_B and also Bundle_B can import the Interface definition of Bundle_A interface so that it can work with the object reference passed as parameter.
But the above approach does not feel clean and in coincide with OSGi principles. Is there a better approach for this kind of two way communication or am I doing it right? Thanks in advance!
If I understood correctly you want to send data using the send call and be called back when B finishes. Bundle A needs to know the service interface to make the send call. So you will always have a dependency A->B. So to avoid a loop I would also define the callback interface in B. Some class in A can then implement the callback interface and you send the object instance as second parameter. B then just needs to know the callback interface.
Related
My subclass has a property which is an instance of its parent class. I wanted to intercept most of the functions in this subclass using interceptors, so that way it would call the same function on the parent class with the args passed. However, I have two issues: I don't know how to access the property, and call the function by unpacking the args at the same time.
I'm trying to create a subclass for a class in Minecraft that I'm already injecting into using Mixins, which does the thing I said above. The only problem is that that class has over 100 functions, and I'm not sure which ones I need to override in order to get the functionality I need. I was curious if Byte Buddy was suitable for this task, or if I need to consider a different solution entirely.
After seeing some examples at my class, I know that if I want to send a "TypeA" object to server and receive a "ProcessedA" object as a result, I only need one client class.
But if I want to send "TypeA", "TypeB", and "TypeC" objects (not at the same time) to server, do I need to make 3 different client classes, each one of which sends objects of one of those data types, or I only need to make one client class and write 3 different "send" methods?
You can have only one method if the objects you send inherits from one unique class or interface, and the same logic is applied to the result class.
It's a bit hard to understand what you need if you don't include a sample code of what you are trying (as is noticed in another post related to your request).
If this condition can be met by your needs, you can use the instanceof operator inside the server method to detect the type of the received object and cast it to the known child type. And apply the same logic to proccess the response in the client.
You might be thinking why would you want to have an object both Remote AND serializeable. Well let me give you some context.
I'm building an air traffic control system (school project), it's distributed so that each control zone runs on it's own server and communicates with other control zones. Each control zone keeps track of its own aiplanes.
When an airplane (flying in controlzone A) is 100km near its border, it is passed as a remote object to the controlzone (controlzone B) it's near to. This way controlzone B can see where the aiplane is (by periodical asking its position) while it's still controlled by controlzone A.
But when an airplane crosses the border between controlzone A and B, controlzone B should keep track of the airplane instead of controlzone A. So we we want to serialize the airplane and pass it to controlZone B. This is where our problem lies.
Can I make the airplane remote AND serializeable?
EDIT: Also, I could use remote methods to copy the needed fields for the airplane, but I prefer serializing it.
If a remote object isn't exported at the time it is sent as a remote method parameter or result, it is serialized instead of being passed as a remote reference, provided that it implements Serializable as well as Remote. It is then exported at the receiver. UnicastRemoteObject does this for example, and therefore so does any remote object derived from it. This can be used for mobile remote agents.
You don't have to make your object subclass UnicastRemoteObject.
Take your class, define it to implement Serializable and your RMI api interface, which itself should implement Remote. It doesn't need to subclass anything other than java.lang.Object.
When you are ready for your object to be called remotely, call the static UnicastRemoteObject.exportObject() method on it. From that point on, any reference you return over RMI to that object will be remotely callable.
When you want to pass the object off to another server, call UnicastRemoteObject.unexportObject() on your object. Then when you pass it over an RMI call, you'll be passing the serialized representation of that object.
The downside to this is once you pass it off, the object on your server will no longer accept RMI calls. unexportObject() turns it off completely as an RMI call recipient.
If you want to be able to maintain an object as an RMI target and concurrently pass it around over RMI as a serializable object, you'll need to make it serializable and interpose a proxy object that exports the Remote interface and which can talk to the non-exported, serializable object on the caller's behalf.
When you want to pass the underlying object with serialization, you pass it directly. When you want to pass a remotely callable reference to it, you pass the proxy.
Take a look at UnicastRemoteObject class. It is normally used for callback driven programming in RMI and hence implements both Remote and Serializable. Though you might want to revisit your logic since you now have an entity (airplane) which acts like a "remote server".
Turns out this solution was not correct. See #EJP's answer below for the only way to do this with a single instance.
I need to pass an object from one class to many different classes.
The aim of this is to create one method that broadcasts the object to any other classes that are listening. This is so that more classes can be added and I just need to implement a listener function for that class and not edit any of the framework.
I am trying to accomplish this without the use of JMS (if it's possible!)
Observer pattern to the rescue! Woooosh!
Let your Subject define a method for relaying that object to many listening Observers. You can then dynamically add and remove listeners.
Please forgive the very basic nature of this questions - but we all have to start somewhere. I've done some googling but all answers seem to relate to UI Events.
I am creating a very simple android app that will display your location on screen. I have my main class (HelloAndroid at the moment) that extends Activity and I have created a class LcoationUpdateHandler that listens for updates.
HelloAndroid holds an instance of LocationUpdateHandler so my question is how does the LocationUpdateHandler communicate with HelloAndroid.
In flex I would dispatch an event from one to the other but from the searching I have done this doesn't seem like a very java-y way of doing things?
Thanks for your help.
When your HelloAndroid instance creates an instance of LocationUpdateHandler it can pass a reference to itself in the constructor, which LocationUpdateHandler can store to use for future method calls in the case of events.
For these kinds of situations you don't really need to know what type of object instatiated LocationUpdateHandler. This is were interfaces come in, you can define an interface defining the event methods and implement that interface so that LocationUpdateHandler can keep a reference to that interface to deliver events.
If the situation is symmetrical, both classes can implement the same event interface.
It sounds like what you're looking for is the Observer pattern. The way it works is that observers register with the object that they are observing, such that they can be notified on events.
In your specific case, if you want LocationUpdateHandler to push information to HelloAndroid, it has to know about HelloAndroid. So your LocationUpdateHandler should at least contain a reference to HelloAndroid, but to generalize this, it should have a List of observers that all implement a common interface containing a callback function that would be called whenever LocationUpdateHandler has an update.