Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: Using ServiceTracker
From: "John E. Conlon" <jconlon@verticon.com>
Reply-To: jconlon@verticon.com
To: erodriguez@apache.org
Cc: felix-dev@incubator.apache.org
In-Reply-To: <4379BC56.4060503@apache.org>
References: <1131660106.4079.27.camel@trout>  <4373D592.3050900@apache.org>
	 <1131683458.4080.38.camel@trout>  <437453F0.9050908@apache.org>
	 <1131754171.4074.80.camel@trout>  <4379BC56.4060503@apache.org>
Content-Type: text/plain
Organization: Verticon, Inc.
Message-Id: <1132075378.4098.149.camel@trout>
Mime-Version: 1.0
Date: 15 Nov 2005 11:22:58 -0600
Content-Transfer-Encoding: 7bit

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