You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Minto van der Sluis <mi...@xup.nl> on 2014/04/07 11:02:38 UTC
No TcManager instance available
Hi Reto,
Sorry to address you directly, but I think this is related to issue #885
(an maybe #888).
Freshly building my stuff against the latest Clerezza snapshot
introduced a problem where some of my bundles couldn't start due their
dependency on TcManager.
Looking at the rdf.core bundle karaf tell me the following services:
karaf@root>bundle:services 147
Clerezza - SCB Core (147) provides:
-----------------------------------
[org.apache.clerezza.rdf.core.serializedform.Serializer]
[org.apache.clerezza.rdf.core.sparql.QueryParser]
[org.apache.clerezza.rdf.core.serializedform.Parser]
I expected to see TcManager in here as well.
Previously I used Blueprint to inject the TcManager service into my
bundles like this:
<reference id="clerezzaManagerServiceRef"
ext:proxy-method="classes"
interface="org.apache.clerezza.rdf.core.access.TcManager" />
Apparently this doesn't work anymore. Is the getInstance() method the
only left?
TcManager.getInstance();
I thought this one was for none OSGi environments. Is there another way?
Can you please explain how I can access the active TcManager.
Regards,
Minto
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: No TcManager instance available
Posted by Reto Gmür <re...@wymiwyg.com>.
On Tue, Apr 8, 2014 at 1:55 PM, Minto van der Sluis <mi...@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
>
>
Re: No TcManager instance available
Posted by Minto van der Sluis <mi...@xup.nl>.
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
Re: No TcManager instance available
Posted by Reto Gmür <re...@wymiwyg.com>.
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.
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.
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
>
>
Re: No TcManager instance available
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Reto,
Reto Gmür schreef op 7-4-2014 19:24:
>> Freshly building my stuff against the latest Clerezza snapshot
>> introduced a problem where some of my bundles couldn't start due their
>> dependency on TcManager.
>>
>> Looking at the rdf.core bundle karaf tell me the following services:
>>
>> karaf@root>bundle:services 147
>>
>> Clerezza - SCB Core (147) provides:
>> -----------------------------------
>> [org.apache.clerezza.rdf.core.serializedform.Serializer]
>> [org.apache.clerezza.rdf.core.sparql.QueryParser]
>> [org.apache.clerezza.rdf.core.serializedform.Parser]
>>
>> I expected to see TcManager in here as well.
>>
> It could be that TcManager has no longer all dependency satisfied with the
> new requirement introduced with CLEREZZA-885.
It appeared the SingleTdbDatasetTcProvider even though marked as general
purpose in the sources did not have that property in my environment.
Adding that property the configuration did the trick. The provider was
properly marked and TcManager was able to start/run.
>> Previously I used Blueprint to inject the TcManager service into my
>> bundles like this:
>>
>> <reference id="clerezzaManagerServiceRef"
>> ext:proxy-method="classes"
>> interface="org.apache.clerezza.rdf.core.access.TcManager" />
>>
>> Apparently this doesn't work anymore. Is the getInstance() method the
>> only left?
>>
>> TcManager.getInstance();
>>
>> I thought this one was for none OSGi environments. Is there another way?
>> Can you please explain how I can access the active TcManager.
>>
> 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.
>
> 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
Re: No TcManager instance available
Posted by Reto Gmür <re...@apache.org>.
Hi Minto
> Sorry to address you directly, but I think this is related to issue #885
> (an maybe #888).
>
CLEREZZA-885 could well be the cause.
>
> Freshly building my stuff against the latest Clerezza snapshot
> introduced a problem where some of my bundles couldn't start due their
> dependency on TcManager.
>
> Looking at the rdf.core bundle karaf tell me the following services:
>
> karaf@root>bundle:services 147
>
> Clerezza - SCB Core (147) provides:
> -----------------------------------
> [org.apache.clerezza.rdf.core.serializedform.Serializer]
> [org.apache.clerezza.rdf.core.sparql.QueryParser]
> [org.apache.clerezza.rdf.core.serializedform.Parser]
>
> I expected to see TcManager in here as well.
>
It could be that TcManager has no longer all dependency satisfied with the
new requirement introduced with CLEREZZA-885.
>
> Previously I used Blueprint to inject the TcManager service into my
> bundles like this:
>
> <reference id="clerezzaManagerServiceRef"
> ext:proxy-method="classes"
> interface="org.apache.clerezza.rdf.core.access.TcManager" />
>
> Apparently this doesn't work anymore. Is the getInstance() method the
> only left?
>
> TcManager.getInstance();
>
> I thought this one was for none OSGi environments. Is there another way?
> Can you please explain how I can access the active TcManager.
>
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.
Cheers,
Reto
>
> Regards,
>
> Minto
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
>