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 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.
> Thanks,
> Scott
> [1]
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx

Back to the top