|summary:||As some would say "HELL FROZE OVER."|
|date:||2008-03-26 21:47:31 UTC (8 years)|
|message:||As some would say "HELL FROZE OVER."
Merging FighterFish branch with trunk.
Corresponding HK2 workspace revision is #600.
To get back to the earlier point, check out from tag called
With this change, GlassFish can now run on *OSGi* platform in addition to HK2.
Tested on Apache Felix, but it should work on any OSGi R4 compliant platform.
By default, GlassFish would use HK2 until we change all things like asadmin
launcher, quicklook, etc.
The changes are described below:
1. A new module called javaee-api has been added. This has several sub-modules,
one for each javax API that's part of Java EE. Why we need this when we
already have api module? The reason is that api module is meant to be
vendor neutral. It uses groupId javax.javaee. It does not know about OSGi.
On the other hand, the new module, javaee-api, knows about OSGi and is
private to GlassFish project, hence it uses a groupId of org.glassfish.
All the javax.* APIs are now packaged as OSGi bundles and they are assembled
into a jumbo bundle called javax.javaee.jar. All GlassFish modules that were
referencing the javaee.jar from api module have been changed to refer to this
module in their pom.xml.
2. All HK2 modules in GlassFish have now also become OSGi bundles. How?
If a module uses packaging type hk2-jar, hk2-maven-plugin generates the
required OSGi manifest headers. There are some modules which don't use
hk2-jar packaging. I use the excellent maven-bundle-plugin from Felix to
do OSGi packaging. I recommend evey GlassFish v3 developer to take a look at
3. Fixed dependency on all pom.xml. This is needed for the following reason:
let's say module m1 depends on m2 and m3. m2 depends on m3. Because of
transitive dependency in Maven, in order to compile m1, it is sufficient to
specify dependency on m2 alone. The way our hk2-maven-plugin works is that
it generates a Require-Bundle header for m2 alone, so at runtime m1 only sees
m2. Therefore, when it tries to load any class from m3, it would get
NoClassDefFoundError. HK2 has been recently changes to work around this by
automatically adding m3 to m1's dependency at runtime. I don't want such
a solution on OSGi platform because of two reasons, viz:
a) runtime dependency of a module should be carefully constructed from
information that user supplies, otherwise system is going to be very slow.
b) when we switch to packaged based wiring of modules, we will not face this
issue at all, as maven-bundle-plugin would generate appropriate
Import-Package headers by analysing the class files. We don't currently
do this because we have some real "Split Packages" in our code base. Refer to
earlier email thread in dev alias to know what are the split packages that we
4. Added a URLHandlerService in webtier that registers a URL handler for
custom scheme called "jndi" that's used by webtier. This uses URL handler
service feature of OSGi platform. This is needed, because registration
of a new scheme in JVM is a one-time operation, and a OSGi platform
always tries to register a new scheme at startup. Look at the following file
for more details.
5. Change GlassFishTldProvider in jsf-connector and jstl module to stop
assuming the ClassLoader to be a URLClassLoader. Instead, they use
ModulesRegistry.find to locate the module and from their they get all the
URIs for that module.
6. Renamed org.apache.catalina.util.StringManager.class in war-util module
to org.apache.catalina.util.StringManagerTemp.class. Also changed every class
in war-util that referenced the old class to use the new class name. In fact,
only one such class was found - that's WebappClassLoader. This change is needed
because there exist such an identical class in webtier. Since webtier depends
on war-util, the class in webtier was shadowed by the one in war-util. Although
the classes are identical, depending on which module loads them decides what
ReosurceBundles are available to them. Hence the change.
7. We were using -1 in version numbers in many of the artifacts in api module.
They have all been changed to .1 (or similar one) so that the version is
compliant with Maven's version scheme. This issue was discussed in
dev@glassfish alias. I must say that this change has nothing to do with
OSGi related feature.
What does not yet work:
1. Rails app won't work while using OSGi platform until we resolve the use of
HK2 API called Module.addImport.
2. lib dir does not yet work. So, you need to explicitly add jars to -cp option.
3. Because of some issue, javaee-api is not yet built as part of v3 build.
Since this is a fairly static module, once we make the binary available
in maven repo, engineers should not see any issues.
4. We still don't export HK2 Service as OSGi service. This change needs to be
done in HK2/osgi-adapter.
5. We still don't make OSGi service available as HK2 service. This also has
to be done as part of HK2/osgi-adapter.
QuickLook passes on either mode.
Simple web apps, JSP, JSF, JSTL and JDBC datasource lookup all work.
More details about this change to be published soon. To be specific, I will
write how to run GlassFish v3 on OSGi platform.