You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Mark Derricutt <ma...@talios.com> on 2009/09/04 06:14:13 UTC
Configuration changes leaves components unsatisfied/deactivated..
Hey all,
I'm seeing some strange behavior and thought I'd ask here about it before
raising a ticket on JIRA.
I have two SCR components A and B, B has a 1..1 mandatory service reference
to A (and other services).
When I deactivate A, I see B also get deactivated - all good.
When I reactivate A, I see B get reactivate - all good.
When I change A's configuration (via the web console), B becomes unsatisfied
- bad :(
How come I'm seeing this behaviour? I would have expected to see B
momentarily deactivate/reactivate as A changes its configuration, not
deactivate and sit at 'unsatisfied'?
Strangely, if I look at the bound services via the web console, I can see
that each reference is currently bound.
I'm currently running:
org.apache.felix.bundlerepository - 1.2.1
org.osgi.core - 1.2.0
org.osgi.compendium - 1.2.0
org.apache.felix.framework - 1.2.2
org.apache.felix.main - 1.2.2
org.apache.felix.webconsole - 1.0.0
org.apache.felix.eventadmin - 1.0.0
org.apache.felix.scr - 1.0.8
org.apache.felix.configadmin - 1.0.10
org.apache.felix.metatype - 1.0.2
Am I seeing something wrong with Felix/OSGi or is it more likely my
understanding thats off? Hopefully once we get over a current piece of work
we can upgrade our base system so we can move to Felix 1.8, thou it'd be
nice to know if this is a me of felix issues.
Cheers,
Mark
--
Pull me down under...
Re: Configuration changes leaves components unsatisfied/deactivated..
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Mark,
Sorry for the delay ... this seems to have slipped my radar
However,
Mark Derricutt schrieb:
> Anyone have any idea why trunk of SCR would start causing the below error
> message when starting Apache Sling? As mentioned in the previous email, the
> code throwing the exception seems to have been introduced as part of FELIX-1416
> to src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java:273
> - is this likely a bug now in SCR or in Sling?
This is a dependency of Sling on wrong SCR implementation in Apache
Felix. Namely previsouly Felix SCR supported creating component
instances of ComponentFactory's by configuring factory configurations.
This is in fact explicitly forbidden by the spec.
With FELIX-1416 I have removed this support by default. It can still be
enabled by setting
ds.factory.enabled = true
in the sling.properties file.
As soon as the scr plugin vote has passed, we will update the Sling
embedded repository bundle to use SCR correctly.
Sorry for the confusion
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configuration changes leaves components unsatisfied/deactivated..
Posted by Mark Derricutt <ma...@talios.com>.
Anyone have any idea why trunk of SCR would start causing the below error
message when starting Apache Sling? As mentioned in the previous email, the
code throwing the exception seems to have been introduced as part of FELIX-1416
to src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java:273
- is this likely a bug now in SCR or in Sling?
--
Pull me down under...
On Wed, Sep 9, 2009 at 10:27 AM, Mark Derricutt <ma...@talios.com> wrote:
> 09.09.2009 10:07:06.009 *ERROR* [FelixStartLevel]
> org.apache.sling.jcr.jackrabbit.server
> [org.apache.sling.jcr.jackrabbit.server.SlingServerRepository] Component
> Factory cannot be configured by factory configuration
>
Re: Configuration changes leaves components unsatisfied/deactivated..
Posted by Mark Derricutt <ma...@talios.com>.
Hi Felix,
I pulled out the svn trunk and built up 1.0.9-SNAPSHOT and that solved my
various problems with my components not reactivating, however it seems to
have triggered a problem starting sling 2.0.2-incubator, in my logs I see:
09.09.2009 10:07:06.009 *ERROR* [FelixStartLevel]
org.apache.sling.jcr.jackrabbit.server
[org.apache.sling.jcr.jackrabbit.server.SlingServerRepository] Component
Factory cannot be configured by factory configuration
This is being thrown
by src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java:273
- looks like this change came as a result of FELIX-1416 based on commit
logs.
--
Pull me down under...
On Fri, Sep 4, 2009 at 5:56 PM, Felix Meschberger <fm...@gmail.com>wrote:
> If you would upgrade to a trunk build of SCR, this should be fixed.
>
Re: Configuration changes leaves components unsatisfied/deactivated..
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Mark,
You have probably hit FELIX-1445 [1].
If you would upgrade to a trunk build of SCR, this should be fixed.
Regards
Felix
[1] https://issues.apache.org/jira/browse/FELIX-1445
Mark Derricutt schrieb:
> Hey all,
>
> I'm seeing some strange behavior and thought I'd ask here about it before
> raising a ticket on JIRA.
>
> I have two SCR components A and B, B has a 1..1 mandatory service reference
> to A (and other services).
>
> When I deactivate A, I see B also get deactivated - all good.
> When I reactivate A, I see B get reactivate - all good.
> When I change A's configuration (via the web console), B becomes unsatisfied
> - bad :(
>
> How come I'm seeing this behaviour? I would have expected to see B
> momentarily deactivate/reactivate as A changes its configuration, not
> deactivate and sit at 'unsatisfied'?
>
> Strangely, if I look at the bound services via the web console, I can see
> that each reference is currently bound.
>
> I'm currently running:
>
> org.apache.felix.bundlerepository - 1.2.1
> org.osgi.core - 1.2.0
> org.osgi.compendium - 1.2.0
> org.apache.felix.framework - 1.2.2
> org.apache.felix.main - 1.2.2
> org.apache.felix.webconsole - 1.0.0
> org.apache.felix.eventadmin - 1.0.0
> org.apache.felix.scr - 1.0.8
> org.apache.felix.configadmin - 1.0.10
> org.apache.felix.metatype - 1.0.2
>
> Am I seeing something wrong with Felix/OSGi or is it more likely my
> understanding thats off? Hopefully once we get over a current piece of work
> we can upgrade our base system so we can move to Felix 1.8, thou it'd be
> nice to know if this is a me of felix issues.
>
> Cheers,
> Mark
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org