On Fri, Jun 19, 2015 at 6:16 AM, Peter Kriens <peter.kri...@aqute.biz>
wrote:
> I got quite confused by this discussion :-( and that makes it likely that
> more people are.
>
> Original question: when to track all References?
>
> Rule 1: never. The only exception is when you’re doing something really
> special and want to bypass the type system. This implies that you’re NOT
> bound to the tracked type.
>
Great! I'm clear on this point! I will never use it!.
> Rule2: very rare, when tracking properties of the service are ok, looking
> in its bundle might also work, but annotations would not work because to
> work with the annotations you must be in the same class space for the
> annotation packages. Basically if you track all references, everything is
> an Object.
>
> That said, I think there is a bit of confusion about class space
> compatibility. The spec does not define compatibility, it defines
> *incompatibility*. Bundles are incompatible when they would see more than
> one exporter for a package taking the transitive closure of uses into
> account. So if either bundle has no import of a package, then they are by
> definition not incompatible.
>
> A: extendee
> B: extender, will call A.register(foo.Foo), imports={foo}
> C: tracker for Foo, exports={foo}
>
> a) A.imports={}, so Foo is not incompatible for A.
> b) A.imports={foo}, A, C, and B must be in the same class space for foo
>
>
So this explanation seems to indicate that there should be no with what we
attempted!
The scenario as described is EXACTLY what we are doing. However, the
tracker in C fails to track the service of A (registered by B as
A.register(foo.Foo))
It fails because equinox's FiltereServiceListener (as ServiceTracker
registers a ServiceListener) does the following:
if (allservices || ServiceRegistry.isAssignableTo(context, reference)) {
....
}
The call to ServiceRegistry.isAssignableTo(context, reference) fails when
context (A) does not import package of reference ("foo")
Is this a bug?
> As you should be able to see, if you just do the right thing (track only
> your visible references) things work safely out of the box and you do not
> have to do anything special.
>
> So the remaining problematic scenario is when you want handle the case
> where you have A.imports={foo} and A’s import is bound to a bundle D:
>
>
> In this case, A & B are not in the same class space so B should NOT extend
> A. This allows having multiple versions of A,B, and C. B could use A’s
> bundle to load Foo, however, now C cannot see it (X2). It could use its own
> version but then will get an error when registering it (X1). So you could
> now make C track all services but then you get Foo objects that are not Foo
> objects to you, so you need to handle them reflectively which utterly sucks
> and implies you no longer have type safety. An easier solution is then to
> not import foo, then you can see every object of the foo package.
>
> Anyway, the moment you start to try to handle these cases your code will
> balloon wildly out of proportions and become utterly unreadable. This
> rarely worth it in my opinion because if you don’t want type safety, go to
> Javascript.
>
> Kind regards,
>
> Peter Kriens
>
> On 18 jun. 2015, at 21:46, chris.g...@kiffer.be wrote:
>
> 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
>
>
>
> _______________________________________________
> 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
