Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » eclipse server-side startup questions
eclipse server-side startup questions [message #57095] Wed, 18 January 2006 19:09 Go to next message
Jim DAnjou is currently offline Jim DAnjouFriend
Messages: 25
Registered: July 2009
Junior Member
Currently the server-side eclipse/OSGI platform is initialized using the
bridge servlet that is automatically started when the web container is
started.

Does this not mean that all OSGI-registered servlets are under the control
of the bridge servlet and not the web container itself? Has there been any
consideration to initializing OSGI using a servlet context listener which
is called by the web container when it starts and before any servlet is
run in lieu of the current bridge servlet?

Any features that the web container may provide such as caching of
requests are not likely to be supported in these OSGI-registered servlets.
Also are the lifecycle of the servlets spawned under OSGI (via HTTPService
or the extension point) like init and destroy the responsiblity of the
parent servlet to emulate?

Also I think OSGI registered servlets might want to be initialized on
startup. Currently I don't see an OSGI mechanism for this and its probably
required for any serious use of this platform. If it existed the bridge
servlet which needs to run first (among firsts) might result in some sort
of interference or a race condition.

Thanks,
Jim D'Anjou
Re: eclipse server-side startup questions [message #57122 is a reply to message #57095] Thu, 19 January 2006 03:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: skaegi.sympatico.ca

> Currently the server-side eclipse/OSGI platform is initialized using the
> bridge servlet that is automatically started when the web container is
> started.
>
> Does this not mean that all OSGI-registered servlets are under the control
> of the bridge servlet and not the web container itself?
Yes. The bridge servlet proxies all requests.

> Has there been any
> consideration to initializing OSGI using a servlet context listener which
> is called by the web container when it starts and before any servlet is
> run in lieu of the current bridge servlet?
Good question. This is something I'd like to do in the future when perhaps
more than just servlets are proxied ;)

> Any features that the web container may provide such as caching of
> requests are not likely to be supported in these OSGI-registered servlets.
Containers can do a good job with static files so... resources are an area
where we could use Http Headers more effectively to reduce load.
For servlet requests I'm not really sure what containers do, but I also
don't think the servlet bridge does anything that gets in the way.

> Also are the lifecycle of the servlets spawned under OSGI (via HTTPService
> or the extension point) like init and destroy the responsiblity of the
> parent servlet to emulate?
Yes, all of that is emulated.

> Also I think OSGI registered servlets might want to be initialized on
> startup. Currently I don't see an OSGI mechanism for this and its probably
> required for any serious use of this platform.
The OSGi registered servlets are always initialized on startup.
What's missing is a way to initialize them lazily.

> If it existed the bridge
> servlet which needs to run first (among firsts) might result in some sort
> of interference or a race condition.
The servlet bridge guarantees that it will be fully initialized before any
other OSGi registered servlet can service a request.
Now, there are still possible race conditions between the OSGi registered
servlets as controlling their start-up order is not directly managed.

I think many of your comments are directed towards having a server-side
model/API that more closely resembles the Servlet API.
I'm very interested in looking at the possibilities.

-Simon
Re: eclipse server-side startup questions [message #57149 is a reply to message #57122] Thu, 19 January 2006 19:24 Go to previous message
Richard Backhouse is currently offline Richard BackhouseFriend
Messages: 19
Registered: July 2009
Junior Member
Hi Simon,

Simon Kaegi wrote:
>>Currently the server-side eclipse/OSGI platform is initialized using the
>>bridge servlet that is automatically started when the web container is
>>started.
>>
>>Does this not mean that all OSGI-registered servlets are under the control
>>of the bridge servlet and not the web container itself?
>
> Yes. The bridge servlet proxies all requests.
>
>

This means that it won't be possible to mix web.xml defined servlets
with extension point defined servlets. I think it would be desirable to
support both methods of definition.

>>Has there been any
>>consideration to initializing OSGI using a servlet context listener which
>>is called by the web container when it starts and before any servlet is
>>run in lieu of the current bridge servlet?
>
> Good question. This is something I'd like to do in the future when perhaps
> more than just servlets are proxied ;)
>
>

I can think of a scenario where a Web Application would want to use an
OSGi framework without defining extension point servlets. In this case
bootstrapping the framework would be best performed in a
ServletContextListener. That way a Web Application could use an OSGi
framework without having to enable the bridge servlet.

>>Any features that the web container may provide such as caching of
>>requests are not likely to be supported in these OSGI-registered servlets.
>
> Containers can do a good job with static files so... resources are an area
> where we could use Http Headers more effectively to reduce load.
> For servlet requests I'm not really sure what containers do, but I also
> don't think the servlet bridge does anything that gets in the way.
>
>

Here is a example of where this approach is problematic. In WebSphere it
is possible to enable caching of requests. The configuration of which
requests are cached is defined at a url mapping level. As the bridge
servlet is handling all requests this level of fine grained caching
would not be possible as the WebContainer is unaware of what the
extension point servlets are mapped to.

>>Also are the lifecycle of the servlets spawned under OSGI (via HTTPService
>>or the extension point) like init and destroy the responsiblity of the
>>parent servlet to emulate?
>
> Yes, all of that is emulated.
>
>
>>Also I think OSGI registered servlets might want to be initialized on
>>startup. Currently I don't see an OSGI mechanism for this and its probably
>>required for any serious use of this platform.
>
> The OSGi registered servlets are always initialized on startup.
> What's missing is a way to initialize them lazily.
>
>
>>If it existed the bridge
>>servlet which needs to run first (among firsts) might result in some sort
>>of interference or a race condition.
>
> The servlet bridge guarantees that it will be fully initialized before any
> other OSGi registered servlet can service a request.
> Now, there are still possible race conditions between the OSGi registered
> servlets as controlling their start-up order is not directly managed.
>
> I think many of your comments are directed towards having a server-side
> model/API that more closely resembles the Servlet API.
> I'm very interested in looking at the possibilities.
>

The approach taken currently will mean you will have to pretty much
emulate an awful lot of WebContainer functionality to achieve this. This
is no simple task :(

A better solution would be to somehow hook into the WebContainer
directly to allow the regstration of Servlets etc so that it manages the
resources. Unfortunately I don't think this is going to be possible in a
WebContainer neutral manner.

> -Simon
>
>

Richard Backhouse
Previous Topic:getting started with eclipse server-side
Next Topic:Minor problem with serverSide web.xml
Goto Forum:
  


Current Time: Fri Apr 26 02:42:58 GMT 2024

Powered by FUDForum. Page generated in 0.03073 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top