[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] servlet container incubator


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