felix-dev mailing list archives

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

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

Carsten Ziegeler commented on FELIX-4785:
-----------------------------------------

I've now splitted this into a whole new bundle (scr-compat). This one registers the old ScrService
and the ScrInfo.
The scr bundle itself is now free from the org.apache.felix.scr package (which currently causes
the Aries bundle to fail therefore I disabled it for now).
As mentioned previously I think it makes sense to move the ScrInfo interface as well, if we
still think this is usefull, we can add a similar interface in a new package in the DS bundle.

With the implementation I see a couple of problems
- How should we implement Component#getComponentInstance ? Currently it simply returns null
- Component#isServiceFactory has no equivalent in the DTOs - should we simply return false?
- The ScrInfo service is now always registered regardless of a system property which was previously
used. I think as this is a compat bundle that's fine.
- The ScrInfo#config method can't get the configuration and therefore it does not print it
out

> 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