What does MSC stand for?

Modular Service Container. The code lives here

Why use Blueprint and not Spring directly?

Spring is an implementation and only a single impl exists. OSGi Blueprint is a specification of which multiple implementations exist. Being a specification gives the users the freedom to move from one implementation to another.

Does JBoss Modules support different versions of a module?

Yes, JBoss Modules has what we call a 'slot'. It is not termed 'version' because not all java projects use the version to associate a compatibility promise with it. You can use the same slot to span multiple major versions. For projects that use an OSGi like version scheme the 'slot' would be equivalent to the 'version'.

How are the JDK packages like javax.* used by a OSGI bundle?

A bundle must explicitly declare an import on a javax.* package. This allows these packages to be substitutable.

javax.* packages are not by default exported from the JRE, when using javax.* packages there are two options:

• Deploy one or more bundles that export the javax.* packages

• Pick them up from the JRE via the system bundle, to achieve this the org.osgi.framework.system.packages.extra property needs to be set in the AS7 configuration so that these packages are exported via the system bundle.

Why not use one of the current OSGi Framework implementations (e.g. Felix, Equinox, ...) as the basis for AS7?

JBoss AS7 has been designed around Amdahl's law. This is why it is so blazingly fast. The JBoss OSGi project primarily aims to make OSGi bundles available in the context of AS7, so you can leverage OSGi benefits in connection with Standard JavaEE 6 Technologies. Although JBoss OSGi can be used as a standalone OSGi Runtime, it is not our goal to compete with other runtimes like Felix, Equinox. We use jboss-modules as the integration point with AS7. We hence benefit from the ingenious design and runtime properties. This would not have been possible by using an existing OSGi Framework.

Why would I opt for JBoss OSGi and not go with Equinox or Felix?

A JavaEE Application Server is the best provider of middleware services. Currently the best one out there is AS7 of course . A pure OSGi Runtime is a good choice if your project stays within the limits of what such a runtime can provide. It is unreasonable to expect that you can assemble a fully functional, highly integrated, performant "middleware layer" by throwing together a collection of OSGi bundles. A much better strategy in my humble opinion is to opt for an already existing middleware solution with sound OSGi integration. JBoss gives you open choice in that respect.

Where does project jigsaw fit into all of this ?

Project Jigsaw is being designed to work well with OSGi, but is not a replacement of the mature OSGi technology.

Is Jigsaw the OSGi core implementation of JBoss AS7

No

Is there a way to isolate your EJB/Servlet from OSGi APIs, so that dependencies to OSGi services can be injected?

This is currently not supported, but will be in the context of standard Enterprise OSGi JNDI integration. Please monitor JBOSGI-81

What are the following AS7 milestones, when could we expert OSGi v4.3 support?

We aim for Core 4.3 support by Q3/2012.

Do you think the integration with standard EE components will be "cleaner" in future versions? Will OSGi be part of specification?

We are working on a standard for integration of OSGi Frameworks with JavaEE Application Servers. There are many hurdles to this and not all of them are technical in nature. We'll publish progress as it occurs.

How does OSGi module deployment work in a JBoss AS7 domain?

Domain deployments are fully supported. This means you can use the AS 7 management channels to deploy your bundle to multiple servers.

Where can I find the presentation material from the webinar?

This is documented here

Are this JBoss OSGi test benchmarks published anywhere?

The benchmark tests can be run as part of the performance testsuite

Will it be possible to use the same OSGi bundle/services in JBoss AS7 and e.g. Eclipse?

Yes it should be. As long as they don't use any proprietary Eclipse functionality.

The OSGi API seems clumsy with respect to dependency injection methodologies like CDI. What API should I bind to when I want to use OSGi?

Yes, the OSGi API is not what should be used in user domain code. Instead, opt for Declarative Services, Blueprint. There is also an CDI/OSGi integration that we are working on.

Folks tell me that productivity drops by orders of magnitude. What are the common pitfalls when working with OSGi?

Design with modularity/dynamicity in mind - be strict about what you provide - be lenient about what you accept. Use OSGi when you need have a modularity issue in large projects. For larger and complex projects you can scale cost linearly. For simple projects you have cost and little benefit.

Because OSGi is an isolated world with respect to class loading, it is hard to write unit tests for it. What do you recommend as a test strategy?

We use Arquillian, which has a sound OSGi integration. You can learn how to write OSGi tests by looking at our distributed examples.

What is they key value OSGi modularity provides

Benefits on both technical and business levels.

• Technical

  • encapsulation, no leaking of privates

  • side-by-side deployments: multiple versions of the same library can co-exist

  • memory footprint: libraries are shared across deployments. Only those libraries that are needed are loaded

• Business

  • splitting up your architecture into many modules

  • clear interface improves the scalability of development teams making

  • make it easier to do development efforts in parallel

  • limit the impact of change.

Is there another feature that's unique to OSGi?

OSGi Services-based applications allow the application to be patched or updated without having to restart the service consumers. This means that if your application is built using OSGi services you can often fix it without taking in down!