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 <ad...@cs.unibo.it> on 2010/12/15 15:54:26 UTC
Running Stanbol on other OSGi containers
Hi,
I'd like to test Stanbol bundles on an OSGi environments other than
Felix, esp. Equinox.
Before setting up the environment, I was wondering if I can expect these
bundles to run despite the fact there are Felix SCR components and
services.
In my understanding, declarative services are part of the OSGi
specifications, but what if in the Java code they are defined with Felix
annotations (@Component, @Reference etc.)? Are they converted to
"standardized" component/service declarations at build time? I haven't
found anything of much use in the generated MANIFEST.MF files.
Thanks
Alessandro
Re: Running Stanbol on other OSGi containers
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Thanks Bertrand,
I can see that now... I was browsing bundles that just provided the
interfaces and lacked that directory. I overlooked the fact that Felix
annotations are concentrated in the service implementations.
Will try that out on Equinox and let you know. I'm going to launch the
environment from Eclipse rather than the Sling launcher.
Thanks again,
Alessandro
On 12/15/10 4:06 PM, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Dec 15, 2010 at 3:54 PM, Alessandro Adamou<ad...@cs.unibo.it> wrote:
>> ...I'd like to test Stanbol bundles on an OSGi environments other than Felix,
>> esp. Equinox.
>>
>> Before setting up the environment, I was wondering if I can expect these
>> bundles to run despite the fact there are Felix SCR components and services....
> In theory yes, I'm not sure about our Sling-based launcher but you
> might not even use it IIUC.
>
>> In my understanding, declarative services are part of the OSGi
>> specifications, but what if in the Java code they are defined with Felix
>> annotations (@Component, @Reference etc.)? Are they converted to
>> "standardized" component/service declarations at build time? I haven't found
>> anything of much use in the generated MANIFEST.MF files...
> The annotations are processed at build time by the maven-scr-plugin
> [1] so they have no impact at runtime.
>
> The result is written to serviceComponents.xml files found at
> target/classes/OSGI-INF/serviceComponents.xml for modules that call
> this maven plugin. Those xml files get included in the bundles and
> that's what the SCR subsystem uses.
>
> -Bertrand
>
> [1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
>
Re: Running Stanbol on other OSGi containers
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Bertrand,
Indeed successful Equinox+SCR configurations are what I first went
looking for and will keep looking, and also the Equinox mailing list.
However, we have started work on refactoring the KReS components so that
they can still launch when SCR is missing (see issue STANBOL-10). We'll
keep you posted on that.
Thanks,
Alessandro
On 12/21/10 9:51 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Mon, Dec 20, 2010 at 6:13 PM, Alessandro Adamou<ad...@cs.unibo.it> wrote:
>> Some progress:
>>
>>> Did you install the required SCR runtime bundles? You need at least
>>> the org.apache.felix.scr (or Equinox equivalent) bundle
>> I thought org.eclipse.equinox.dr (Declarative Services) could be the one,
>> but adding it resulted in no effect...
> I don't know enough about Equinox to be more specific, but I would
> recommend looking for an Equinox example that use SCR and works, this
> would help find out exactly what you need.
>
>> So I added these bundles to the platform (as per the lite launcher
>> list.xml):
>>
>> - org.apache.felix:org.osgi.core:1.2.0
> that's the OSGi framework itself, you should not add it IMO. Having to
> add it might mean that the Felix SCR components depend on a more
> recent version of the framework than Equinox is providing, but you'll
> end up with a mess if you add it.
>
>> - org.apache.felix:org.apache.felix.scr:1.4.0
>> - org.apache.felix:org.apache.felix.configadmin:1.2.4
>> - org.apache.felix:org.apache.felix.metatype:1.0.4
>> - org.osgi:org.osgi.compendium:4.1.0
>>
>> and their dependencies (resolved automatically by Eclipse)....
>>
>> This time a few components did start, but only the ones that did not have a
>> configuration (i.e. no variables annotated with @Property). The others won't
>> start.
>>
>> The first time I tried it out I was getting, for every component with a
>> configuration, a ClassCastException:
>> "org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
>> org.osgi.service.cm.ConfigurationAdmin" was thrown....
> Confirms that you've then got several versions of the platform
> interfaces in your system, not good.
>
>> Then I remade an OSGi config from scratch and the exception was gone. Still,
>> no components with properties were activated.
>>
>> I thought org.apache.felix.configadmin was the bundle that would provide
>> this feature, but maybe I'm wrong?...
> I think you really need to come up first with an Equinox setup that
> runs the simplest SCR component that you can find, and then try
> running the stanbol SCR components on that.
>
> -Bertrand
>
Re: Running Stanbol on other OSGi containers
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Dec 20, 2010 at 6:13 PM, Alessandro Adamou <ad...@cs.unibo.it> wrote:
> Some progress:
>
>> Did you install the required SCR runtime bundles? You need at least
>> the org.apache.felix.scr (or Equinox equivalent) bundle
>
> I thought org.eclipse.equinox.dr (Declarative Services) could be the one,
> but adding it resulted in no effect...
I don't know enough about Equinox to be more specific, but I would
recommend looking for an Equinox example that use SCR and works, this
would help find out exactly what you need.
>
> So I added these bundles to the platform (as per the lite launcher
> list.xml):
>
> - org.apache.felix:org.osgi.core:1.2.0
that's the OSGi framework itself, you should not add it IMO. Having to
add it might mean that the Felix SCR components depend on a more
recent version of the framework than Equinox is providing, but you'll
end up with a mess if you add it.
> - org.apache.felix:org.apache.felix.scr:1.4.0
> - org.apache.felix:org.apache.felix.configadmin:1.2.4
> - org.apache.felix:org.apache.felix.metatype:1.0.4
> - org.osgi:org.osgi.compendium:4.1.0
>
> and their dependencies (resolved automatically by Eclipse)....
>
> This time a few components did start, but only the ones that did not have a
> configuration (i.e. no variables annotated with @Property). The others won't
> start.
>
> The first time I tried it out I was getting, for every component with a
> configuration, a ClassCastException:
> "org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
> org.osgi.service.cm.ConfigurationAdmin" was thrown....
Confirms that you've then got several versions of the platform
interfaces in your system, not good.
>
> Then I remade an OSGi config from scratch and the exception was gone. Still,
> no components with properties were activated.
>
> I thought org.apache.felix.configadmin was the bundle that would provide
> this feature, but maybe I'm wrong?...
I think you really need to come up first with an Equinox setup that
runs the simplest SCR component that you can find, and then try
running the stanbol SCR components on that.
-Bertrand
Re: Running Stanbol on other OSGi containers
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Many thanks Bertrand.
Some progress:
> Did you install the required SCR runtime bundles? You need at least
> the org.apache.felix.scr (or Equinox equivalent) bundle
I thought org.eclipse.equinox.dr (Declarative Services) could be the
one, but adding it resulted in no effect.
So I added these bundles to the platform (as per the lite launcher
list.xml):
- org.apache.felix:org.osgi.core:1.2.0
- org.apache.felix:org.apache.felix.scr:1.4.0
- org.apache.felix:org.apache.felix.configadmin:1.2.4
- org.apache.felix:org.apache.felix.metatype:1.0.4
- org.osgi:org.osgi.compendium:4.1.0
and their dependencies (resolved automatically by Eclipse).
This time a few components did start, but only the ones that did not
have a configuration (i.e. no variables annotated with @Property). The
others won't start.
The first time I tried it out I was getting, for every component with a
configuration, a ClassCastException:
"org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
org.osgi.service.cm.ConfigurationAdmin" was thrown.
Then I remade an OSGi config from scratch and the exception was gone.
Still, no components with properties were activated.
I thought org.apache.felix.configadmin was the bundle that would provide
this feature, but maybe I'm wrong?
Regards,
Alessandro
Re: Running Stanbol on other OSGi containers
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Dec 20, 2010 at 1:07 PM, Alessandro Adamou <ad...@cs.unibo.it> wrote:
> I've been making runs through Eclipse-generated Equinox frameworks, and
> eventually pulled in the Stanbol bundles I needed.
>
> From an OSGi console ss I can see bundles are activated, but their
> components are not. I don't see the effects of any execution of the
> activate() methods at least.
>
> So the bad news is that SCR components seem to be ignored. The good news is
> that this doesn't seem to prevent bundles from activating. Looks like this
> means having a fallback strategy for non-Felix environments....
Did you install the required SCR runtime bundles? You need at least
the org.apache.felix.scr (or Equinox equivalent) bundle and maybe some
additional ones, check what the FISE runtime is using.
-Bertrand
Re: Running Stanbol on other OSGi containers
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi,
I've been making runs through Eclipse-generated Equinox frameworks, and
eventually pulled in the Stanbol bundles I needed.
From an OSGi console ss I can see bundles are activated, but their
components are not. I don't see the effects of any execution of the
activate() methods at least.
So the bad news is that SCR components seem to be ignored. The good news
is that this doesn't seem to prevent bundles from activating. Looks like
this means having a fallback strategy for non-Felix environments.
Alessandro
On 12/15/10 4:06 PM, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Dec 15, 2010 at 3:54 PM, Alessandro Adamou<ad...@cs.unibo.it> wrote:
>> ...I'd like to test Stanbol bundles on an OSGi environments other than Felix,
>> esp. Equinox.
>>
>> Before setting up the environment, I was wondering if I can expect these
>> bundles to run despite the fact there are Felix SCR components and services....
> In theory yes, I'm not sure about our Sling-based launcher but you
> might not even use it IIUC.
>
>> In my understanding, declarative services are part of the OSGi
>> specifications, but what if in the Java code they are defined with Felix
>> annotations (@Component, @Reference etc.)? Are they converted to
>> "standardized" component/service declarations at build time? I haven't found
>> anything of much use in the generated MANIFEST.MF files...
> The annotations are processed at build time by the maven-scr-plugin
> [1] so they have no impact at runtime.
>
> The result is written to serviceComponents.xml files found at
> target/classes/OSGI-INF/serviceComponents.xml for modules that call
> this maven plugin. Those xml files get included in the bundles and
> that's what the SCR subsystem uses.
>
> -Bertrand
>
> [1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
>
Re: Running Stanbol on other OSGi containers
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 15, 2010 at 3:54 PM, Alessandro Adamou <ad...@cs.unibo.it> wrote:
> ...I'd like to test Stanbol bundles on an OSGi environments other than Felix,
> esp. Equinox.
>
> Before setting up the environment, I was wondering if I can expect these
> bundles to run despite the fact there are Felix SCR components and services....
In theory yes, I'm not sure about our Sling-based launcher but you
might not even use it IIUC.
>
> In my understanding, declarative services are part of the OSGi
> specifications, but what if in the Java code they are defined with Felix
> annotations (@Component, @Reference etc.)? Are they converted to
> "standardized" component/service declarations at build time? I haven't found
> anything of much use in the generated MANIFEST.MF files...
The annotations are processed at build time by the maven-scr-plugin
[1] so they have no impact at runtime.
The result is written to serviceComponents.xml files found at
target/classes/OSGI-INF/serviceComponents.xml for modules that call
this maven plugin. Those xml files get included in the bundles and
that's what the SCR subsystem uses.
-Bertrand
[1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html