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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
Best regards,
Harald
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
