ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | oscar List | July 2004 Index

<--  Date Index  --> <--  Thread Index    

RE: [oscar] HTTP Service:: mapping URIs to servlets

Title: Re: [oscar] HTTP Service:: mapping URIs to servlets
Hi Eric,
Based on your experiences, i will share my experiences on a RI of HttpService.
As you said about a end user( a Developer) expects to have features of a
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 implementation.
The Servlet Specification is an integral part of OSGi. where in a servlet class
is loaded by the Framework and that removes the burden of the classloader functionality
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 by
default there are 6 type of url handlers available in JDK, OSGi expects handling
such protocols so that resources or resource bundles can be accessed.
I think a good implementation would be not only support to Jar files, but also war
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 Contexts).
This is a good feature provided. Normal Servlet implementations share a single ServletContexts
and hence if two or more Servlets(belonging to different services) can access each other regardless of
authenticaton or security checks.
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........

-----Original Message-----
From: Erik Wistrand [mailto:erik@xxxxxxxxxxxx]
Sent: Fri 7/30/2004 5:10 PM
To: Tom
Cc: oscar@xxxxxxxxxxxxx
Subject: Re: [oscar] HTTP Service:: mapping URIs to servlets

Tom wrote:

> 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, ...)
> 3- 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 deployment
functionality on an OSGi platform clashes with the design goals of
embedded devices. E.g, queries for JSP pages are common, but it's not
really reasonable to compile code on a small box. Likewise, an XML
parser may also me to much of an requirement.

  - the servlet API itself contains a lot of functionality for managing
the life cycle of an application which is unnesseary or duplication
in an OSGi environment.

  - some mistakes has actually been done when designing the http API,
such as not using the whiteboard model for registering
resources/servlet, and the actually quite meaningless resource
registration API (since servlets could have handled that).

Also, writing a web server seems deceptively easy at the first stabs,
but tend to grow into monsters really fast. Small issues like handling
paths, connection pools, keep-alive connections and CRLF handling etc
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 itself.

It can be argued that a) is best if you don't have a good starting point.

 > 1- runs on different frameworks (only standard OSGi interfaces)

In principle, I agree, but which? ;) *no* API except for
org.osgi.framework is really required to be installed on any given
framework. And the number of OSGi APIs are quickly approaching

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?

As an example, the KF impl uses the log service API and the CM service
API (and yes, it actually dares to use a single non-OSGi class for
wrapping the tedious use of the logging service). It doesn't require
implementation of these services though. Perhaps even this is too many
dependencies, but 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 it.

The following snippet is from running the KF http service (installed
manually) on Oscar:

 > ps -l
    ID   State         Level  Location
[   0] [Active     ] [    0] System Bundle
[   1] [Active     ] [    1] file:bundle/shell.jar
[   2] [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]


/Erik W

PS. BTW, the KF http impl does accept /x/y paths, which I believe is the

Erik Wistrand, erik@xxxxxxxxxxxx

Confidentiality Notice 

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.

<--  Date Index  --> <--  Thread Index    

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.