OSGi applications are composed of modules called bundles. The problem is that any reasonably sized application will have a large number of bundles (could easily be hundreds, just look at the plugins directory of your Eclipse IDE), so that you want a coarser granularity than individual bundles when managing or deploying the application.
The OSGi Service Compendium Spec contains a Deployment Admin Service, which defined deployment packages as a collection of bundles and other artifacts (such as configuration) that can be deployed, upgraded, uninstalled and so forth as a single unit.
Unfortunately, I could not find much information about Deployment Admin implementations, tooling or users.
What is the status of this service?
Does anyone have any experience, opinion or recommendation regarding Deployment Admin?
Also, Spring dm-server has the concept of application-scope collection of bundles (PAR files) and Eclipse Equinox is working on nested frameworks to address the problem, I think. How do these approaches relate to Deployment Admin?
Deployment Admin is one of those OSGi compendium services that seems to have attracted relatively little attention. Clearly there is a specification and therefore presumably a reference implementation and compliance tests. An implementation was contributed to the Apache Felix project, but seems to have sunk pretty much without trace.
I looked into Deployment Admin when designing the PAR file support in SpringSource dm Server, but the model was inappropriate for our use cases. In particular, a bundle with a given symbolic name (and any version) may not reside in two distinct Deployment Packages which are installed in the same OSGi framework.
In contrast, two PAR files installed in the same instance of dm Server may both contain a bundle with a given bundle symbolic name (and the same or different bundle version). We see this as an application scaling requirement: we didn't want large applications to "collide" simply because their developers happened to package the same bundle. Services are also scoped by PAR files.
In dm Server 2.0 we have generalised the concept of PARs into "plans" which are files referring, by type name and version, to artifacts to be installed. A plan may be scoped (like a PAR) or unscoped and may be atomic (meaning the lifecycle of its contents is tied atomically to the lifcycle of the plan, like a PAR) or non-atomic.
Nested frameworks are also being investigated as a possible future OSGi standard to address application scoping requirements but with a rather different design point to dm Server scopes. A nested framework cannot automatically see the packages and services in its parent framework. So the model is one of isolation by default, whether that is isolation of child frameworks from each other or isolation of child and parent frameworks. dm Server scopes deliberately isolate children from each other but only isolate a child from its parent in one direction: a child can see all its parent's packages and services.
You might be interested to know that Apache Ace (which is currently in incubation and ramping up) can dynamically generate deployment packages for Deployment Admin, and uses (by default, when provisioning to OSGi target) Felix's Deployment Admin.
Since the website is very much under development: Apache Ace is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. It is built using OSGi and
can be deployed in different topologies. The target systems are usually also OSGi based, but don't have to be.
Related
Everybody in the world, except me, seems to know what exactly the "Dynamic Web Module" facet is adding to a project. Web search reveals tons of responses how to recover from various errors originating in more or less unwanted changes in the version of this facet, but there is hardly any information about what the facet actually does.
So my questions are:
What exactly does the "Dynamic Web Module" facet add to my eclipse project?
Why should I want this to happen?
Why do my colleagues using IntelliJ, Visual Studio Code etc. –where this concept does not seem to exist– have no problem?
Keeping mind that I didn't decide on these names (and I grumbled about them myself at the time)... The term dates back to the early J2EE Tutorials, like https://docs.oracle.com/cd/E17802_01/j2ee/j2ee/1.4/docs/tutorial-update2/doc/WebApp3.html The tutorial would explain that J2EE web modules are the web applications from the then Java Servlet specification. J2EE loved to subsume the other specs and use its own naming for things that already had names. The doc and tools often followed suit.
It also mentions that they can contain static web resources, and in fact you can run web modules that only contain static resources. So WTP has the concept of a static web module and a dynamic web module, as static web projects and dynamic web projects in Eclipse. The Facet designates a project as being one of the two, and for dynamic modules, which API level it supports and requires at runtime.
Server adapters then have to state which API versions the server types they provide can support. The Server Tools and validation can then help you avoid deploying to an incompatible server, as well as build against a valid server. You want to build against a valid server in the same way you want to compile against your intended Java runtime. It's the most straightforward way to, for example, avoid calling classes and methods that didn't exist at the time.
There's also a Module Core nature that gets added, which supports APIs for describing the deployment details. Details like saying your Java class output folder contents go into WEB-INF/classes, that the jars you select go into WEB-INF/lib and that those static resources go into the application root, all to comply with the layout expected at runtime. That API is meant to be pluggable, so it can be fulfilled by e.g. Maven integration.
The terms in the UI can be changed, but that has its own pain points. The community tends not to update old videos and tutorials that have been correct for years.
I am trying to understand OSGI, as per definition it says
OSGi technology is a set of specifications that define a dynamic
component system for Java. These specifications enable a development
model where an application is composed of several components which are
packaged in bundles. Components communicate locally and across the
network through services.
But I am confused here as the same dynamic module creation can be done with Maven multi module project structure too. So my question is how OSGI architecture is different from Maven multi module projects.
The main difference between maven and OSGi is how modules depend on each other.
In maven a module depends on a list of other maven modules. This is a simple model but often leads into problems in transitive dependencies. If the same module appears in the dependency tree with different versions maven simply chooses the highest version. This is a good guess but does not always work. Another typical case is having two modules with the same packages but different names (split packages).
In OSGi dependencies are expressed as requirements and capabilities. The OSGi resolver is then used at assembly time of your application to find a closure over the candidate bundles (repository) that satisfy a set of initial requirements. Most commonly these initial reuirements are your top level user bundles. The resolver then determines a closure over the bundles that solves the requiremnts. So the obvious advantage is that when using the resolver you have a high confidence that the set of bundles you run will actually work. In plain java you simply run some jars together and hope for the best.
The most common requirement is on a package in a version range. Another bundle may offer the package in a suitable version. It is then a candidate for the resolver.
Luckily at build time creating bundles from maven builds is easy. You use the bnd-maven-plugin or maven-bundle-plugin. It typically figures out the requirements and capabilities on its own.
In OSGi you always try to develop against APIs (API-jars) instead of runtime jars. This makes your code more loosely coupled.
At assembly time in OSGi you need to provide a set of bundles to form the repository for the resolver to work on. This is often done using a pom. So actually this is not too different from plain maven. The main difference is that the resolver gives you a validates minimal set of bundles to run while a typical mavne build simply gives you a set of jars that represent all transitive dependencies.
As an example see the new enroute microservice example. It shows how to create the individual bundles and how to assemble them into a running application. See also the tutorial for the example.
I'm planning to build a Java-based system to handle different business processes where each of these is a particular module in the system. Most modules would depend on some of the other modules to handle their particular business process. In other words, top modules would consume some sort of basic services provided by underlying modules. Some modules will be developed from the very beginning, but some will be added to the system later. Next, some modules will expose RESTful interfaces to handle external input / output.
To handle all this, OSGi seems appropriate, but it's a bit difficult to learn with all the different "distributions" out there (Equinox, Felix, etc.) and I'm concerned about the ease of using the Spring framework and other 3rd party libraries within each module (starting with Spring 3.2 the different jars might not come with OSGi manifests).
On top of this, I'd like a central web portal to administer all bundles, thus with each new bundle there will be a new admin section.
that's why we developed osgi-less modularity for Spring https://github.com/griddynamics/banshun Your feedback is appreciated!
Why do you need OSGi? Why not use a Web Server like Tomcat, and deploy your application as a war? You can deploy it on multiple servers in a cluster, and your application can scale on and on.
Why do you need Spring? It has become incredibly coupled. And it has a complexity that find quite useless since OSGi applications tend to be built from small components communicating through services; voiding most of the advantages of the Spring wiring model which assumes it is central.
And hard to configure is a strange remark, OSGi is excellent configuration support. It is just different than what you're used to.
Instead of using spring, why not using OSGi Blueprint it'll give you an "easy" transition from Spring to OSGi.
OSGi seems to have an excellent benefit of having small deployable artifacts by not wrapping dozens of JAR dependencies into a lib directory. However, I can't find anything that tells me an easy, reliable way to deploy dependencies to a container. For instance, I have an application that uses CXF and several Spring subprojects. If I need to deploy this application to a new Glassfish server, what would be the best way to do so, ensuring that all dependencies get installed?
I'm using Maven, and it would seem that there could be some way to have a hook that looks at the META-INF/maven directory and pulls the dependency list from the pom.xml and goes and fetches the required libs (probably from a local repo). Is there a way to do that?
The Pax plugin sort of sounds like it's doing this, but it seems to be based around boostrapping a Felix container? Which is not what I want, I am dealing with an already running, remote container.
Is there any shot such a thing exists as command line tool as opposed to GUI as well?
There are a number of ways to deploy dependent bundles to OSGi containers. Here are some of them:
1 The Felix OBR bundle repository
You first need to create an XML index file for your available bundles, using a tool such as bindex. If you are using the maven-bundle-plugin, then it automatically maintains an OBR index in ~/.m2/repository/repository.xml.
Load the index using the OBR command-line interface:
> obr:addUrl file:/Users/derek/.m2/repository/repository.xml
Then ask OBR to deploy your target bundle, with dependencies determined from the OBR index:
> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)
Required resource(s):
---------------------
Paremus Command API (1.0.23.SNAPSHOT)
Optional resource(s):
---------------------
Paremus Config Admin Commands (1.0.23.SNAPSHOT)
Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)
2 Apache Karaf
Karaf supports "features", which are basically lists of bundles required to provide the feature:
karaf#root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0
karaf#root> features:install obr
3 Eclipse Virgo
Virgo uses plans to define the artifacts that comprise an application and it is able to
automatically supply the dependencies of an application including bundles, plans, plan archives (PARs), and configurations, from both local and remote repositories.
4 Paremus Nimble
Nimble uses OBR (or its own extended) repository indexes, to automatically deploy all dependent bundles needed to activate a target bundle (and uninstalls them when the target bundle is stopped). It can also detect other dependencies, such as a WAB bundle requires a web-extender and automatically install one according to a configurable policy.
Nimble can also be configured to launch Glassfish, so that its features are available to bundles in the Glassfish container.
The example below also shows that logging support is automatically installed when sshd is activated:
$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd#active
-- sorted parts to install --
4325 osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729 osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727 osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797 osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792 osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436 osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533 osgi.resolved.bundle/sshd-core:0.3
398 osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396 osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
(disclaimer: I'm a developer at Paremus)
5 Apache Felix Gogo
gogo is the new RFC147 standard command-line shell. It is already used in Felix, Karaf, Nimble and will soon be available in Glassfish.
Gogo allows you to run any commands that you could type interactively, as a script. So you could generate the list of bundles to install and convert it to a script, or even capture the installed bundles from a working configuration so that it can be re-created from a clean start.
If you create an OSGi application and a classic Java application that do the same thing and use the same libraries then you'll need exactly the same set of JARs. The big difference is being able to explicitly define your dependencies (and possibly produce more granular JARs for your application).
There's only one pure OSGi-based server that I know of (Eclipse's Virgo, previously Spring's DM Server). Glassfish and Websphere have support for OSGi, but I haven't played with them so I can't say much. What I can say is that all of them require an OSGi container and that's usually Eclipse's Equinox or Apache's Felix.
Your question seems to really be about provisioning the application (working out what needs to be deployed). I know that for Maven 3.0 they've done a bunch of stuff working with Eclipse's P2 provisioning framework.
For your application are you deploying an EAR or WAR? For either of those, your build system will need to produce the archive with all dependencies or it won't work. It's a bit confusing on why you have a problem because people use Maven because it does the transitive dependency management for their builds.
There is a fundamental aspect of your question that is not yet addressed.
Glassfish is indeed a full fledged Application server like most modern application servers: these provide you with a Web container (where you would deploy WAR archives), a Java EE container (to deploy EJB's in JAR and EAR archives), as well as integrate an OSGI container. The later is then used for the application server's own internal start-up mechanisms.
In essence, you may target three containers. Modern IDE's and build tools provide you with means to pack your logic to target any of these. So the question becomes: how do I architect my application with all those possibilities?
There are a few very important technical issues not to lose from sight. (I focus here on objective and factual considerations, keeping out from any subjective choices, philosophy, strategy, and other context-dependent considerations that indeed may also weight much on your final decision):
An OSGI container does not provide you with Implicit or Declarative Thread Management, Persistence, or Transaction management services like the Web and Java EE containers. So, do plan to analyse these issues and produce the code to manage your threads and deal with transaction propagation over these threads for instance. Of course OSGi provides all necessary APIs to deal with those aspects, but does require coding (where AOP may help). On the other hand, in the Web and Java EE containers, you rely on container-managed services and/or use EJB annotations, deployment descriptors, and server managed objects like pools to simply declare how many threads you want in parallel, the sizes of connection pools, and which transaction attributes. There are advantages and drawbacks in either style (procedural in OSGi versus declarative or implicit in java app. servers).
OSGI provides an orderly way of loading your code, manage module dependencies, even deal with multiple coexisting versions of the same module, and dynamically add/remove and start/stop so-called bundles (OSGI deployment units), provided indeed your bundle contains the logic to handle potential start/stop issues like properly interrupting all launched threads on a stop -- threads which could have 'propagated' through other dependent modules. On the other hand, Java EE and Web containers will often embark copies of dependent JAR's that may yield more fat deployments unless you start to consider your application server's classloader hierarchy and take advantage of it to deploy 'shared libraries' either as plain POJO JARs, or as Java EE beans packed in JAR's. Anyhow, in the later cases, managing deployment dependencies becomes a concern which you will have to address at least at build time using frameworks like Maven indeed. Then, at run time you may have to script start/stop cascades according to dependencies; else, take advantage from specific application server extensions that address these dynamic deployment issues in Web and Java EE containers (e.g. Weblogic).
As already said, OSGI is now used by most application servers to manage their own start-up sequence. With the increasing complexity of platforms, multiplication of API's, increrase in the number of development teams to assemble a single final product, as well as use of numerous third party / open source components, OSGI becomes an indispensable server-start-up tool to ensure stable releases and a coherent set of compatible versions of all components. Think about the Eclipse IDE: with a catalogue of thousands of plug-ins and a high rate of new releases, this IDE would be a much brittle platform without OSGI as a base. Modern Application servers face just the same problem.
Based on above considerations, you may be much tempted to layer your code into some facilities which you could base into the OSGI layer, which in turn provides core services to a Java EE bean layer hosting business logic, and then a Web servlet layer to interface the whole... but two other questions pop up: (a) How do you make all these components communicate together? OSGI has its own repository mechanism and the deployed JAR's API's will not be visible by other modules unless explicitly published in OSGI. Web and Java EE containers use a completely different repository technology to access each-other components' interfaces, namely JNDI. Again, look at your specific application server documentation which may provide means to address Java EE beans from OSGI bundles and vice-versa (Glassfish for instance, since V3); but be cautious about thread management and transaction scopes. (b) How would you avoid interfering in the application server start-up sequence? OSGI tends to become a core system feature (under the vendor's governance), compared to the Web and Java EE containers naturally oriented to host your application code (under your governance). Upgrading your application server or installing a new release can interfere with your own OSGI deployments; you'll have to check the issue and organize your deployment scripts as a consequence.
The question is rich and its analysis is complex. Further consideration must take into account the nature of the application to build. Moreover, if you intend to use development frameworks like open source Spring and/or Camel, as well as vendor specific ones like Oracle Fusion SOA composites, JBoss Switchyard, etc. you will have many other technical constraints to take into consideration.
There is no "one-size-fits-all" answer in these matters and that, in essence, justifies the current plethora of overlapping technologies.
When that architecture question is first solved, then you can look to optimize productivity with a suitable configuration management and deployment repository.
I'm working with very large JSF/Facelets applications which use Spring for DI/bean management.
My applications have modular structure and I'm currently looking for approaches to standardize the modularization.
My goal is to compose a web application from a number of modules (possibly depending on each other). Each module may contain the following:
Classes;
Static resources (images, CSS, scripts);
Facelet templates;
Managed beans - Spring application contexts, with request, session and application-scoped beans (alternative is JSF managed beans);
Servlet API stuff - servlets, filters, listeners (this is optional).
What I'd like to avoid (almost at all costs) is the need to copy or extract module resources (like Facelets templates) to the WAR or to extend the web.xml for module's servlets, filters, etc. It must be enough to add the module (JAR, bundle, artifact, ...) to the web application (WEB-INF/lib, bundles, plugins, ...) to extend the web application with this module.
Currently I solve this task with a custom modularization solution which is heavily based on using classpath resources:
Special resources servlet serves static resources from classpath resources (JARs).
Special Facelets resource resolver allows loading Facelet templates from classpath resources.
Spring loads application contexts via the pattern classpath*:com/acme/foo/module/applicationContext.xml - this loads application contexts defined in module JARs.
Finally, a pair of delegating servlets and filters delegate request processing to the servlets and filters configured in Spring application contexts from modules.
Last days I read a lot about OSGi and I was considering, how (and if) I could use OSGi as a standardized modularization approach. I was thinking about how individual tasks could be solved with OSGi:
Static resources - OSGi bundles which want to export static resources register a ResourceLoader instances with the bundle context. A central ResourceServlet uses these resource loaders to load resources from bundles.
Facelet templates - similar to above, a central ResourceResolver uses services registered by bundles.
Managed beans - I have no idea how to use an expression like #{myBean.property} if myBean is defined in one of the bundles.
Servlet API stuff - use something like WebExtender/Pax Web to register servlets, filters and so on.
My questions are:
Am I inventing a bicycle here? Are there standard solutions for that? I've found a mentioning of Spring Slices but could not find much documentation about it.
Do you think OSGi is the right technology for the described task?
Is my sketch of OSGI application more or less correct?
How should managed beans (especially request/session scope) be handled?
I'd be generally grateful for your comments.
What you're aiming to do sounds doable, with a few caveats:
The View Layer: First, your view layer sounds a little overstuffed. There are other ways to modularize JSF components by using custom components that will avoid the headaches involved with trying to create something as dramatic as late-binding managed beans.
The Modules Themselves: Second, your modules don't seem particularly modular. Your first bullet-list makes it sound as if you're trying to create interoperable web apps, rather than modules per se. My idea of a module is that each component has a well-defined, and more or less discrete, purpose. Like how ex underlies vi. If you're going down the OSGi route, then we should define modular like this: Modular, for the sake of this discussion, means that components are hot-swappable -- that is, they can be added and removed without breaking the app.
Dependencies: I'm a little concerned by your description of the modules as "possibly depending on each other." You probably (I hope) already know this, but your dependencies ought to form a directed acyclic graph. Once you introduce a circular dependency, you're asking for a world of hurt in terms of the app's eventual maintainability. One of the biggest weaknesses of OSGi is that it doesn't prevent circular dependencies, so it's up to you to enforce this. Otherwise your dependencies will grow like kudzu and gradually choke the rest of your system's ecosystem.
Servlets: Fuhgeddaboudit. You can't late-bind servlets into a web app, not until the Servlet 3.0 spec is in production (as Pascal pointed out). To launch a separate utility servlet, you'll need to put it into its own app.
OK, so much for the caveats. Let's think about how this might work:
You've defined your own JSF module to do... what, exactly? Let's give it a defined, fairly trivial purpose: a login screen. So you create your login screen, late-bind it using OSGi into your app and... then what? How does the app know the login functionality is there, if you haven't defined it in your .jspx page? How does the app know to navigate to something it can't know is there?
There are ways to get around this using conditional includes and the like (e.g., <c:if #{loginBean.notEmpty}>), but, like you said, things get a little hairy when your managed loginBean exists in another module that may not have even been introduced to the app yet. In fact, you'll get a servlet exception unless that loginBean exists. So what do you do?
You define an API in one of your modules. All the managed beans that you intend to share between modules must be specified as interfaces in this API layer. And all your modules must have default implementations of any of these interfaces that they intend to use. And this API must be shared between all interoperable modules. Then you can use OSGi and Spring to wire together the specified beans with their implementation.
I need to take a moment to point out that this is not how I would approach this problem. Not at all. Given something like as simple as a login page, or even as complicated as a stock chart, I'd personally prefer to create a custom JSF component. But if the requirement is "I want my managed beans to be modular (i.e., hot-swappable, etc)," this is the only way I know to make it work. And I'm not even entirely sure it will work. This email exchange suggests that it's a problem that JSF developers have only just started to work on.
I normally consider managed beans to be part of the view layer, and as such I use them only for view logic, and delegate everything else to the service layer. Making managed beans late-binding is, to my mind, promoting them out of the view layer and into the business logic. There's a reason why all those tutorials are so focused on services: because most of the time you want to consider what it would take for your app to run "headless," and how easy it would be to "skin" your view if, for instance, you wanted it to run, with all its functionality, on an Android phone.
But it sounds like a lot of what you're working with is itself view logic -- for instance, the need to swap in a different view template. OSGi/Spring should be able to help, but you'll need something in your app to choose between available implementations: pretty much what OSGi's Service Registry was built to do.
That leaves static resources. You can modularize these, but remember, you'll need to define an interface to retrieve these resources, and you'll need to provide a default implementation so your app doesn't choke if they're absent. If i18n is a consideration, this could be a good way to go. If you wanted to be really adventurous, then you could push your static resources into JNDI. That would make them completely hot-swappable, and save you the pain of trying to resolve which implementation to use programmatically, but there are some downsides: any failed lookup will cause your app to throw a NamingException. And it's overkill. JNDI is normally used in web apps for app configuration.
As for your remaining questions:
Am I inventing a bicycle here? Are there standard solutions for that?
You are, a little. I've seen apps that do this kind of thing, but you seem to have stumbled into a fairly unique set of requirements.
Do you think OSGi is the right technology for the described task?
If you need the modules to be hot-swappable, then your choices are OSGi and the lighter-weight ServiceLocator interface.
Is my sketch of OSGI application more or less correct?
I can't really tell without knowing more about where your component boundaries are. At the moment, it sounds like you may be pushing OSGi to do more than it is capable of doing.
But don't take my word for it. I found other reading material in these places.
And since you ask about Spring Slices, this should be enough to get you started. You'll need a Git client, and it looks like you'll be training yourself on the app by looking through the source code. And it's very early prototype code.
I am facing the same problems in my current project. In my opinion, OSGi is the best and cleanest solution in terms of standards and future support, but currently you may hit some problems if you try using it in a web application:
there is no well integrated solution between a Web Container and the OSGi platform yet.
OSGi may be too much for a custom build web application that is just searching for a simple modularized architecture. I would consider OSGi if my project needs to support third party extensions that are not 100% under our control, if the project needs hot redeployments, strict access rules between plugins, etc.
A custom solution based on class loaders and resource filters seems very appropriate for me.
As an example you can study the Hudson source code or Java Plug-in Framework (JPF) Project(http://jpf.sourceforge.net/).
As about extending the web.xml, we may be lucky with the Servlet 3.0 specification(http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html#pluggability-and-extensibility).
The "web module deployment descriptor fragment" (aka web-fragment.xml) introduced by the Servlet 3.0 specification would be nice here. The specification defines it as:
A web fragment is a logical
partitioning of the web app in such a
way that the frameworks being used
within the web app can define all the
artifacts without asking devlopers to
edit or add information in the
web.xml.
Java EE 6 is maybe not an option for you right now though. Still, it would to be the standardized solution.
Enterprise OSGi is a fairly new domain so dont think you will get a solution that directly satisfies your need. That said one of the things I found missing from Equinox (osgi engine behind eclipse and hence one with largest user base!) is a consistent configuration / DI service. In my project recently we had some similar needs and ended building a simple configuration osgi service.
One of the problems which will be inherent to modular applications would be around DI, as the module visibility could prevent class access in some cases. We got around this using a registered-buddy policy, which is not too ideal but works.
Other than configuration, you can take a look at the recently released Equinox book for guidance on using OSGi as base for creating modular applications. The examples may be specific to Equinox, but the principles would work with any OSGi framework. Link - http://equinoxosgi.org/
You should look into Spring DM Server (it's being transitioned to Eclipse Virgo but that's not been released yet). There's a lot of good things in the recent OSGi enterprise spec which has also just been released.
Some of the Spring DM tutorials will help, I'd imagine. But yes, it's possible to have both resources and classes loaded from outside the web bundle using standard modularity. In that, it's a good fit.
As for the session context - it gets handled as you would expect in a session. However, you might run into problems with sharing that session between web bundles to the extent that in not sure if it's even possible.
You could also look to have a single web bundle and then use e.g. the Eclipse extension registry to extend the capabilities of you web app.