On 10/26/2011 03:20 PM, Olaf Otto wrote:
So, I've finally found the issue. With a regular OSGi bundle, the
following works:
@Service(MyService.class)
@Component(name = "com.acme.MyService",
label = "My Service",
metatype = true,
configurationFactory = true,
policy = ConfigurationPolicy.REQUIRE,
immediate = true)
@Properties({
@Property(name = "service.vendor", value = "Me"),
@Property(name = "service.description", value = "My Service
Description")
})
...
However I am building a fragment bundle. While normal SCR-based service
declarations work, factory services do not. It seems there is an issue
with configuration binding that prevents the new service configurations
from being bound and services from being instantiated. I would usually
expect the service configurations to be bound to the host bundle.
I've tested this by simply removing the "fragment-host" manifest entry;
in this case the factories work smoothly.
Is it possible to alter configuration binding? Is this a known issue?
Regards,
Olaf
Hi,
Thank you for the quick reply!
The factory configuration now shows up as expected - however it
appears I am still doing something wrong - the component is never
instantiated, the component class is not even loaded after I set the
property "policy" to ConfigurationPolicy.REQUIRE.
As far as I understand it now, a dedicated factory service is not
required at all. Instead, one simply defines configurationFactory =
true. I also suppose when I create a new configuration instance a
component instance should be created and activated, i.e. the @Activate
method should be called.
So, I must be doing something wrong here:
@Service(MyInterface.class)
@Component(label = "MyComponentfactory", metatype = true,
configurationFactory = true, policy = ConfigurationPolicy.REQUIRE)
@Properties({
@Property(name = "service.vendor", value = "My Company"),
@Property(name = "service.description", value = "MyComponent
factoryconfiguration")
})
public class MyComponent implements MyInterface {
@Property(value = "defaultValue", label = "Some property",
description = "replace me")
public static final String SOME_PROPERTY = "some.property";
@Activate
protected void start(ComponentContext context) {
...
}
}
Can someone spot the issue?
Thanks!
Olaf
PS:
I am using:
- declarative services 1.6.0
- config admin service 1.2.8
- felix framework 3.0.7
- maven-scr-plugin 1.7.0
- org.apache.felix.scr.annotations 1.5.0
On 10/25/2011 01:22 PM, Felix Meschberger wrote:
Hi,
Am 25.10.2011 um 13:13 schrieb Olaf Otto:
Hi,
I am trying to create a ManagedServiceFactory implementation and
have so
far failed to get it to work using SCR metadata. The plugin
documentation is somewhat confusing; is it impossible to use a dynamic
service declaration for a ManagedServiceFactory?
Yes, you have to set the configurationFactory attribute of the
@Component annotation to true. This will generate a Metatype
descriptor indicating factory configurations.
There is no need to implement the ManagedFactory interface. SCR will
create an instance of the component for each factory configuration
instance for you.
Regards
Felix
(http://felix.apache.org/site/apache-felix-maven-scr-plugin.html)
What I have is this
@Service(ManagedServiceFactory.class)
@Component(label = "Test service factory", metatype = true)
@Properties({
@Property(name = "service.pid", value =
"org.acme.FactoredType.factory")
})
public class TestServiceFactory implements ManagedServiceFactory {
@Property(value = "defaultValue")
public static final String SOME_PROPERTY = "someProperty";
// implementation...
}
However The service shows up like a regular Service in the felix config
admin. I can edit the @Property, and the config is persisted in the
admin service, however none of the implemented ManagedServiceFactory
methods get called. Do I need to use the factory... properties of the
@Component annotation? Is it necessary to manually register the
service?
Any hint is appreciated!
Thanks,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
