Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » r-OSGI: Upgrading from ECF 3.4 to 3.10/11(Trying to make old code work again)
r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1711275] Wed, 14 October 2015 14:05 Go to next message
Lars Brenna is currently offline Lars BrennaFriend
Messages: 5
Registered: October 2015
Junior Member
Hi,

I have some really old code that's been running fine for 5 years but now I have to provide some new features. I figured that I would at the same time update external libraries such as the ECF provider library. However, the code breaks and I am not sure how to make something equivalent. The old code that breaks is the following:

Dictionary<String, Object> props = new Hashtable<String, Object>();
			props.put(Constants.SERVICE_REGISTRATION_TARGETS, _clientContainer
					.getConnectedID());
			props.put(Constants.AUTOREGISTER_REMOTE_PROXY, "true");
			Constants.
	
			callContainer.registerRemoteService(new String[] { ARTParameterService.class.getName() }, 
					(Object) _artParameter, props);
			theContext.registerService(ARTParameterService.class.getName(), _artParameter, new Hashtable<String,Object>());


The observant reader will see that the constant Constants.AUTOREGISTER_REMOTE_PROXY breaks, as it seems to have been removed from the library. I have not been able to figure out why and how to replace it.

Any hints or tips on how to make the above code run on ECF 3.10/11 are greatly appreciated!

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1711294 is a reply to message #1711275] Wed, 14 October 2015 16:08 Go to previous messageGo to next message
markus is currently offline markusFriend
Messages: 2
Registered: July 2009
Junior Member
On 14.10.2015 17:06, Lars Brenna wrote:
> Hi,
>
> I have some really old code that's been running fine for 5 years but now
> I have to provide some new features. I figured that I would at the same
> time update external libraries such as the ECF provider library.
> However, the code breaks and I am not sure how to make something
> equivalent. The old code that breaks is the following:
>
> Dictionary<String, Object> props = new Hashtable<String, Object>();
> props.put(Constants.SERVICE_REGISTRATION_TARGETS,
> _clientContainer
> .getConnectedID());
> props.put(Constants.AUTOREGISTER_REMOTE_PROXY, "true");
> Constants.
>
> callContainer.registerRemoteService(new String[] {
> ARTParameterService.class.getName() }, (Object)
> _artParameter, props);
>
> theContext.registerService(ARTParameterService.class.getName(),
> _artParameter, new Hashtable<String,Object>());
>
>
> The observant reader will see that the constant
> Constants.AUTOREGISTER_REMOTE_PROXY breaks, as it seems to have been
> removed from the library. I have not been able to figure out why and how
> to replace it.
>
> Any hints or tips on how to make the above code run on ECF 3.10/11 are
> greatly appreciated!
>
>

Hi Lars,

you will find more context with regards to the changes in the git commit
[1] that removes the constant (among others) and bug #334448 [2].

Cheers
M.

[1]
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/framework/bundles/org.eclipse.ecf.remoteservice/src/org/eclipse/ecf/remoteservice/Constants.java?id=ec9cb7618d514b0a6a4bc0d895ca622cf3305696
[2] https://bugs.eclipse.org/334448

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1711304 is a reply to message #1711275] Wed, 14 October 2015 18:53 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Lars,

Lars Brenna wrote on Wed, 14 October 2015 10:05
Hi,

I have some really old code that's been running fine for 5 years but now I have to provide some new features. I figured that I would at the same time update external libraries such as the ECF provider library. However, the code breaks and I am not sure how to make something equivalent. The old code that breaks is the following:

Dictionary<String, Object> props = new Hashtable<String, Object>();
			props.put(Constants.SERVICE_REGISTRATION_TARGETS, _clientContainer
					.getConnectedID());
			props.put(Constants.AUTOREGISTER_REMOTE_PROXY, "true");
			Constants.
	
			callContainer.registerRemoteService(new String[] { ARTParameterService.class.getName() }, 
					(Object) _artParameter, props);
			theContext.registerService(ARTParameterService.class.getName(), _artParameter, new Hashtable<String,Object>());


The observant reader will see that the constant Constants.AUTOREGISTER_REMOTE_PROXY breaks, as it seems to have been removed from the library. I have not been able to figure out why and how to replace it.

Any hints or tips on how to make the above code run on ECF 3.10/11 are greatly appreciated!



Marcus' links are quite correct, but I want to add a little explanation.

When registerRemoteService was called as above, on the remote client(s) a proxy would be created and registered. When we initially created this functionality, there was no specification from OSGi about how/when remote service proxies would be registered and so this property allowed ECF's implementation to do it in a non-standard way.

Now, however, there is the OSGi Remote Service Admin specification (chap 122 in the enterprise spec) that ECF implements. Part of that spec is a specification of the conditions under which a proxy is created, i.e. how it's discovered/created/registered locally, etc. To support the spec properly it was necessary to remove support for this constant.

I would recommend using the OSGi Remote Services approach...which actually makes it much easier IMHO...and does not require that your code call the ECF remote services API at all. Everything can/does happen as specfied by the RSA spec, and as implemented by the appropriate distribution provider (e.g. generic, rosgi, jms, etc...see https://wiki.eclipse.org/Distribution_Providers ). Here's a tutorial showing an example: https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service.

If you want to stay with the ECF remote services API yourself, and not move to OSGi Remote Services, then it would be possible register an IRemoteServiceListener and handle/respond to IRemoteServiceRegisteredEvents on clients by creating and registering a proxy of your own creation. This can/ get pretty complicated however (WRT classloading, versioning, etc), and so I recommend that you use RSA. If you would like more support on this method, however, I can provide it on ecf-dev mailing list: https://dev.eclipse.org/mailman/listinfo/ecf-dev or via direct communication at slewis at composent.com.

Thanks,

Scott

[Updated on: Wed, 14 October 2015 18:54]

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1711356 is a reply to message #1711304] Thu, 15 October 2015 09:46 Go to previous messageGo to next message
Lars Brenna is currently offline Lars BrennaFriend
Messages: 5
Registered: October 2015
Junior Member
Dear Marcus and Scott; thank you so much for your quick and well-thought through answers! They are much appreciated.

Scott; it sounds like there will be a bit of work required to move to the new way of doing things but it does sound like the RSA method is best for maintainability in the long run. I'll get back to you if I get into further trouble during the refactoring.

Thanks again!
Best regards,
Lars

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1711916 is a reply to message #1711356] Tue, 20 October 2015 09:56 Go to previous messageGo to next message
Lars Brenna is currently offline Lars BrennaFriend
Messages: 5
Registered: October 2015
Junior Member
Hi again,

I ran into another issue during my work. The ServiceTracker interface has changed quite a bit. In the old code it is used like this:

Declaration:
	private ServiceTracker _fileIdServiceTracker;


setContext(BundleContext theContext) :
	_fileIdServiceTracker = new ServiceTracker(_context, FileIdService.class.getName(), null);
       _fileIdServiceTracker.open();

and then:
	public FileIdService getFileIdService() throws BundleException {
		FileIdService service = null;
		try {
			if (_fileIdServiceTracker.getTrackingCount() <= 0) {
				String msg = "Could not find local service " + FileIdService.class.getName();
				_logger.error("getFileIdService() " + msg);
				throw new BundleException(msg);
			}
			service = (FileIdService) _fileIdServiceTracker.getService();
		} catch (NullPointerException e) {
			_logger.error("getFileIdService() NullPointerException: " + e.getMessage());
			throw e;
		}
		
		return service;
	}


Reading what I could find on the web (the forum doesn't allow me to post external links...) leaves me thinking that I could get away with simply adding type arguments to ServiceTracker<s, t> where s is the type of object/service being tracked and t the type of object being returned. However, it seems that in my case s and t are the same so I'm adding the same type argument twice, like this:
	private ServiceTracker<FileIdService, FileIdService> _fileIdServiceTracker;
	_fileIdServiceTracker = new ServiceTracker<FileIdService, FileIdService>(_context, FileIdService.class.getName(), null);


So my question is; does this look correct? It seems a bit funny to add the same type argument twice to ServiceTracker<s,t>...

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1712357 is a reply to message #1711916] Fri, 23 October 2015 09:24 Go to previous messageGo to next message
Lars Brenna is currently offline Lars BrennaFriend
Messages: 5
Registered: October 2015
Junior Member
I realize I might be talking to myself here, but giving it another try.
So I did what I posted above throughout the 20 plugin bundles I have, and it builds without errors. So far so good. However, I can't start the system (I'm using Eclipse Mars.1 by the way), and Eclipse throws a bunch of exceptions without pointing at my code or any of my settings. Googling these exceptions have not given any answers, the only thing I haven't tried is downgrading Eclipse to Luna. This is the console output: 
WARNING: Port 9278 already in use. This instance of R-OSGi is running on port 9279
***WARNING: Display must be created on main thread due to Cocoa restrictions.
!SESSION 2015-10-23 11:14:45.173 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_31
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=nb_NO
Framework arguments:  --os macosx
Command-line arguments:  -dev file:/Users/larsbrenna/Desktop/svn/PARS-Runtime/configuration/dev.properties --os macosx -ws cocoa -arch x86_64 -console -consoleLog

!ENTRY org.eclipse.ui.ide 4 0 2015-10-23 11:14:47.400
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start() of bundle org.eclipse.ui.ide.
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
	at org.eclipse.osgi.container.Module.doStart(Module.java:571)
	at org.eclipse.osgi.container.Module.start(Module.java:439)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Caused by: org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4491)
	at org.eclipse.swt.SWT.error(SWT.java:4406)
	at org.eclipse.swt.SWT.error(SWT.java:4377)
	at org.eclipse.swt.widgets.Display.error(Display.java:1097)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:848)
	at org.eclipse.swt.widgets.Display.create(Display.java:831)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:130)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:721)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:712)
	at org.eclipse.swt.widgets.Display.getDefault(Display.java:1427)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.createProblemsViews(IDEWorkbenchPlugin.java:388)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start(IDEWorkbenchPlugin.java:345)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
	... 12 more
Root exception:
org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4491)
	at org.eclipse.swt.SWT.error(SWT.java:4406)
	at org.eclipse.swt.SWT.error(SWT.java:4377)
	at org.eclipse.swt.widgets.Display.error(Display.java:1097)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:848)
	at org.eclipse.swt.widgets.Display.create(Display.java:831)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:130)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:721)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:712)
	at org.eclipse.swt.widgets.Display.getDefault(Display.java:1427)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.createProblemsViews(IDEWorkbenchPlugin.java:388)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start(IDEWorkbenchPlugin.java:345)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
	at org.eclipse.osgi.container.Module.doStart(Module.java:571)
	at org.eclipse.osgi.container.Module.start(Module.java:439)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://131.fwk346861221:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://131.fwk346861221:2/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See <SLFJ website url omitted> for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
log4j:WARN No appenders could be found for logger (org.eclipse.m2e.core.internal.project.registry.ProjectRegistryRefreshJob).
log4j:WARN Please initialize the log4j system properly.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://95.fwk346861221/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://95.fwk346861221:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See <SLFJ website url omitted> for an explanation.
2015-10-23 11:14:49,404 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:28) - ClientActivator() Default locale nb_NO changed to no_NO
2015-10-23 11:14:49,408 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:35) - start() [PARS-RichClient] Starting
2015-10-23 11:14:50,038 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:40) - start() [PARS-RichClient] Started successfully
osgi>

Report message to a moderator

Re: r-OSGI: Upgrading from ECF 3.4 to 3.10/11 [message #1718162 is a reply to message #1712357] Mon, 21 December 2015 00:03 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Lars Brenna wrote on Fri, 23 October 2015 05:24
I realize I might be talking to myself here, but giving it another try.
So I did what I posted above throughout the 20 plugin bundles I have, and it builds without errors. So far so good. However, I can't start the system (I'm using Eclipse Mars.1 by the way), and Eclipse throws a bunch of exceptions without pointing at my code or any of my settings. Googling these exceptions have not given any answers, the only thing I haven't tried is downgrading Eclipse to Luna. This is the console output: 
WARNING: Port 9278 already in use. This instance of R-OSGi is running on port 9279
***WARNING: Display must be created on main thread due to Cocoa restrictions.
!SESSION 2015-10-23 11:14:45.173 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_31
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=nb_NO
Framework arguments:  --os macosx
Command-line arguments:  -dev file:/Users/larsbrenna/Desktop/svn/PARS-Runtime/configuration/dev.properties --os macosx -ws cocoa -arch x86_64 -console -consoleLog

!ENTRY org.eclipse.ui.ide 4 0 2015-10-23 11:14:47.400
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start() of bundle org.eclipse.ui.ide.
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
	at org.eclipse.osgi.container.Module.doStart(Module.java:571)
	at org.eclipse.osgi.container.Module.start(Module.java:439)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Caused by: org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4491)
	at org.eclipse.swt.SWT.error(SWT.java:4406)
	at org.eclipse.swt.SWT.error(SWT.java:4377)
	at org.eclipse.swt.widgets.Display.error(Display.java:1097)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:848)
	at org.eclipse.swt.widgets.Display.create(Display.java:831)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:130)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:721)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:712)
	at org.eclipse.swt.widgets.Display.getDefault(Display.java:1427)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.createProblemsViews(IDEWorkbenchPlugin.java:388)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start(IDEWorkbenchPlugin.java:345)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
	... 12 more
Root exception:
org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4491)
	at org.eclipse.swt.SWT.error(SWT.java:4406)
	at org.eclipse.swt.SWT.error(SWT.java:4377)
	at org.eclipse.swt.widgets.Display.error(Display.java:1097)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:848)
	at org.eclipse.swt.widgets.Display.create(Display.java:831)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:130)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:721)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:712)
	at org.eclipse.swt.widgets.Display.getDefault(Display.java:1427)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.createProblemsViews(IDEWorkbenchPlugin.java:388)
	at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start(IDEWorkbenchPlugin.java:345)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
	at org.eclipse.osgi.container.Module.doStart(Module.java:571)
	at org.eclipse.osgi.container.Module.start(Module.java:439)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://131.fwk346861221:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://131.fwk346861221:2/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See <SLFJ website url omitted> for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
log4j:WARN No appenders could be found for logger (org.eclipse.m2e.core.internal.project.registry.ProjectRegistryRefreshJob).
log4j:WARN Please initialize the log4j system properly.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://95.fwk346861221/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://95.fwk346861221:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See <SLFJ website url omitted> for an explanation.
2015-10-23 11:14:49,404 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:28) - ClientActivator() Default locale nb_NO changed to no_NO
2015-10-23 11:14:49,408 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:35) - start() [PARS-RichClient] Starting
2015-10-23 11:14:50,038 [Start Level: Equinox Container: a048a780-6679-0015-10b8-91135119a1dc] DEBUG (ClientActivator.java:40) - start() [PARS-RichClient] Started successfully
osgi>


Hi Lars. Sorry I never responded to this previously, but your exceptions don't seem related at all to ECF Remote Services. Rather, these seem to be cause by some non SWT thread calling into SWT code. It seems to be an event handler thread.

Report message to a moderator

Previous Topic:Cannot connect to my Gmail or MSN accounts
Next Topic:Cannot connect to my Gmail or MSN accounts
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Apr 19 01:19:28 GMT 2024

Powered by FUDForum. Page generated in 0.02390 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly