felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: [VOTE] Apache Felix SCR Releases
Date Sun, 09 Aug 2015 17:12:20 GMT
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

    // 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.

david jencks

> On Aug 9, 2015, at 5:15 AM, Carsten Ziegeler <cziegeler@apache.org> 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
> cziegeler@apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message