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)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
