[
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 org.eclipse.ecf.osgi.services.remoteserviceadmin (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 org.eclipse.ecf.osgi.services.discovery and
org.eclipse.ecf.osgi.services.distribution to then depend upon/use the
org.eclipse.ecf.osgi.services.remoteserviceadmin
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/org.eclipse.osgi.services.remoteserviceadmin (OSGi 4.2
classes)
incubation/bundles/org.eclipse.ecf.osgi.services.remoteserviceadmin
incubation/bundles/org.eclipse.ecf.tests.osgi.services.remoteserviceadmin
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 above...so 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.
Scott
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?
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
