Re: [ecf-dev] migrating toward remote service admin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [ecf-dev] migrating toward remote service admin

From: Wim Jongman <wim.jongman@xxxxxxxxx>
Date: Wed, 12 Jan 2011 01:25:14 +0100
Delivered-to: ecf-dev@xxxxxxxxxxx
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dc+nELMDmgBTyZLK3SAqUYy4y7GX0sFLrm6uvthUUf4C4DMgg/7K/Q7BsbAHEk+zj1 IhtyULthD+e3/v8VrH+k6DxFwAc8wWh1jcW5JJWXNT0Dbm2wOf3q+2iP3gRDEjzdHsS7 Ah3onH/uHwC0nAZRetRaPImO/SJqB1+wr89OY=
List-archive: <https://dev.eclipse.org/mailman/private/ecf-dev>
List-help: <mailto:ecf-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/ecf-dev>, <mailto:ecf-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/ecf-dev>, <mailto:ecf-dev-request@eclipse.org?subject=unsubscribe>

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?

org.apache.zookeeper
org.ecf.examples.rsa.endpoint
org.eclipse.ecf
org.eclipse.ecf.discovery
org.eclipse.ecf.identity
org.eclipse.ecf.osgi.services.remoteserviceadmin
org.eclipse.ecf.provider
org.eclipse.ecf.provider.remoteservice
org.eclipse.ecf.provider.zookeeper
org.eclipse.ecf.remoteservice
org.eclipse.ecf.server.generic
org.eclipse.ecf.sharedobject
org.eclipse.ecf.tests
org.eclipse.ecf.tests.osgi.services.remoteserviceadmin
org.eclipse.ecf.tests.remoteservice
org.eclipse.ecf.tests.remoteservice.generic
org.eclipse.osgi.services.remoteserviceadmin

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


Regards,

Wim

junit.framework.AssertionFailedError: null
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.fail(Assert.java:53)
	at org.eclipse.ecf.tests.osgi.services.remoteserviceadmin.ServiceInfoFactoryTest.testCreateBadECFEndpointDescription(ServiceInfoFactoryTest.java:47)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:116)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.tigris.subversion.subclipse.tools.usage.reporting.UsageReport.askUser(UsageReport.java:69)
	at org.tigris.subversion.subclipse.tools.usage.reporting.UsageReport.access$2(UsageReport.java:65)
	at org.tigris.subversion.subclipse.tools.usage.reporting.UsageReport$AskUserJob.runInUIThread(UsageReport.java:174)
	at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:47)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1383)




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 example...security/permissions 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 discovery...so 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 providers...is 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 org.eclipse.ecf.osgi.services.discovery and/or
> org.eclipse.ecf.osgi.services.distribution 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] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>

Follow-Ups:
- Re: [ecf-dev] migrating toward remote service admin
  - From: Scott Lewis

References:
- [ecf-dev] migrating toward remote service admin
  - From: Scott Lewis

Prev by Date: Re: [ecf-dev] Intents in ECF
Next by Date: Re: [ecf-dev] migrating toward remote service admin
Previous by thread: Re: [ecf-dev] migrating toward remote service admin
Next by thread: Re: [ecf-dev] migrating toward remote service admin
Index(es):
- Date
- Thread

Breadcrumbs