DS adds a component.name property to each component's properties. You 
control the component name. So you can find a service with the 
component.name you control.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge <raymond.a...@liferay.com>
To:     OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Date:   2015/03/08 12:48
Subject:        Re: [osgi-dev] getting a service filtered on my bundleId
Sent by:        osgi-dev-boun...@mail.osgi.org



I come up with:

    @Activate
    protected void activate(BundleContext bundleContext) {
        Bundle bundle = bundleContext.getBundle();

        _bundleId = bundle.getBundleId();
    }

    @Reference(
        cardinality = ReferenceCardinality.AT_LEAST_ONE,
        policy = ReferencePolicy.DYNAMIC,
        policyOption = ReferencePolicyOption.GREEDY
    )
    protected void setServletContext(
        ServletContext servletContext, Map<String, Object> properties) {

        long serviceBundleId = MapUtil.getLong(properties, 
"service.bundleid");

        if (serviceBundleId == _bundleId) {
            _servletContext = servletContext;
        }
    }

    private long _bundleId;
    private volatile ServletContext _servletContext;

Man that's ugly!
I think I prefer:

    @Activate
    protected void activate(BundleContext bundleContext)
        throws InvalidSyntaxException {

        Bundle bundle = bundleContext.getBundle();

        Filter filter = bundleContext.createFilter(
            "(&(objectClass=" + ServletContext.class.getName() +
                ")(service.bundleid=" + bundle.getBundleId() + "))");

        _serviceTracker = new ServiceTracker<ServletContext, 
ServletContext>(
            bundleContext, filter, null);

        _serviceTracker.open();
    }

    @Deactivate
    protected void deactivate() {
        _serviceTracker.close();
    }

    private ServiceTracker<ServletContext, ServletContext> 
_serviceTracker;

But I really wish I could do:

    @Reference(target = "(service.bundleid=${bundle.id})")
    protected void setServletContext(ServletContext servletContext) {
        _servletContext = servletContext;
    }

    private volatile ServletContext _servletContext;



On Sun, Mar 8, 2015 at 12:17 PM, Raymond Auge <raymond.a...@liferay.com> 
wrote:
.. pray there isn't multi version, or mutli-instance support for this type 
of extender.

On Sun, Mar 8, 2015 at 12:08 PM, Raymond Auge <raymond.a...@liferay.com> 
wrote:
Tim and Neil,

Are you both suggesting that it's better to do the following?

The manifest file contains:

Web-ContextPath: /blah


The component contains:

@Reference(target = "(osgi.web.contextpath=/blah)")
protected void setServletContext(ServletContext servletContext) { ... }


On Sun, Mar 8, 2015 at 12:02 PM, Raymond Auge <raymond.a...@liferay.com> 
wrote:


On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <njbartl...@gmail.com> 
wrote:
Ray, to quote two sentences from your email:

* "I want the thing that was built for me specifically”
* "I never talked about coupling providers to consumers.”

These two statements are in direct contradiction with each other!

If there is coupling, it's coupling I specifically want, and it lives 
inside my bundle! So what's the issue?
 

To be honest this doesn’t sound like a job for the service registry, but 
instead Java’s “new” keyword…

You've missed the point! It's someone else who already created the thing I 
need! However, it still belongs to me!

Please see my examples.
 

Neil


On 8 Mar 2015, at 15:38, Raymond Auge <raymond.a...@liferay.com> wrote:



On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <tim.w...@paremus.com> wrote:
Hi Ray,

Using the bundle id feels more like a workaround for a missing feature of 
the extender. 

Wouldn't it make more sense for the metadata processed by the extender 
publish a property to filter on, and/or to have the service published by 
the extender respond to config admin in the same way that DS components 
do?

If, for example, the extendee asked for the property 
"mySuperCoolProperty=awesome" to be applied to the extender registered 
service then that could be used in the filter.

that won't work because neither do you know the value of the property at 
build time, nor in this case do you want to change the value during 
configuration. I want the thing that was built for me specifically... the 
only unique value that I know about is bundleId.
 
Ideally the target filter would be set using config admin to maximise the 
reusability of the bundle (for example in an environment without the 
extender where another service should be used).

Config admin implies human responsibility and in this case I don't want 
humans involved.

I can create a contrived example of this using current OSGi pieces.

I have a bundle, it uses both gemini blueprint and DS.

How can I tell the DS component to get my instance of 
org.springframework.context.ConfigurableApplicationContext? I can't 
without manually implementing a ServiceTracker because the only bits I can 
filter on are things you can't know at XML creation time or that you'd 
never want to duplicate from the manifest.

 

One of the best things about the service registry is decoupling the 
provider from the consumer. I'd try very hard to avoid breaking that.

I never talked about coupling providers to consumers.
 

Regards,

Tim



Sent from my iPhone

On 8 Mar 2015, at 14:49, Raymond Auge <raymond.a...@liferay.com> wrote:

Hey all,

I have a need for a component to get a service created on behalf of the 
bundle by an extender. There are many such services in the system so what 
I really need is to get a bundle with a filter like so:

        Filter filter = bundleContext.createFilter(
            "(&(objectClass=" + ExtenderCreatedService.class.getName() +
                ")(service.bundleid=" + bundle.getBundleId() + "))");

i.e. get the one created which has my bundleId.

Is there any trick to doing this besides a ServiceTracker which the 
component must manually create and start?

Note the component can't know it's own bundleId at the time of generating 
the XML.

Is there any property parsing happening in the component XML files or 
anything?

-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


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



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Reply via email to