You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Alessandro Adamou <al...@istc.cnr.it> on 2011/04/27 17:03:01 UTC
Deploy/run Stanbol as POJO
Hi,
there seem to be some early adopters who are interested in using
Stanbol, yet would like to run it in non-OSGi environments.
There is of course an issue about making sure there are alternative
constructors for all SCR services, BundleActivator#start() methods
called etc.
However now I am mostly concerned about working dir management. By
simply adding all JARs to the classpath and instantiating Stanbol
clases, I get missing Jena resource files such as
com.hp.hpl.jena.reasoner.ReasonerException: Can't load rules file:
etc/rdfs-fb-tgc-noresource.rules
We are wondering whether this could be due to the centralized working
directory management in POJO as opposed to distributed (?) working
directory management in OSGi.
Do you know if compiling with a goal other than bundle would help? mvn
assembly:assembly doesnt seem to work on Stanbol root.
Thanks
Alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"As for the charges against me, I am unconcerned. I am beyond their timid, lying morality, and so I am beyond caring."
(Col. Walter E. Kurtz)
Re: Deploy/run Stanbol as POJO
Posted by Stefane Fermigier <sf...@nuxeo.com>.
Please note that OSGi is POJO-based:
http://www.osgi.org/blog/2006/03/pojos.html
(TL;DR: You don't need to implement a specific interface to create an OSGi service).
Your issue seems more related to the classpath and I'm sure there is a simple workaround.
S.
On Apr 27, 2011, at 5:03 PM, Alessandro Adamou wrote:
> Hi,
>
> there seem to be some early adopters who are interested in using Stanbol, yet would like to run it in non-OSGi environments.
>
> There is of course an issue about making sure there are alternative constructors for all SCR services, BundleActivator#start() methods called etc.
>
> However now I am mostly concerned about working dir management. By simply adding all JARs to the classpath and instantiating Stanbol clases, I get missing Jena resource files such as
>
> com.hp.hpl.jena.reasoner.ReasonerException: Can't load rules file: etc/rdfs-fb-tgc-noresource.rules
>
> We are wondering whether this could be due to the centralized working directory management in POJO as opposed to distributed (?) working directory management in OSGi.
>
> Do you know if compiling with a goal other than bundle would help? mvn assembly:assembly doesnt seem to work on Stanbol root.
>
> Thanks
>
> Alessandro
>
> --
> M.Sc. Alessandro Adamou
>
> Alma Mater Studiorum - Università di Bologna
> Department of Computer Science
> Mura Anteo Zamboni 7, Bologna - Italy
>
> Semantic Technology Laboratory (STLab)
> Institute for Cognitive Science and Technology (ISTC)
> National Research Council (CNR)
> Via Nomentana 56, 00161 Rome - Italy
>
>
> "As for the charges against me, I am unconcerned. I am beyond their timid, lying morality, and so I am beyond caring."
> (Col. Walter E. Kurtz)
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Re: Deploy/run Stanbol as POJO
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
> Clerezza uses the java.util.ServiceLoader functionality to enable to use of
> Clerezza outside of an OSGI environment.
I've observed that, possible reason why I've only been facing trouble
with Jena and not with Clerezza so far.
>> IMO, supporting non-OSGi environments outside of 1) and 2) is out of
>> scope for Stanbol, that would distract us from our primary goal. You'd
>> need to provide lifecycle, service registry, ConfigurationAdmin and a
>> number of other things that probably forget, that's a lot of work that
>> doesn't help fulfilling our own goals.
Yeah, but it looks like having option (1) with Java-only API, as part of
the classpath of some external program using Stanbol, could suffice.
> Do you plan to use all of Stanbol (along with the HTTP / JAX-RS
> endpoints) or just a restricted subset of the lowlevel components?
We (and the adopters) would be happy to even just use its Java API to
begin with.
> It's hard to tell how to best solve this without the rest of the stacktrace.
Here it is, if it helps. It really looks like a working dir problem with
Jena resources tho'
----------------
03.05.2011 18:06:36.526 *ERROR* [main]
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.CoreOntologySpaceImpl
KReS :: [NONFATAL] An error occurred while storing root ontology
Ontology(<http://www.iks-project.eu/scope/TestScope/core/root.owl>
[Axioms: 0] [Logical axioms: 0]) . Ontology management will be volatile!
com.hp.hpl.jena.reasoner.ReasonerException: Can't load rules file:
etc/rdfs-fb-tgc-noresource.rules
at
com.hp.hpl.jena.reasoner.rulesys.FBRuleReasoner.loadRules(FBRuleReasoner.java:259)
at
com.hp.hpl.jena.reasoner.rulesys.RDFSRuleReasoner.loadRulesLevel(RDFSRuleReasoner.java:197)
at
com.hp.hpl.jena.reasoner.rulesys.RDFSRuleReasoner.<init>(RDFSRuleReasoner.java:69)
at
com.hp.hpl.jena.reasoner.rulesys.RDFSRuleReasoner.<init>(RDFSRuleReasoner.java:81)
at
com.hp.hpl.jena.reasoner.rulesys.RDFSRuleReasonerFactory.create(RDFSRuleReasonerFactory.java:46)
at
com.hp.hpl.jena.ontology.OntModelSpec.getReasoner(OntModelSpec.java:382)
at
com.hp.hpl.jena.ontology.impl.OntModelImpl.generateGraph(OntModelImpl.java:2742)
at
com.hp.hpl.jena.ontology.impl.OntModelImpl.<init>(OntModelImpl.java:139)
at
com.hp.hpl.jena.ontology.impl.OntModelImpl.<init>(OntModelImpl.java:120)
at
com.hp.hpl.jena.rdf.model.ModelFactory.createOntologyModel(ModelFactory.java:402)
at
com.hp.hpl.jena.rdf.model.ModelFactory.createOntologyModel(ModelFactory.java:361)
at
com.hp.hpl.jena.rdf.model.ModelFactory.createOntologyModel(ModelFactory.java:344)
at
org.apache.stanbol.owl.trasformation.JenaToOwlConvert.ModelOwlToJenaConvert(JenaToOwlConvert.java:196)
at
org.apache.stanbol.ontologymanager.ontonet.impl.io.ClerezzaOntologyStorage.store(ClerezzaOntologyStorage.java:179)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.AbstractOntologySpaceImpl.setTopOntology(AbstractOntologySpaceImpl.java:490)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.OntologySpaceFactoryImpl.setupSpace(OntologySpaceFactoryImpl.java:88)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.OntologySpaceFactoryImpl.createCoreOntologySpace(OntologySpaceFactoryImpl.java:52)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.OntologyScopeImpl.<init>(OntologyScopeImpl.java:71)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.OntologyScopeFactoryImpl.createOntologyScope(OntologyScopeFactoryImpl.java:61)
at
org.apache.stanbol.ontologymanager.ontonet.impl.ontology.OntologyScopeFactoryImpl.createOntologyScope(OntologyScopeFactoryImpl.java:48)
at it.cnr.istc.stlab.stanboltests.SetupKres.main(SetupKres.java:24)
Caused by: java.io.FileNotFoundException:
etc/rdfs-fb-tgc-noresource.rules (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at
com.hp.hpl.jena.util.FileUtils.openResourceFileAsStream(FileUtils.java:397)
at com.hp.hpl.jena.util.FileUtils.openResourceFile(FileUtils.java:375)
at
com.hp.hpl.jena.reasoner.rulesys.Util.loadRuleParserFromResourceFile(Util.java:221)
at
com.hp.hpl.jena.reasoner.rulesys.FBRuleReasoner.loadRules(FBRuleReasoner.java:257)
... 20 more
Re: Deploy/run Stanbol as POJO
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Alessandro
Clerezza uses the java.util.ServiceLoader functionality to enable to use of
Clerezza outside of an OSGI environment.
This means that manager type components typically also have an static
getInstance() method that uses the java.util.ServiceLoader to search for
available implementations.
The ServiceLoader can also be used by components to initialize dependencies
to manager type components.
As far as I know this can not be used to provide configurations to components.
I used this way to allow some components of the Stanbol Entityhub to run
outside an OSGI environment.
On Thu, Apr 28, 2011 at 11:07 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> IMO, supporting non-OSGi environments outside of 1) and 2) is out of
> scope for Stanbol, that would distract us from our primary goal. You'd
> need to provide lifecycle, service registry, ConfigurationAdmin and a
> number of other things that probably forget, that's a lot of work that
> doesn't help fulfilling our own goals.
+1
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Deploy/run Stanbol as POJO
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Apr 27, 2011 at 5:03 PM, Alessandro Adamou
<al...@istc.cnr.it> wrote:
> ...there seem to be some early adopters who are interested in using Stanbol,
> yet would like to run it in non-OSGi environments....
I see two (almost) out-of-the box ways:
1) Run the stanbol jar in a separate JVM and access it via its http interfaces
2) Create a war file that embeds the OSGi framework and Stanbol
bundles, and run in a J2EE server alongside other code
The maven-launchpad-plugin supports 2) but it's not currently
configured in our launcher's poms, should be fairly easy to add. See
http://sling.apache.org/site/maven-launchpad-plugin.html
Next option is http://code.google.com/p/pojosr/ which I haven't tested
yet but might help.
IMO, supporting non-OSGi environments outside of 1) and 2) is out of
scope for Stanbol, that would distract us from our primary goal. You'd
need to provide lifecycle, service registry, ConfigurationAdmin and a
number of other things that probably forget, that's a lot of work that
doesn't help fulfilling our own goals.
-Bertrand
Re: Deploy/run Stanbol as POJO
Posted by Olivier Grisel <ol...@ensta.org>.
2011/4/27 Alessandro Adamou <al...@istc.cnr.it>:
> Hi,
>
> there seem to be some early adopters who are interested in using Stanbol,
> yet would like to run it in non-OSGi environments.
>
> There is of course an issue about making sure there are alternative
> constructors for all SCR services, BundleActivator#start() methods called
> etc.
>
> However now I am mostly concerned about working dir management. By simply
> adding all JARs to the classpath and instantiating Stanbol clases, I get
> missing Jena resource files such as
>
> com.hp.hpl.jena.reasoner.ReasonerException: Can't load rules file:
> etc/rdfs-fb-tgc-noresource.rules
It's hard to tell how to best solve this without the rest of the stacktrace.
As for instantiating the Stanbol classes, the will also probably need
to inject the service instance into one another: we use SCR
annotations (e.g. @Reference annotated attributes) to perform
automated dependency injection. I think it would be rather tedious to
do it manually. Adding explicit setters for all the @Reference
annotated fields might be possible although it would make the code
base slightly more verbose.
Do you plan to use all of Stanbol (along with the HTTP / JAX-RS
endpoints) or just a restricted subset of the lowlevel components?
> We are wondering whether this could be due to the centralized working
> directory management in POJO as opposed to distributed (?) working directory
> management in OSGi.
>
> Do you know if compiling with a goal other than bundle would help? mvn
> assembly:assembly doesnt seem to work on Stanbol root.
To use the assembly goal you need a special declaration in the
pom.xml. I would suggest to write your own assembly pom.xml file with
the necessary declarations and put all the required stanbol artifacts
as dependencies.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel