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

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 twenty-something.

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] http://www.knopflerfish.org/repo/jars/http/http_all-1.0.0.jar [ 5] [Resolved ] [ 1] http://www.knopflerfish.org/releases/1.3.2/jars/log/log_api-1.0.0.jar [ 6] [Resolved ] [ 1] http://www.knopflerfish.org/releases/1.3.2/jars/cm/cm_api-1.0.0.jar [ 8] [Resolved ] [ 1] http://www.knopflerfish.org/releases/1.3.2/jars/jsdk/jsdk-2.2.jar


/Erik W

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

Erik Wistrand, erik@xxxxxxxxxxxx

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

Reply via email to:

Powered by MHonArc.

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