Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Remote OSGI services over XMPP 
Hi Leen,

Leen Toelen wrote:

Hi,
thanks a lot for the help. Right now I'm listening for container events using a containerManagerTracker and for each one I call getAdapter(IRemoteServiceContainerAdapter.class). It's rough but it works. 

OK, good.  I've added a bug for this here

https://bugs.eclipse.org/bugs/show_bug.cgi?id=218187
I would love to help out when I got the time to continue this project, right now I am only doing some investigation. I guess it would be great for everyone to have a remotely manageable OSGI environment throught ecf, along the lines of r-osgi. Do you have any plans for this?
FYI, we have already submitted requests to use r-OSGi as an implementation of the ECF provider API...Jan Rellermeyer (ECF committer) has written an ECF remote services provider that uses r-OSGi for its implementation. It just has to go through Foundation legal approval.
So in answer to your question...we do have plans to provide remote access to some of the Equinox p2 APIs for Ganymede: 

http://wiki.eclipse.org/Equinox_p2
But are in need of contributions and some input on which APIs would be most immediately useful for specific use cases (e.g. Equinox servers, Eclipse, etc) 

Thanks,

Scott




Regards,
Leen
On Feb 7, 2008 7:37 AM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote: 

    Hi Leen,

    Leen Toelen wrote:
    > Hi,
    >
    > I am trying to set up a network with lots of automatic bots that
    > basically need to expose their OSGI services to an
    administrator. I am
    > using XMPP as the protocol, and sending IM's and files work
    without a
    > problem. I would like to try remote services as well, but can't
    get it
    > working.
    >
    > This is what the bots do when admin comes online:
    >
    >     /**
    >      * Register remote services with the admin
    >      * This is called when admin comes online
    >      */
    >     private void initializeRemoteServices() {
    >         try {
    >             // Get ECF adapter for remote services
    >             IRemoteServiceContainerAdapter adapter =
    > (IRemoteServiceContainerAdapter) container
> .getAdapter(IRemoteServiceContainerAdapter.class); 
    >
    >             // This is the ID of the administrator
    >             ID[] targetIDs = new ID[] { getID("admin") };
    >
    >             Dictionary props = new Hashtable();
    >             props.put(Constants.SERVICE_REGISTRATION_TARGETS,
    targetIDs);
    >             props.put(Constants.AUTOREGISTER_REMOTE_PROXY, "true");
    >
    >             // Create service instance
    >             PlatformAdmin service = Platform.getPlatformAdmin();
    >
    >             IRemoteServiceRegistration reg =
    > adapter.registerRemoteService(new String[] { PlatformAdmin.class
    >                     .getName() }, service, props);
    >             System.out.println("Registered remote service
    server: "+reg);
    >         } catch (Exception e) {
    >             e.printStackTrace();
    >         }
    >     }
    >
    > The admin uses the normal contacts view, and has an action to
    use this
    > services when right-clicking on a bot. This is the code that
    tries to
    > connect to the PlatformAdmin service oof the selected bot:
    >
    > ID[] ids = new ID[] { entry.getUser().getID() };
    > IRemoteServiceContainerAdapter adapter =
    > (IRemoteServiceContainerAdapter)
    > container.getAdapter(IRemoteServiceContainerAdapter.class);
    > IRemoteServiceReference[] refs =
    > adapter.getRemoteServiceReferences(ids,
    PlatformAdmin.class.getName(),
    > null);
    >
    > But this always gives an empty array.

    Hmmm.  This looks right.  But one possibility...*when* is the line on
    the bot that runs:

    IRemoteServiceContainerAdapter adapter =
    (IRemoteServiceContainerAdapter)
    container.getAdapter(IRemoteServiceContainerAdapter.class);

    Invoked for the first time?  Is it just prior to the line above?

    Because the adapter is initialized for receiving the remote service
    registrations *when the
    container.getAdapter(IRemoteServiceContainerAdapter.class) is
    called for
    the first time*.  This is because the adapter manager (the way
    that the
    remote service container adapter is associated with the xmpp
    container),
    is lazy...and so the code that sets up to *receive* service
    registrations may not be getting called until after the service
    registration has already occurred.

    So if you could move the container.getAdapter call (in the client/bot)
    to either container creation time, or container connect time I think
    this might be solved.  If this turns out to be the case I will file a
    bug/enhancement request so that we can address it somehow in the
    underlying protocol so this isn't necessary.

    >
    > Is there something else I need to do to enable remote services
    on the
    > "client" side?

    I think this may be it...moving up the
    container.getAdapter(IRemoteServicesContainerAdapter.class) call to
    earlier in the sequence.

    BTW...also to be more like BundleContext.getServiceReferences, we've
    adjusted the adapter.getRemoteServiceReferences to return null instead
    of an empty array.  I prefer using empty arrays, but we are trying to
    make it as much like getServiceReferences as possible.

    Thanks.  Please let us know if this is the issue.

    Also...I happen to be working on a demo for using remote services to
    access the Equinox EnvironmentInfo service information.  Combined with
    the PlatformAdmin service this could be very interesting for providing
    remote support/problem diagnosis and repair.  Please let me know
    if you
    are interested in working on this in prep for EclipseCon (as I see you
    are providing remote access to PlatformAdmin...BTW...remember,
    that all
    method parameters and return values have to be Serializable to allow
    them to be sent over the wire...I'm not sure if this is true for
    PlatformAdmin's methods.

    If you are interested in looking at the examples work see these three
    plugins:

    <ecf
    root>/examples/plugins/org.eclipse.ecf.examples.remoteservices.common
    (defines IRemoteEnvironmentInfo interface)
    <ecf
    root>/examples/plugins/org.eclipse.ecf.exmaples.remoteservices.server
    (a
    very simple Equinox process that registers an impl of
    IRemoteEnvironmentInfo)
    <ecf
    root>/examples/plugins/org.eclipse.ecf.examples.remoteservices.client
    (a
    very simple client that uses the ECF discovery API to discover
    IRemoteEnvironmentInfo and then provides a serviceAccessHandler to
    hook
    into the service discovery view context menu...and allow the
    service to
    be connected to and then accessed via ECF IRemoteService methods
    (proxy,
    synch, asynch, future).

    I'll have a wiki page with screen shots of this tomorrow.  In the
    meantime, here's the code in the CVS browser:

    http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/examples/plugins/?root=Technology_Project

    Scott


    >
    > Regards,
    > Leen Toelen
    >
    >
    ------------------------------------------------------------------------
    >
    > _______________________________________________
    > ecf-dev mailing list
    > ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
    > https://dev.eclipse.org/mailman/listinfo/ecf-dev
    >

    _______________________________________________
    ecf-dev mailing list
    ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/ecf-dev


------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top