Felix,
> On 17 Jun 2015, at 21:35, Felix Meschberger <[email protected]> wrote: > > Hi > > >> Am 17.06.2015 um 21:56 schrieb Neil Bartlett <[email protected] >> <mailto:[email protected]>>: >> >> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Wed, Jun 17, 2015 at 3:38 PM, BJ Hargrave <[email protected] >>> <mailto:[email protected]>> 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 >>> <tel:%2B1%20386%20848%201781> >>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >>> <tel:%2B1%20386%20848%203788> >>> [email protected] <mailto:[email protected]> >>> >>> >>> ----- Original message ----- >>> From: Raymond Auge <[email protected] >>> <mailto:[email protected]>> >>> Sent by: [email protected] >>> <mailto:[email protected]> >>> To: OSGi Developer Mail List <[email protected] >>> <mailto:[email protected]>> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <tel:%2B1%20386%20848%201781> >>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >>> <tel:%2B1%20386%20848%203788> >>> [email protected] <mailto:[email protected]> >>> >>> >>> ----- Original message ----- >>> From: Raymond Auge <[email protected] >>> <mailto:[email protected]>> >>> Sent by: [email protected] >>> <mailto:[email protected]> >>> To: OSGi Developer Mail List <[email protected] >>> <mailto:[email protected]>> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <tel:%2B1%20386%20848%201781> >>> OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 >>> <tel:%2B1%20386%20848%203788> >>> [email protected] <mailto:[email protected]> >>> >>> >>> ----- Original message ----- >>> From: Raymond Auge <[email protected] >>> <mailto:[email protected]>> >>> Sent by: [email protected] >>> <mailto:[email protected]> >>> To: OSGi Developer Mail List <[email protected] >>> <mailto:[email protected]>> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <tel:%2B1%20386%20848%201781> >>> OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 >>> <tel:%2B1%20386%20848%203788> >>> [email protected] <mailto:[email protected]> >>> >>> >>> ----- Original message ----- >>> From: Raymond Auge <[email protected] >>> <mailto:[email protected]>> >>> Sent by: [email protected] >>> <mailto:[email protected]> >>> To: OSGi Developer Mail List <[email protected] >>> <mailto:[email protected]>> >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <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 >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <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 >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <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 >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <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 >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > [email protected] <mailto:[email protected]> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
