Actually Chris is correct in describing the scenario and BJ you are not
correct.

C) is some bundle which has a header "ImCool: oh so cool!"
B) is an extender which makes servlets from the header "ImCool" IT knows
how to make a Servlet service.
A) is the whiteboard


This doesn't work because C) does not import Servlet.

- Ray

On Wed, Jun 17, 2015 at 3:24 PM, BJ Hargrave <[email protected]> wrote:

> OK.
>
> So A, the whiteboard impl, has ServiceTrackers and must care about the
> specific package.
>
> B is the extends which registers the services. It has no ServiceTrackers
> and does not care about the package since it does not use the package
> itself.
>
> C also must care about the same package as A (so they are type compatible).
>
> So there is not bundle which both is the extender and registers the
> services and also has ServiceTrackers which must care about the specific
> package. Therefore trackAllServices=true is not needed.
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> [email protected]
>
>
>
> ----- Original message -----
> From: Raymond Auge <[email protected]>
> Sent by: [email protected]
> To: OSGi Developer Mail List <[email protected]>
> Cc:
> Subject: Re: [osgi-dev] whiteboard pattern & extenders
> Date: Wed, Jun 17, 2015 2:55 PM
>
>
>
> On Wed, Jun 17, 2015 at 2:44 PM, BJ Hargrave <[email protected]> wrote:
>
> So this is like DS (an extender) registering Servlet services on behalf of
> a bundle using DS. Then of course the extender bundle does not care about
> the servlet package but also the extender bundle is not using
> ServiceTrackers to track the Servlet services. That is done by the Http
> Whiteboard impl bundle which does care about the servlet package and its
> version.
>
>
> I'm sorry but you've lost me, and DS isn't an example of the scenario
> because the DS bundle is itself tracker in this scenario.
>
> In the scenario I'm describing there are 3 bundles in play:
>
> A) the whiteboard bundle (has the trackers)
> B) an extender which registers services that the whiteboard
> C) a bundle which is being extended by B) but doesn't know anything about
> A) or the API it's being extended with
>
> Sincerely,
> - Ray
>
>
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788
> [email protected]
>
>
>
> ----- Original message -----
> From: Raymond Auge <[email protected]>
> Sent by: [email protected]
> To: OSGi Developer Mail List <[email protected]>
> Cc:
> Subject: Re: [osgi-dev] whiteboard pattern & extenders
> Date: Wed, Jun 17, 2015 2:23 PM
>
> But an extender who registers services to a whiteboard impl on behalf of
> extendee will result in those services not being visible to the whiteboard
> if the extendee does not import the packages used by the services?
>
> On Wed, Jun 17, 2015 at 2:16 PM, BJ Hargrave <[email protected]> wrote:
>
> Well whiteboard and extenders are different.
>
> Whiteboard should not use true since it cares about the specific API
> package version.
>
> Extenders should use BundleTrackers rather than ServiceTrackers since they
> are not using whiteboard services.
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788
> [email protected]
>
>
>
> ----- Original message -----
> From: Raymond Auge <[email protected]>
> Sent by: [email protected]
> To: OSGi Developer Mail List <[email protected]>
> Cc:
> Subject: [osgi-dev] whiteboard pattern & extenders
> Date: Wed, Jun 17, 2015 2:12 PM
>
> When implementing a whiteboard pattern should we always open trackers
> using the trackAllServices = true ? via:
>
> ServiceTracker.open(true);
>
> It would seem that this is the only way that we can support extenders
> where the extendee has no knowledge of the APIs in question, correct?
>
> --
> *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)
> _______________________________________________
> 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

Reply via email to