Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] migrating toward remote service admin

Hi Wim,

As fast as possible, I am working on completing some tasks to make this all easier...specifically, I'm doing the following:

1) Move the (and the osgi classes/bundle it depends upon) out of the incubation area and to it's 'final resting place' in the git repo...not sure where that is yet
2) Move the existing tests to their proper location (out of incubation)
3) Add some tests that I've been using locally for development/testing and haven't yet released to master
4) Setup some launch configs to be used for the build/automated testing

and then my intention is to

5) change over the and to then depend upon/use the

Once this is done, it should be possible to run all the existing test code with the new code, and have them all pass (as well as new tests that test the RSA stuff specifically).

So in the mean time/while I get the above done, I suggest getting/examining the source code from these projects:

osgi/bundles/ (OSGi 4.2 classes)

And take a look at the classes/implementation...and look at the spec.

I'll make announcements on the mailing list as I complete the tasks listed that people can use/refer to the new bundles (once they are in the proper locations).

My apologies that all that the repo, testing, and relneg is not done yet...but I'm only able to work on this sporadically.


On 1/11/2011 4:25 PM, Wim Jongman wrote:
Hi Scott,

I am looking at this but where to start? Can you provide some
jumpstart instructions? What would be the basic steps on the client
and the server to use this?

I have this initial set of bundles. Do you think this is enough?


Some of the tests fail in this setup [*].
When do the XML files come into the picture?



junit.framework.AssertionFailedError: null
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at junit.framework.TestCase.runTest(
	at junit.framework.TestCase.runBare(
	at junit.framework.TestResult$1.protect(
	at junit.framework.TestResult.runProtected(
	at junit.framework.TestSuite.runTest(
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(
	at org.eclipse.pde.internal.junit.runtime.UITestApplication$
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(
	at org.eclipse.swt.widgets.Display.runAsyncMessages(
	at org.eclipse.swt.widgets.Display.readAndDispatch(
	at org.eclipse.jface.window.Window.runEventLoop(
	at org.eclipse.ui.progress.UIJob$
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(
	at org.eclipse.swt.widgets.Display.runAsyncMessages(
	at org.eclipse.swt.widgets.Display.readAndDispatch(
	at org.eclipse.ui.internal.Workbench.runEventLoop(
	at org.eclipse.ui.internal.Workbench.runUI(
	at org.eclipse.ui.internal.Workbench.access$4(
	at org.eclipse.ui.internal.Workbench$
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(
	at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at org.eclipse.equinox.launcher.Main.invokeFramework(
	at org.eclipse.equinox.launcher.Main.basicRun(
	at org.eclipse.equinox.launcher.Main.main(

On Wed, Jan 5, 2011 at 7:08 PM, Scott Lewis<slewis@xxxxxxxxxxxxx>  wrote:
Hi Folks,

First, Happy New Year.

Over the past 4 months, in my off time I've been working on the ECF impl of
the OSGi 4.2 Remote Services Admin (RSA) specification.  Here [1] is the
enhancement request.

This implementation is now working, and nearing completion (see the bug[1]
for details and for access to source).  There still is plenty more to
do...including some simplification/refactoring, documentation, testing
against OSGi TCK, review, bug fixes, some amount of additional specified
behavior (for checks as per spec) and perhaps
some renaming of classes/interfaces for clarity.  With some assistance from
the other committers and contributors, I believe all of these things can be
completed for ECF 3.5 (end of Feb).

But, the impl *is* now fully working...for a simple topology manager that
duplicates the functionality of the basic remote services implementation
(part of the RSA spec is the ability for other TopologyManagers to be
created...that can handle more complex use cases for exporting and importing
remote services).  It uses ECF's discovery API for that *all*
ECF discovery providers are automatically supported (i.e. Zookeeper,
zeroconf, slp, dnssd, others), and *all* ECF remote services providers are
automatically supported (i.e. ECF generic, r-osgi, jms, javagroups, rest*,
xmpp, others).  This means that ECF consumers can now not only write their
own standard remote services...and be able to mix and match discovery and/or
distribution providers...but they can also customize and control the
distribution logic using the remote services admin specification...and also
mix and match discovery and/or distribution providers for their use case,
deployment environment (e.g. lan vs. wan), and security
requirements....using standardized RSA APIs.

IMHO this is pretty cool...because it gives consistency of remote services
and admin API through OSGi standardization, but still allows the flexibility
to use the protocols and associated providers that fit the particular use
case and deployment environment.

Further, since the ECF discovery and remote services API abstractions are
completely open...others are completely free to create their own discovery
and/or distribution implementations based upon whatever serialization and
wire protocol they prefer (e.g. Riena, xml-rpc, rest-based protocols,
proprietary/legacy systems, etc).  All such implementations will be usable
by the Remote Service Admin...since the RSA interacts only with the
discovery API and remote services API abstractions.  As far as I know...this
ability to use a single, standard impl of RS/RSA...with multiple discovery
and/or remote services unique to ECF's implementation.

One issue that I would like to discuss and get community feedback on is
this:  The new RSA implementation essentially makes obsolete the ECF 3.4
remote service implementation.  That is...all the functionality of the
existing remote services implementation is available via RSA, and RSA also
has other API for more complex use cases.  This brings up the issue of
migration...from the existing remote services impl to RSA.

The question is how to do such migration.  One approach would be to simply
start distributing RSA rather than the existing RS impl...but this would
create a problem for people updating from 3.4 to 3.5 (as they would then
have both active).  Another approach would be to modify/remove most of the
functionality in the existing RS bundles, and distribute new versions with
most of the functionality and API removed (obviously this would be a
breaking change for anyone that used the existing API...currently marked as
internal).  Just to be clear...any apps that use the OSSi 4.2 RS
specification only will migrate completely transparently...only apps that
use the and/or classes will be at issue for
migration to RSA.

I would like people to comment on the migration strategy that seems best to
them...and/or ask any questions that you might have.



ecf-dev mailing list

ecf-dev mailing list

Back to the top