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] [Updated] (FELIX-3536) Consider putting the non-spec ComponentFactory behavior in a separate class
Date Tue, 05 Jun 2012 01:45:22 GMT

     [ https://issues.apache.org/jira/browse/FELIX-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

David Jencks updated FELIX-3536:

    Attachment: FELIX-3536.diff

Suggestion on how to split spec and non-spec behavior to make it clearer what is required
for spec behavior.  Also includes determining which state is the satsified state by returning
from the class rather than using a switch statement, which is a separate change.
> Consider putting the non-spec ComponentFactory behavior in a separate class
> ---------------------------------------------------------------------------
>                 Key: FELIX-3536
>                 URL: https://issues.apache.org/jira/browse/FELIX-3536
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.8.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: scr-1.8.0
>         Attachments: FELIX-3536.diff
> I personally find it pretty confusing to figure out which parts of CompnentFactoryImpl
relate to the spec behavior and which relate to the non-spec ManagedServiceFactory-like backwards
compatible behavior enabled with the "ds.factory.enabled" configuration flag.  I'd like to
suggest putting the non-spec behavior in a separate class, see patch.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message