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
