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é* <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 > > _______________________________________________ > 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
