Hi Andreas: http://team.ops4j.org/browse/PAXRUNNER-403
Cheers, David On 1 September 2011 07:55, Andreas Pieber <[email protected]> wrote: > Well, after following this thread a while (and not giving Jboss7 a look > right now tbh) I don't see a reason why there shouldn't be a pax-runner > profile for it if someone likes to stand up and do it :-) @David: can you > please create an issue referencing to this thread that we don't loose the > information somewhere in the history at least? > Thanks and kind regards, > Andreas > > On Wed, Aug 31, 2011 at 10:11, David Bosschaert <[email protected]> > wrote: >> >> 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 > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
