stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Stanbol on Karaf?
Date Tue, 06 Mar 2012 20:09:35 GMT
Hash: SHA1

Just a check in:

Things are looking good. I've the EntityHub up and running in Karaf 2.2.5 using the Felix
framework, and it was fairly easy. I'll give a few notes here on the way to writing up something
more substantive after I've got the complete 'stable' suite up.

1) The Sling Launchpad Maven plugin went nowheresville for making Karaf feature repositories.
I'm sure it does work and work well, but for me, I couldn't get over a NullPointer exception
when it went looking for an unnamed properties file. Googling and a quick glance at the code
got me no further, so I decided to hack it for now and come back to Maven later. Of course,
for a "sustainable" solution, I'll have to engage the Maven build.

2) I decided to just run XSL stylesheets against the Sling bundlelists to make Karaf feature
lists. This is not a good approach for any length of time, but time marches on and so do I,
so I wanted to try to get something up and running.

3) I dropped the OSGi framework bundlelist entirely, because the only things I needed from
it were the Felix webconsole, which is available as a Karaf feature, an OSGi DS implementation
(I picked Felix's, for obvious reasons) and an HTTP service (again, I chose Felix's).

4) I ran into an issue with Jersey. It uses the SPI machinery to configure itself, which does
not make OSGi resolution happy. It's a known issue, although I don't know whether the Jersey
folks actually consider it a problem. The quickest way forward was just to copy the jersey-server
META-INF/services directory into the Stanbol o.a.s.commons.web.base bundle. Again, a hack,
but I thought it better not to trouble too much about Jersey while issues like:

are in play.

5) After getting the Stanbol Commons and EntityHub up and started, I had to manually configure
the EntityHub's own Yard. This wasn't difficult, but it's not totally clear to me why the
bundles didn't do this on activation.

And now I'm happily moving entities in and out of the Hub! The REST API is functional.

Now I'm moving on to the other parts of the 'stable' suite.

Thanks for the help so far!

- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library

On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:

> Hi
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot
of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time
at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri
to some XForms applications, and I was impressed by how quickly I could index and deploy new
> Thank you for the very positive feedback.
>> I've got a question about Stanbol's build and deployment. Currently, it uses the
Sling launcher gear to assemble components into an instance. I see that there is some support
in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories
for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix,
and I would very much like to be able to reuse that investment and knowledge.
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository
functionality? Is there any experience with this or any known pitfalls?
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
> Before I come to the details let me add two things:
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at ""
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
> - - - - - - - - - - - - - - -
> BundleLists:
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
> The following lists are required by Apache Stanbol:
> 1. OSGI framework bundle list:
>    I assume that you will already have most of those dependencies. I
> assume that you will not need "" because
> Karaf will have an own logging component.
> 2. Stanbol Commons bundle list:
> There are some dependencies that need further investigation
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
> Related dependencies:
>    * This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>    * required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>    * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>    * Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>    * This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
>    * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "" as it will install
> the configurations in the configured directory as soon as it stats.
> (b) Jersey
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
> The rest of the dependencies should not have any issues.
> 3. Enhancer Bundle List:
> 4. Entityhub Bundle List:
> 5. Data Bundle List:
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
> The Full launcher uses additional Bundle list:
> * CMS Adapter:
>    Allows to connect Stanbol directly with CMIS, JCR
> * Contenthub:
>   I think this depends on the Enhancer and the CMS Adapter
> * FactStore:
> * Ontology Manager:
> * Rules:
> * Reasoners
>    Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
> [1]
> [2]
> [3]
> [4]
> [5]
>> Thanks again for a really elegant set of software components. I'm looking forward
to exploring more!
> Hope this helps
> best
> Rupert
> -- 
> | Rupert Westenthaler   
> | Bodenlehenstra├če 11                             ++43-699-11108907
> | A-5500 Bischofshofen

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -


View raw message