felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Using ServiceTracker
Date Sat, 12 Nov 2005 00:09:31 GMT
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:

> 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/**"/>

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 
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. 
PS - I will save my testimonials on the apacheDS for another newslist.

View raw message