Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Message-ID: <7491480.1173183984372.JavaMail.root@brutus>
Date: Tue, 6 Mar 2007 04:26:24 -0800 (PST)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: felix-dev@incubator.apache.org
Subject: [jira] Updated: (FELIX-243) Add support for ServiceFactory
 components
In-Reply-To: <19715195.1173179904830.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Felix Meschberger updated FELIX-243:
------------------------------------

    Attachment: FELIX-243_2.diff

Modified patch to reduce code duplication in the Delayed*ServiceFactory classes.

> Add support for ServiceFactory components
> -----------------------------------------
>
>                 Key: FELIX-243
>                 URL: https://issues.apache.org/jira/browse/FELIX-243
>             Project: Felix
>          Issue Type: Improvement
>          Components: Declarative Services
>         Environment: Felix SCR trunk Rev. 515074
>            Reporter: Felix Meschberger
>         Attachments: FELIX-243.diff, FELIX-243_2.diff
>
>
> Currently the SCR bundle only supports delayed components but not ServiceFactory components. That is the servicefactory attribute of the <service> element is in fact ignored. Another issue is, that for each bundle using a delayed component which is NOT a ServiceFactory a new instance of the component is created.
> Attaching a patch which solves the issues as follows:
>    * Creates a new inner DelayedServiceFactoryServiceFactory (name is more functional than beautiful) class which supports for ServiceFactory components. Each call to the getService method creates a new instance of the component. The m_implementationObject is never set in this case. The ComponentContext used to call the activate method is kept in an map to use the same ComponentContext to call deactivate when the service is released through the ungetService method.
>    * Modified DelayedComponentServiceFactory.getService method to return the m_implementationObject if not null. Otherwise the m_implementationObject is created, bound, activated and returned. The ungetService method is just enhanced with a comment indicating that the delayed component is only deactivated when the component is deactivated. The ComponentContext created by the getService method has the owner bundle field set to null as there is only really a single Component instance shared by all bundles.
>    * Modified the invokeBindMethod and invokeUnbindMethods to take the object on which to call the method as a parameter. This accomodates for the DelayedServiceFactoryServiceFactory which never sets the m_implementationObject field.

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