Hi, Smaller things first ... Will you create issues for them ?
Am 03.06.2012 um 20:21 schrieb David Jencks: > In other DS issues: > > I'd like to separate the felix specific non-spec ComponentFactory behavior > (where it acts like a ManagedServiceFactory) into a separate class so I can > understand the spec compliant behavior more easily. Basically this non-compliant behaviour is AFAICT only apparent in two methods. Not sure whether factoring this out is worth it. > > I think that the behavior of ServiceFactory components that are configured by > config admin is wrong. AFAICT for service factory components we will never > call a modify method but always destroy and recreate the instances. Right. Unlike other component managers updating configuration, ServiceFactory components may internally have more than one actual instance to update. The getInstance() method is not appropriate for this situation. We'd probably need new methods for this situation (or some more abstract mechanism) in the ImmediateComponentManager.modify(): (1) instead of the getInstance()==null check a method return true or false indicating whether modify makes sense. The ServiceFactoryComponentManager implementation returns true if at least one instance has been created (2) instead of directly calling the modify method (step 4) a method is implemented which is called by the ServiceFactoryComponentManager. > > I also have a few cleanup changes such as better javadoc and removing stray > references to no-longer-present *ing transient states that I don't think will > be controversial so I plan to just commit them. +1 Regards Felix
