I think it's all clear now! Sincerely, - Ray
On Wed, Jun 17, 2015 at 4:03 PM, <chris.g...@kiffer.be> wrote: > 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 > -- *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
