RE: [equinox-dev] servlet container incubator

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

equinox-dev-bounces@xxxxxxxxxxx wrote on 02/21/2006
01:40:52 AM:

> Hi Scott,
> > Is there a way to plugin code to detect whether it's running
> > via this servlet container bridge or whether it's running in
> > Eclipse or some other OSGI environment?
> 
> For OSGi environment use "org.osgi.framework.vendor" (as
the other Simon
> recommended ;)
> 
> The HttpService should be registered with some properties that will
help
> you determine the provider.
> Currently the Servlet Bridge implementation does not register a
> service.pid, service.vendor, or service.description but will shortly
> (waiting to finalize a bundle name first). This is probably the way
to
> go longer-term.

The service.pid approach feels a little limiting as
a general mechanism.  Not everything is a service.

This actually brings up something that I've been thinking
about for a while -- a way of uniquely identifying configurations and instances
of those configurations.  In a system where there might be many instances
of OSGi running it makes sense that one would be able to distinguish between
them.  Similarly, if you have many configurations you might want to
distinguish.  This seems related as it is another flavour of understanding/processing
the runtime environment. 

> If you need to do something short-term you can
check to see if the
> BridgeServlet is visible in your class space.

> > > A couple of quick questions about the
osgi runtime in 
> > servlet container:
> > >
> > > 1) Is anyone working on an html interface for the OSGI console...if
> > > so, where is that?  We would like to start/stop/restart,
> > > etc., etc our 
> > > server bundle(s) without using the servlet container and
> > > OSGI console.  
> > > I've seen the httpconsole pointers on the incubator page
> > > and haven't 
> > > worked with it yet, but probably will start...but wanted
to 
> > > know what 
> > > work is going on here
> For now I'd recommend looking at the httpconsole. There certainly
are
> plans to create an http/html interface however things haven't really
got
> going yet.

FYI, one of the students working with the Equinox
team has done an extensible JMX based mechanism that is really pretty cool.
 We hope to have that in the incubator soon.

> > > 2) I've seen in passing discussion
of a consistent programmatic 
> > > interface for startup bundle initialization but haven't
> > > read the whole 
> > > thread.  Where is that work at this point? 
> Hmm... I'm not sure what you're referring to.
> Right now a combination of a hard-coded config.ini and the
> update.configurator are used similar to RCP.

Is this a reference to the "how do I startup
all the bundles that my bundle depends on" and "controlling the
startup order" discussions?  If so, there really hasn't been
a conclusion there.  Several people have pointed out that depending
on start order etc is somewhat less than optimal.  Having said that,
there are still issues with how things actually do get started.  The
spec is silent. Some frameworks have a policy of starting everything.  Some
start nothing.  Clearly more work/thinking is needed in this area.

> > > 4) What are the plans WRT the servlet
container incubator?
> Good question.
> For my part I'd like to more-or-less follow the 3.2 plan and really
just
> tie up loose ends with the functionaility as it exists today. Perhaps
if
> there's time (and consensus) these components can graduate from the
> incubator however a process still has to be defined so for the time
> being this is a work in progress. 

Simon, in any event, we should work to get the various
server side bundles as part of the build process and downloads on the Equinox
downloads page in an Incubator section.  The process is pretty easy.
 You talk with one of the old-timers :-) and releng to get it setup.
 I'll suggest DJ since he is not online at this very instant and I
am a long long long way away from him ;-)
 
> There are also some really cool new ideas coming both for servlet
> containers and other server-side environments that can continue in
the
> incubator until they're ready to move out.

Yes, the server-side incubator should continue running
for sometime.  There are it seems plenty of ideas/issues for some
time to come.

> > > 5) Is there jaas-based authentication
work in 3.2M5?  If 
> > so, is there a description of how to use it somewhere?
> I've been using declarative and custom (non-JAAS) authentication.
> JAAS support would be nice but it's not in place currently.

Not in M5.  We are working hard to get a contribution
from IBM in this space.  Not sure where it is in the process right
now.  Depending on when it comes in it may or may not be an official
part of 3.2.

Jeff