Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <1964957460.1248791054808.JavaMail.jira@brutus>
Date: Tue, 28 Jul 2009 07:24:14 -0700 (PDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-1416) Wrong factory configuration
 behaviour
In-Reply-To: <1639214185.1248788596176.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Felix Meschberger commented on FELIX-1416:
------------------------------------------

Added unit and integration (Pax Exam based) tests for the fixed configuration behaviour in Rev. 798522

In Rev. 798529 adapted the ImmediateComponentManager to the new holder mechanism.

Rev. 798531 finally brings the big block of ComponentHolder and implementation.

The ComponentRegistry is refactored to be a factory for ComponentHolders and has no Configuration support. The ConfigurationComponentRegistry extends the ComponentRegistry adding support for Configuration from ConfigurationAdmin.

For ComponentFactory components the ComponentFactoryImpl also acts as the component holder. For Components without configuration (configuration-policy=ignore) UnconfiguredComponentHolder instances are used. This class is also used if no ConfigurationAdmin service is available.

For components taking configuration the ConfiguredComponentHolder class is used. This class can cope with singleton and factory configurations.

The Configuration policy "ignore" is handled by the ComponentRegistry in that an UnconfiguredComponentHolder is created to hold the component without ever forwarding configuration.

For Configuration policy "require" and "optional" a ConfiguredComponentHolder is used. The "require" policy is handled by the AbstractComponentManager to prevent activation if there is no configuration.

> Wrong factory configuration behaviour
> -------------------------------------
>
>                 Key: FELIX-1416
>                 URL: https://issues.apache.org/jira/browse/FELIX-1416
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR), Specification compliance
>    Affects Versions: scr-1.0.8
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: scr-1.2.0
>
>
> Currently factory configurations are applied to component factories, such that each factory configuration instance creates a componnent
> instances of a component factory. Reversly deleting a factory configuration also deletes component instances. This is not how it is specified.
> Correct is, that 
>   (1) Component Factories can only be configured with singleton configurations applying
>           the configuration to all instances created with newInstance
>   (2) Factory configurations are applied to non-component-factory components and
>           cause multiple component instances to be created.
> To accomodate for this, the handling of components has to be redesigned: A component descriptor now causes the creation of a ComponentHolder. Depending on configuration availability a ComponentHolder will hold a single component (no configuration or singleton configuration) or multiple components (factory configuration).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.