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é* <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
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> 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
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> 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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to