For those that are not aware of ServiceMix Kernel (I know David is), i'd like to point them to it. Feel free to download it and give it a try. It's based on felix, gshell and a few other bundles. We're using it to deploy our JBI container in ServiceMix 4 (including the geronimo transaction manager, activemq, jetty, but those are not included in the kernel). See http://servicemix.apache.org/kernel/index.html
To add to this discussion, we are deploying stuff on servicemix using "features", which is imho the metdata related to (2). A feature is mostly a list of OSGi bundles with some dependencies on other features and some optional configuration. We are almost using Import-Packages exclusively, using spring-dm to configure most of our services ... 2009/3/17 Lin Sun <linsun....@gmail.com> > Rex, > > If you follow the discussion closely, I think David was just saying > that he prefers to stay away from Require-Bundle for now, as the OSGi > specification doesn't recommend people to use it, along with the probs > people mentioned about it in the link I posted earlier. > > I also found these links interesting - > > http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html > > > http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html > > David, > > Some comments regarding #2, its essential to know what > jars/bundles/plugins/modules are actually in your running system. > > I think OSGi framework provides the ability to display the currently > running bundles, so there should be APIs to get that. For example, > you type "ss" in equinox console to get the list of installed bundles: > > osgi> ss > > Framework is launched. > > id State Bundle > 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 > 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 > 17 RESOLVED org.osgi.impl.service.http_4.2.0.200902181209 > 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 > > OSGi framework also uses resolver to resolve bundles. For example, > if I want to install Bundle A to the framework, and Bundle imports > package AA, then when I install the bundle A, the OSGi framework uses > the resolver to find out if there is any bundle that exports package > AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A > will be marked as INSTALLED. If you search "resolver" in the OSGi > core spec, you'll see a couple of places that mention it. > > I recently took a look at the new OSGi bundle repository spec (RFC > 112). It talks about the concept of Resolver and the interface > Resolver It talks about scenarios where a user wants to install a > bundle (that uses Import-Package), the server should be able to pull > all its dependencies from the bundle repository (or repositories) on > the fly using the resolver. This seems something we would need for > geronimo. > > Lin > > > > > > > On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang <rwo...@gmail.com> wrote: > > "At the moment I'm inclined to think that require-bundle is not a > workable > > solution for (2) and so we might as well use import-package plus an osgi > > runtime that uses and requires explicit external dependency information > such > > as provided by maven or geronimo-plugin.xml to choose what bundle to > resolve > > to. " > > > > From my point of view, I am not quite like this "mix" version, because we > > must maintain the related information in two different places, that will > > absolutely increase geronimo's complexity and some sorts of confusing on > the > > dependency settings, not only to the developers but also the users. I > think > > one of the purpose that we adopt OSGi is to make our server > infrastructure > > "standardize" to the OSGi specification, but not to create a new > application > > model. Because this may lead to a non osgi compatiable bundle, IIUC, any > > bundle that wanna be used in geronimo must re-write to provide the > > additional mvn-style information. > > > > Why do you think the require-bundle is not a workable solution for (2) ? > > > > > > Rex. > > > > > > > > 2009/3/14 David Jencks <david_jen...@yahoo.com> > >> > >> On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: > >> > >>> David Jencks wrote: > >>>> > >>>> I read the blog entry and discussion. The entire discussion is > >>>> predicated on the idea that osgi is close to ideal as-is and we have > no need > >>>> to consider any other point of view. If you step back a bit I see two > >>>> things clearly acknowledged by everyone: > >>>> > >>>> 1. its useful to be able to know what classes are needed to make a > >>>> jar/bundle/plugin/module work and which classes are expected to be > used > >>>> elsewhere > >>>> 2. its essential to know what jars/bundles/plugins/modules are > actually > >>>> in your running system > >>>> > >>>> In osgi-land, import-package and export-package supply (1), and > >>>> require-bundle sort of helps with (2) but AFAICT right now doesn't > support > >>>> "artifact aliasing" > >>>> In maven-land, the pom dependency tracking provides a pretty good > >>>> solution for (2), including some support for overriding "requirements" > >>>> through exclusions, but it's single-classloader model doesn't > translate > >>>> directly into an app server or osgi runtime > >>>> In geronimo trunk we emphasize (2) and can actually assemble working > >>>> servers using it, and have support for (1) (although its mostly > backwards > >>>> from osgi specifications) > >>>> > >>>> I'd say that in my (limited) experience osgi zealots typically think > >>>> that (1) is essential and brush (2) under the carpet by working in > >>>> constrained environments such as their eclipse workspace. I'd say > that our > >>>> experience with geronimo is that (1) is rarely needed if you have a > working > >>>> (2) (look at how many hidden-classes and non-overriable classes > filters are > >>>> in our poms -- none for the use of geronimo, and a few to make > deploying > >>>> applications that include the same jars as us work) > >>>> > >>>> The geronimo/maven approach to (2) is to include the dependency > >>>> information with the artifact. I'm not sure what approach(es) osgi is > >>>> considering -- OBR appears to not consider bundling dependency info > with the > >>>> artifact but to have a completely external specification. I don't > know > >>>> about p2.... but since jason vanZyl seems to be looking at it I'd > guess it > >>>> is more maven friendly. > >>>> > >>>> If you don't bundle (2) with the artifacts then you need some kind of > >>>> import-package to artifact map or resolution system. We sort of have > some > >>>> vestiges of this today: when you deploy a web app as a geronimo plugin > (or > >>>> export it from a server where it was deployed) it has picked up > dependencies > >>>> on jetty or tomcat based on which deployer you specified in the plugin > >>>> project pom or which kind of server you deployed on. Another example > is > >>>> that the car-maven-plugin filters the view of the local maven repo so > only > >>>> the versions specified in the pom are visible to the geronimo server > we run > >>>> off the repo -- this allows you to build plugins for a 2.1.3 server > even if > >>>> you have 2.2-SNAPSHOT artifacts locally and some of the dependencies > don't > >>>> specify the version required. > >>>> > >>>> I don't know where the best balance for geronimo lies here. I > certainly > >>>> think claiming all we need is import-package is shortchanging most of > our > >>>> experience in producing geronimo as a working server. > >>> > >>> But on the other hand, I'd hate to have not using just Import-package > as > >>> the starting point. Given how much it is assumed in the OSGi world, it > >>> would be best to assume its use and only step outside of that box once > we've > >>> found the intractable problem that requires it. Starting outside of > those > >>> limits means we're abandoning the things OSGi does straight off because > >>> their may be some places where the exception mechanisms are required. > >> > >> Aren't you exhibiting exactly the same attitude as the blog posters in > >> saying the (2) is not really a problem we need to consider? Whereas all > our > >> work in getting geronimo to actually work has been focussed on solving > (2). > >> If we ditch our working system for (2) we won't have a server.... > perhaps > >> ever. In terms of assembling a server, without (2) the space of > possible > >> bundles to resolve to is the entire maven central repo. ( I anticipate > that > >> any working server is going to be able to convert plain jars to bundles > on > >> the fly. If not, no one who is not osgi-obsessed will be willing to use > it) > >> > >> At the moment I'm inclined to think that require-bundle is not a > workable > >> solution for (2) and so we might as well use import-package plus an osgi > >> runtime that uses and requires explicit external dependency information > such > >> as provided by maven or geronimo-plugin.xml to choose what bundle to > resolve > >> to. However until we get something working we won't know much about > whether > >> this or any proposal is a good or workable choice. > >> > >> I'm still waiting for news of a working osgi system that is comparable > in > >> scale to eclipse that primarily uses import-package. > >> > >> thanks > >> david jencks > >> > >>> > >>> > >>> Rick > >>>> > >>>> thanks > >>>> david jencks > >>>> > >>>> On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: > >>>> > >>>>> I think I was not too clear below. I didn't mean to say that I am in > >>>>> favor of Require-Bundle because it is a lot harder to come up with > the > >>>>> right Import-Package lists. What I meant was that the reason why a > >>>>> lot of people are using Require-Bundle like David mentioned in his > >>>>> early notes is probably because it is a lot easier to use. > >>>>> > >>>>> I personally had to spend quite some time to figure out the prob I > >>>>> mentioned earlier - I was developing a bundle that needs to import > >>>>> the javax.transaction package from the transaction in OSGi bundle, > but > >>>>> two bundles have it (the basic OSGi J2SE and the transaction in OSGi > >>>>> bundle). I was able to resolve this using Import-Package with the > >>>>> specific version of javax.transaction package that I need. I just > >>>>> tried to switch to use Require-Bundle, that is to have my bundle to > >>>>> depend on the transaction in OSGi bundle as it contains the right > >>>>> version of the javax.transaction package I need, but my bundle is > >>>>> broken completely due to CDNFE. I don't think the Require-Bundle > >>>>> offers the fine grain control that I needed for my bundle and I am > >>>>> sure Geronimo would have a lot more complicated bundles than what I > >>>>> was developing. > >>>>> > >>>>> BTW, there's a good discussion here: > >>>>> > http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html > >>>>> > >>>>> - in particular in the first comment from Neil Bartlett and the > >>>>> limitations of Require-Bundle documented in the OSGi v 4.1 core spec > >>>>> (section 3.13.3). > >>>>> > >>>>> Lin > >>>>> > >>>>> > >>>>> On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun <linsun....@gmail.com> > wrote: > >>>>> > >>>>>> Not sure about Require-Bundle. I personally has never used it and I > >>>>>> never see it is being used in the OSGi repo. Require-Bundle may not > >>>>>> offer the level of control that the Import-Package provides but it > is > >>>>>> probably a lot harder to come up with the right Import-Package > lists. > >>>>>> I think this scenario should work just fine if using Import-Package. > >>>>>> > >>>> > >>>> > >>> > >> > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
