You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2010/04/22 11:31:24 UTC
SCR/DS: ComponentFactory and the ConfigurationAdmin
When I started seriously doing OSGi last year, I've come to like
Declarative Services. I'm currently running an application in production
which consists of many such components. Some of them are factory
components. What I liked about them was that I could add a new
configuration via FileInstall's configuration file feature which would
give me a service for each configuration. Currently, I'm running an SCR
1.0.9.SNAPSHOT which basically works fine but shows problems on startup
in that it often does not enable all components properly (an admin
nuisance, but not a big one since the application can easily run for
months without a restart even with the occasional update of a bundle).
Still, I want to get rid of that problem.
So I upgraded to Karaf 1.4 and SCR 1.4.1, but I had to realize that
SCR 1.0.9 seemed to contain a bug which I seem to have made use of.
Right now, my component configurations in ConfigAdmin don't result in
services being registered. Only if I set "ds.factory.enabled=true" do I
get my desired functionality back. I've read back and forth in the DS
spec but I find it extremely difficult to understand. In the end, I'm
clueless whether what I want is actually possible (as per the DS spec)
without making the component implement ManagedServiceFactory which would
make my components more complicated. Without the non-standard setting
above, I just get a ComponentFactory registered, but I don't really want
to instantiate each component through method calls.
I'd appreciate some clues on this issue.
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR/DS: ComponentFactory and the ConfigurationAdmin
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thank you, Felix. That did help! I've got it working now, although
without Maven (I'm one of those evil Maven-haters). I've added the
factoryPid to the Designate in the MetaType info and removed the
"factory" attribute in the component description and suddenly, it clicks
together. I'm off now cleaning up my code and documenting this as a blog
entry as I'm sure other people have had similar problems in the past.
Thanks again!
On 22.04.2010 11:59:24 Felix Meschberger wrote:
> Hi Jeremias,
>
> You are right, versions before 1.4 contained this "feature" which was
> not specification compliant. The actual wording is Section 112.7,
> Deployment (page 328 in the R4.2 compendium release):
>
> A factory configuration must not be used if the component is a
> factory component. This is because SCR is not free to create
> component configurations as necessary to support multiple
> Configurations. When SCR detects this condition, it must log
> an error message with the Log Service, if present, and
> ignore the component description.
>
> This wrong behaviour has been fixed in 1.4, but the ds.factory.enabled
> allows for support for use cases where this wrong behaviour is still
> expected.
>
> If you only need the automatic creation of component instances based on
> factory configuration, you might be better of turning your factory
> components into regular components and have SCR create the components
> from the factory configurations.
>
> If you are using the Maven SCR Plugin, you might want to use the latest
> version and set the following properties in the @scr.component tag:
>
> configurationFactory="true" policy="require"
>
> For the @Component annotation this would be
>
> getConfigurationFactory=true policy=ConfigurationPolicy.REQUIRE
>
> This generates the Metatype descriptions such that the configurations
> are marked as factory configurations.
>
> Hope this helps.
>
> Regards
> Felix
>
> On 22.04.2010 11:31, Jeremias Maerki wrote:
> > When I started seriously doing OSGi last year, I've come to like
> > Declarative Services. I'm currently running an application in production
> > which consists of many such components. Some of them are factory
> > components. What I liked about them was that I could add a new
> > configuration via FileInstall's configuration file feature which would
> > give me a service for each configuration. Currently, I'm running an SCR
> > 1.0.9.SNAPSHOT which basically works fine but shows problems on startup
> > in that it often does not enable all components properly (an admin
> > nuisance, but not a big one since the application can easily run for
> > months without a restart even with the occasional update of a bundle).
> > Still, I want to get rid of that problem.
> >
> > So I upgraded to Karaf 1.4 and SCR 1.4.1, but I had to realize that
> > SCR 1.0.9 seemed to contain a bug which I seem to have made use of.
> > Right now, my component configurations in ConfigAdmin don't result in
> > services being registered. Only if I set "ds.factory.enabled=true" do I
> > get my desired functionality back. I've read back and forth in the DS
> > spec but I find it extremely difficult to understand. In the end, I'm
> > clueless whether what I want is actually possible (as per the DS spec)
> > without making the component implement ManagedServiceFactory which would
> > make my components more complicated. Without the non-standard setting
> > above, I just get a ComponentFactory registered, but I don't really want
> > to instantiate each component through method calls.
> >
> > I'd appreciate some clues on this issue.
> >
> > Thanks,
> > Jeremias Maerki
> >
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR/DS: ComponentFactory and the ConfigurationAdmin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jeremias,
You are right, versions before 1.4 contained this "feature" which was
not specification compliant. The actual wording is Section 112.7,
Deployment (page 328 in the R4.2 compendium release):
A factory configuration must not be used if the component is a
factory component. This is because SCR is not free to create
component configurations as necessary to support multiple
Configurations. When SCR detects this condition, it must log
an error message with the Log Service, if present, and
ignore the component description.
This wrong behaviour has been fixed in 1.4, but the ds.factory.enabled
allows for support for use cases where this wrong behaviour is still
expected.
If you only need the automatic creation of component instances based on
factory configuration, you might be better of turning your factory
components into regular components and have SCR create the components
from the factory configurations.
If you are using the Maven SCR Plugin, you might want to use the latest
version and set the following properties in the @scr.component tag:
configurationFactory="true" policy="require"
For the @Component annotation this would be
getConfigurationFactory=true policy=ConfigurationPolicy.REQUIRE
This generates the Metatype descriptions such that the configurations
are marked as factory configurations.
Hope this helps.
Regards
Felix
On 22.04.2010 11:31, Jeremias Maerki wrote:
> When I started seriously doing OSGi last year, I've come to like
> Declarative Services. I'm currently running an application in production
> which consists of many such components. Some of them are factory
> components. What I liked about them was that I could add a new
> configuration via FileInstall's configuration file feature which would
> give me a service for each configuration. Currently, I'm running an SCR
> 1.0.9.SNAPSHOT which basically works fine but shows problems on startup
> in that it often does not enable all components properly (an admin
> nuisance, but not a big one since the application can easily run for
> months without a restart even with the occasional update of a bundle).
> Still, I want to get rid of that problem.
>
> So I upgraded to Karaf 1.4 and SCR 1.4.1, but I had to realize that
> SCR 1.0.9 seemed to contain a bug which I seem to have made use of.
> Right now, my component configurations in ConfigAdmin don't result in
> services being registered. Only if I set "ds.factory.enabled=true" do I
> get my desired functionality back. I've read back and forth in the DS
> spec but I find it extremely difficult to understand. In the end, I'm
> clueless whether what I want is actually possible (as per the DS spec)
> without making the component implement ManagedServiceFactory which would
> make my components more complicated. Without the non-standard setting
> above, I just get a ComponentFactory registered, but I don't really want
> to instantiate each component through method calls.
>
> I'd appreciate some clues on this issue.
>
> Thanks,
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org