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
Related
I know the question is very general and the answer is too biased to the scale, scope, type, etc. of the the target system. Hence, actually I want to know what is the pros and cons of using various containers such as spring-boot, single-main, karaf, etc. and also when/why I should to use a container for such a system.
In our previous project my colleagues used apacha-karaf but they had a lot of troubles such as building the project, settings to allow components export jmx, poor documentation, etc. with it. Since the current system is a spring-based application maybe using spring-boot makes more sense. Any thoughts?
The main questions you have to ask is what are your requirements regarding:
How many integration (micro?)services you will have to support?
Will you need to support independent configuration of these services?
Will you need to support independent branching/versioning of these services?
Will you need to have "hot deployment" (i.e. deploying/ updating/ re-configuring one does not inherently affects the operation of the others) of these services?
If the answer is yes to all, then you have two main alternatives:
Go the JBoss Fuse way (RedHat branded version of Apache Karaf). This means that each of your integration (micro)services will be an OSGi bundle in Fuse.
Go with a non OSGi container, but in this case in order to satisfy your requirements you need another layer of managing the life-cycle of your services. E.g. you can take a look at Fabric8 (https://fabric8.io/).
This will mean that you will ideally have one (micro)service per Docker container (instead of a micro-service per OSGi bundle) and Fabric8 will provide you will the Web UI (plus many other tools, like Kubernetes commands, maven commands) to manage the deployment of your service to a Docker container. As a result, a service may be using spring boot/ tomcat, another one may be just a jvm standalone process or another one may be an OSGi bundle running inside Karaf container, deployed inside a docker container. So option (1) can also be deployed to option (2).
Depending what path you follow you have to be savvy with different technologies, e.g.:
Fuse: osgi/ Fuse container, camel, maven, ..
Fabric: your on demand container (e.g. spring-boot/ tomcat, java process, Fuse, python process, scala process etc..), Docker, Kubernetes, Fabric8, OpenShift, maven, ..
Hope this help :-)
I use the java dsl of Camel together and deploy it inside apache-karaf wrapped inside a docker container. The key is to use feature descriptors and a maven repository. Then you can create custom distributions of a camel project which are loaded in your karaf distribution. This means you can work towards a really cool microservice approach where services are deployed as individual docker containers.
The biggest difficult was getting the custom distribution of Karaf working. Once that was done the rest was pretty ok. I don't use spring so can't speak about spring-boot.
Inside Karaf/docker you can deploy hawtio and from hawtio do monitoring, see metrics and do all kinds of other stuff. Karaf also has decanter which has a kibana dashboard and alerting feature.
The answer should totally depend on what container technologies you are most familiar with and what you'd like to do with the Camel application.
I think Spring Boot is best when you'd like to create a MSA application with Camel and you are familiar with Spring already. The good news is that Camel now fully supports Spring Boot: http://camel.apache.org/spring-boot.html
On the other hand, if you have a preference to the classical-style standalone approach Karaf would be a rock-solid option since commercial products like JBoss Fuse (https://developers.redhat.com/products/fuse/overview/) use Karaf as the primary container. Plus, if you are an OSGi lover then no doubt you choose Karaf ;-)
Finally, don't forget that you can also run Camel applications on a JEE application container. Basically you can package them as .war and deploy them to any JEE container, but it should be worth noting that WildFly has an extended integration support for Camel: http://wildfly-extras.github.io/wildfly-camel/ With the WildFly-Camel subsystem you can deploy Camel applications as simple .jar as you do on Karaf.
Actually I have the same question, here is my conclusion:
Karaf
pros:
1. OSGI based, hot deploy and support multiple version.
2. Maven support, can continuously deploy from maven repo.
Cons:
1. Legacy jars are not support OSGI, need to recreate the jars
2. Dependency conflicts are really hell.
3. Split functions into bundles, it will take more time to develop and test.
Spring Boot
pros:
1. Spring is like a glue, can integration different libraries easily.
2. Spring boot make it much easier to startup, develop and test efficiently.
3. Spring boot + docker, will make the deployment much easier in cloud environment
cons:
1. If you want to support multiple version at same time, need double your infra.
So my suggestion is to use camel in Spring boot. My architecture design is like Spring Boot + Camel + Docker + Consul + Registrator
I have an OSGI application deployed in Karaf v2.3.4, it worked well, but I want to migrate it to WebSphere application server, I want to know the difference between these two servers, and the guidlines for doing that
thanks for your help
I've lead the development of OSGi applications on WebSphere, but am less familiar with Karaf. From what I can tell, we share the same Blueprint implementation. I believe that Karaf supports the OSGi application (.eba) packaging model - WebSphere Application Server insists upon it.
You can download free, developer-licensed WebSphere Application Server runtimes and Eclipse-based tooling from wasdev.net. The simplest approach would be to import your application source into the tooling, and deploy it onto a runtime from there.
The Karaf home page describes it as 'a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.' WebSphere Application Server is a Java EE-compliant application server. Until the advent of the Liberty Profile, it could not have been described as 'small'. Both runtimes are OSGi based.
We don't have a specific guide for migrating OSGi applications from Karaf to WebSphere, which is why I recommend that you try it and see what happens. Good luck - do let us know how you get on, either here or on the wasdev.net forums.
Regards,
Mark
I am currently trying to deploy my camel app as a FAB bundle in the Fuse ESB container. I understand that I can install Fab(Fabric-bundle) as a feature on OSGI containers like Karaf or felix and deploy the bundle. I want to know if this feature is available on all OSGI containers as well as other application servers like IBM Websphere(Websphere supports OSGI) or will this tie me up to the Fuse ecosystem.
Will deploying as a WAR or an OSGI bundle be a better approach as the goal is to support as many ESB Containers/Application Servers as possible.
No, this is a specialty of Fuse, for this it'll only work on the FUSE containers. Even Vanilla Karaf doesn't understand FAB (unless it's a standard Karaf feature, with just another name to it)
For usage of Karaf Featurs outside of Karaf you'd need to add the feature resolver and services of Karaf to the other OSGi containers first. Never tried that but might be possible.
I am a little bit confused about what Apache Karaf exactly is.
Can you say that Apache Karaf includes, amongst other things:
Apache Felix (which is an implementation of the OSGi 4.2 framework)
Apache Aries (which is an implementation of the Blueprint standard)
TLDR: Apache Karaf is much more 'batteries-included'. It can also run on any OSGI runtime.
Apache Felix (which is an implementation of the OSGi 4.2 framework)
Sort of. Apache Karaf can use Apache Felix. Apache Karaf can also use Equinox or another OSGi runtime. By default, the Apache Karaf standard download does come with Apache Felix.
Apache Aries (which is an implementation of the Blueprint standard)
Again, sort of. The standard download of Apache Karaf does come with Apache Aries by default.
Now let's talk about what OSGI (Apache Felix, Equinox) is and what Apache Karaf is:
OSGI is very simple. You can start an OSGI runtime in your application and not even notice it. The shell, the ability to hot deploy from a folder, install from a maven repo, etc..These are all extras that OSGI doesn't have to do and are provided by additional projects like Karaf, GOGO, or Pax
Now on to Apache Karaf:
It is basically an OSGI environment that provides some additional goodies on top of a standard OSGI implementation. Because Apache Karaf is just built on standard OSGI, it can in theory run on any OSGI runtime. This gives you a uniform interface for working with OSGI runtimes.
Some goodies Apache Karaf provides that you won't see in a Apache Felix without some additional work:
Folder based hot deployment
A (IMHO) better default console than gogo. (org.apache.karaf.shell)
Remote SSH access to that console. (org.apache.karaf.shell.ssh)
Centralized Logging System. (org.apache.karaf.log)
It has it's own way of provisioning bundles and start levels. (org.apache.karaf.features)
Karaf has it's own maven plugins as well.
Pretty much anything here:
http://mvnrepository.com/search.html?query=org.apache.karaf*
I mentioned Karaf having it's own way of provisioning bundles and start levels. Apache Karaf also comes with a bunch of pre-defined ones to get started with. I know Apache Felix comes with some as well, through OBR, but Apache Karaf comes much more 'batteries-included'.
Apache Karaf is a swiss army knife to run OSGi "stuff" and non OSGi things bundled as OSGi.
Felix and Aries are default but the frameworks are pluggable, so equinox works as well.
"Unix like" shell accessible from CLI or SSH
Hotdeploy of bundles
May deploy almost anything as a bundle (plain .jar, spring xml, blueprint, etc)
WAR files
Deploy from maven - including autowrapping non OSGi bundles.
Web Console
Karaf features - ".kar files" that includes bundles and custom karaf features/commands.
A side note is that Karaf is part of ServiceMix (the initial name was ServiceMix kernel), so it has very tight integration with Apache Camel, Apache CXF and Apache ActiveMQ. Turning Karaf into an ESB with those features is trivial.
Apache Karaf is just an OSGi framework (it can be equinox, felix .etc) with a bunch of predefined modules.
Apache Karaf architecture:
Is it possible to have standard war deployment, which can be deployed on tomcat and also can be build as OSGi bundle and deployed with other bundles in OSGi container tomcat(i think virgo)?
Yes, there's a good deal of interoperability between WARs and WABs. Apache Aries and WebSphere Application Server will convert WARs to WABs on deployment. This is a good way to get up and running, but it's a better practice to use proper WABs in which you build in the OSGi metadata yourself. The extra OSGi headers won't interfere with the deployment in a normal Tomcat container, so the WAB has the greatest flexibility.
For your build, you have a number of options. For example, the maven bundle plugin can be configured to build WABs, or you can use Eclipse PDE's tooling support for OSGi metadata.
Pax-Url-War provides this functionality to containers like Apache Karaf. In brief, this allows you to import an URL like war:file:///path/to/myapp.war and Pax will wrap it as an OSGi bundle, optionally changing the URL root and other parameters on the fly.