[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Remote OSGI services over XMPP
|
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.
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?
Regards,
Leen
On Feb 7, 2008 7:37 AM, Scott Lewis <
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.
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
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
