clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Gmür <r...@wymiwyg.com>
Subject Re: No TcManager instance available
Date Wed, 09 Apr 2014 21:09:34 GMT
On Tue, Apr 8, 2014 at 1:55 PM, Minto van der Sluis <minto@xup.nl> wrote:

> 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?
>
What legitimation has a manager of there is nothing to manage? As a
component to depend on TcManger meens depending on the possibility of
retrieving and creating graphs. Throwing an exception would cause
components to fail in the activator, which is usually a problem that's hard
to find.


>
> 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).

Quoting from: http://www.planetmarrs.net/start-levels-in-osgi/

In other words, you must always be able to start your bundles in a random
> order, and this should never cause any problems. The worst case scenario is
> that the order is very inefficient, but it must never be the case that your
> application won't start at all.
>

Also some features of rdf.core are required early like parsers. TcProvider
are even likely to depend on these, so thy wouldn't start earlier even with
startlevels.


> 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.
>
This makes thing more performant starting up. Also it's useful so you can
stop your app while still having the infrastructure running.


> >
> > 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.
>

They can. But if a component needs to create a graph taht component depend
on a TcManager that can actually create graphs. The TcManager could
advertise it's capabilities via service properties like this is done by the
Parser service (which advertises the supported formats). This wouldn't
solve the problem when the in-memory TcProvider is present as well as one
with persistent storage. Wouldn't it be nice if TcManager would wait for
the peristent one to show up, before creating graphs?

Cheers,
Reto







> >
> > 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message