You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "John E. Conlon" <jc...@verticon.com> on 2005/11/10 23:01:46 UTC
Using ServiceTracker
While doing some testing with bundle development on Eclipse, Felix OSGi,
framework, and the Felix OSGi M2 plugin, I have encountered class
loading problems with the ServiceTracker.
java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTracker
is thrown when my bundle is started.
Eclipse and M2 can find the class for compiling and building but Felix
can't find it at bundle start time.
Just starting out with Felix and OSGi perhaps I am doing something
fundamentally wrong?
Any suggestions?
thanks
John
Re: Using ServiceTracker
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2005-11-15 at 04:45, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> > On Fri, 2005-11-11 at 02:18, Enrique Rodriguez wrote:
> ...
> >>In the same way that you are importing 'log' you also need to import
> >>'tracker' and since you are using an Activator you'll need 'framework', too.
> >
> > Up to this point I have not imported org.osgi.framework and finding the
> > BundleActivator worked okay (When I did not use the tracker that is, -
> > when I just 'manually managed my services.)
> > Explicitly importing the org.osgi.framework and org.osgi.util.* classes
> > seems counter-intuitive, (of course I'm a beginner still coming up to
> > speed.) But one would think all the framework classes should be
> > accessible on the parent classloader. Or at least I did with framework.
>
> Did BJ's explanation make sense? This is core OSGi philosophy. By
> requiring the bundle to import what it needs, it can even use a
> different framework version from the framework it is running on.
Yes it does. (Thanks BJ)
>
> > I made the change you recommended and now I get:
> > [ 12] [Installed ] [ 1] My OSGi Felix Experiment 1 (1.0-SNAPSHOT)
> > -> start 12
> > org.osgi.framework.BundleException: Unresolved package in bundle 12:
> > org.osgi.util.tracker
>
> Perfect. Now we're at Long Answer #2, where we need to get bundlized
> and Mavenized OSGi jars out there. In other words, your import is now
> working but there's no corresponding export.
Thought I would test my newly 'fixed' (but now broken felix) bundle in
the 3.2.0 equinox osgi implementation. Before the change it did not work
in equinox but now it does! (My dream of interoperability is now
restored).
> >>Long Answer:
> ...
> > Is the ant right? Or should the org.osgi.util.tracker package be
> > included in the osgi.jar? If it was I would expect to find the
> > ServiceTracker as it's in the latest src tree and it jar up very easily
> > with a <include name="org/osgi/util/**"/> added to the jar command.
> ...
> >>2) The jars coming from OSGi Alliance aren't bundlized, so even if you
> >>were importing the right packages, and you had the OSGi jars
> >>installed/started, they wouldn't be exporting what you need. I think
> >>what we should do is create a wrapper project here at Felix to re-wrap
> >>the OSGi jars as bundles and to work with Maven 2.
> >
> > What is the difference between the org.osgi.util.tracker.ServiceTracker
> > in the <felix home>/lib/osgi.jar and the one that is in
> > <artifactId>org.osgi.compendium</artifactId>
> > <version>4.0</version>
> > Why two different jars?
>
> The presence of the OSGi classes in the Felix framework is largely a
> leftover from when Felix R4 started development. Up until mid-October
> (when R4 was released) we had to obtain the draft R4 EPL'd sources and
> check them into our SVN. The R4 jars are now released from the OSGi
> Alliance. This is an example of "make it work" and now we need to "make
> it work right." The correct way to import the OSGi packages will be
> from the bundlized OSGi jars and we'll work soon to clean up the
> framework in SVN. So, no, we won't start include'ing more service or
> util packages, we'll work to remove packages in SVN that shouldn't be there.
Right.
Then your previous comments regarding wrapping these packages:
> 2) The jars coming from OSGi Alliance aren't bundlized, so even if
> you
> were importing the right packages, and you had the OSGi jars
> installed/started, they wouldn't be exporting what you need. I think
> what we should do is create a wrapper project here at Felix to re-wrap
> the OSGi jars as bundles and to work with Maven 2.
Would be related to wrapping the other util packages mentioned on the
thread 'request for contributions'?
> > org.osgi.util.measurement The OSGi Measurement Package.
> > org.osgi.util.position The OSGi Position Package.
> ...
>
> It has been brought to my attention that 'measurement' and 'position'
> are utility classes provided in the OSGi R4 Compendium jar. I did not
> know that. We do not need to re-implement anything, including any of
> the other requested contribution packages if they are already
> provided.
regards,
John
Re: Using ServiceTracker
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
> On Fri, 2005-11-11 at 02:18, Enrique Rodriguez wrote:
...
>>In the same way that you are importing 'log' you also need to import
>>'tracker' and since you are using an Activator you'll need 'framework', too.
>
> Up to this point I have not imported org.osgi.framework and finding the
> BundleActivator worked okay (When I did not use the tracker that is, -
> when I just 'manually managed my services.)
> Explicitly importing the org.osgi.framework and org.osgi.util.* classes
> seems counter-intuitive, (of course I'm a beginner still coming up to
> speed.) But one would think all the framework classes should be
> accessible on the parent classloader. Or at least I did with framework.
Did BJ's explanation make sense? This is core OSGi philosophy. By
requiring the bundle to import what it needs, it can even use a
different framework version from the framework it is running on.
> I made the change you recommended and now I get:
> [ 12] [Installed ] [ 1] My OSGi Felix Experiment 1 (1.0-SNAPSHOT)
> -> start 12
> org.osgi.framework.BundleException: Unresolved package in bundle 12:
> org.osgi.util.tracker
Perfect. Now we're at Long Answer #2, where we need to get bundlized
and Mavenized OSGi jars out there. In other words, your import is now
working but there's no corresponding export.
>>Long Answer:
...
> Is the ant right? Or should the org.osgi.util.tracker package be
> included in the osgi.jar? If it was I would expect to find the
> ServiceTracker as it's in the latest src tree and it jar up very easily
> with a <include name="org/osgi/util/**"/> added to the jar command.
...
>>2) The jars coming from OSGi Alliance aren't bundlized, so even if you
>>were importing the right packages, and you had the OSGi jars
>>installed/started, they wouldn't be exporting what you need. I think
>>what we should do is create a wrapper project here at Felix to re-wrap
>>the OSGi jars as bundles and to work with Maven 2.
>
> What is the difference between the org.osgi.util.tracker.ServiceTracker
> in the <felix home>/lib/osgi.jar and the one that is in
> <artifactId>org.osgi.compendium</artifactId>
> <version>4.0</version>
> Why two different jars?
The presence of the OSGi classes in the Felix framework is largely a
leftover from when Felix R4 started development. Up until mid-October
(when R4 was released) we had to obtain the draft R4 EPL'd sources and
check them into our SVN. The R4 jars are now released from the OSGi
Alliance. This is an example of "make it work" and now we need to "make
it work right." The correct way to import the OSGi packages will be
from the bundlized OSGi jars and we'll work soon to clean up the
framework in SVN. So, no, we won't start include'ing more service or
util packages, we'll work to remove packages in SVN that shouldn't be there.
Enrique
Re: Using ServiceTracker
Posted by BJ Hargrave <ha...@us.ibm.com>.
"John E. Conlon" <jc...@verticon.com> wrote on 2005-11-11 07:09:31 PM:
> On Fri, 2005-11-11 at 02:18, Enrique Rodriguez wrote:
> > John E. Conlon wrote:
> > ...
> >
> > Hi, John,
> >
> > The POM nicely put everything in one place so I can provide some
> > feedback. I have a short answer and a long answer:
> >
> > Short Answer:
> >
> > In the same way that you are importing 'log' you also need to import
> > 'tracker' and since you are using an Activator you'll need
'framework', too.
>
> Up to this point I have not imported org.osgi.framework and finding the
> BundleActivator worked okay (When I did not use the tracker that is, -
> when I just 'manually managed my services.)
> Explicitly importing the org.osgi.framework and org.osgi.util.* classes
> seems counter-intuitive, (of course I'm a beginner still coming up to
> speed.) But one would think all the framework classes should be
> accessible on the parent classloader. Or at least I did with framework.
This was common with pre-R4 frameworks since the parent classloader was
often the frameworks class loader. But a bundle is still in error if it
does not import all the org.osgi package it uses. This is how a bundle
declares its dependency on the specific framework version it need by the
org.osgi.framework package import version.
With R4 (and with some pre-R4) frameworks, the framework's class loader
will not be the parent of the bundle's class loader. This addresses 2
issues. (1) performance: avoid searching the framework impl and (2)
implementation hiding: the framework impl classes should not be visible to
a bundle for proper modularity reasons.
>
> >
> > <importPackage>org.osgi.service.log,org.osgi.util.tracker,org.
> osgi.framework</importPackage>
>
> I made the change you recommended and now I get:
> [ 12] [Installed ] [ 1] My OSGi Felix Experiment 1 (1.0-SNAPSHOT)
> -> start 12
> org.osgi.framework.BundleException: Unresolved package in bundle 12:
> org.osgi.util.tracker
Some bundle or the System Bundle (i.e. framework impl) needs to export
this package at the version you require.
>
> >
> > Long Answer:
> >
> > 1) You are using 'scope' 'provided' which means the dependencies
won't
> > be included in your jar and added to the Bundle-Classpath. This is
> > recommended for OSGi jars and the reason you need to import these
> > packages. Despite the presence of the OSGi API packages in the Felix
> > framework project, they are not included in the felix jar during the
Ant
> > build.
> Right the felix.jar just has org.apache.* packages in it but it is
> specifying osgi.jar and moduleloader.jar on it's manifest classpath. The
> ant build for creating the osgi.jar has:
> <!-- Create OSGi JAR file. -->
> -
> <target name="osgi" depends="compile">
> -
> <jar jarfile="${lib.dir}/osgi.jar" basedir="${output.dir}">
> <include name="org/osgi/framework/**"/>
> <include name="org/osgi/service/packageadmin/**"/>
> <include name="org/osgi/service/startlevel/**"/>
> <include name="org/osgi/service/url/**"/>
> </jar>
> </target>
>
> It's got the framework in it but no util packages. This appears to be
> why the org.osgi.framework.BundleActivator was available to me when I
> did not do a explicit importPackage of it and why I could not find the
> org.osgi.util.tracker.ServiceTracker class.
>
> Is the ant right? Or should the org.osgi.util.tracker package be
> included in the osgi.jar? If it was I would expect to find the
> ServiceTracker as it's in the latest src tree and it jar up very easily
> with a <include name="org/osgi/util/**"/> added to the jar command.
>
> >
> > 2) The jars coming from OSGi Alliance aren't bundlized, so even if
you
> > were importing the right packages, and you had the OSGi jars
> > installed/started, they wouldn't be exporting what you need. I think
> > what we should do is create a wrapper project here at Felix to re-wrap
> > the OSGi jars as bundles and to work with Maven 2.
> What is the difference between the org.osgi.util.tracker.ServiceTracker
> in the <felix home>/lib/osgi.jar and the one that is in
> <artifactId>org.osgi.compendium</artifactId>
> <version>4.0</version>
> Why two different jars?
> >
> > 3) With Rob Walker's mangen contribution, we should be able to rig in
> > more automatic import and export dependency resolution. Though, as
with
> > the old Maven 1 OSGi plugin, if you set an import or export statement
in
> > the POM, automatic resolution is skipped.
> >
> > 4) The current version of maven-osgi-plugin doesn't use the POM
project
> > metadata for much, it seems. I'll make sure we add in manifest entry
> > acquisition for basic entries such as bundleName, bundleDescription,
and
> > bundleVendor. I thought that was in there. That will be easy to add.
> >
> > 5) You shouldn't need the dependency on R3. You need R4-core for the
> > framework and R4-compendium for tracker and log, though.
> Removed the R3 dependency.
>
> Like to mention how pleased I am with the M2 plug in. (As well as the
> felix OSGi project in general.) My whole development workflow is light
> years ahead of my previous ant/nano container/ivy environment. Thanks
> for all the excellent work.
> rgds,
> John
> PS - I will save my testimonials on the apacheDS for another newslist.
> ;-).
>
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Re: Using ServiceTracker
Posted by "John E. Conlon" <jc...@verticon.com>.
On Fri, 2005-11-11 at 02:18, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> ...
>
> Hi, John,
>
> The POM nicely put everything in one place so I can provide some
> feedback. I have a short answer and a long answer:
>
> Short Answer:
>
> In the same way that you are importing 'log' you also need to import
> 'tracker' and since you are using an Activator you'll need 'framework', too.
Up to this point I have not imported org.osgi.framework and finding the
BundleActivator worked okay (When I did not use the tracker that is, -
when I just 'manually managed my services.)
Explicitly importing the org.osgi.framework and org.osgi.util.* classes
seems counter-intuitive, (of course I'm a beginner still coming up to
speed.) But one would think all the framework classes should be
accessible on the parent classloader. Or at least I did with framework.
>
> <importPackage>org.osgi.service.log,org.osgi.util.tracker,org.osgi.framework</importPackage>
I made the change you recommended and now I get:
[ 12] [Installed ] [ 1] My OSGi Felix Experiment 1 (1.0-SNAPSHOT)
-> start 12
org.osgi.framework.BundleException: Unresolved package in bundle 12:
org.osgi.util.tracker
>
> Long Answer:
>
> 1) You are using 'scope' 'provided' which means the dependencies won't
> be included in your jar and added to the Bundle-Classpath. This is
> recommended for OSGi jars and the reason you need to import these
> packages. Despite the presence of the OSGi API packages in the Felix
> framework project, they are not included in the felix jar during the Ant
> build.
Right the felix.jar just has org.apache.* packages in it but it is
specifying osgi.jar and moduleloader.jar on it's manifest classpath. The
ant build for creating the osgi.jar has:
<!-- Create OSGi JAR file. -->
-
<target name="osgi" depends="compile">
-
<jar jarfile="${lib.dir}/osgi.jar" basedir="${output.dir}">
<include name="org/osgi/framework/**"/>
<include name="org/osgi/service/packageadmin/**"/>
<include name="org/osgi/service/startlevel/**"/>
<include name="org/osgi/service/url/**"/>
</jar>
</target>
It's got the framework in it but no util packages. This appears to be
why the org.osgi.framework.BundleActivator was available to me when I
did not do a explicit importPackage of it and why I could not find the
org.osgi.util.tracker.ServiceTracker class.
Is the ant right? Or should the org.osgi.util.tracker package be
included in the osgi.jar? If it was I would expect to find the
ServiceTracker as it's in the latest src tree and it jar up very easily
with a <include name="org/osgi/util/**"/> added to the jar command.
>
> 2) The jars coming from OSGi Alliance aren't bundlized, so even if you
> were importing the right packages, and you had the OSGi jars
> installed/started, they wouldn't be exporting what you need. I think
> what we should do is create a wrapper project here at Felix to re-wrap
> the OSGi jars as bundles and to work with Maven 2.
What is the difference between the org.osgi.util.tracker.ServiceTracker
in the <felix home>/lib/osgi.jar and the one that is in
<artifactId>org.osgi.compendium</artifactId>
<version>4.0</version>
Why two different jars?
>
> 3) With Rob Walker's mangen contribution, we should be able to rig in
> more automatic import and export dependency resolution. Though, as with
> the old Maven 1 OSGi plugin, if you set an import or export statement in
> the POM, automatic resolution is skipped.
>
> 4) The current version of maven-osgi-plugin doesn't use the POM project
> metadata for much, it seems. I'll make sure we add in manifest entry
> acquisition for basic entries such as bundleName, bundleDescription, and
> bundleVendor. I thought that was in there. That will be easy to add.
>
> 5) You shouldn't need the dependency on R3. You need R4-core for the
> framework and R4-compendium for tracker and log, though.
Removed the R3 dependency.
Like to mention how pleased I am with the M2 plug in. (As well as the
felix OSGi project in general.) My whole development workflow is light
years ahead of my previous ant/nano container/ivy environment. Thanks
for all the excellent work.
rgds,
John
PS - I will save my testimonials on the apacheDS for another newslist.
;-).
Re: Using ServiceTracker
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
...
Hi, John,
The POM nicely put everything in one place so I can provide some
feedback. I have a short answer and a long answer:
Short Answer:
In the same way that you are importing 'log' you also need to import
'tracker' and since you are using an Activator you'll need 'framework', too.
<importPackage>org.osgi.service.log,org.osgi.util.tracker,org.osgi.framework</importPackage>
Long Answer:
1) You are using 'scope' 'provided' which means the dependencies won't
be included in your jar and added to the Bundle-Classpath. This is
recommended for OSGi jars and the reason you need to import these
packages. Despite the presence of the OSGi API packages in the Felix
framework project, they are not included in the felix jar during the Ant
build.
2) The jars coming from OSGi Alliance aren't bundlized, so even if you
were importing the right packages, and you had the OSGi jars
installed/started, they wouldn't be exporting what you need. I think
what we should do is create a wrapper project here at Felix to re-wrap
the OSGi jars as bundles and to work with Maven 2.
3) With Rob Walker's mangen contribution, we should be able to rig in
more automatic import and export dependency resolution. Though, as with
the old Maven 1 OSGi plugin, if you set an import or export statement in
the POM, automatic resolution is skipped.
4) The current version of maven-osgi-plugin doesn't use the POM project
metadata for much, it seems. I'll make sure we add in manifest entry
acquisition for basic entries such as bundleName, bundleDescription, and
bundleVendor. I thought that was in there. That will be easy to add.
5) You shouldn't need the dependency on R3. You need R4-core for the
framework and R4-compendium for tracker and log, though.
Enrique
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.verticon.felix</groupId>
> <artifactId>experiment1</artifactId>
> <packaging>osgi-bundle</packaging>
> <version>1.0-SNAPSHOT</version>
> <name>Felix Experiement 1</name>
> <url>http://www.verticon.com/felix/experiment1</url>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.felix.plugins</groupId>
> <artifactId>maven-osgi-plugin</artifactId>
> <extensions>true</extensions>
> <version>0.3.0</version>
> <configuration>
> <osgiManifest>
> <bundleName>My OSGi Felix Experiment 1</bundleName>
> <bundleDescription>Bundle that finds a logger and sends
> logging messages.</bundleDescription>
>
> <bundleActivator>com.verticon.osgi.felix.example1.Activator2</bundleActivator>
> <importPackage>org.osgi.service.log</importPackage>
> <bundleVendor>Verticon</bundleVendor>
> </osgiManifest>
> </configuration>
> </plugin>
> </plugins>
> </build>
> <dependencies>
>
> <dependency>
> <groupId>org.osgi</groupId>
> <artifactId>org.osgi</artifactId>
> <version>3.0</version>
> <scope>provided</scope>
> </dependency>
>
> <dependency>
> <groupId>org.osgi</groupId>
> <artifactId>org.osgi.compendium</artifactId>
> <version>4.0</version>
> <scope>provided</scope>
> </dependency>
>
> <dependency>
> <groupId>org.osgi</groupId>
> <artifactId>org.osgi.core</artifactId>
> <version>4.0</version>
> <scope>provided</scope>
> </dependency>
>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>3.8.1</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> </project>
Re: Using ServiceTracker
Posted by "John E. Conlon" <jc...@verticon.com>.
On Thu, 2005-11-10 at 17:19, Enrique Rodriguez wrote:
>
> Could you please post your pom.xml (assuming it's not private or gigantic) ?
>
> I think it will be easier to tell by looking at the POM first.
>
> Enrique
Here is the pom.xml...it's neither private nor gigantic but it could be embarrassing if
I've made a stupid mistake.
John
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.verticon.felix</groupId>
<artifactId>experiment1</artifactId>
<packaging>osgi-bundle</packaging>
<version>1.0-SNAPSHOT</version>
<name>Felix Experiement 1</name>
<url>http://www.verticon.com/felix/experiment1</url>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix.plugins</groupId>
<artifactId>maven-osgi-plugin</artifactId>
<extensions>true</extensions>
<version>0.3.0</version>
<configuration>
<osgiManifest>
<bundleName>My OSGi Felix Experiment 1</bundleName>
<bundleDescription>Bundle that finds a logger and sends
logging messages.</bundleDescription>
<bundleActivator>com.verticon.osgi.felix.example1.Activator2</bundleActivator>
<importPackage>org.osgi.service.log</importPackage>
<bundleVendor>Verticon</bundleVendor>
</osgiManifest>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi</artifactId>
<version>3.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.compendium</artifactId>
<version>4.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Re: Using ServiceTracker
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
...
> Any suggestions?
Could you please post your pom.xml (assuming it's not private or gigantic) ?
I think it will be easier to tell by looking at the POM first.
Enrique