|Re: How to implement a new provider [message #623458 is a reply to message #623457]
||Wed, 09 April 2008 17:29
| Scott Lewis
Registered: July 2009
James Peltzer wrote:
> Is there any place where I can find information about implementing a new
> Information like:
> Interfaces I need to implement
> Extension Points I need to use
> What the interfaces are actually supposed to do
There is information about how to create a new IContainer type in the
first few sections of the ECF Archtectural Overview here
As a quick summary (I'm trying to work on a tutorial on exactly this
topic, but it's slow going with all the other commitments):
Necessary Extension points:
org.eclipse.ecf.namespace: This allows new providers to define a new
type of Namespace and ID. Extensions must create a class that extends
Namespace (and, of course overrides/implements appropriate methods).
org.eclipse.ecf.containerFactory: This allows new providers to define a
new IContainer implementation class (and any adapter interfaces). The
interface that must be implemented is
org.eclipse.ecf.IContainerInstantiator. Note there is also a utility
BaseContainerInstantiator class that can be used (in same package) if
These are the only two 'required' extension points to create an ECF
There is a trivial example provider implementation that implements these
two extension points called org.eclipse.ecf.examples.provider.trivial.
The project is located here in CVS:
You can browse the source via the web, if you wish, here:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/exa mples/plugins/org.eclipse.ecf.examples.provider.trivial/?roo t=Technology_Project
> The only part of ECF I care about is the remote services API and I don't
> really care if my provider is capable of anything outside of that scope.
Understood. So in addition to the above, you will need to implement
(via IContainer.getAdapter()) the IRemoteServiceContainerAdapter
interface. Since you don't want your provider to supply any other
functionality then you don't need/want to implement other providers.
> Also, if someone already has a SOAP provider implemented, I would really
> like to know so I can avoid re-inventing the wheel.
There is not any SOAP provider implemented that I know of...yet. We
would very much like to make one available though...would you consider
working with us and contributing/making the implementation available?
BTW, the Orbit project makes the Apache axis (v1.4) SOAP library
available as a bundle/bundles:
as well as some other libraries potentially useful/relevant to a ECF
remoteservices SOAP provider (org.apache.ws.*, jetty, etc). I don't
know what you have in mind WRT making the actual SOAP calls (Axis or
something else), but these may come in handy...they are already being
used, I believe, in WTP and perhaps STP and other Eclipse Foundation
projects. They have already been approved for use in Eclipse
Foundation/EPL projects so ECF's using them would be very easy.
Also, we now have an implementation of the ECF remote services API that
uses/is based upon r-OSGI (r-osgi.sourceforge.net). The provider
implementation is here:
This is not yet at Eclipse.org because we are waiting for IP approval,
which we expect to have within next week or so (and at that point it
will move to dev.eclipse.org). This provider was implemented by Jan
Rellermeyer, based upon his work on r-OSGi.
Also, I (Scott) am in the middle of using the Riena project
http://www.eclipse.org/riena to create a remote services provider that
uses Riena's RPC mechanism (JSON over http-based). This work is not yet
checked into the ECF codebase, but it will be over the next week.
We would love to have a SOAP-based ECF remote services provider
available, so if this is something you would consider please let us
know. Also, if you have any questions and/or suggested changes WRT the
ECF core APIs (namespace and/or IContainer) or the remote services API,
please do let us know...via this newsgroup, dev mailing list, and/or
bug/enhancement reports at bugs.eclipse.org.
Powered by FUDForum
. Page generated in 0.01683 seconds