Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 69AD2200B67 for ; Tue, 16 Aug 2016 13:57:25 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 682EF160A76; Tue, 16 Aug 2016 11:57:25 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B1C1B160AA8 for ; Tue, 16 Aug 2016 13:57:24 +0200 (CEST) Received: (qmail 11471 invoked by uid 500); 16 Aug 2016 11:57:23 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 11457 invoked by uid 99); 16 Aug 2016 11:57:23 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Aug 2016 11:57:23 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 8551B2C02A4 for ; Tue, 16 Aug 2016 11:57:22 +0000 (UTC) Date: Tue, 16 Aug 2016 11:57:22 +0000 (UTC) From: "Pierre De Rop (JIRA)" To: dev@felix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FELIX-5320) Dependency Manager: adapter service propagates adaptee properties *after* the init (and start) callbacks are called MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 16 Aug 2016 11:57:25 -0000 [ https://issues.apache.org/jira/browse/FELIX-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422636#comment-15422636 ] Pierre De Rop commented on FELIX-5320: -------------------------------------- Hello Andrea; You normally use an Adapter in order to create another component on top of an existing one. Typically, for example you want to create a management component (like a servlet, or an amdatu restful web service) on top of an existing service component. say you are developing a nosql database, and you have for instance a "MyNoSqlDatabase" service component: {code} dm.add(createComponent() .setImplementation(MyNoSqlDatabaseImpl.class) .setInterface(MyNoSqlDatabase.class.getName(), null)); {code} Now, assume you wan to make a restful web service which allows to administer your database. To do so, you wan to be modular and you want to make (for example) a jax rs web component, which would allow for example to display the number of transactions performed, or tune your nosql database from the web. So, you would in this case write an adapter component, like the following, which creates an amdatu web service component on top of the existing MyNoSqlDatabase service component: {code} dm.add(createAdapterService(MyNoSqlDatabase.class, null) .setImplementation(MyNoSqlDatabaseAdmin.class) .setInterface(Object.class.getName(), null)); {code} and your jax rs amdatu web service used to aminister your no sql database: {code} @Path("mynosql") class MyNoSqlDatabaseAdmin { volatile MyNoSqlDatabase database; // original database component, injected @GET @Produces("text/plain") public int transactions() { return database.getTransactions(); } } {code} I don't know if you need or not adapter, but let's assume that yes, you need an adapter. So, getting back to your initial question: your want to add a dynamic dependency for your adapter, based on the adaptee. So, in our example, the adaptee is "MyNoSqlDatabase". Now, assume that the MyNoSqlDatabase has some services properties. These service properties are by default propagated to the adaptee service properties (MyNoSqlDatabaseAdmin). Now, if you want to get access to the adaptee service properties, you can simply define a callback for the adaptee, instead of inject it in a compatible map field. And the callback may then use a signature which takes the adaptee, as well as a map for the adaptee service properties. You can then just keep the adaptee service properties and use it from your adapter init method in order to decide to add (or not) an additiona adapter dependency. let's see this a a concrete example. First, let's redefine the adapter Activator: {code} dm.add(createAdapterService(MyNoSqlDatabase.class, null, "setDatabase", null /* no change callback */, null /* no remove callback */) .setImplementation(MyNoSqlDatabaseAdmin.class) .setInterface(Object.class.getName(), null)); {code} and let's refactor the adapter with the "setDatabase" callback {code} @Path("mynosql") class MyNoSqlDatabaseAdmin { volatile MyNoSqlDatabase database; // original database component volatile Map databaseProperties; // original database service properties volatile SomeOtherService otherService; // dependency dynamically added from init method void setDatabase(MyNoSqlDatabase, Map properties) { this.database = database; this.databaseProperties = properties; } void init(Component comp) { // at this point, the database and database properties have been injected: then depending on the database service properties (which are by default // propagated to our adapter service properties), then possibly add one more service dependency: if (databasePropertiesRequiresAnotherDependency(this.databaseProperties)) { DependencyManager dm = c.getDependencyManager(); String filter = getFilter(databaseProperties); comp.add(dm.createServiceDependency().setService(SomeOtherService.class, filter).setRequired(true)); } } @GET @Produces("text/plain") public int transactions() { return database.getTransactions(); } } {code} so, in the above example, the database (adaptee) is injected using the setDatabase method and the service properties are kept in the "databaseProperties", which is then reused in the init method, in order to possibly add an extra dependency. Notice that if you don't need an adapter at all, you can do the same with a regular Component. does this help ? > Dependency Manager: adapter service propagates adaptee properties *after* the init (and start) callbacks are called > ------------------------------------------------------------------------------------------------------------------- > > Key: FELIX-5320 > URL: https://issues.apache.org/jira/browse/FELIX-5320 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Affects Versions: org.apache.felix.dependencymanager-r8 > Reporter: Andrea Leofreddi > > In an adapter service, created using the createAdapterService method of DependencyManager class, one would expect to find the adaptee's properties being propagated to the adapter service itself, as stated in the documentation (http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/component-adapter.html). > Instead no propagation happens, and both init and start methods won't see any propagated properties. > After investigating I've found that propagations indeed happens (via AdapterServiceImpl's propagateAdapteeProperties) only after the callbacks are called. -- This message was sent by Atlassian JIRA (v6.3.4#6332)