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 would handle the persistence, leaving all this complexity out of scr entirely. This would make something like the referenced adobe project work without the components starting first.
david jencks > On Mar 26, 2018, at 3:53 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > 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 component identifiers who's > value is enabled/disable (say bsn+component.name)? > > > On Mon, Mar 26, 2018 at 5:24 PM, David Jencks <david.a.jen...@gmail.com> > wrote: > >> Imnsho this might be needed only in case of terrible design. > > > Granted! I've come to the point in my career that arguments of "that's > terrible design" are pretty much microcosms of the whole software industry. > > >> 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. > > > If the component is standalone, then there's surely no issue! Just stop the > bundle (which is again persistent). > > >> Otherwise it has some references or dependencies so you can use its >> configuration to set them to nonexistent dependencies. >> > > This makes people look at me strangely when I suggest this approach (almost > every day). I really want to give them a more direct and explicit way to do > it because THIS approach leads to more maintenance issues over time than I > believe a left over disable component configuration every could. > > >> >> This all being said, although I’m still firmly opposed to scr itself >> having a persistence mechanism, I wouldn’t really object to a flag causing >> the initial state of all components to be disabled. An external helper >> service could then enable any whitelisted components at its whim. >> > > Could you imagine an IBM customer getting their shinny new Websphere > Liberty server up and having to individually enable the thousands of > components just so they can turn one off... 8| > > > >>> On Mar 26, 2018, at 2:50 PM, Roy Teeuwen <r...@teeuwen.be> wrote: >>> 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 >> disabling the component (of which we don't control the source code so we >> can't change the configuration). You then have to get the library owners to >> fix it, which sometimes takes weeks / months to release a hotfix for it. >> What would be so bad about creating something to manage this? >>> >>> [1] https://adobe-consulting-services.github.io/acs-aem- >> commons/features/osgi-disablers/component-disabler/index.html < >> https://adobe-consulting-services.github.io/acs-aem-commons/features/osgi- >> disablers/component-disabler/index.html> >> > > Hear, Hear!!! > > >>> >>> Greets, >>> Roy >>>> On 24 Mar 2018, at 10:36, Carsten Ziegeler <cziege...@apache.org> >> wrote: >> >>> 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. >> > > This is not a workable solution. What if you don't handle the packaging of > the artifacts? As a system administrator this is like asking to compile the > thing from source. > >>> David Jencks wrote >>>>> Could you describe the behavior you want in a little more detail? >> > > I need to disable an individual component in a bundle which has N > components and I cannot stop the bundle. > > >>>>> Is there a global switch to turn this on, or per bundle, or per >> component? >> > > Maybe? > > Maybe I need to opt in on SCR to say "Oh, btw, here's components that > please don't enable." > > That's what I'm asking anyway. > > >>>>> What happens when you upgrade a bundle to a new version? >> > > This is a good question! What happens with configuration in this scenario > today? It continues to work until the configuration is changed, or until > the configuration is not used by anyone! > > >>>>> How do you clear the slate and start over with no persisted enablement >> info? >> > > Remove the configuration property. > OR > Delete the configuration entirely. > > >>>>> How do you get a report of the enablement overrides? >> > > Look at the configuration dictionary? > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
