So far, I did not find how I can register the context itself nor how I can add static content (i.e. resources) to it.

To make this work more effective I assigned https://jira.jboss.org/jira/browse/JBOSGI-308 to you (Remy) so you can provide us with the necessary pointers to documentation. When done, please assign back to me or to whoever can make the next progress step.

> What is wrong with the Servlet 3 API

Possibly nothing if it sufficiently documents how to create/modify/delete contexts and populate them dynamically with servlet instances and resources.

createDefaultHttpContext - the implementation is a factory method. It doesn't map to directly to the Servlet 3.0 API. The model code Remy found could be a good place to start. I reviewed it, but not deeply.

registerResources - This needs more digging, however the ServletContext allows access to resources.

registerServlet - Maps to addServlet(String name, Servlet s). The ServletRegistration object allows further configuration (initparams for example). There are still questions/problems, but I can start prototyping here.

The HttpService does not have a dependency on org.osgi.jmx and neither should it. Pluggability is at the heart of OSGi, so it should be possible to take the Felix or Equinox framework and install the jboss-osgi-http bundle on it. The only package (i.e. API) that is exported from that bundle is org.osgi.service.http everyting else should be private.

There may be additional functionality that this bundle provides (i.e. a management interface). In that case it would optionally import the org.osgi.jmx package and track the jboss-osgi-jmx provided MBeanServer service.

registerResources - This needs more digging, however the ServletContext allows access to resources.

Apparently, this needs to go through the HttpContext.

registerServlet - Maps to addServlet(String name, Servlet s). The ServletRegistration object allows further configuration (initparams for example). There are still questions/problems, but I can start prototyping here.

I think you should add a wrapper, and populate it.

Overall, the existing code I found looks probably fine with some minor fixes, so we should start from it (rather than the other way around).

Hi, I noted that JMX instrumentation could be used from HttpServer to fill whatever gaps we have in the Servlet3 API. The sample code that Remy found is a bridge to a facade called Tomcat6Service. The only way they would have to register/unregister would be through Tomcat6 internals; MBean instrumentation would make up a good portion of those internals. I noted also that any annotations in the Servlet class passed in HttpService::registerServlet will be processed when ServletContext::addServlet is called.

Tomcat6Service is start/stop/configure the container. Nothing really new. All these tasks that are done by TomcatService in the "tomcat" module in AS, so this needs to be adapted using the OSGI way (and without JMX ): create a Catalina instance, configure the connectors, and add engine and host to be able to create the Contexts.

I was trying to run the examples in 1.0.0.Beta7 and tests. It appears that 1.0.0.Beta7/jboss-osgi-testsuite-1.0.0.Beta7.pom hasn't been added to the repository yet. Is Beta7 necessary for the testsuite? or will editing the pom to fall back fto 1.0.0.Beta6 work around it for now?

The tests ran successfully once my maven settings where set to the new maven repository. Now I'm working on getting git to clone the project without complaining. Wnen I do that, I'll move what code I have into git.

My bit of prototyping right now depnds on osgi.cmpn.jar for version 4.1, which contains the org.osgi.service API definitions. Will that change when the code is better integrated with the project?

Note, there is currently ongoing discussion about the missing org.osgi.enterprise jar in maven central. In the meantime you can get it from here http://www.osgi.org/Download/File?url=/download/r4v42/osgi.enterprise.jar

where is that discussion? My searches didn't produce it. The reason I ask is the contents of osgi.enterprise.jar and osgi.cmpn.jar are not mutually exclusive. Maybe reading the discussion will help clear this up.