Reto Gmür schreef op 8-4-2014 18:20: > Hi Minto > >> Clearly the static method should not be used. >>> Well, it seems you don't have an a active TcManager the most likely cause >>> given the zz-885 change is that you don't have a TcProvider marked as >>> general purpose. It should be easy to mark your TcProvider as >>> general-purpose, but we can also discuss zz-885, maybe it was a bad idea. >> Personally I fail to see the benefit. If there is no TcProvider there >> will also not be a general-purpose provider. So the behaviour is >> probably still the same as before. In my opinion it does not solve the >> issue you had in the first place. >> > It prevent the problem that a TcManager is available even if not TcProvider > is able to create new graphs. In our traditional launcher this is addressed > with startlevels but I don't think that this is a good solution. Ah now I see.
Why couldn't TcManager just report errors/exceptions when no suitable TcProvider is present? It's a manager after all. Why should the manager disappear when there is nothing to manage? Why are start levels not a good solution. It's this just the kind of scenario they were designed for? Just start the components that use TcManager in a later startlevel than TcManager (and TcProviders). This is how I do it inside Apache Karaf. TcManager and TcProviders are the infrastructure my app uses, so I start the infrastructure first before starting my app. > > A problem that is still open is what if there is an in-memory TcProvider in > the system? I've had problems that graphs got created in this because the > TdbTcProvider was loaded later. > > Ideally TcManager should wait for all TcProviders to be active, but I'm not > sure if an d how this can be done. How is TcManager to know which TcProvider to expect to be able to know whether they are all active? Besides OSGi is a dynamic environment. Shouldn't TcManager be able to cope with this dynamic behaviour? Theoretically TcProviders could come and go. > > Cheers, > Reto > > > >>> Cheers, >>> Reto >> Fortunately I was able to resolve my issue. Thanks for that. >> >> I also have some other issue/things to discuss, but I will use a >> separate thread for that. >> >> Regards, >> >> Minto >> >> -- >> ir. ing. Minto van der Sluis >> Software innovator / renovator >> Xup BV >> >> Mobiel: +31 (0) 626 014541 >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
