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" <[email protected]> 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" <[email protected]>
>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" <[email protected]> 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
>>><[email protected]>:
>>>
>>>> -----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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [email protected]
>>>For additional commands, e-mail: [email protected]
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>>
>
>*** 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딮KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
>??[�?쒁�쉃셁??K[XZ[?�?\?�?[�?쒁�쉃셆?�[?^?�\?X?K�??몳??Y??]?[?[??栢
>[X[�???K[XZ[?�?\?�??[???�[?^?�\?X?K�??
