Hi Harald, On 30 August 2011 19:47, Harald Wellmann <[email protected]> wrote: > Am 30.08.2011 09:39, schrieb David Bosschaert: > >> AS7 does not run on an OSGi Framework >> - it internally runs on a proprietary module system. AS7 *is* an OSGi >> framework in the sense that end users can deploy OSGi bundles in it >> and use it as any OSGi Framework, in a way similar to Equinox and >> Felix. Granted, AS7 contains more stuff that's not OSGi-related, but >> we can ignore that in this thread I think :) >> > > I'm afraid we can't ignore that, because the meaning of "OSGi framework" is > defined in the OSGi Core Spec, and it does not mean "something you can > deploy OSGi bundles to". > > An OSGi framework provides a run-time environment for so-called bundles that > can be started and stopped dynamically. An OSGi framework eats its own dog > food by representing itself as the "system bundle" with bundle id 0.
AS7 supports all that and fully passes the OSGi 4.2 Core CT :) > From the OSGi perspective, bundles are atomic modules (let's forget about > fragments). So if the JBoss OSGi framework implementation has its own > internal module system or microkernel or whatever you call it, this is just > an implementation detail from the OSGi perspective. Yes, it's just an implementation detail. I only mentioned it to clarify that AS7 itself is not built on top of OSGi. > AS7 may well be running on something that is not OSGi but is able to > represent an OSGi framework, but this is irrelevant to the questions of > whether or not AS7 is an OSGi framework. > > When you start AS7 and inspect the OSGi runtime enviroment, you will see > dozens of active bundles. This is just what happens to be the default configuration. The default configuration (start level 1) will give you 9 bundles, but none of these are mandatory. Just like other OSGi frameworks may have a default configuration that contains a few bundles (e.g. Felix gives you 4). > When you start an OSGi framework, you will see just one bundle, the system > bundle 0. > > So this is why calling a full blown Java EE application server an OSGi > framework does not make sense. Because it has a few more bundles installed by default? Sorry I don't follow that argument :) >> JBoss OSGi is the subcomponent that adds the OSGi functionality to AS7 >> but the main distribution channel for this OSGi functionality is >> through AS7. Because AS7 is lightweight and starts up quickly there is >> generally no need to use the base subcomponent on its own... >> > > Oh cool, a new lightweight OSGi framework with a tiny 74 MB download ;-) > The Equinox Framework JAR is about 1,1 MB, the Apache Felix Framework is > about 400 KB... The runtime footprint of AS7 is very light weight - it generally starts up in under 2 seconds. Yeah, the download contains a lot, but that's just disk space. IMHO every project and product is free to choose how to package itself. > I downloaded the JBoss OSGi 1.0.0 distribution (13 MB) and gave it a try. > > Even when running the so-called minimal configuration (run.sh -c minimal), > there are four other bundles on top of the system bundle: > 18:52:29,897 INFO [msc] JBoss MSC version 1.0.0.CR2 > 18:52:30,144 INFO [BundleManager] JBossOSGi Framework Core - 1.0.0 > 18:52:30,454 INFO [BundleManager] Install bundle: system.bundle:0.0.0 > 18:52:30,510 WARN [vfs] VFS was unable to set the URLStreamHandlerFactory. > This will have unpredictable results > 18:52:30,668 INFO [BundleManager] Install bundle: > org.apache.felix.log:1.0.0 > 18:52:30,668 INFO [BundleManager] Install bundle: jboss-osgi-common:1.0.6 > 18:52:30,668 INFO [BundleManager] Install bundle: jbosgi-hotdeploy:1.0.10 > 18:52:30,871 INFO [BundleManager] Install bundle: > osgi.cmpn:4.2.0.200908310645 > 18:52:30,881 INFO [StartLevelPlugin] Starting bundles for start level: 1 > > so whatever this runtime may be, it is larger than an OSGi framework and > therefore not an OSGi framework. There are a few extra bundles in there but they aren't really mandatory. If you configure server/minimal/conf/jboss-osgi-framework.properties to remove all the lines that start with org.jboss.osgi.auto... you'll get your system-bundle-only framework: 08:46:39,886 INFO [msc] JBoss MSC version 1.0.0.CR2 08:46:40,005 INFO [BundleManager] JBossOSGi Framework Core - 1.0.0 08:46:40,145 INFO [BundleManager] Install bundle: system.bundle:0.0.0 08:46:40,167 INFO [StartLevelPlugin] Starting bundles for start level: 1 08:46:40,167 INFO [FrameworkActive] OSGi Framework started 08:46:40,168 INFO [OSGiBootstrapBean] JBossOSGi Runtime booted in 0.294sec > Digging a little deeper, I found that the JBoss OSGi project does indeed > provide Maven artifacts (not on Maven Central, unfortunately), and this one > here > > <dependency> > <groupId>org.jboss.osgi.framework</groupId> > <artifactId>jbosgi-framework-aggregated</artifactId> > <version>1.0.0</version> > <scope>test</scope> > </dependency> > > appears to be the thing that may legitimately be called an OSGi framework. So this artifact is actually an internal testing artifact, I would prefer not to use that with pax-runner simply because it's not going to be what people will be running when they are running a JBoss OSGi Framework that they downloaded. > I was able to launch it via the FrameworkFactory API and found nothing but > the system bundle itself running in it. > > So far, so good. > > Unlike Equinox or Felix, this artifact is not an executable JAR, so I have > no idea if there is a way to launch the stand-alone framework from the > commandline. > > The next thing I tried was running this framework via the Pax Exam Native > Container, which failed with a VFS exception because the framework would not > let me provision a bundle from a non-standard URL, a mandatory OSGi feature > used rather heavily in Pax projects. Could you please tell me what the exact exception was? Or file a bug so we can fix it? https://issues.jboss.org/browse/JBOSGI Ok, I understand is that what is needed is: 1. An executable JAR to start up the framework 2. Support for the FrameworkFactory API 3. A fix for the VFS issue > All in all, these first experiments leave me with mixed feelings. The fact > that there is now a new OSGi framework around which might gain some momentum > is certainly good news. > > On the other hand, JBoss OSGi appears to be just a means to the end of > running JBoss AS, much like Equinox originally was just a means to the end > of running Eclipse. Nope - JBoss OSGi is a component that provides fully compliant OSGi functionality to end users. It's not needed to run JBoss AS7. It can either be consumed standalone (via the JBoss OSGi project) or as part of AS7. We expect that people will prefer to consume it as part of the AS7 appserver, but both options are possible. > Eclipse has boosted the popularity of OSGi a lot, but it has also blurred > the casual user's ideas of OSGi by calling bundles plugins and introducing > non-standard features like buddy policies, source bundles, etc. > > I'm afraid that JBoss AS might now be doing the same thing, only much worse, > by bending established concepts and by doing something OSGi-ish without > offering a stand-alone 100 % OSGI compliant framework implementation. JBoss OSGi passes all the OSGi Core TCK tests. No bending going on here. If you want to have a naked JBoss OSGi framework you can get this from the JBoss OSGi project. The AS7 distro contains more, but you don't have to use it if you don't want to - it's still a fully compliant OSGi Framework. > If the JBoss OSGi project has any intention of attracting users who are > interested in OSGi for its own sake and don't either know or care much about > Java EE application servers in general or JBoss AS in particular, then they > should throw away all baggage, provide a framework-only artifact on Maven > Central and some documentation for using the framework and nothing but the > framework. Ok - thanks for these suggestions, I'll certainly take them into account! Now - back to the original question... If the 3 issues mentioned above can be resolved, will that be enough to allow pax-runner to launch JBoss OSGi? Thanks for the help, David _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
