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
