RMI callback client stub

I am new to RMI.
We have a server component that runs within its own JVM.It needs to callback on client applets/consoles etc.
Ordinarily,the client would implement an interface, and distribute the interface and remoting stub to the server ,for the server to callback on.
However,rather than the client distributing the interface and stub,we wish the server to define a callback interface and implementation.
Thereby,the server can generate its own stub from the callback implementation.
This implementation can be provided to the client as a packaged class(along with the remote server stub and server interface).
The interested clients can extend this implementation.
The point that we wish to avoid through this framework,is the client providing the RMI stubs to the server for callback,as the server needs to be developed independently.
Is this a possible framework?
Any help will be appreciated.

If you do that you'll have to use the codebase feature to distribute the stub class to the client. I would use JDK 1.5 and forget about stubs altogether.

Similar Messages

  • Check java.rmi.Remote client alive?

    Hi,
    I have a Client program which extends java.rmi.Remote and a Server program which has a method Connect(java.rmi.Remote client).
    in my Server program, I add the "java.rmi.Remote client" stub reference into a vector when any client calls the remote method Connect(java.rmi.Remote client).
    when I am trying to check if the client is still alive, how could i make use of the stub reference to do so? I have check if the reference is null but it doesn't work.
    Thank you for any help.

    I am checking on the client without client knowing it. i need to use this when any of the client call my server method to shut down.
    i will need to check that no client are connected or alive before shutting down the server. this is why the operation have to be transparent to all other client.
    Yet i could not change the callback interface as it has been published and there are all sort of clients connecting to the server using this interface.
    Probably could I achieve that using socket connection ?
    i would appreciate if someone could suggest a solution to it. Thank you.
    Message was edited by:
    eddy_nyp

  • RMI Callback with Applet

    Hi,
    I have a simple RMI Callback Client/Sever Application, where the client-side is inplemented in a JApplet. All works fine by local tests (client and server on my machine), but when the client is on remote machine I got an security exception or error (ClassFormatError(Bad magic number)).
    How can I make my client/server work?

    No, I'm testing inside LAN, no firewalls, no proxys, no nothing. Just a server and the client (applet).
    And this strange error, I'll paste the entire stack trace:
    java.lang.ClassFormatError: Client (Bad magic number)
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadCode(Unknown Source)
    at sun.applet.AppletPanel.createApplet(Unknown Source)
    at sun.plugin.AppletViewer.createApplet(Unknown Source)
    at sun.applet.AppletPanel.runLoader(Unknown Source)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
    On my local machine oll works fine... is the problem the applet's "sandbox"? Or...?
    Any ideas are welcome
    Thanks

  • RMI callbacks with no replica aware stubs in a cluster?

    We would like to use either an RMI ping mechanism or an RMI callback in an upcoming project but are limited to 1.1 and 1.2 JRE's. I don't believe generating a replica aware proxy is an option for us given those constraints, no support for dynamic proxies. So we have a remote server object that we would ideally like to be clusterable that we can register a callback interface with. How can we accomplish this given our client limitations with weblogic 8.1 RMI? Any options?

    Yep you speak no lies. Of course once I thought about it some more I realized the error of assuming one could register a jdk rmi object with a weblogic rmi object. JRMP vs T3?. Not good.
    We still like using plain jane RMI w/in weblogic. I can register my UnicastRemoteObject stub with a normal RMI object on the server and it can callback and deliver messages. It will also send heartbeats periodically. If the heartbeat isn't heard from in awhile we re-register through http. The advantage of this is that the http session has failed over to another box and the web tier manages the rmi registration for me. The client can remain ignorant of any RMI lookups, which are tedious when not using JNDI or the cluster aware proxy.
    All of this to get back a few seconds and keep a few thousand clients from polling through a servlet every second. Argh JDK 1.1.
    Thanks for hammering that final point in.

  • RMI Callback messages can not be sent to all clients

    we I send a message to all clients using RMI Callback the message dont arrive to all clients when one or more clients is disconnected without removing themselves from the hashtable at the server side .
    how i can know if the client is disconnected before sending the message to him using RMI callback taking into account that the client dosnt tell the server when he has disconnected.
    please i want a solution to this problem.
    thanks

    You seem to be making this a little complicated. During the login (or sometime) have one of the parms that are passed back to the server be a remote object on the client. It can have a nice interface like
    public void callMe(Object obj) throws .... or you could get cute and add
    pubic void shutDown() throws.... but this could be handled in the other method.
    During the call the client becomes the server and the server the client. The callMe method has no clue as to what thread it is on so it should just quickly queue up whatever it has gotten and return. It should not be doing work that will effect the Awt thread. If the client is no longer there then you should be able to catch this on the server, and continue posting other clients.
    Howie
    Your question is very similar to what I'm currently
    researching. I've got the additional complication of
    detecting when clients crash without unregistering (in
    my case unlocking) a resource. I haven't written any
    test code yet, so don't shoot me if I'm wrong, but
    here is my general strategy.
    In order to implementing RMI callbacks, it looks like
    you must make both the clients and the server register
    themselves in the RMI Registry. Parameters sent
    through RMI method calls are done by value so
    you can't simply add a listener as you normally do.
    The server will put itself in the registry using a
    well known ID. The clients will get this reference
    and ask the server for a unique ID. They will then
    register themselves in the RMI registry using this
    value. The client will then tell the server that it
    is registered. I believe if the client object is
    wrapped in a WeakReference, then when the client dies
    or ends, the reference contained in the WeakReference
    will be null. The server will perform this check on
    all registered clients to determine which clients are
    still alive.
    ,Marcus

  • RMI callback with JAVA1.5

    Since the version 1.5 we have no need to distribute the stub to all the clients.
    It's a great feature, but I need to perform a callback from the server to the client, in this case I need to perform a call to UnicastRemoteObject.exportObject() client-side before calling the registration method exposed by the server, and the stub of the class implementing the callback interface must be placed in the classpath of the server, is it true? Is there any other methos to perform an RMI-callback?
    To be clear as much as possible I have this interface exposed by the server
    public interface Services extends Remote
      public Map<String, ApplicationStatus> applicationsList () throws RemoteException;
       public ApplicationStatus startApplication (String identifier) throws RemoteException;
      public ApplicationStatus stopApplication (String identifier) throws RemoteException;
      public int exitCode (String identifier) throws RemoteException;
       * This method, as the name says, is used by the client to register the listener to some server-side event.
       * @param callback
       * @throws RemoteException
      public void registerForNotification (ExitCodeCallback callback) throws RemoteException;
    }and the interface of the callback is
    public interface ExitCodeCallback extends Remote
      public void notifyExitCode (ExitCodeEvent event) throws RemoteException;
    }On the server side I export the services in the registry
    Services servicesServerSide = new MyServices();
    Services services = (Services) UnicastRemoteObject.exportObject(servicesServerSide , 0);and on the client I perform a lookup of the services
    Registry registry = LocateRegistry.getRegistry("192.168.0.1", 1099);
    Services services = (Services) registry.lookup("SERVICES");I export my implementation of the interface
    public class ClientExitCodeCallback implements ExitCodeCallback
      public void notifyExitCode (ExitCodeEvent event)
        System.out.println(event.asString());
    }through the code
    services.registerForNotification(remoteCallback);but on the calling of this method I obtain a ServerSideException
    java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
         java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
         java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:325)
         at sun.rmi.transport.Transport$1.run(Transport.java:153)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
         at java.lang.Thread.run(Thread.java:595)
         at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
         at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
         at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
         at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:179)
         at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
         at $Proxy0.registerForNotification(Unknown Source)
         at it.sogei.jscheduler.rmi.client.StartClient.main(StartClient.java:45)
    Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
         java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:285)
         at sun.rmi.transport.Transport$1.run(Transport.java:153)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:246)
         at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
         at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
         at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
         at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
         at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
         at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290)
         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:279)
         ... 6 moreIs it true all of the above?

    If the server gets that exception, it's because the client found and used the stub when it exported its callback, or else the server is running < 1.5.
    If the client explicitly cites a port number or zero and it is running >= 1.5 and there is no stub class, it won't use it; it will create a dynamic stub class; and it will send an object of that class to the server as a parameter to the registration call. If the server is running >= 1.5, it will succesfully deserialize that object, reconstruct the dynamic stub from information in the serialization stream, and execute the registration method implementation.
    If the client exports by using a stub class instead of the above, it will create an object of that class and send it to the server as a parameter to the registration call; the server will try to deserialize it; and if it doesn't have the stub class available it will throw that exception.
    This is how it works.

  • NAPT Firewall, RMI Callbacks and JRMP MultiplexProtocol

    Hi All,
    I am looking at having an RMI client behind a Network Address Port Translation firewall receive RMI calls back from an RMI server. NAPT makes it impossible for the client to listen for connection coming from the server through the NAPT firewall.
    This is discussed at http://www.rmiproxy.com and http://cssassociates.com/rmifirewall.html but the proposed solutions do not appear to use the MultiplexProtocol protocol defined by JRMP (http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol3.html).
    The RMI FAQ
    "How can I receive incoming RMI calls through a local firewall"?
    (http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html#firewallIn) had a section for JSSE 1.3 that explained how to use the multiplex protocol (option 4). It sounds like this option referred to the JRMP MultiplexProtocol protocol.
    The multiplex protocol option has been removed from the 1.4 FAQ
    (http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html#firewallIn).
    Tried the "checkListen" and "socket factory" techniques mentioned in the 1.3 FAQ without success with 1.4.2. The RMI client behind the NAPT firewall runs in a signed Applet.
    Is the ability of using the JRMP MultiplexProtocol protocol available in the JRE in order to receive incoming RMI calls through a local firewall? If yes, what do you do in order to use it?
    What is the best way to have RMI callbacks work behind NAPT?
    Thanks a lot in advance!
    Cheers
    Bertrand

    As of about JDK 1.2.2, the ability of RMI clients to negotiate the multiplex protocol was
    removed, but the server-side support remains.
    Your best answer for negotiating NAT filrewalls may be the RMI Proxy http://www.rmiproxy.com, although I could be biased as I wrote it.
    EJP

  • RMI-IIOP client - CORBA Server

    I already have a CORBA server in C++ which has already been written. I am trying to develop an RMI-IIOP client which would talk to this CORBA Server.
    The CORBA server has several interfaces that I would like to use with my RMI-IIOP client. How do I proceed?? Can somebody give me an example of an RMI-IIOP client? Basically my question is: how do I take the IDL and build an RMI-IIOP client with it???

    Hello
    I already have a CORBA server in C++ which has already
    been written. I am trying to develop an RMI-IIOP
    client which would talk to this CORBA Server.
    The CORBA server has several interfaces that I would
    like to use with my RMI-IIOP client. How do I
    proceed?? Can somebody give me an example of an
    RMI-IIOP client? Basically my question is: how do I
    take the IDL and build an RMI-IIOP client with it???The steps to do are the following:
    * Creating the Remote interface
    * Using the rmic compiler to genarate the IDL and the client stub.
    * Generating stub and skeleton of the C++ server using that IDL (the one you already made is no longer compatible)
    * Bulding up the new C++ server
    * Using a nameservice (tnameserver for example) and binding your server to that.
    * Writing the RMI-IIOP client
    I proceeded like this (using Visibroker 4.5 on the server side) and I was able to do it... but as you can see from my last post, I wasn't able to pass Strings from the client to the server.
    Bye

  • RMI Callbacks with Highavailability

    Hi,
    I would like to use the RMI Callbacks mechanism. The only problem I got is that I need to also implement highavailability, meaning that I will have more than one server. How can this be implement? Do I need to pass the callback reference to all the other servers? Is it possible to keep the reference in a data base?
    Thanks!

    I resent your remark.
    A client can connect to one server. Now, this server has the refernce to later be used by RMI Callback. In order for other servers to use it as well, the server can serialize the reference and save it in the DB (that was my question - if saving it in the database is possible). A server that gets a request from a client and wants to forward it to another client, checks to see if it has its reference. If not, it reads it from the database and uses it.

  • RMI callback

    Hello everyone!
    I have problem with RMI callbacks. I have on server function "connect" which is adding a client to host lists. Then if necessary I send something to people from that list. Everything is working, client can send info to server which is next resend to clients from host list. But problem is at start-up. Sending to a server a reference to a client object is very, very slow. It takes about 10-20 sec.
    Then everything is fine, every method gives me an answer within parts of seconds.
    How can I eliminate this startup problem?
    Thanks in advance,
    Daniel

    It seems that I resolve the problem first :) Hopfully.
    Here is the answer for those of You who has or will have same problem:
    If you want to pass the object by reference to server you need to implement Remote interface. Of course this is implemented by class UnicastRemoteObject, which you have to extend, but you must remember to implement it in every object which is called by class as well. I have forgoten about this and insted passing by reference it copied object, which is horrible SLOW!!

  • "DEADLOCK" when showing dialog from RMI-callback.

    Hi!
    Today is the 10th day (full time) that I've been searching for a solution in Java Forums and Internet, but I couldn't find anything that helps me. Help is extremely appreciated, otherwise I'll go crazy! :-)
    The problem is that RMI-callback thread "somehow blocks" the Event Dispatch Thread.
    I want to do following:
    1) I push the button in the client (btDoSomething)
    (MOUSE_RELEASED,(39,14),button=1,modifiers=Button1,clickCount=1 is automatically pushed onto EventQueue)
    2) btDoSomethingActionPerformed is invoked
    3) inside of it I make a call to RMI-server (server.doSomething())
    4) from this server method I invoke RMI-callback back to the client (client.askUser())
    5) in the callback I want to display a question to the user (JOptionPane.showConfirmDialog)
    6) user should answers the question
    7) callback returns to server
    8) client call to the server returns
    9) btDoSomethingActionPerformed returns and everybody is happy :-)
    This works normally in normal Client, that means, while a button is pushed, you can show Dialogs, but with RMI callback I get problems.
    I just made a small client-server sample to simulate real project. What I want to achieve is that client invokes server method, server method does something, but if server method doesn't have enough information to make the decision it needs to do call back to the client and wait for input, so the user gets an JOptionPane.
    Here is my callback method:
        /** this is the remote callback method, which is invoked from the sevrer */
        public synchronized String askUser() throws java.rmi.RemoteException {
            System.out.println("askUser() thread group: " + Thread.currentThread().getThreadGroup());
            System.out.println("callback started...");
            try {
                SwingUtilities.invokeLater(new Runnable() {
                    public void run() {
                        System.out.println("My event started...");
                        JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                        System.out.println("My event finished.");
            }catch (Exception e) {
                e.printStackTrace();
            try {
                Thread.currentThread().sleep(10000);
            }catch (Exception e) {
                e.printStackTrace();
            System.out.println("callback finished.");
            return "Yo!"; // just return anything
        }Here in this sample I let the callback thread sleep for 10 seconds, but in real project I let it sleep infinitely and I want to wake it up after the user has answered JOptionPane. But I have the DEADLOCK, because event queue is waiting for callback to finish and doesn't schedule the "showing dialog" event which contains the command for waking up the callback thread.
    I looked very precisely when the event queue starts again to process events: it is precisely then when btDoSomethingActionPerformed is finished.
    When I'm not accessing GUI inside of the callback, this callback mechanism works perfectly, but as soon as I want to show the dialog from inside of the RMI-callback method, the "AWT Event Dispatch Queue" is somehow frozen until RMI-callback thread is finished (and in turn btDoSomethingActionPerformed terminates) . I cannot explain this weird behaviour!!!
    If I don't use SwingUtilities.invokeLater (I know this shoudn't be done outside of Event Dispatch Thread), but access the GUI directy, my JOptionPane is shown, but is not painted (it is blank gray) until callback thread returns.
    Why showing (or painting) of dialog is not done until btDoSomethingActionPerformed is finished?
    I also tried to spawn a new Thread inside of main RMI-callback thread, but nothing changed.
    I also tried the workaround from some older posting to use myInvokeLater:
        private final static ThreadGroup _applicationThreadGroup = Thread.currentThread().getThreadGroup();
        public void myInvokeLater(final Runnable code) {
            (new Thread(_applicationThreadGroup, new Runnable() {
                public void run() { SwingUtilities.invokeLater(code); }
            ).start();
        }but this didn't help either.
    Then I tried to spawn a new Thread directly from the Client's constructor, so that I'm sure that it belongs to the main appplication thread group. I even started that thread there in the constructor and made it wait for the callback. When callback came in, it would wake up that sleeping thread which should then show the dialog. But this did't help either.
    Now I think that it is IMPOSSIBLE to solve this problem this way.
    Spawning a new Process could work I think, but I'm not really sure if I want do to that.
    I know I could make a solution where server method is invoked and if some information is missing I can raise custom exception, provide the input on client side and call the same server mathod again with this additional data, but for that I need to change server RMI interfaces, etc... to fit in this concept. I thought callback would much easier, but after almost 10 days of trying the callback...I almost regreted it :-(
    Is anyone able to help?
    Thank you very much!
    Please scroll down for the complete sample (with build and run batch files), in case someone wants to try it. Or for the time being for your convenience you can download the whole sample from
    http://www.onlineloop.com/~tornado/download/rmi_callback_blocks_gui.zip
    ######### BEGIN CODE ####################################
    package callbackdialog;
    public interface ICallback extends java.rmi.Remote {
        public String askUser() throws java.rmi.RemoteException;
    package callbackdialog;
    public interface IServer extends java.rmi.Remote {
        public void doSomething() throws java.rmi.RemoteException;
    package callbackdialog;
    import java.rmi.Naming;
    public class Server {
        public Server() {
            try {
                IServer s = new ServerImpl();
                Naming.rebind("rmi://localhost:1099/ServerService", s);
            } catch (Exception e) {
                System.out.println("Trouble: " + e);
        public static void main(String args[]) {
            new Server();
    package callbackdialog;
    import java.rmi.Naming;
    public class ServerImpl extends java.rmi.server.UnicastRemoteObject implements IServer {
        // Implementations must have an explicit constructor
        // in order to declare the RemoteException exception
        public ServerImpl() throws java.rmi.RemoteException {
            super();
        public void doSomething() throws java.rmi.RemoteException {
            System.out.println("doSomething started...");
            try {
                // ask the client for the "missing" value via RMI callback
                ICallback client = (ICallback)Naming.lookup("rmi://localhost/ICallback");
                String clientValue = client.askUser();
                System.out.println("Got value from callback: " + clientValue);
            }catch (Exception e) {
                e.printStackTrace();
            System.out.println("doSomething finished.");
    package callbackdialog;
    import java.rmi.server.RemoteStub;
    import java.rmi.server.UnicastRemoteObject;
    import java.rmi.registry.Registry;
    import java.rmi.registry.LocateRegistry;
    import java.rmi.Naming;
    import javax.swing.JOptionPane;
    import javax.swing.SwingUtilities;
    import javax.swing.JFrame;
    public class Client extends javax.swing.JFrame implements ICallback {
        private final JFrame parentFrame = this;
        private Registry mRegistry = null;
        private RemoteStub remoteStub = null;
        private IServer server = null;
        private final static ThreadGroup _applicationThreadGroup = Thread.currentThread().getThreadGroup();
        /** Creates new form Client */
        public Client() {
            initComponents();
            System.out.println("Client constructor thread group: " + Thread.currentThread().getThreadGroup());
            try {
                server = (IServer)Naming.lookup("rmi://localhost/ServerService");
                // register client to the registry, so the server can invoke callback on it
                mRegistry = LocateRegistry.getRegistry("localhost", 1099);
                remoteStub = (RemoteStub)UnicastRemoteObject.exportObject((ICallback)this);
                Registry mRegistry = LocateRegistry.getRegistry("localhost", 1099);
                mRegistry.bind("ICallback", remoteStub);
            }catch (java.rmi.AlreadyBoundException e) {
                try {
                    mRegistry.unbind("ICallback");
                    mRegistry.bind("ICallback", remoteStub);
                }catch (Exception ex) {
                    // ignore it
            }catch (Exception e) {
                e.printStackTrace();
        /** This method is called from within the constructor to
         * initialize the form.
         * WARNING: Do NOT modify this code. The content of this method is
         * always regenerated by the Form Editor.
        private void initComponents() {
            java.awt.GridBagConstraints gridBagConstraints;
            secondTestPanel = new javax.swing.JPanel();
            btDoSomething = new javax.swing.JButton();
            getContentPane().setLayout(new java.awt.GridBagLayout());
            setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
            setTitle("RMI-Callback-GUI-problem sample");
            addWindowListener(new java.awt.event.WindowAdapter() {
                public void windowClosing(java.awt.event.WindowEvent evt) {
                    formWindowClosing(evt);
            secondTestPanel.setLayout(new java.awt.GridBagLayout());
            btDoSomething.setText("show dialog");
            btDoSomething.addActionListener(new java.awt.event.ActionListener() {
                public void actionPerformed(java.awt.event.ActionEvent evt) {
                    btDoSomethingActionPerformed(evt);
            gridBagConstraints = new java.awt.GridBagConstraints();
            gridBagConstraints.gridx = 0;
            gridBagConstraints.gridy = 3;
            gridBagConstraints.insets = new java.awt.Insets(10, 0, 0, 0);
            secondTestPanel.add(btDoSomething, gridBagConstraints);
            gridBagConstraints = new java.awt.GridBagConstraints();
            gridBagConstraints.gridx = 0;
            gridBagConstraints.gridy = 1;
            gridBagConstraints.fill = java.awt.GridBagConstraints.BOTH;
            gridBagConstraints.weightx = 1.0;
            gridBagConstraints.weighty = 1.0;
            getContentPane().add(secondTestPanel, gridBagConstraints);
            pack();
        private void btDoSomethingActionPerformed(java.awt.event.ActionEvent evt) {                                             
            System.out.println(java.awt.EventQueue.getCurrentEvent().paramString());
            try {
                server.doSomething(); // invoke server RMI method, which will do the client RMI-Callback
                                      // in order to show the dialog
            }catch (Exception e) {
                e.printStackTrace();
        private void formWindowClosing(java.awt.event.WindowEvent evt) {                                  
            try {
                mRegistry.unbind("ICallback");
            }catch (Exception e) {
                e.printStackTrace();
            setVisible(false);
            dispose();
            System.exit(0);
        /** this is the remote callback method, which is invoked from the sevrer */
        public synchronized String askUser() throws java.rmi.RemoteException {
            System.out.println("askUser() thread group: " + Thread.currentThread().getThreadGroup());
            System.out.println("callback started...");
            try {
                SwingUtilities.invokeLater(new Runnable() {
                    public void run() {
                        System.out.println("My event started...");
                        JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                        System.out.println("My event finished.");
            }catch (Exception e) {
                e.printStackTrace();
            try {
                Thread.currentThread().sleep(10000);
            }catch (Exception e) {
                e.printStackTrace();
            System.out.println("callback finished.");
            return "Yo!"; // just return anything
         * @param args the command line arguments
        public static void main(String args[]) {
            java.awt.EventQueue.invokeLater(new Runnable() {
                public void run() {
                    Client client = new Client();
                    client.setSize(500,300);
                    client.setVisible(true);
        // Variables declaration - do not modify
        private javax.swing.JButton btDoSomething;
        private javax.swing.JPanel secondTestPanel;
        // End of variables declaration
    1_build.bat
    javac -cp . -d . *.java
    rmic callbackdialog.ServerImpl
    rmic callbackdialog.Client
    pause
    2_RunRmiRegistry.bat
    rmiregistry
    pause
    3_RunServer.bat
    rem java -classpath .\ Server
    java callbackdialog.Server
    pause
    4_RunClient.bat
    java callbackdialog.Client
    pause
    ######### END CODE ####################################

    I can understand that only partially, because SwingUtilities.invokeLater puts(redirects) my runnable object directly into AWT thread. The only conclusion I can draw from all things that I have tried until now , is that SwingUtilities.invokeLater(<showing the dialog>) invoked from a RMI thread somehow have lower "priority" than events coming directly from the AWT-thread and therefore it is held back until normal awt event completes (in this case BUTTON_RELEASED).
    But what I don't understand is the fact that the dialog is not shown even If I create and start a new thread from the client's constructor. This thread has nothing to do with RMI as it is in the main thread group:
        private BlockingObject dialogBlocker = new BlockingObject();
        private BlockingObject blocker = new BlockingObject();
        public Client() {
            initComponents();
            (new Thread() {
                public void run() {
                    try {
                        dialogBlocker.sleep(0);
                        System.out.println("My event started...");
                        JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                        blocker.wake();
                        System.out.println("My event finished.");
                    }catch (Exception e) {
                        e.printStackTrace();
            }).start();
            ...Callback is then only used to wake up this thread which should display the dialog:
        public Object askUser() throws java.rmi.RemoteException {
            System.out.println("callback started...");
            dialogBlocker.wake();
            blocker.sleep(0);
            System.out.println("callback finished.");
            return userChoice; // return anything I don't care for now
    class BlockingObject {
        public void sleep(long timeout) {
            synchronized(this){
                try {
                    wait(timeout);
                }catch (InterruptedException e) {}
        public void wake() {
            synchronized(this){
                notifyAll();
        }In this case the dialog is shown, but it is NOT painted, so I have deadlock again. Why it is not painted?!?
    Haven't I uncouple it from RMI-Thread?
    But perhaps I'm looking at the wrong side of the whole thing.
    If I invoke server.doSomething (as ejp proposed) in a separate thread, then everything is fine (except that I cannot use this solution in my project :-( ).
    It seems that the whole problem is NOT AT ALL related to callback itself, but rather to the fact that if client invokes remote call, even dialogs can't be shown until the rmi call returns to the client.
    Thank you, Drindilica

  • RMI skeleton and stubs

    Hi,
    I'm studying RMI and have been reading a book. In the book they speak about having to generate a stub and a skeleton class.
    However, I also did the exercise on the site below and it seems it worked fine, without having to create a stub or skeleton. http://java.sun.com/docs/books/tutorial/rmi/overview.html
    Can anyone explain please???
    Thanks

    in fact, i don't understand the paragraph below on the site:
    "Later, in JDK 1.2, the skeletons were incorporated into the server itself so that there are no separate entities as skeletons. In other words, the skeletons's functionality was incorporated into the server itself. So, the scenario became like this:
    Client<--->stub<--->[NETWORK]<--->Server_with_skeleton_functionality"
    how does it works then????
    i understand the concept with stubs and skeletons well, but now that skeletons are not needed anymore, i'm a bit lost....
    you can just indicate a class to extend "remote", and then compile it with javac ?
    from then on the remote class file can remotely be called???
    right???

  • ClassCastException for RMI-IIOP client hitting CORBA server

    I am writing a RMI-IIOP client to connect to an existing CORBA C++ server. I started out with writing a RMI Interface mimicking the IDL and then converting into a stub using rmic -iiop option. I then use COSNaming to connect to the server. When I narrow the reference using PortableRemoteObject.narrow(), I get a ClassCastException. Probably because the object that I get from naming service will be a CORBA object which cannot be casted to RMI Interface object.
    Exception in thread "main" java.lang.ClassCastException
    at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:229)
    at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
    at com.att.cswd.poc.RMIIIOPClient.IMSConnect(RMIIIOPClient.java:46)
    at com.att.cswd.poc.RMIIIOPClient.main(RMIIIOPClient.java:27)
    Caused by: java.lang.ClassCastException: Object is not of remote type com.att.cswd.poc.CORBAInterface
    at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:221)
    ... 3 more
    Code
                                    CORBAInterface ims;
              String tranCode="CRTUN130";
              byte[][] input_segs = null;
               try {
                    Hashtable hm = new Hashtable();
                    hm.put("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
                    hm.put("java.naming.provider.url", "corbaloc:iiop:BSYS.MVS.SC.COM:14050/NameService");
                    Context initialNamingContext = new InitialContext(hm);
                   Object objref = initialNamingContext.lookup("O2K/AdapterInterface");
                   ims = (CORBAInterface) PortableRemoteObject.narrow(objref, CORBAInterface.class);
                   byte output_segs[][] = ims.run_transaction_binary(tranCode, input_segs);               
                   System.out.println ("Response is " + output_segs);
              } catch (NamingException e) {
                   e.printStackTrace();
              } catch (RemoteException e) {
                   e.printStackTrace();
              }

    I am writing a RMI-IIOP client to connect to an existing CORBA C++ serverAs it says in [the Javadoc|http://java.sun.com/j2se/1.5.0/docs/guide/rmi-iiop/rmiiiopUsing.html#when], you can't do that. For RMI/IIOP you have to start with a PortableRemoteObject and rmic -iiop. You can use a C++ client to that but you can't use an RMI/IIOP client to a C++ server.
    Use IDLJ.

  • RMI Callback ConnectException

    Hi,
    I'm trying to get a RMI Callback running on 2 different machines. The client registers itself at the server who then calls a method on the client. Locally everything works fine, but when running the server on a different PC I get a ConnectException when trying to call the callback method on the client. Funnily enough, the IP to which the connection is refused is that of the server! Why does it try to connect to itself? No firewalls involved, policies okay, registry running... Tested already with two machines running the same OS and Java version.
    What am I missing?
    Thanks a lot!

    I'm also facing the same problem. The application without callbacks runs without problem in one machine AND two different machines. but when i run those on different machines the app with callbacks fails. In this case the client program gives error. The IP address it looks to connect is correct in my case.
    Lookup completed
    Server said hello
    Exception in CallbackClient: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
         java.rmi.ConnectException: Connection refused to host: 192.168.0.199; nested exception is:
         java.net.ConnectException: Connection refused

  • Client & stub

    hi...friends
    i'm a new learner to rmi concepts. can anybody help me in knowing the client & stub concepts in rmi.

    stub is a client side proxy for a remote object ( instance of a class that implements a remote interface ) which is responsible for communicating method invocations on remote objects to the server where the actual remote object implementation resides and are generated with the command -rmic class_name. Client gets reference to the remote object with the help of stub.
    More information can be obtained from either Java Tutorial or the Java Documentation.

Maybe you are looking for

  • Sql loader error

    I am using sql loader command line sqlldr to load 141306 records into my table. It ended with an error message -- SQL*Loader-605: Non-data dependent ORACLE error occurred -- load discontinued. Checking for data load failures Checking Log data for cli

  • 'WHEN-NEW-FORM-INSTANCE-trigger' in JDeveloper/ADF/JHeadstart

    Hello, I'm new to JDeveloper/ADF with JHeadstart. I want to execute a PL/SQL-procedure when the application starts. I've added the method to execute the PL/SQL-procedure to the Application module class. How can we execute this method? Thanks in advan

  • I cannot delete my previously synced folders of photos off my iPhone 4s-

    HELP!!!!! I have followed all the instructions you have sent on Google- I went to itunes and made sure that I have no synced folders checked and have restarted and rebooted my computer and iPhone several times. My problem started when-- I made an iPh

  • Handbook for iBooks Author

    Is there a handbook for iBooks Author?

  • Embed the Javascript debugger into Designer

    Please embed the JS debugger into Designer. Having to have Acrobat Pro open while using Designer just to use the JS debugger is a serious pain in the a$$. When they both decide to work at the same time that is...