Hi Christian, Per my original email, there are some limitations of the require policy. Further it seems to me that this is a bit of a mix of concerns. It shouldn't be ConfigAdmin's job to enable/disable components and, in point of fact, that isn't actually what the require policy does. It marks a component as "unsatified" which is not semantically the same as "disabled" (even if the result is the same).
Regards, Justin On Mon, Feb 15, 2016 at 11:11 AM Justin Edelson <jus...@justinedelson.com> wrote: > Hi, > Responses are inline. > > On Mon, Feb 15, 2016 at 10:52 AM BJ Hargrave <hargr...@us.ibm.com> wrote: > >> DS is already declarative. What additional declarations are you thinking >> of? >> > > Alex and I are looking for a declaration which would augment the existing > declarations which we have found are not sufficient for the use cases > outlined. > > >> Where would a "deployment' declaration come from? If the deployment >> declaration disabled a component, how would the component later become >> enabled? >> > > TBD. That's the point of this thread -- to discuss possible options. > > >> Through API calls? >> > > This is already possible, but as I wrote, is IMHO subpar because it isn't > declarative. > > >> How would the deployer create and deploy deployment declarations? >> > > Again, TBD. I can propose a strawman, but was hoping to hear more about > other potential use cases. > > >> >> I am a bit confused as to how you think this would work. >> >> It seems to me the best way for the deployer to "disable" a component is >> to not install or start the bundle holding the component if the component >> is not relevant to the system. Remember, the set of installed/started >> bundles is a significant part of the "configuration" of a system and the >> deployer is in complete control over the set of installed/started bundles. >> > > This is a fair point. It happens to not work for our application, but I > can certainly accept that that is due to to packaging decisions we have > made in the past. > > I'd still be curious if Alex and I are the only ones who have this issue. > I find that a bit hard to believe, but perhaps it is in fact the case. > > Regards, > Justin > > >> >> I think the best solution is to properly partition the components into >> bundles such the deployer can decide whether to install and/or start a >> certain bundle holding the components that should or should not be enabled. >> >> -- >> >> BJ Hargrave >> Senior Technical Staff Member, IBM // office: +1 386 848 1781 >> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >> hargr...@us.ibm.com >> >> >> >> ----- Original message ----- >> From: Justin Edelson <jus...@justinedelson.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> Cc: >> Subject: [osgi-dev] Declarative disabling of a DS component >> Date: Thu, Feb 11, 2016 12:53 PM >> >> Hi, >> I see a real need in the DS specification for a standardized way to >> declaratively disable DS components by default *at deploy time* whereas the >> current model (please correct me if I'm wrong) only allows for components >> to be disabled by default at packaging time. >> >> The primary use case I'm concerned about is where we provide an >> OSGi-based application which gets deployed into a variety of environments >> (I'm speaking specifically about Adobe Experience Manager, but I don't >> believe that this problem is necessarily specific to our product), some of >> which are managed by us and others are managed by our customers. The >> application is composed of thousands of DS components. In a variety of >> cases, the manager of the deployment environment (I'll call them the >> "deployer" below) may wish to disable some of these DS components. >> >> I'm aware of three ways to do this, all of which are problematic for one >> reason or another. >> >> * Use the require configuration policy >> -- If the component developer requires a configuration policy, then in >> theory the deployer could disable a component by deleting the corresponding >> configuration. The problem here is that we don't want a deployer to delete >> one of our standard configurations. Should they want to reenable the >> component in the future, they would have to have a backup of the >> configuration something which seems error prone. It is also likely (and >> this may be specific to our application) that when a new version is >> deployed, a new configuration would be deployed and the component would be >> reenabled. >> >> * Use the SCR API to disable the component >> -- This almost works :) It, however, isn't declarative -- you have to >> write code which uses this API. And it is a bit tricky because disabling a >> component isn't stateful, i.e. restarting the SCR implementation bundle >> will automatically restart any manually disabled components. >> >> * Implement a custom component.enabled configuration property and read it >> in the activate method. >> -- This actually works perfectly but is non-standard and requires that >> every component developer explicitly support this. And it is also >> fundamentally wrong -- what we want is to disable the component. If you use >> this technique the component is actually activated, it just isn't >> functional. Which means that referring components still get the "disabled" >> component. >> >> I'm curious if others have similar requirements, if there are options I >> haven't considered, and whether or not the OSGi EG has any plans to provide >> native support for declarative disabling of components. >> >> Best regards, >> Justin Edelson >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
