Re: [osgi-dev] whiteboard pattern extenders
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. 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
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
Re: [osgi-dev] whiteboard pattern extenders
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?
ServiceRegistry.isAssignableTo(context, reference) seems to be doing its job.
This method performs the following checks:
1. Get the package name from the specified class name.
2. For the bundle that registered the service referenced by this
ServiceReference (registrant bundle); find the source for the package.
If no source is found then return true if the registrant bundle is
equal to the specified bundle; otherwise return false.
Ding! No source is found for the package for A, and A != B.
So the question is whether ServiceRegistry.isAssignableTo(context,
reference) is a necessary condition for ServiceTracker. As I understand
Peter's post, it is too narrow a constraint because it excludes the
(unusual) case where no source for the package is found in 'context'.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] whiteboard pattern extenders
I haven't ever built 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
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
I think it's all clear now! Sincerely, - Ray On Wed, Jun 17, 2015 at 4:03 PM, chris.g...@kiffer.be wrote: Since B is the one creating the service objects, B must be wired up to C in order to use the same runtime package. The fact that these objects are being created because of some magic cookies in A doesn't really change very much - B could as well register a servlice every time it receives a tweet with the hashtag #crackerjack. Or am I missing something? 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
Re: [osgi-dev] whiteboard pattern extenders
If you want to pick up services that implement the Servlet interface, you should use false as you want to pick up only those services that wire to the same javax.servlet package (otherwise you would get a class cast exception). If you want to pick up services based on their annotations or service properties (not really caring what interfaces they implement), you should use true. *Zsoldos Balázs* Rendszertervező | Software architect +36 70 594 9234 | balazs.zsol...@everit.biz *EverIT Kft.* 1137 Budapest, Katona József utca 17. III. em. 2. http://www.everit.biz I i...@everit.biz Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. This message and any attachment are confidential and are legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Please note that any dissemination, distribution, copying or use of or reliance upon the information contained in and transmitted with this e-mail by or to anyone other than the recipient designated above by the sender is unauthorised and strictly prohibited. On Wed, Jun 17, 2015 at 8:12 PM, Raymond Auge raymond.a...@liferay.com wrote: 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
Re: [osgi-dev] whiteboard pattern extenders
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. 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. 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 mailto: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 tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 tel:%2B1%20386%20848%203788 hargr...@us.ibm.com mailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto: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 mailto: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 tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 tel:%2B1%20386%20848%203788 hargr...@us.ibm.com mailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto: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
Re: [osgi-dev] whiteboard pattern extenders
Now I'm the one that's lost, perhaps because part of clause B) below has been eaten by gremlins. Suppose that my extender recognises some magic header in your bundle and uses it to generate a Servlet which acts as a plug-in for the Felix web console. Would that be an example? 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
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
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. +1 For DS the situation is different: the SCR knows nothing about the services it is registering on behalf of other bundles, it just regurgitates what it finds in the XML. In the webby proxy thingy model it is precisely the extender which knows about servlets and who knows maybe MVC and REST frameworks and more besides, while the extendee is just a passive victim. That's why in the former case it make sense for the extender to masquerade as the extendee and in the latter it doesn't. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] whiteboard pattern extenders
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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Raymond Auge raymond.a...@liferay.comSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] whiteboard pattern extendersDate: 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 withSincerely, - Ray --BJ HargraveSenior Technical Staff Member, IBM office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Raymond Auge raymond.a...@liferay.comSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc: Subject: Re: [osgi-dev] whiteboard pattern extendersDate: 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 HargraveSenior Technical Staff Member, IBM office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Raymond Auge raymond.a...@liferay.comSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: [osgi-dev] whiteboard pattern extendersDate: 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 ArchitectLiferay, Inc.(@Liferay)Board Member EEG Co-Chair, OSGi Alliance (@OSGiAlliance) ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev-- Raymond Augé(@rotty3000) Senior Software ArchitectLiferay, Inc.(@Liferay)Board Member EEG Co-Chair, OSGi Alliance (@OSGiAlliance) ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev-- Raymond Augé(@rotty3000) Senior Software ArchitectLiferay, Inc.(@Liferay)Board Member EEG Co-Chair, OSGi Alliance (@OSGiAlliance) ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] whiteboard pattern extenders
I'm not trying to get around classloader protections, and certainly want to ensure binding to the correct packages. I'm simply trying to avoid that a bundle which doesn't actually use an API still can be extended, it's just the extender and the whiteboard are different bundles. Sincerely, - Ray On Wed, Jun 17, 2015 at 2:23 PM, Balázs Zsoldos balazs.zsol...@everit.biz wrote: If you want to pick up services that implement the Servlet interface, you should use false as you want to pick up only those services that wire to the same javax.servlet package (otherwise you would get a class cast exception). If you want to pick up services based on their annotations or service properties (not really caring what interfaces they implement), you should use true. *Zsoldos Balázs* Rendszertervező | Software architect +36 70 594 9234 | balazs.zsol...@everit.biz *EverIT Kft.* 1137 Budapest, Katona József utca 17. III. em. 2. http://www.everit.biz I i...@everit.biz Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. This message and any attachment are confidential and are legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Please note that any dissemination, distribution, copying or use of or reliance upon the information contained in and transmitted with this e-mail by or to anyone other than the recipient designated above by the sender is unauthorised and strictly prohibited. On Wed, Jun 17, 2015 at 8:12 PM, Raymond Auge raymond.a...@liferay.com wrote: 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
Re: [osgi-dev] whiteboard pattern extenders
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
[osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
Since B is the one creating the service objects, B must be wired up to C in order to use the same runtime package. The fact that these objects are being created because of some magic cookies in A doesn't really change very much - B could as well register a servlice every time it receives a tweet with the hashtag #crackerjack. Or am I missing something? 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
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
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 hargr...@us.ibm.com mailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto: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 mailto: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 tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 tel:%2B1%20386%20848%203788 hargr...@us.ibm.com mailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto: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 mailto: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 tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 tel:%2B1%20386%20848%203788 hargr...@us.ibm.com mailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.com mailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.org mailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org mailto: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 mailto: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
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
AllService 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 Hargravehargr...@us.ibm.comwrote: 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 HargraveSenior Technical Staff Member, IBM // office:+1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile:+1 386 848 3788hargr...@us.ibm.com - Original message -From: Raymond Auge raymond.a...@liferay.comSent by:osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc: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 Hargravehargr...@us.ibm.comwrote: 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 HargraveSenior Technical Staff Member, IBM // office:+1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile:+1 386 848 3788hargr...@us.ibm.com - Original message -From: Raymond Auge raymond.a...@liferay.comSent by:osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc: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 Hargravehargr...@us.ibm.comwrote: 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 withSincerely, - Ray --BJ HargraveSenior Technical Staff Member, IBM office:+1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance mobile:+1 386 848 3788hargr...@us.ibm.co
Re: [osgi-dev] whiteboard pattern extenders
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
Re: [osgi-dev] whiteboard pattern extenders
] 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.commailto: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 1781tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788tel:%2B1%20386%20848%203788 hargr...@us.ibm.commailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.commailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.orgmailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.orgmailto: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.commailto: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 1781tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788tel:%2B1%20386%20848%203788 hargr...@us.ibm.commailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.commailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.orgmailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.orgmailto: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.commailto: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 1781tel:%2B1%20386%20848%201781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788tel:%2B1%20386%20848%203788 hargr...@us.ibm.commailto:hargr...@us.ibm.com - Original message - From: Raymond Auge raymond.a...@liferay.commailto:raymond.a...@liferay.com Sent by: osgi-dev-boun...@mail.osgi.orgmailto:osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.orgmailto: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 Alliancehttp://osgi.org/ (@OSGiAlliance) ___ OSGi Developer Mail List osgi-dev@mail.osgi.orgmailto:osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
