felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4785) Incompatible SCR API
Date Mon, 16 Feb 2015 18:48:11 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323134#comment-14323134
] 

David Jencks commented on FELIX-4785:
-------------------------------------

I'm using ScrInfo service so I'll need to reimplement it.  What package name would you suggest?

-- I'm happy with Component#getComponentInstance returning null.  I don't think we should
ever have exposed this, and we can't stop too soon IMO
-- glad you figured out how to implement "isServiceFactory() :-)
-- I won't be using this ScrInfo service so don't care about it.  I think registering it is
fine.
-- OK about ScrInfo#config.... maybe hooking it up to the new ScrInfo I'm going to write would
also work?

I'm really not sure about your implementation of 
        public void enable()
        {
            this.runtime.enableComponent(this.description);
        }

        public void disable()
        {
            this.runtime.disableComponent(this.description);
        }

The original implementation operated, basically, on a Configuration not a Description.  I'm
not going to be using this but changing the scope of the operation seems like an incompatible
change to me.  I might rather have these no-ops.

> Incompatible SCR API
> --------------------
>
>                 Key: FELIX-4785
>                 URL: https://issues.apache.org/jira/browse/FELIX-4785
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: scr-2.0.0
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: scr-2.0.0
>
>
> Current trunk contains version 2.0.0 of the org.apache.felix.scr API package. While this
is a logical step, this makes the new implementation unusable as a drop-in replacement into
existing installations which might use the 1.x version of that API.
> I think we should go a more moderate way, leave the 1.x version in but deprecate it and
also provide the replacement API (if any). Then in one of the further versions along the road,
we can remove the API. This gives our users a chance to migrate slowly



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message