felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Jackson <Bruce.Jack...@myriadgroup.com>
Subject Re: bundle starting order
Date Fri, 15 Aug 2014 12:28:20 GMT
Yes:

“look bundle B will not work without bundle A started” declaratively


is just a case for bundle B having a BundleTracker that tracks A, and when
it starts it does its own initialisation.
Alternatively, you can do this all using DS if you declare & export a
simple service interface class in A, and make B depend on that using
cardinality of 1..n


On 15/08/14 13:13, "Konstantine Kougios" <Konstantine.Kougios@akqa.com>
wrote:

>Sling bundle (bundle C) is searching for annotated classes. Bundle B has
>the issue. So my module B doesn’t search for the annotated classes. It
>just uses them but calls C’s methods which fail because A (annotated
>model) is not loaded
>
>So what I could do with BundleTracker on B is track when A is loaded and
>then do the logic on B. Though it will probably work, it is weird and I
>will have to do it in all services which need to do things using A’s
>classes.
>
>All in all it seems this is not properly supported by sling/osgi.
>Probably the way sling registers the annotations is not supported by osgi
>reg. bundle lifecycle.
>
>I’d rather manually start A in the Activator rather than have my services
>BundleTrack A because if I use BundleTracker I will have to do that on
>each service of B.
>
>
>So no way in osgi to say “look bundle B will not work without bundle A
>started” declaratively? It sounds a pretty common scenario to me.
>
>
>
>From: Neil Bartlett <njbartlett@gmail.com<mailto:njbartlett@gmail.com>>
>Date: Friday, 15 August 2014 13:06
>To: "users@felix.apache.org<mailto:users@felix.apache.org>"
><users@felix.apache.org<mailto:users@felix.apache.org>>, Konstantine
>Kougios
><konstantine.kougios@akqa.com<mailto:konstantine.kougios@akqa.com>>
>Subject: Re: bundle starting order
>
>Well you said you’re searching for annotated classes in A; this can be
>done with a BundleTracker, as I indicated about 3 or 4 messages back in
>the thread.
>
>Regards,
>Neil
>
>
>
>On 15 August 2014 at 12:58:50, Konstantine Kougios
>(konstantine.kougios@akqa.com<mailto:konstantine.kougios@akqa.com>) wrote:
>
>Ok, any hints?
>
>From: Neil Bartlett <njbartlett@gmail.com<mailto:njbartlett@gmail.com>>
>Date: Friday, 15 August 2014 13:02
>To: "users@felix.apache.org<mailto:users@felix.apache.org>"
><users@felix.apache.org<mailto:users@felix.apache.org>>, Konstantine
>Kougios
><konstantine.kougios@akqa.com<mailto:konstantine.kougios@akqa.com>>
>Subject: Re: bundle starting order
>
>Oh I’m pretty sure it is possible in your case.
>
>Regards,
>Neil
>
>
>On 15 August 2014 at 11:07:00, Konstantine Kougios
>(konstantine.kougios@akqa.com<mailto:konstantine.kougios@akqa.com>) wrote:
>
>Hi Bruce,
>
>This is not possible in my case. This is because A doesn’t expose any
>service. A is just a models bundle for apache sling, so there are model
>classes annotated with @Model. Then C (sling) registers those models in
>it’s adaptTo registry. There is no service exported by A.
>
>B is my service layer and it requires the models of A, and there are
>services that need to adaptTo() during activation.
>
>Cheers
>
>
>On 15/08/2014 10:59, "Bruce Jackson"
><Bruce.Jackson@myriadgroup.com<mailto:Bruce.Jackson@myriadgroup.com>>
>wrote:
>
>>Konstantine
>>
>>As others have said, you should assume anything about bundle start order,
>>and neither should you have to make one bundle start another.
>>If B depends on A, then it should have a dependency on a service
>>interface
>>exported by A. There are several ways you can implement this, as Neil
>>says, either by DS or by a ServiceTracker in B.
>>
>>Thanks
>>
>>Bruce
>>
>>On 14/08/14 17:18, "Konstantine Kougios"
>><Konstantine.Kougios@akqa.com<mailto:Konstantine.Kougios@akqa.com>>
>>wrote:
>>
>>>Hi Bruce,
>>>
>>>C is a service that keeps a class registry based on annotations
>>>A uses those annotations. When A is started, the annotated classes are
>>>registered with C
>>>B depends on A but via C.
>>>
>>>So B doesn’t depend on a service of A (A contains domain model classes
>>>that are annotated). But it needs the annotated classes to be registered
>>>on C. C is a 3rd party bundle (sling) which is always in started state.
>>>
>>>What I did so far, on B I added a BundleActivator that forces A to
>>>start:
>>>
>>>public class Activator implements BundleActivator {
>>> @Override
>>> public void start(final BundleContext bundleContext) throws
>>>Exception {
>>> Bundle[] bundles = bundleContext.getBundles();
>>> for (Bundle bundle : bundles) {
>>> String name = bundle.getSymbolicName();
>>> if (“my_A_bundle_symbolic_name".equals(name)) {
>>> bundle.start();
>>> }
>>>….
>>>}
>>>
>>>This works and solves my issue but it means I need to manage any other
>>>such dependencies in that class. I don’t know if there is a better way.
>>>
>>>Cheers
>>>
>>>
>>>
>>>
>>>
>>>On 14/08/2014 17:12, "Bruce Jackson"
>>><Bruce.Jackson@myriadgroup.com<mailto:Bruce.Jackson@myriadgroup.com>>
>>>wrote:
>>>
>>>>Hi Konstantine
>>>>
>>>>I think if you could provide some kind of simple dependency statement,
>>>>it
>>>>would be clearer. I can’t work out if you’re saying you have:
>>>>
>>>>a depends on b
>>>>b depends on c
>>>>
>>>>or
>>>>
>>>>a depends on b
>>>>b depends on c
>>>>
>>>>or a depends on b
>>>>c depends on a and b
>>>>
>>>>?
>>>>
>>>>Thanks
>>>>
>>>>Bruce
>>>>
>>>>On 14/08/14 15:55, "Konstantine Kougios"
>>>><Konstantine.Kougios@akqa.com<mailto:Konstantine.Kougios@akqa.com>>
>>>>wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>"If they depend on a service that are not started yet they should just
>>>>>wait until it becomes available²
>>>>>
>>>>>Problem is that the service is on bundle C and started during
>>>>>container
>>>>>startup. Bundle C is not restarted when I deploy my bundles. A has
>>>>>annotations on some classes that declare that they have to be
>>>>>registered
>>>>>on C. B uses those annotated classes and the services of C. But B is
>>>>>started before A which means C is not aware of the annotated classes
>>>>>of
>>>>>A.
>>>>>(I hope it makes sense)
>>>>>
>>>>>Cheers
>>>>>
>>>>>
>>>>>On 14/08/2014 12:23, "Tommy Svensson"
>>>>><tommy@natusoft.se<mailto:tommy@natusoft.se>> wrote:
>>>>>
>>>>>>I agree with the following statement:
>>>>>>
>>>>>> Your bundles should never make any assumptions on the order in
>>>>>>which
>>>>>>they are started.
>>>>>>
>>>>>>I would stick to this statement. Your bundles should be able to
>>>>>>handle
>>>>>>themselves correctly no matter in which order things are started.
If
>>>>>>they
>>>>>>depend on a service that are not started yet they should just wait
>>>>>>until
>>>>>>it becomes available. When all bundles are upp and running and all
>>>>>>services are available all should be good. You should consider a
>>>>>>timeout
>>>>>>waiting for something however. If your code just accept that
>>>>>>something
>>>>>>will be available in due time, the order bundles are started in are
>>>>>>completely irrelevant. I would also say that the
>>>>>>application/service/whatever will be more stable then, since if it
>>>>>>can
>>>>>>handle that, it can also handle services temporarily being gone later
>>>>>>due
>>>>>>to bundle redeployment by simply waiting for them to become available
>>>>>>again. This allows redeployments with minimal impact on running code.
>>>>>>
>>>>>>Cheers,
>>>>>>Tommy
>>>>>>
>>>>>>
>>>>>>14 aug 2014 kl. 12:54 skrev Jan Willem Janssen
>>>>>><janwillem.janssen@luminis.eu<mailto:janwillem.janssen@luminis.eu>>:
>>>>>>
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> On 14/08/14 12:47, Konstantine Kougios wrote:
>>>>>>>> This creates problems for me as some services on A do register
>>>>>>>> classes on a separate bundle C. So A services, when activated,
>>>>>>>> expect to find those registrations on C but can¹t.
>>>>>>>>
>>>>>>>> Is this a common issue? Is there a solution?
>>>>>>>
>>>>>>> Your bundles should never make any assumptions on the order in
>>>>>>>which
>>>>>>> they are started. OSGi is intended to be a dynamic environment
in
>>>>>>> which services can come and go at any time.
>>>>>>>
>>>>>>> Basically, you want to use a higher-level API, such as Felix
>>>>>>> Dependency Manager or Declarative Services to describe the service
>>>>>>> dependencies. This way, your services can get callbacks or get
>>>>>>> notified when their dependencies are met or are no longer met.
>>>>>>>
>>>>>>> - --
>>>>>>> Met vriendelijke groeten | Kind regards
>>>>>>>
>>>>>>> Jan Willem Janssen | Software Architect
>>>>>>> +31 631 765 814
>>>>>>>
>>>>>>> /My world is revolving around INAETICS and Amdatu/
>>>>>>>
>>>>>>> Luminis Technologies B.V.
>>>>>>> Churchillplein 1
>>>>>>> 7314 BZ Apeldoorn
>>>>>>> +31 88 586 46 00
>>>>>>>
>>>>>>> http://www.luminis-technologies.com
>>>>>>> http://www.luminis.eu
>>>>>>>
>>>>>>> KvK (CoC) 09 16 28 93
>>>>>>> BTW (VAT) NL8169.78.566.B.01
>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>>>>>>> Comment: GPGTools - http://gpgtools.org
>>>>>>>
>>>>>>> iQIcBAEBAgAGBQJT7JVWAAoJEKF/mP2eHDc4tyQP/2nBps6b0s5JAm6NFceq0w8Z
>>>>>>> W/jM6CTP2+3T3kZBsUIauU74thMAo3fYDapprtS1dSIc5CvQYJIGN6Ls4fw+NVt7
>>>>>>> jh+iQpddtWEsR+j3K38TP+5LhRL4glQcaKu5As1kWeLpccMIxG8X/b+PjelMbuXD
>>>>>>> DBu3JPp3n7SH20JKfcCAtvo5a7fVXmFg8C5i3xEyfX9nd0IjccaAgC6MJTbyFyTX
>>>>>>> pw0p5cwdRP1/izo+ErIHcOu0zTKvSnfovPYgl7HOwwwafCj5ZJpZjNTHezIiNDWq
>>>>>>> 1UvTJN6owX0a7sG/O/dOl1KZ1r7HG3w0pRX88XJ952FIBZXiwGROyuciizt7S8hj
>>>>>>> vaikwUXkX1L8VG3O5/wVEbBVXzaStTCtjUUL2obh7hMt8gHFweV4wAte3Z49cr4G
>>>>>>> 11V5PoaS0lCyqA7JiSi42Ob23JiZZ9vg3ja2+n98LT6F9bhjV3Tm5J+pPvKxnkcB
>>>>>>> +0Z2WTCsQ0URwKE8zY4aXARuVVm1ypq3c5DPz7bP+tEOG3b00kpgMCZkc3R8hut+
>>>>>>> 0NXfyzS99f9HAMX4Gyy65d6CcWGewOKc+qflkJLehdNs8taM/cRn8Cg3gF1gvXEU
>>>>>>> 29W7+3xLKf3jSRONPKsyXAZ3K/ykhvpRhJvrNzWDdZLUlANMHPq7+vI3lN5eycyp
>>>>>>> 3SR528SyP9q0xpGNpbay
>>>>>>> =3/N6
>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>
>>>>>>>
>>>>>>>--------------------------------------------------------------------
>>>>>>>-
>>>>>>> To unsubscribe, e-mail:
>>>>>>>users-unsubscribe@felix.apache.org<mailto:users-unsubscribe@felix.ap
>>>>>>>ache.org>
>>>>>>> For additional commands, e-mail:
>>>>>>>users-help@felix.apache.org<mailto:users-help@felix.apache.org>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail:
>>>>>>users-unsubscribe@felix.apache.org<mailto:users-unsubscribe@felix.apa
>>>>>>che.org>
>>>>>>For additional commands, e-mail:
>>>>>>users-help@felix.apache.org<mailto:users-help@felix.apache.org>
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail:
>>>>>users-unsubscribe@felix.apache.org<mailto:users-unsubscribe@felix.apac
>>>>>he.org>
>>>>>For additional commands, e-mail:
>>>>>users-help@felix.apache.org<mailto:users-help@felix.apache.org>
>>>>>
>>>>
>>>>*** DISCLAIMER ***
>>>>
>>>>This message, including attachments, is intended solely for the
>>>>addressee
>>>>indicated in this message and is strictly confidential or otherwise
>>>>privileged. If you are not the intended recipient (or responsible for
>>>>delivery of the message to such person) : - (1) please immediately (i)
>>>>notify the sender by reply email and (ii) delete this message and
>>>>attachments, - (2) any use, copy or dissemination of this transmission
>>>>is
>>>>strictly prohibited. If you or your employer does not consent to
>>>>Internet
>>>>email messages of this kind, please advise Myriad Group AG by reply
>>>>e-mail immediately. Opinions, conclusions and other information
>>>>expressed
>>>>in this message are not given or endorsed by Myriad Group AG unless
>>>>otherwise indicated by an authorized representative independent of this
>>>>message.
>>>>?B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
>>>>C
>>>>B
>>>>*
>>>>??[???昧?X?K??K[XZ[???\???[???昧?X?P??[?^??\?X?K???‘???Y??]?[?[??栢
>>>>[X[????K[XZ[???\????[????[?^??\?X?K???
>>>
>>
>>*** DISCLAIMER ***
>>
>>This message, including attachments, is intended solely for the addressee
>>indicated in this message and is strictly confidential or otherwise
>>privileged. If you are not the intended recipient (or responsible for
>>delivery of the message to such person) : - (1) please immediately (i)
>>notify the sender by reply email and (ii) delete this message and
>>attachments, - (2) any use, copy or dissemination of this transmission is
>>strictly prohibited. If you or your employer does not consent to Internet
>>email messages of this kind, please advise Myriad Group AG by reply
>>e-mail immediately. Opinions, conclusions and other information expressed
>>in this message are not given or endorsed by Myriad Group AG unless
>>otherwise indicated by an authorized representative independent of this
>>message.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>users-unsubscribe@felix.apache.org<mailto:users-unsubscribe@felix.apache.o
>rg>
>For additional commands, e-mail:
>users-help@felix.apache.org<mailto:users-help@felix.apache.org>

*** DISCLAIMER ***

This message, including attachments, is intended solely for the addressee indicated in this
message and is strictly confidential or otherwise privileged. If you are not the intended
recipient (or responsible for delivery of the message to such person) : - (1) please immediately
(i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any
use, copy or dissemination of this transmission is strictly prohibited. If you or your employer
does not consent to Internet email messages of this kind, please advise Myriad Group AG by
reply e-mail immediately. Opinions, conclusions and other information expressed in this message
are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative
independent of this message.
Mime
View raw message