richard jackson wrote:
I guess I read it more as we don't really need all the extra stuff that a
normal Servlet container has (class loading, war file deployments ect...).
Basicly only support bundles and bundles only. But then again I also want
filters and such as well. But anyways what I'm more thinking about is a
really light core bundle (spec only) then have the ability to plug in (via
bundles) more advanced stuff. Any ways this stuff is still just percolating
in my mind for now. Oh I do intend to grab what you have so far and take a
look at it as I'm sure it has much in it I can use.
The lightweight-ness of that JIRA issue really refers to something that
is small and only addresses the HTTP Service spec (although this latter
requirement is not strictly necessary if any extensions are really small
too). The point is, we really have two different use cases for an HTTP
Service:
1. A more full-featured implementation that could possibly handle
more advanced situations, perhaps offer extended capabilities for
WARs etc., and one that could be used for heavy-duty apps.
2. A more lightweight implementation that simply implements the HTTP
Service spec and does not use any advances JRE features so that it
could easy be used on the smallest devices to create web-enabled
applications.
I, personally, would love to see #2, since we already have some forms of
#1. We have even discussed moving PaxWeb to Felix subproject, for
example, which makes #2 the missing piece. Still, in the end, do what
interests you and we will see how it fits in.
-> richard
Richard
On Thu, Sep 4, 2008 at 8:16 AM, Richard S. Hall <[EMAIL PROTECTED]>wrote:
p.s. One thing I should point out, since you reference FELIX-538, is that
this issue is for a "really lightweight" HTTP Service. So, all of the stuff
you are discussing (i.e., iPOJO, Grizzly, Servlet 2.5, plus extensions) does
not really fit into this definition; however, that doesn't mean that you
shouldn't do it, do what interests you. But if you are interested in
addressing this issue, then it probably will require that you don't use
these technologies. This JIRA issue references a file-based http server in
my sandbox that is only about 6 or 7 files, I think this might be a good
place to start for a really lightweight HTTP Service implementation.
richard jackson wrote:
After I finish off learning what I need to know about felix I want to
tackle
writing a OSGi HTTP Service bundle. But I have a few questions about what
can be included in this bundle if I want to contribute it to Felix:
1) Can it contain out side code? In particular I'm thinking about Grizzly
(
https://grizzly.dev.java.net/ ). This is the front end used in both Jetty
and GlassFish which means it is already heavily tested and why reinvent
the
wheel if I don't have to. The potential problem is that it is under the
CDDL
and was not sure if that License is ok for a Apache project.
2) Is there a problem with extending the spec for this? For instance can I
expose a spec compliant service but also expose a enhanced service? Kind
of
like what the Pax Web bundle does (see
http://wiki.ops4j.org/confluence/display/ops4j/Pax+Web+-+Http+Service+Extensions
).
3) Can I use iPOJO for the service? Or do I need to just do it myself?
This
is not a issue I was just wondering as again why code it up by hand if I
can
just get iPOJO to do it for me. But then again maybe iPOJO can't do what I
will need for HTTP Service ( I'm still learning what it can do still
haven't
got far enough to know what it can't do )
4) The spec states that the HTTP Service must implement at least Servlet
spec 2.1 (If I remember correctly that is) whould implementing Servlet
Spec
2.5 satisfy the requirement? Yea I know maybe a stupid question but still
wanted to ask as I don't want to wast my research time if I don't have to.
Want to get the spec part done first before trying to do the added stuff I
want/need. If I have to do Servlet spec 2.1 does anyone know where I can
find the spec. I have only been able to find 2.3 and newer.
I'll have more questions as I look into doing this but for now that covers
the basics. (I have packaging questions as well but those questions depend
on answers to some of the questions)
Thanks
Richard Jackson
