Hi Felix,
On 10/26/2011 06:12 PM, Felix Meschberger wrote:
Hi Olaf,
Am 26.10.2011 um 18:01 schrieb Olaf Otto:
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)
This is key ! Components exposing a service are delayed by default -- thus only
instantiating them when they are used. So, unless you have some specific needs
to eagerly instantiate this service component, I suggest you leave it at the
default (delayed).
Yepp, setting immediate = true helps :-)
@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?
What exactly does not work ?
Don't the factory configurations cause components to be created ?
Or aren't the factory configurations editable in the Web Console ?
The factory configurations are created but do not cause a component to
be created. Also, they appear as "new / unbound" (which led me to assume
this may actually be the cause of the components not being instantiated).
If you can create the factory configurations but these are not bound the
fragment's host bundle but to the fragment, there is probably a bug. You can
check for the configuration binding in the web console -- you can also unbind
the configuration there (but you have to save the configuration again to have
them rebound if possible).
Well, unfortunately there is no unbind option in my console version (and
that is fixed to the product)
Anyway, regardless of whether your components are declared in a fragment or in
a regular bundle, they should always be supported by factory configuration and
configuration should probably always be bound to the host bundle and not the
fragment bundle because the components are registered through the host bundle's
context.
Yes, I think we have a bug here when declaring factory configs in
fragment bundles. I will cook up a test bundle and file an issue tomorrow.
Best,
Olaf
Regards
Felix
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]
---------------------------------------------------------------------
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]
