I’ve done enough stress testing now so I’m OK with the functionality. I still
haven’t had a chance to investigate the bug Pierre found but I don’t regard it
as a showstopper at this point.
I don’t see that the changelog has been updated to include anything since 1.8.2.
Is everyone happy with the next release being with the bndtools infrastructure
replacing the maven infrastructure?
I’m not sure that everyone is fully aware of the felix-spscific extensions I
made and is happy with the names I gave them to turn them on.
You can turn on all the extensions using namespaces attributes in the
component.xml; the configuration property approach still works for the old ones
but I don’t recommend it as it produces global settings.
// Namespace URI of Felix DS extensions 1.0
public static final String NAMESPACE_URI_1_0_FELIX_EXTENSIONS =
"http://felix.apache.org/xmlns/scr/extensions/v1.0.0";;
//extension features
public static final String CONFIGURABLE_SERVICE_PROPERTIES =
"configurableServiceProperties”;
This is the feature that apparently only I use where lifecycle and event
methods can return the new service property map; previously enabled using the
custom 1.2-felix namespace.
public static final String PERSISTENT_FACTORY_COMPONENT =
"persistentFactoryComponent”;
(new behavior) This is a modified kind of factory component that makes some
sense :-). The lifecycle of such a factory component is just like a normal
component, it doesn’t disappear permanently at the slightest provocation, but
can come and go as needed.
public static final String DELETE_CALLS_MODIFY = "deleteCallsModify”;
(new behavior) This makes the sensible ds 1.3 behavior happen for pre-1.3
components; when you delete a configuration that otherwise would not cause the
component to be deactivated, modify is called as one would expect rather than
deactivating and reactivating the component.
public static final String OBSOLETE_FACTORY_COMPONENT_FACTORY =
"obsoleteFactoryComponentFactory”;
This is the incompatible with 1.3 behavior where you can make a factory
component act sort of like a normal component configured with a factory
pid/configuration. Now available per-component.
public static final String CONFIGURE_WITH_INTERFACES =
"configureWithInterfaces”;
(new behavior) This lets you use interfaces along with annotations as
configuration holders in lifecycle methods. In addition, it allows nested
interfaces and annotations, e.g. an annotation with an annotation member type.
The configuration property map for this must be encoded where the path to the
value is encode in the key, and each “leaf” value appearing in a nested member
has it’s own key. IIUC Peter Kriens thinks this is the wrong approach and the
keys should be the top-level interface members and the values json-encoded
strings. I disagree but am willing to implement both when I have a little more
time. I expect the decoding logic can figure out which encoding is in use by
looking at the key.
public static final String DELAYED_KEEP_INSTANCES = "delayedKeepInstances”;
This makes a delayed component exposing a service stick around even when all
its’ users have ungot the service. Now available per-component.
I might be able to update the changelog later today or tomorrow. I’m inclined
to think we should fix it for the release. I would like some indication that
everyone is OK with the flags and behaviors they control before we release, as
there wasn’t much discussion when I put them in.
thanks
david jencks
> On Aug 9, 2015, at 5:15 AM, Carsten Ziegeler <[email protected]> wrote:
>
> Am 07.08.15 um 17:50 schrieb David Jencks:
>> I’m still testing this.
>
> We've been testing this and couldn't find a regression compared to the
> latest 1.8.x release. I think we shouldn't block this vote. If we find
> an issue we can easily do a 2.0.2 release.
>
>>
>> One possible missing bit is that I haven’t yet written a bnd meta-annotation
>> for the felix ds custom flags. I guess this class should end up in it’s own
>> project? Does anyone have a suggestion for a package name and project name?
>
> I guess an own project sounds good, we already have a bnd project which
> supports processing of the Apache Felix DS annotations. We could either
> add this class there or add something next to it
>
> Carsten
>
>>
>> Also Pierre may have found a bug in circular reference handling, although I
>> haven’t been able to reproduce it.
>> https://issues.apache.org/jira/browse/FELIX-4984
>> <https://issues.apache.org/jira/browse/FELIX-4984>
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]
