[
https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313420#comment-14313420
]
David Jencks commented on FELIX-4785:
-------------------------------------
>>Now, in addition, it seems 1.8.2 has some bugs that are fixed in 2.0.0 - (it
>>seems there are cases where a change to a factory config is not causing a
>>reactivation of the component); so again updating to get just that fix is not
>>possible.
The spec behavior is clearly wrong and caused by failure to notice that a
section needed to be updated for 1.1, but apparently we could only have the
correct behavior in 1.3 specced components. No one has objected in practice to
the correct but non-spec behavior that the last couple of releases have had.
If someone does we could release a 1.8.4 with just that fix. Actually from
your note it almost sounds like you would be ok with releasing 1.8.4 based on
our last release with this wrong spec-required behavior present and the old api
deprecated, and of course without any 1.3 features, and then as soon as the
spec is finalized releasing current trunk as 2.0.0. Since spec approval is
still some months off, we could do this easily and it would give users several
months of warning.
If you or someone wants to provide an additional bundle or fragment
implementing the old api in terms of DTOs I won't object as long as the current
behavior of the main bundle classes doesn't change. The two Items I am totally
against breaking to provide alleged compatible old behavior are:
1. The operations in the old api operate on the ComponentConfigurationDTO layer
whereas the operations in the spec api operate on the ComponentDescriptionDTO
layer. Providing operations that operate on the ComponentConfigurationDTO
layer is not acceptable, it cannot be made consistent with the spec API.
2. The component objects in the old api basically correspond to
ComponentConfigurationDTOs. However, since there is no
ComponentConfigurationDTO, a bogus ComponentConfigurationDTO-like-object is
provided whenever there is no actual ComponentConfigurationDTO, to represent
the ComponentDescriptionDTO. This is why a reimplementation of the old api
needs to use objects independent of the runtime classes (e.g.
SingleComponentManager which more or less corresponds to a
ComponentDescriptionDTO). We can't add a bogus ComponentManager in to
represent the missing object modeling the ComponentDescriptionDTO. However,
I'd be ok with an entirely new set of objects backing the old api, where the
"always present" component is constructed based on either the
ComponentDescriptionDTO (if there are no ComponentConfigurationDTOs) or the
"first" ComponentConfigurationDTO.
> 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)
