Ok, perhaps you didn’t get the point of my proposal, which is that there could
be a scr management agent that is in control of enabling whichever components
you want; I called this a whiltelist, but it could just as well be defined by
“everything except this blacklist”. The point is this agent
In my original request the expression "persistent" was intended to be used
rather loosely, and perhaps I should have really said "configuration"
(which is itself persistent).
What if the "enabled" flag was configurable (i.e. through configuration
admin)?
What if SCR's own configuration could hold
Sent from my iPhone
Imnsho this might be needed only in case of terrible design. If a component is
quite standalone I’d expect it to be in its own bundle, do can not install the
bundle if you don’t like it. Otherwise it has some references or dependencies
so you can use its configuration to
Hey all,
I too have used a tool more than once to disable a component [1], most of the
time because built in components of a system you don't have under control are
doing unexpected behaviour (like throwing nullpointer exceptions / errors /
...) and we are not able to solve this unless by
I tend to agreee, requiring a config is usually the way we solve it.
You could also simply repackage the bundle and simply change the
component XML inside. This gives you full control. Can be easily done by
a tool.
Regards
Carsten
David Jencks wrote
> Could you describe the behavior you want in
Hello All,
I know this topic has come up many different times.
I'd like to request support for persistent component state (i.e.
persistently enable/disable) components.
I've created an issue for it
https://issues.apache.org/jira/browse/FELIX-5817
I will also try in the next while to implement
