Is it possible to use classes that are in a websphere application server shared library from within an OSGi bundle?
I did some research and found this http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_v8/was/8.5/ProgrammingModel/WAS85_LP_Class_Loading.pdf which indicates that it ispossible to load OSGi classes from standard java, however, there is no indication whether the opposite is possible. Any help would be appreciated!
No, it is not possible to use a Java EE shared library from an OSGi application, but you can use a bundle repository to share binaries across OSGi applications.
The document you linked is primarily discussing Java EE applications in the Liberty Profile runtime:
The class loader configuration is only valid for Java EE applications.
If it is provided for an OSGi application, it is ignored.
...
Since OSGi allows applications to specify the versions of packages to
be imported, once again this coarser level of control is only needed
for Java EE applications.
Any mention of OSGi class loading is pointing out that Java EE applications have visibility to product classes that are loaded by an OSGi runtime. There is a brief mention of bundle repositories for OSGi applications:
Note that this library definition is for use by Java EE applications.
There is a separate facility known as the bundle repository for
configuring additional bundles to be used by OSGi applications.
Related
I have a Spring Boot+React application that is packaged as a bundled WAR.
This works well for most cases, but we need to be able to drop-in functionality in some cases that is not part of the bundle (such as via a JAR).
I knew OSGI exists for this case, but not sure of any usage with Spring Boot. Is there another way to do this as well?
If your use case is a kind of small plugin functionality for your spring boot app then you could start an OSGi framework inside spring boot and load bundles from a separate directory. You plugins could then offer their service via an interface that is provided by the spring boot app and an OSGi service with that interface.
You need some good OSGi knowledge for this to work.
Can OSGi components be deployed to any Container like Tomcat/Websphere/JBoss..etc ? (just as we deploy a WAR file) or do they require any special libraries or OSGi containers to run the OSGi components ?
If you want just expose the "component" classes, you can treat the jar files as .. jar files.
If you consider the OSGi "component" as a "bundle" exposing some services and doing something, then answer is "no". You need an OSGi container (Karaf, WebSphere Liberty, Carbon, Glassfish, JBoss WildFly ...).
However - as you can see, some application servers provide OSGi support natively.
OSGi components (I guess you mean bundles) require an OSGi framework to run in. So a plain servlet container will not work. Some versions of JBoss provide support for OSGi though.
Imagine you want to have a highly modular web application in Java. Components are already using Spring framework also. Some components cover only pure Logic and some others also come with some presentation GUIs in HTML. The application is not Portlet compatible but we need to have dynamic menu which promotes the list of installed modules and links to the pages or REST APIs. Since it’s Java, using OSGI is recommended but I got too much confused with the recent features in OSGI (introduced past few years) and I have few questions:
Now OSGI is not only Module Management System but also IoC Container! It almost contains equivalent annotations for many of Spring IoC features. So How we can use Spring enabled modules inside OSGI? Can we eliminate Spring for our new designs and completely rely on OSGI? Or for dependency Injection within the modules we can use Spring and for Dependency injection over the Modules we can use OSGI?
For real-life large scale applications we have two options: Using Embedded Felix within application Container (e.g. Tomcat) or Using OSGI Bundle of Application Container (Jetty or Tomcat) within KARAF. Which approach is better? Which one is more scalable?
Researching OSGi can get confusing because there are 15 years of articles and examples out there - a lot of which are valid but may be out of date.
You could consider removing Spring if it was just used as an IoC container. OSGi DS provides #Component and #Reference annotations (like spring Autowire) if DS is enabled in your OSGi container. The new OSGi enroute project has some modern examples of performing IoC and providing REST services.
Replacing more of the features might be more work. Running the latest Spring in OSGi may not work due to the classloader differences in OSGi and the spring projects move away from OSGi.
OSGi is no IoC container at all. There are some technologies for injection support that run on OSGi though. The most important are declarative services and blueprint. Spring is not really supported. There is some Spring DM support but this code is not maintained for ages.
So you should use one of the two supported IoC containers above. For aries blueprint I have written support for CDI annotations using the maven-blueprint-plugin. This may be your best bet to convert the application. I recommend to first convert your spring application to use only CDI annotations and only then start the OSGi migration. Such a migration is not easy. Make sure you get some good coaching and consulting.
Embedded Felix on a servlet container is good if most of you application is non OSGi and you just want to use bundles for a very small part. Karaf is better if you want to write your whole application for OSGi.
I'm experimenting with OSGI and CDI. I want to register my OSGI services using CDI annotations and also retrieve the registered OSGI services using CDI.
I have found the following: https://github.com/mathieuancelin/weld-osgi, it seems like it is integrated into weld-core. But when I depenend on the weld-core 1.2.0.Beta1 or 2.0.0.Final version, I do not find any of the annotations specified in the documentation on https://github.com/mathieuancelin/weld-osgi.
It this weld-osgi the way to go when you want to use OSGI with CDI? Or should I use spring? (I prefer weld because my AS is currently jboss EAP 6.1)
In which dependency can I find the annotations specified in the documentation?
Thanks!
Currently I do not advice using CDI to work with OSGi services. The Weld-OSGi library is still very experimental and will most likely change when the OSGi-CDI specification is released.
At this moment a new specification, OSGi-CDI (RFC 193) is being written in the Enterprise OSGi expert group (I'm one of the members writing this spec). OSGi-CDI is scheduled to be part of Enterprise OSGi R6 early next year. Unfortunately, it's too early to start using this yet, the reference implementation is far from finished. Some more details about the upcoming specification can be found in a presentation I gave at EclipseCon this year: https://speakerdeck.com/paulbakker/rfc-193-osgi-cdi
I strongly advice to use one of the other dependency injection solutions available for OSGi services, preferably either Apache Felix Dependency Manager or Dynamic Services. Because both of these libraries are built directly on the OSGi service API, you don't have to drag in other dependencies. The programming model is obviously different than CDI, but the concepts are very similar, so it should be easy to pick up.
Do not use Spring either because it doesn't really fit OSGi very well (although it can work).
I haven't worked on it, and I know little about weld-osgi, but you should be using it if you want OSGi and CDI to play nicely. I'm pretty sure they're separate jars, you'll need to add the weld-osgi dependency to your project.
Apache Karaf is a sub project of Apache Felix. It is defined as "a lightweight OSGi container".
I don't understand when should I use the heavyweight and when to use the lightweight. Their site doesn't explain this too much.
The 'lightweight OSGi container' label is contrasting Karaf with more feature rich OSGi containers, not with Felix.
To quote Guillaume Nodet (Karaf's author) from here:
Felix is just the OSGi core runtime. Karaf provides a "distribution" based on Felix by adding other features such as a console, an SSH remoting mechanism, a file deployer and more.
In this diagram of the Karaf architecture, Felix (or other OSGi implementation - currently Equinox is also supported) is the OSGi box, the other boxes are the features added by Karaf:
Therefore, unless you have specific needs which are not met by Karaf (requiring access to the underlying implementation) it usually makes sense to use this since it provides more 'out of the box'.
#Marcel
Karaf isn't monolithic or huge like a Java EE server. It is a very slim and minimalist implementation. It is a core product without much functionality other than a basic console, file loading so that you can actually read configuration files, etc. The latest zip file of it is 19.1 MB. Yeah. Small. It can easily run on small devices and work in embedded.
What you may be thinking of is something more like ServiceMix which uses Karaf as a core/kernel. But it includes CXF, ActiveMQ, Camel and other libraries in its full configuration. Even then they have minimal, medium and full sizes.
Really, for 99% of the projects out there it wouldn't make sense to start directly with Felix and not use Karaf instead.
Currently, there are three popular open source OSGi containers:
- Equinox. It is the modular Java runtime at the heart of the Eclipse IDE,
- Knopflerfish, Is an open source implementation of the OSGi R3 and OSGi R4 specifications.
- Apache Felix. Is the open source OSGi container from the Apache Software Foundation.
http://www.javaworld.com/article/2077837/java-se/java-se-hello-osgi-part-1-bundles-for-beginners.html
The Apache project maintains a general-purpose OSGi container called Felix.
Here is used as ServiceMix and
The main difference between the ServiceMix and Karaf is that
ServiceMix bundles a bunch of other integration components — ActiveMQ
message broker, the Camel routing engine, and some other things
According: http://kevinboone.net/osgitest.html