[
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)
