felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantine Kougios <Konstantine.Koug...@akqa.com>
Subject Re: bundle starting order
Date Fri, 15 Aug 2014 11:58:45 GMT
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.apache.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.apache.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.apache.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?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKC
>>>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.org>
For additional commands, e-mail: users-help@felix.apache.org<mailto:users-help@felix.apache.org>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message