Ok so here is what I could figure from the logs:
At 15:53 - 16:09 hours you were getting exceptions of type
java.lang.NoSuchMethodError:
org.apache.stanbol.commons.owl.util.URIUtils.desanitize(Lorg/semanticweb/owlapi/model/IRI;)Lorg/semanticweb/owlapi/model/IRI;
This was clearly due to your commons.owl bundle being outdated because
the desanitize() methods were introduced recently, about a week ago.
Then the commons.owl bundle got somehow updated and activation proceeded.
I can see then that you also got a MissingOntologyException while
rebuilding the virtual network structures.
This is because last week I introduced a different naming scheme for
assigning public keys to stored ontologies (the "ontonet::" prefix will
most often no longer be part of the public key, while it is still the
prefix of Clerezza graph names).
When the ontology is a named one, the public key will be of type
ontologyIRI[:::versionIRI], otherwise Stanbol will assign a public key
of its own.
I didn't bother to make this system backwards compatible, since virtual
network persistence ( STANBOL-571) is a new feature not present in the
0.9.0-incubating release anyway.
However, if you would like to update and reinstall the ontologymanager
bundles, I have just now committed a fix that makes scope and session
rebuilding more fault-tolerant.
Alessandro
On 8/8/12 8:58 PM, Melanie Reiplinger wrote:
when I checked again a few minutes ago, the ontologymanager was back.
I had changed nothing since my last eMail, I was off for a while and
when I came back, it was there again, and all components are
'satisfied' suddenly. But the REST interface looks ancient now, like
it looked before my last big update. And I cannot produce any logs. I
configured another debug logger, just as the first time, but no log
file is created, nothing written.
What is left is the log file I had it write to this afternoon, I
append it below because I think it took record of what happened when I
tried to install the bundle.
Am 08.08.2012 17:36, schrieb Alessandro Adamou:
On 8/8/12 4:56 PM, Melanie Reiplinger wrote:
I always skip the tests in doing the global mvn clean install
(-DskipTests), because whenever I let it do the test, the build fails.
Well, it would be better to actually run them. The only failed tests
that we can expect are from the EntityHub, because now and then your
system might not be able to bring up the Solr index on time. Which
failures are you getting?
Can't tell you exactly, because I didn't save the log files. But I
know that they vary, i.e., when starting the build process several
times in a row (starting it again after it had failed), then the
different runs fail for different reasons, at different points during
the build.
Do you think it makes sense if I try to do a fresh installation?
Then how can I make sure an up-to-date launcher is built?
I already did a complete re-installation but since you assume my
launcher is too old, how can I solve this?
After reinstalling, where do you go to run the rebuilt Stanbol?
if you go to
[stanbol-dir]/launchers/full/target
that launcher is the one up to date. But only if it was NOT running
while you were rebuilding Stanbol.
Do you run the Stanbol jar from that directory or do you copy the Jar
somewhere else usually?
I go to the main directory and call for the
launchers/full/target/org.apache.stanbol.launchers.full-0.10.0-incubating-SNAPSHOT.jar.
I always stop the launcher before updating and rebuilding.
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
