Since B is the one creating the service objects, B must be wired up to C in order to use the same runtime package. The fact that these objects are being created because of some magic cookies in A doesn't really change very much - B could as well register a servlice every time it receives a tweet with the hashtag #crackerjack. Or am I missing something?
> On Wed, Jun 17, 2015 at 3:38 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: > >> Well you were the one describing the scenario, I was trying to repeat >> what >> I thought you were saying :-) >> >> So C is a bundle which does not have any implementation of Servlet and >> does not import the servlet package and B will register a Servlet >> service, >> using C's bundle context, with some object implementing Servlet and B >> does >> not import the servlet package. >> >> How does B get an object implementing Servlet to register as the service >> since it has no wiring to any package containing Servlet? >> > > I never said that B doesn't know about Servlet... In fact I said exactly > that B knows about making Servlets. > > >> It seems odd that neither B or C is wired to the servlet package, yet >> they >> conspire to register a Servlet service. >> > > B should certainly be wired to the servlet package... and the same one as > the whiteboard. > > Let me try to clarify with a concrete example. > > There are many "webby" technologies in existence which remove the need for > a developer to have any knowledge of Servlet API. These technologies use > things like annotations or even simply pure packaging conventions for > describing their application. > > However, in the end, you need a servlet. Typically some framework looks at > the packaging convention and then reacts to that by creating a Servlet > which turns the convention into something concrete. > > In this scenario the original "bundle" doesn't know anything about > Servlet... BUT there is certainly a "concrete" servlet implementation > somewhere that knows about the convention. > > However, this concrete thing (the extender) wants to use the whiteboard > instead of handling all the HTTP stuff itself. > > the whiteboard knows nothing about this extender. > > > > >> >> -- >> >> 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 >> hargr...@us.ibm.com >> >> >> >> ----- Original message ----- >> From: Raymond Auge <raymond.a...@liferay.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> Cc: >> Subject: Re: [osgi-dev] whiteboard pattern & extenders >> Date: Wed, Jun 17, 2015 3:32 PM >> >> 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 <hargr...@us.ibm.com> >> 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 >> hargr...@us.ibm.com >> >> >> >> ----- Original message ----- >> From: Raymond Auge <raymond.a...@liferay.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> 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 <hargr...@us.ibm.com> >> 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 >> hargr...@us.ibm.com >> >> >> >> ----- Original message ----- >> From: Raymond Auge <raymond.a...@liferay.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> 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 <hargr...@us.ibm.com> >> 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 >> hargr...@us.ibm.com >> >> >> >> ----- Original message ----- >> From: Raymond Auge <raymond.a...@liferay.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> 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 >> 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) >> _______________________________________________ >> 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) > _______________________________________________ > 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
