I haven't ever built a wicket extender, but I did once make a contraption which automagically generated a REST interface based on information in the target bundle. In this case B registers servlets which will be picked up by C, so far so good, but these servlets result in calls to classes which are defined in A - to which B is not normally wired. So B has to do some fancy stuff to load those packages (using A's class loader), but this does not imply that the servlets themselves should be registered on behalf of A: the servlets do not expose any of A's packages in the interfaces they register with C.
> I agree with BJ. > > If the wicket extender were a wicket whiteboard, rather than an extender, > then I think we would expect it to track "wicket services" and then > register Servlet services using its own context as a result of finding > them. This is the same thing that lots of "adapter" bundles do. > > In the case of the wicket extender the only difference is how the wicket > object is obtained. Other than that it should behave in the same way as > the whiteboard version. > > Incidentally, it feels to me as if the wicket example would work better > with a whiteboard than an extender, as it would allow downstream service > dependencies for the wicket objects. I understand that it is only an > example though :) > > Tim > > Sent from my iPhone > >> On 18 Jun 2015, at 00:21, BJ Hargrave <hargr...@us.ibm.com> wrote: >> >> I think it should be B, the wicket extender, since it is B that >> actually is wired to the servlet package and it is B which actually >> implements the Servlet. C does not implement the Servlet and does not >> import the servlet package. It just contributes implementation detail to >> the Servlet created by B. >> >> -- >> >> 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 5:54 PM >> >> >> >> On Wed, Jun 17, 2015 at 5:48 PM, BJ Hargrave <hargr...@us.ibm.com> >> wrote: >> In this case B, the Wicket extender, must import the servlet package >> since it is making Servlet objects and registering them as Servlet >> services. It must use the same servlet package as A, the whiteboard >> impl, in order for A to understand the Servlet services. >> >> Ok, that's fine. Who's bundleContext should be used to register the >> service? >> >> >> -- >> >> 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 5:20 PM >> >> Haha, I think everyone is very close! But I will try very hard to be >> really really clear to the use case: >> >> Take Apache Wicket: >> >> https://wicket.apache.org/learn/examples/helloworld.html >> >> This frame work allows a developer to implement web applications without >> ever needing to touch the Servlet API. It's more like building native >> GUI building, except that it produces HTML. >> >> Most of the time you have to bundle all the framework jars (which >> contain the servlets). >> >> However, let's imagine that now the bundle with the wicket application >> only imports the wicket APIs (no framework jars, or servlet API). >> >> Now let's consider a Wicket extender. This bundle is the "wicket >> framework". It knows about how a wicket application should be >> bootstrapped. And it provides the concrete Servlet which exposes the >> application. >> >> Now the Wicket extender just wants to use the Http Whiteboard to >> register the wicket servlets. >> >> So, you have: >> >> A) the http whiteboard >> B) the Wicket Extender >> C) the Wicket application >> >> I can repeat this example many more times for many other web frameworks. >> >> - Ray >> >> On Wed, Jun 17, 2015 at 4:52 PM, Neil Bartlett <njbartl...@gmail.com> >> wrote: >> Felix, >> >> >>> On 17 Jun 2015, at 21:35, Felix Meschberger <fmesc...@adobe.com> wrote: >>> >>> Hi >>> >>> >>>> Am 17.06.2015 um 21:56 schrieb Neil Bartlett <njbartl...@gmail.com>: >>>> >>>> I think that B (the extender) must register the Servlet service using >>>> its own BundleContext, since it is the bundle that actually creates >>>> the Servlet objects. >>> >>> I donât think that works in general. And I actually think it is >>> wrong. >> >> No, I stand by it because your summary below doesnât match up with >> what Ray actually said. At least insofar as I have understood him >> correctly. >> >>> >>> >>> To repeat Rayâs example: >>> >>> (A) consumes a service, say javax.servlet.Servlet >>> (B) extends packages declaring something and registering services on >>> behalf of them >>> (C) declare something and provide the Servlets, hence implementations >>> of the javax.servlet.Servlet interface. >> >> Ray stated that the extended bundle C does NOT provide Servlets or know >> anything about Servlet API. It just creates these âwebby >> somethingsâ. >> >>> >>> >>> Now, C having the implementations implementing an interface *must* by >>> definition be wired to the service interface, otherwise the >>> implementations cannot be loaded by Câs class loader. And B must not >>> use its own (Bâs) class loader but must use Câs class loader to >>> load the implementations from C and use Câs bundle context to >>> register the service. B is only a messenger and Bâs bundle context >>> (and class loader) is never involved in this game. It cannot be >>> involved. Because it will, in general, never be able to load classes >>> from the extended bundle. >> >> Bâs classloader is involved because B makes the Servlet objects that >> wrap around whatever C provides. >> >> The way I understand this, C provides some kind of bean class, which may >> be a POJO. B instantiates that class (for this it would certainly have >> to use Câs classloader). It then creates a Servlet object that wraps >> around the POJO and forwards HTTP requests to it. >> >> Thus B registers the Servlet service using its own BundleContext. It >> imports javax.servlet, and the whiteboard will only pick up those >> Servlets if they comply with the same API version. >> >> >>> >>> >>> In any case for (A) to make normal use of the service provided by (C) >>> it must wire to the same service interface as (C) is wired to. Hence >>> (A) must not track all service references, hence using *false* on the >>> ServiceTracker to be able to make use of the Servlet service provided >>> by C (and instantiated and registered by B on behalf of C) >>> >>> This BTW actually *is* exactly the DS scenario, where the DS >>> implementation bundle would be B. The Http Service Whiteboard >>> implementation would be (A) and (C) is some bundle with a >>> Service-Components header. >> >> Well I disagree that itâs the same, for the reasons given above. So I >> guess Ray needs to come in here to clarify again. >> >>> >>> >>> >>>> >>>> Since the extended C bundle neither imports nor exports the Servlet >>>> API, *nobody* would be able to use its published Servlet services >>>> without doing trackAllServices=true. If you are required to turn on >>>> trackAllServices in your whiteboard bundle (A) then you are coupling >>>> that whiteboard to the implementation details of this service >>>> provider. All other potential consumers of your Servlet would have to >>>> do the same. >>>> >>>> The rule of thumb is that trackAllService is nearly always wrong >>>> unless you only need to inspect the metadata of a service without ever >>>> invoking it⦠for example if you are implementing a shell like Gogo. >>> >>> Agreed. There are some corner cases where trackAllServices makes sense, >>> but not in general (the Apache Aries JMX Whiteboard is another such use >>> case) >>> >>> Hope that helps more, than it confuses. >>> >>> Regards >>> Felix >>> >>> >>>> >>>> >>>> Regards, >>>> Neil >>>> >>>>> On 17 Jun 2015, at 20:47, Raymond Auge <raymond.a...@liferay.com> >>>>> wrote: >>>>> >>>>> >>>>> 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é (@rotty3000) >>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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 >>> _______________________________________________ >>> 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é (@rotty3000) >> Senior Software Architect Liferay, Inc. (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >> Senior Software Architect Liferay, Inc. (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance (@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 > _______________________________________________ > 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
