Community
Participate
Working Groups
org.eclipse.core.jobs activator declares an OSGi service. We could move that to an declarative OSGi service. This would also allow removing the PROP_REGISTER_JOB_SERVICE property as the service would only be started if requested (lazy).
Matthias, something for you to practice your new OSGi ds skills?
(In reply to Lars Vogel from comment #1) > Matthias, something for you to practice your new OSGi ds skills? Please be careful. That affects startup and lot of code run jobs on startup.
(In reply to Andrey Loskutov from comment #2) > (In reply to Lars Vogel from comment #1) > > Matthias, something for you to practice your new OSGi ds skills? > > Please be careful. That affects startup and lot of code run jobs on startup. Andrey, that exactly should one take care of here?
(In reply to Matthias Becker from comment #3) > Andrey, that exactly should one take care of here? I think Andrey wanted to point out that is should still work after the change. ;-)
(In reply to Lars Vogel from comment #4) > (In reply to Matthias Becker from comment #3) > > Andrey, that exactly should one take care of here? > > I think Andrey wanted to point out that is should still work after the > change. ;-) ;-)
I see two services that are registered: - IJobManager (in JobActivator#registerService) - DebugOptionsListener (in JobOSGiUtils#openServices)
New Gerrit change created: https://git.eclipse.org/r/130154
I uploaded a work in progress change for this. I tried in a first step to replace one of the services with the following component xml file: <?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"> <service> <provide interface="org.eclipse.core.runtime.jobs.IJobManager"/> </service> <implementation class="org.eclipse.core.internal.jobs.JobManager"/> </scr:component> the OSGI console says the following after this change: {org.eclipse.core.runtime.jobs.IJobManager}={service.id=92, service.bundleid=641, service.scope=bundle, component.name=org.eclipse.core.internal.jobs.JobManager, component.id=48} but it was {org.eclipse.core.runtime.jobs.IJobManager}={service.id=107, service.bundleid=95, service.scope=singleton} before this change when I add the service.scope=singleton to the xml I get the following error at startup: org.osgi.service.component.ComponentException: Component org.eclipse.core.internal.jobs.JobManager validation failed: service scope can only be specified in version 1.3 and later What do we do with that?
Just guessing: The ServiceScope is annotated with "since 1.3" https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/ServiceScope.html Your component description is using an 1.1.0 namespace: http://www.osgi.org/xmlns/scr/v1.1.0 There is no "scope" defined in there, but it is here: http://www.osgi.org/xmlns/scr/v1.3.0
(In reply to Karsten Thoms from comment #9) > Just guessing: > > The ServiceScope is annotated with "since 1.3" > https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/ > annotations/ServiceScope.html > > Your component description is using an 1.1.0 namespace: > http://www.osgi.org/xmlns/scr/v1.1.0 > > There is no "scope" defined in there, but it is here: > http://www.osgi.org/xmlns/scr/v1.3.0 so I just change my namespace to 1.3.0 ?
I don't really know, you could try that. I just saw that service.singleton will only be supported in the other namespace. I'm not an expert in this field.
(In reply to Karsten Thoms from comment #11) > I don't really know, you could try that. I just saw that service.singleton > will only be supported in the other namespace. I'm not an expert in this > field. I changed the namespace to 1.3 in patchset 2 of my change, but still I don't get the service running with the correct scope. The OSGI console still says: "scope=bundle". What am I doing wrong?
But you don't get the error 'service scope can only be specified in version 1.3 and later' anymore?
(In reply to Karsten Thoms from comment #13) > But you don't get the error 'service scope can only be specified in version > 1.3 and later' anymore? I don't get that anymore, correct.
Adding Dirk into CC, as the is an OSGI expert. @Dirk: Can you give a hint here, was I am doing wrong?
(In reply to Matthias Becker from comment #15) > Adding Dirk into CC, as the is an OSGI expert. > > @Dirk: Can you give a hint here, was I am doing wrong? I talked with Dirk about this in EclipseCon and he plans to have a look. It is not as easy as I imaged as the JobManager provides static accessor methods.
(In reply to Lars Vogel from comment #16) > (In reply to Matthias Becker from comment #15) > > Adding Dirk into CC, as the is an OSGI expert. > > > > @Dirk: Can you give a hint here, was I am doing wrong? > > I talked with Dirk about this in EclipseCon and he plans to have a look. It > is not as easy as I imaged as the JobManager provides static accessor > methods. Okay. Thanks for the help. Let's see what Dirk will find out.
Alex, can you have a look? I think this might be a wontfix, as replacement seem to be very complex.
I'll take a look.
