Not sure if that is possible...

I think it would be awesome if the DS runtime could try to load the component class and if it fails because of an unwired package it could simply choose to not instantiate the component. It could also report this problem when you look into the components from the shell.

When the bundle is then refreshed later it could try the same again and maybe succeed if the package is wired now. The big advantage would be that the user would not have to code anything to make this work. Currently handling optional imports using an Activator is quite difficult and error prone.

Does that make sense?

Christian


On 26.04.2017 00:06, Raymond Auge wrote:
You're not far off,

but clearly the component could not be implementing the missing package...

Let's say we have an API:

interface com.foo.Provider {
    public void provide();
}

a bundle wants to provide an implementation of this API:

@Component
class FancyProviderImpl implements com.foo.Provider { ... }

However the goal of FancyProviderImpl is to deliver functionality by using fancy-lib.jar which is a second bundle.

e.g.

import fancy.lib.Thing;
@Component
class FancyProviderImpl implements com.foo.Provider {
    public void provide() {
        new Thing().doSomethingFancy();
    }
}

I'd like for the bundle containing FancyProviderImpl to have an optional import on `fancy.lib`, and not blow up when `fancy-lib.jar` is not deployed. Exactly the same scenario you mentioned with configAdmin, metatype and SCR.

I hope that makes sense,
- Ray


On Tue, Apr 25, 2017 at 5:51 PM, Felix Meschberger <fmesc...@adobe.com <mailto:fmesc...@adobe.com>> wrote:

    Hi Ray

    I am not sure, I understand the question.

    Are you asking that the component dynamically decides to register
    as a certain service depending on the whether a certain package is
    wired ?

    I think that does not work as the component implements an
    interface which is the service name and the component class can
    only be loaded if the class object representing the interface
    being implemented is accessible, otherwise a Linkage error occurrs.

    Or may I am on the wrong track alltogether.

    Regards
    Felix

    Am 25.04.2017 um 14:46 schrieb Raymond Auge
    <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>>:

    Thank you Felix, I agree and understand all of what you are saying.

    However, what I'm wondering though is if anyone has come up with
    a design pattern where a DS component can determine
    programmatically whether it (or a peer component it controls)
    should be provided as a service based on the check for some
    optional package.

    Sincerely,
    - Ray

    On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger
    <fmesc...@adobe.com <mailto:fmesc...@adobe.com>> wrote:

        Hi

        You mean dynamic imports due to optional dependencies ?

        I think the key is to limit them. If I remember correctly I
        have (or had) some of this in the Apache Felix SCR
        implementation around the Metatype and Configuration Admin
        dependencies.

        What I do is I hand-craft a DynamicImport-Package statement
        for the exact package along with the packages import version
        range. Then, unless the service is provided, the package may
        not be resolved.

        I generally also have fields, but as long as I don’t access
        that field other than checking for null, the dependency is
        not needed either.

        This works great, but I try to reduce such uses to the
        absolute minimum because it involves manual work.

        Hope this helps

        Regards
        Felix

        Am 25.04.2017 um 14:10 schrieb Raymond Auge
        <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>>:

        I'm wondering if there is a reasonable model for handling
        optional or dynamic package imports in DS.

        While optionality at the package level is not an ideal
        model, sometimes it can't be avoided.

        I'd like to know if others have come across a "reasonable"
        way to model this in DS.

        Sincerely,
-- *Raymond Augé*
        <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
        Senior Software Architect *Liferay, Inc.*
        <http://www.liferay.com/> (@Liferay)
        Board Member & EEG Co-Chair, OSGi Alliance
        <http://osgi.org/> (@OSGiAlliance)
        _______________________________________________
        OSGi Developer Mail List
        osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
        https://mail.osgi.org/mailman/listinfo/osgi-dev
        <https://mail.osgi.org/mailman/listinfo/osgi-dev>


        _______________________________________________
        OSGi Developer Mail List
        osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
        https://mail.osgi.org/mailman/listinfo/osgi-dev
        <https://mail.osgi.org/mailman/listinfo/osgi-dev>




-- *Raymond Augé*
    <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
    Senior Software Architect *Liferay, Inc.*
    <http://www.liferay.com/> (@Liferay)
    Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
    (@OSGiAlliance)
    _______________________________________________
    OSGi Developer Mail List
    osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
    https://mail.osgi.org/mailman/listinfo/osgi-dev
    <https://mail.osgi.org/mailman/listinfo/osgi-dev>


    _______________________________________________
    OSGi Developer Mail List
    osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
    https://mail.osgi.org/mailman/listinfo/osgi-dev
    <https://mail.osgi.org/mailman/listinfo/osgi-dev>




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)


_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to