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 09:59:01 GMT
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>
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>
>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>
>>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> 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>:
>>>>
>>>>> -----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
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>For additional commands, e-mail: 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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB
>>*
>>??[œ?œ昧š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.
Mime
View raw message