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