It's the HTTP host where you are running the launcher Jar.
If you didn't change any port or authentication settings and are running
it on your local machine, you should open the Web browser and go to
http://localhost:8080/system/console/bundles (user: admin, pw:admin)
If you launched Stanbol on another port or changed the admin
credentials, you should input them accordingly.
hth
alessandro
On 4/3/12 12:12 PM, Alessandra Donnini wrote:
What is [stanbol-host]? is it the svn repository? My local directory?
Alessandra Donnini
Etcware s.r.l. via Etna 13 - 00141 Roma
[email protected]
mobile +39 333 8914865
tel/fax 06 64495131
Il giorno 03/apr/2012, alle ore 12.02, Alessandro Adamou ha scritto:
Hi Alessandra
This could mean that the refactor engine dependency is either not installed or
not activated in your installation.
If you go to [stanbol-host]/system/console/bundles do you see a component called
Apache Stanbol Ontology Network Manager
(org.apache.stanbol.ontologymanager.ontonet)
and does it have an active status?
Best,
Alessandro
On 4/3/12 11:45 AM, Alessandra Donnini wrote:
Hi Rupert
I did what you said and the installation seems to work well.
But when I run, after install I have this error:
INFO: Initiating Jersey application, version 'Jersey: 1.12 02/15/2012 04:51 PM'
ERROR: Bundle org.apache.stanbol.enhancer.engines.refactor [90]: Error starting
slinginstall:org.apache.stanbol.enhancer.engines.refactor-0.9.0-incubating-SNAPSHOT.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.stanbol.enhancer.engines.refactor [90]: Unable to resolve 90.0:
missing requirement [90.0] package;
(package=org.apache.stanbol.ontologymanager.ontonet.api))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.stanbol.enhancer.engines.refactor [90]: Unable to resolve 90.0:
missing requirement [90.0] package;
(package=org.apache.stanbol.ontologymanager.ontonet.api)
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3443)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1727)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:680)
and the system starts only with enhancer and entityhub components (for instance
content hub component is missing).
Any suggestion?
thank
Alessandra Donnini
Etcware s.r.l. via Etna 13 - 00141 Roma
[email protected]
mobile +39 333 8914865
tel/fax 06 64495131
Il giorno 03/apr/2012, alle ore 10.39, Rupert Westenthaler ha scritto:
Hi Alessandra
On 03.04.2012, at 08:31, Alessandra Donnini wrote:
I don't know if the error is the same, but I tried to build stanbol from
scratch two times and I had the same attached error.
the log also includes failures while executing the Entityhub Indexing tools.
Those might be related to the error Andreas Kuckartz is experiencing.
It seems that build process went in a loop in:
...
1359474 [main] INFO org.apache.stanbol.commons.testing.stanbol.StanbolTestBase
- Got HttpHostConnectException at http://localhost:8765/ - will retry
...
After a lot of retry I interrupted it with ctrl-C and it finished but id
doesn't work properly.
Regarding the failure of the final Stanbol build contained in the log. Your log
files notes:
This is actually a tricky one. I think this is a combination of:
* https://issues.apache.org/jira/browse/EXEC-54
*
http://stackoverflow.com/questions/5569591/unable-to-access-jarfile-in-linux-land
Workaround:
==================
* rename the "text mining" directory to "text-mining"
Details about this Error:
==================
So basically the Apache Commons Exec quotes the parameter with the Jar file,
but the executed java can not deal with the quoted file path.
See this line in the log
Unable to access jarfile "/Users/ale/Documents/text
mining/stanbol/stanbol/stanbol/integration-tests/target/dependency/org.apache.stanbol.launchers.full-0.9.0-incubating-SNAPSHOT.jar"
and compare it to the result of a call to
java -jar doesnotexist.jar
this prints
Unable to access jarfile doesnotexist.jar
showing that the logging of the JVM does not include the "{path}"
When you try
java -jar "doesnotexist withSpace.jar"
the result is
Unable to access jarfile doesnotexist withSpace.jar
sill without spaces, because the bash pre-processes the command and replaces
the quoted parameter with the escaped one.
However if you call the same via the Apache Commons Exec there is no bash that
does this job and the java process itself has also no support for it.
How to reslove:
============
Not completely sure yet.
* I think I should add this findings as comment to EXEC-54.
* I could try to handle quoting myself and call
CommandLine.addArgument(escape(jarToExecute.getAbsolutePath()),false) but I was
not able to find a library that supports operating system specific escaping and
implementing something myself feels worse as the current situation.
any suggestions?
best
Rupert
On 03.04.2012, at 08:31, Alessandra Donnini wrote:
I don't know if the error is the same, but I tried to build stanbol from
scratch two times and I had the same attached error.
It seems that build process went in a loop in:
...
1359474 [main] INFO org.apache.stanbol.commons.testing.stanbol.StanbolTestBase
- Got HttpHostConnectException at http://localhost:8765/ - will retry
...
After a lot of retry I interrupted it with ctrl-C and it finished but id
doesn't work properly.
ciao
Alessandra
<errorLog.txt.zip>
Il giorno 03/apr/2012, alle ore 07.17, Andreas Kuckartz ha scritto:
I could reproduce the build error and found out when it happens.
The first "mvn install" failed and a second one immediately after that
succeeded.
I have appended logs.
Cheers,
Andreas
---
On 01.04.2012 20:52, Andreas Kuckartz wrote:
On 01.04.2012 10:15, Rupert Westenthaler wrote:
Can you please check the bundle (jar file)
data/sites/dbpedia/target/org.apache.stanbol.data.sites.dbpedia-1.0.3-incubating-SNAPSHOT.jar
it should be about 46MByte in size.
That file exists and the same folder also contains a file named
org.apache.stanbol.data.sites.dbpedia-1.0.3-incubating-SNAPSHOT-sources.jar
which is a little bit (about 5KB) smaller.
If this does not solve the problem It would be very helpful if you
could provide the whole console log of the failing unit tests for the
"/entityhub/ldpath".
I just executed the steps again and now all tests succeeded.
Strange, maybe the error was a result of a network snafu?
In principle skipping clean should be no
problem as long as you do not change the source.
...
NOTE: that a "svn up" is also considered as a change if the source.
So even a change of one line of source code makes a complete rebuild
necessary. I would prefer to be able to do an incremental build. Would
that be possible with Maven with reasonable effort?
(The answer seems to be no, but maybe someone has an idea. Seems to be
one reason why some people prefer Gradle. I used "make" in a distant
past and as far as I remember incremental builds never were a problem
with that old tool ;-)
Cheers,
Andreas
<logs.zip>
--
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, so long as you do not demand anything."
(Ettore Petrolini, 1930)
Not sent from my iSnobTechDevice
--
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, so long as you do not demand anything."
(Ettore Petrolini, 1930)
Not sent from my iSnobTechDevice
