Based on your experiences, i will share my experiences on a RI
As you said about a end user( a Developer) expects to have features of
full blown Http Server with features like JSPs, War's etc...
Coming to this requirement, as JSP's are derieved from Servlets Spec,
the osgi spec1.0 itself talks exclusively about the HttpService
The Servlet Specification is an integral part of OSGi. where in a servlet
is loaded by the Framework and that removes the burden of the
and also deeloping a different sand box according
to the JDK1.2 Sand spec.
Also it talks of developing of a Protocol Handler like bundle://, etc.. as
default there are 6 type of url handlers available in JDK, OSGi expects
such protocols so that resources or resource bundles can be
I think a good implementation would be not only support to Jar files, but
files and also ear files (as those types are resource bundles and
can use JarInputStream to resolve the
Also OSGi talks of handling non available URL contexts (like if
/x/y/index.html was not available
then /x/y or /x or / should be handling the
request) this way the error page need not be re designed.
Registering a Servlet / Resource is mostly based on SandBox of the JVM as
each bundle is loaded
a package in a bundle is not accessible in other, this
way malicious use of Servlet Contexts is
avoided there by providing
flexibility in registering various ServletContexts (ServletContexts as URL
This is a good feature provided. Normal Servlet implementations share a
and hence if two or more Servlets(belonging to
different services) can access each other regardless of
Also there is inter Bundle service sharing being done. This enables inter
service communication and
in the embedded world this kind of Service sharing
on demand is needed.
The above are some to be named. There are several intricacies involved in
the OSGi Spec
and those can be explored when the OSGi forum shares a
Compatibility Test Suite to
check if a OSGi RI is correct or now.....
Many and Many features and points need to be explored........
From: Erik Wistrand
Sent: Fri 7/30/2004 5:10 PM
[oscar] HTTP Service:: mapping URIs to servlets
> Grabbing a different turned out not to
be straightforward: the one I
> tried (Knopflerfish) had too many
dependencies to non-OSGi classes.
> I agree that it would be
nice to have a good HTTP Service bundle that
> 1- runs on different
frameworks (only standard OSGi interfaces)
> 2- makes it possible to
plug in server technologies (wars, jsp,
> velocity, ...)
makes it possible to plug in HTTPS
I can't resist
joining this discussion ;)
My experience is that the HTTP service has
been one of the more
problematic services in OSGi's history
- the user expectations of having full-blown web
functionality on an OSGi platform clashes with the design goals
embedded devices. E.g, queries for JSP pages are common, but it's
really reasonable to compile code on a small box. Likewise, an
parser may also me to much of an requirement.
servlet API itself contains a lot of functionality for managing
cycle of an application which is unnesseary or duplication
in an OSGi
- some mistakes has actually been done when
designing the http API,
such as not using the whiteboard model for
resources/servlet, and the actually quite meaningless
registration API (since servlets could have handled
Also, writing a web server seems deceptively easy at the first
but tend to grow into monsters really fast. Small issues like
paths, connection pools, keep-alive connections and CRLF handling
etc just eats your time and space.
So, my opinion is that you
have one of two choices:
a) integrate an existing full-blown web
service as an OSGi bundle
b) write a "smallish" web server that
skips most attempts at
being a framework in
It can be argued that a) is best if you don't have a good
> 1- runs on different frameworks (only
standard OSGi interfaces)
In principle, I agree, but which? ;) *no* API
org.osgi.framework is really required to be installed on any
framework. And the number of OSGi APIs are quickly
This triggers important question.
Should you, or should you not depend
on other bundles? Should necessary
APIs be included in every bundle, on
the cost of a larger deployment jar?
Or should you rely on systems as
OBR for resolving dependecies?
an example, the KF impl uses the log service API and the CM service
(and yes, it actually dares to use a single non-OSGi class for
tedious use of the logging service). It doesn't require
these services though. Perhaps even this is too many
they're quite easy to resolve. Comments on this is
very welcome, though.
The trouble with OBR in this case is that it might
pull in "unnecessary"
code as XML parser, even when the target bundle
doesn't really require
The following snippet is from running the KF http service
manually) on Oscar:
[ 0] [Active ]
[ 0] System Bundle
[Active ] [ 1] file:bundle/shell.jar
[Active ] [ 1] file:bundle/shelltui.jar
3] [Active ] [ 1] file:bundle/bundlerepository.jar
4] [Active ] [ 1]
5] [Resolved ] [ 1]
6] [Resolved ] [ 1]
8] [Resolved ] [ 1]
PS. BTW, the KF http impl does accept /x/y paths, which I believe
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@xxxxxxxxx immediately
and destroy all copies of this message and any attachments.