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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <[email protected]>
>>> 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 <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <[email protected]> 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 <[email protected]>
>>>>> 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é* <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
>>>>> [email protected]
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OSGi Developer Mail List
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> [email protected]
>>>> 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)
>>>
>>
>>
>>
>> --
>> *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)
>>
>
>
>
> --
> *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)
>
--
*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
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
