- What does MSC stand for?
- Why use Blueprint and not Spring directly?
- Does JBoss Modules support different versions of a module?
- How are the JDK packages like javax.* used by a OSGI bundle?
- Why not use one of the current OSGi Framework implementations (e.g. Felix, Equinox, ...) as the basis for AS7?
- Why would I opt for JBoss OSGi and not go with Equinox or Felix?
- Where does project jigsaw fit into all of this ?
- Is Jigsaw the OSGi core implementation of JBoss AS7
- Is there a way to isolate your EJB/Servlet from OSGi APIs, so that dependencies to OSGi services can be injected?
- What are the following AS7 milestones, when could we expert OSGi v4.3 support?
- Do you think the integration with standard EE components will be "cleaner" in future versions? Will OSGi be part of specification?
- How does OSGi module deployment work in a JBoss AS7 domain?
- Where can I find the presentation material from the webinar?
- Are this JBoss OSGi test benchmarks published anywhere?
- Will it be possible to use the same OSGi bundle/services in JBoss AS7 and e.g. Eclipse?
- 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?
- Folks tell me that productivity drops by orders of magnitude. What are the common pitfalls when working with OSGi?
- 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?
- What is they key value OSGi modularity provides
- Is there another feature that's unique to OSGi?
Modular Service Container. The code lives here
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.
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'.
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.
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.
Project Jigsaw is being designed to work well with OSGi, but is not a replacement of the mature OSGi technology.
Is there a way to isolate your EJB/Servlet from OSGi APIs, so that dependencies to OSGi services can be injected?
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.
Domain deployments are fully supported. This means you can use the AS 7 management channels to deploy your bundle to multiple servers.
This is documented here
The benchmark tests can be run as part of the performance testsuite
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?
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?
Benefits on both technical and business levels.
- 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
- 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.
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!