I have been trying to start with studying OSGI for quiet a few days now. I've tried many tutorials to work on eclipse especially to start with apache felix or Equinox but the step by step tutorials never take me to the end of creating even one bundle.
I even tried the console commands with no luck. Is OSGI out dated? All the tutorials on the alliance web site are also extremely old and I couldn't follow them to the end. I also tried the BndTools Totorial here but on eclipse it couldn't resolve "#Component" when I reach 4.3 so I stopped there. When following Osgi Book Preview, I also couldn't find "Make Bundle" so I stopped again. I'm really frustrated. Isn't there a way for beginners to get into OSGI?
UPDATE:
For other people who are interested in getting started with OSGI, I found the book Osgi in Action as very helpful and a good guide for beginners.
The Bndtools tutorial was mentioned and dismissed in the original question; however we were able to resolve the issue. So I post this as an answer for others who might be looking for an introductory OSGi tutorial: check out the Bndtools Tutorial!
Actually there are two questions being posed here, which I asked myself recently as well, one in the title and one in the content. The question in the title seems mostly rhetorical. It expresses a notional answer for the real question that you find at the end of the text: "I'm really frustrated. Isn't there a way for beginners to get into OSGI?"
Answer: There are ways, but they aren't as easy as they should be. The "update" to the question mentions "OSGi in Action". This is a good book (which I discovered too late, it's not really on the top of the search results), but quite outdated with respect to tooling (e.g. Bndtools appears in the appendix only).
Finding no easy way for beginners, I eventually started to dig my way through the topic using an eclectic selection of resources found on the web. I documented my experience in what you might call a log of my (ongoing) journey in the hope that it may be helpful to others. I'll leave it to you to judge whether this can be considered a shy "yes" to the question, after all.
Not having reached "the end of my journey" yet, I'm not perfectly sure why there are so few up-to-date resources for beginners to get into OSGi. I suppose that the attention that OSGi got from a lot of people because it was used in Eclipse was one of the first problems. The attempt of the OSGi alliance to align with enterprise edition features was another (there are references for this, but I'm not allowed to post more than 2 links). Both incidents led first to hype (and lots of articles) and then to disappointment. In the time following, experts understood the technology better and better and applied it successfully to the problem domains where it is of use. (And these are fewer than the initial hype suggested -- or different, OSGi may regain some attention with the IoT.) But as it is often the case in such cases, the (now) experts never felt tempted to write the kind of introductions that you find during the hype-phase of a new technology.
Which brings me back to the question from the title, after all: "Is there a new standard?" (which implies whether it is worth to spend time on looking into OSGi). The answer depends on what aspects of OSGi are important to you. Project JigSaw aims to bring modules to the Java platform and to developers. With a target date of March 2017 for the central JSR 376 I'd say this might be called an "upcoming standard" (provided it gets finished). But OSGi is more than just modules. Other key features are dynamic configuration (I can't see any competing standard regarding this feature) and micro-Services (be careful about that term, it seems to have two different interpretations currently). Eventually, you have to look a bit into OSGi yourself to decide on its usefulness for your project.
You can check tutorials that help you start with OSGi OSGi Tutorial: From project structure to release and OSGi Tutorial: 4 ways to activate code in OSGi bundle
There's a lot of outdated tutorials out there, outdated documentation, and stuff which is deep in the Java EE thinking bog - incomprehensible if you're not familiar with the problems arising from the solution to the problems arising from the solution to some obscure Java decision in the previous millennium, which you're now stuck with in your mammoth EE app.
Today, there is the OSGi enRoute projects which provides a set of pretty nice tutorials, along with an OSGi "distribution" which makes dependency resolution easier. My understanding is that a lot of the additional services in enRoute are en route (ha!) to becoming the OSGi Release 7 standard.
If you want to do new development in OSGi, it's what I would go to for sure. In fact, even if you want to use OSGi in some legacy-support function, I'd read up on the enRoute way first, before getting into all the ugly compromises needed for legacy's sake.
If you are mainly looking for server side OOGi then using maven and the maven bundle plugin works very well. See http://www.liquid-reality.de/display/liquid/2011/02/15/Karaf+Tutorial+Part+1+-+Installation+and+First+application
Apache Karaf is an OSGi container that I believe makes OSGi, 'easier,' to understand and work with. You might consider getting this installed and just try it out. Documentation is pretty good as well. Take some time learning about a running OSGi container; watch it run first trying out a few commands and then deploy some simple bundles while putting a tail on the karaf.log.
Seeing Karaf running will help you understand more about OSGi and what it takes to get a bundle built and deployed/running.
IMHO: Both BndTools and Maven Bundle plugin are fantastic resources for OSGi development.
Related
I want to know why OSGI framework is used when building java applications. I am searching the web for this but answers look complex to me. Can anyone please explain few points on why we need to adopt osgi.
Am sorry if the question does not suit stackoverflow
I appreciate the patience of the readers. Thanks.
OSGi provides a modular system with versioning of the modules, and further a bit of life cycle management. It manages dependencies between modules, dynamic/lazy startup/uninstall of modules, lookup/discovery and such.
Part of this will become part of the java language. It enables a lesser complexity than a spaghetti wiring of classes.
IMHO OSGI on its own requires a a lot of boiler plate code for what it does. However if you use a library like Karaf & iPOJO most of the overhead is hidden and you get most of the benefits.
The main benefit is being able to control which versions are used and proper module isolation. For example you can
have the container download the right versions from a maven repository like nexus.
use multiple version of the same library and have the modules which need those use the right ones.
stop, upgrade and start modules while the application is running.
a web console to see the state of all your modules and manage them collectively or individually.
For me the best part of OSGi is that it promotes a service-oriented view of your system, which helps decoupling, testing and teamwork.
I don't think it has to be complex, as I tried to demonstrate with my "OSGi for mere mortals" example application [1] and slides [2] (both shameless plugs ;-)
[1] https://github.com/bdelacretaz/OSGi-for-mere-mortals
[2] http://www.slideshare.net/bdelacretaz/osgi-for-mere-mortals
Go through with this tutorial thoroughly. You might get your answer.
OSGi is a fast framework because it knows that which service will be loaded into OSGi environment thanks to pre-defined xml file. It reduces runtime cost thanks to lazy state. Service instance is created when they needed. Some bundle's different version can be used by other bundle at the same time. Since each plug-in has it own class loader, any bundle can be stopped, started, installed or uninstalled without stopping Java Virtual Machine.The communication among the bundle is possible by using declarative service or service tracker in OSGi environment via interfaces. Using interface frequently pay the way for reusable code. Although OSGi framework contains quite a few class and interface, powerful projects can be created by using it. Since java runs everywhere, OSGi can also run.
I'm trying to fully master and fully grasp Java's Spring 2.5 and Hibernate framework for a limited amount of time (maybe in in less than 2 days?) and would like to ask this community if you can point out where I can start in mastering both frameworks. I kind of understand that it takes time to fully master both frameworks but would it be alright if you can point out tutorials where annotations, the xml mapping, and many of the basic things I need to grasp Spring and Hibernate are explained to a beginner who only tried to understand within the past couple of days?
I've tried googling bunch of times and wasted 3 days already trying to figure out and understand the concepts but it seems I understood nothing yet.
One of the major problems is that I could only use the following: Eclipse, Maven, Jetty, MySQL and can't use others like Tomcat or Ant, etc.
I'm using Linux Mint 10 / Ubuntu 10.10 in learning this in short time (yeah, I am in a limited amount of time #_#).
I thank you in advance.
The Spring Reference Documentation (for 2.5.x) is a very good place to get an overview and examples on how to use the framework's features. I would recommend using a recent version of Spring, though (3.0.5 is the current stable release, 3.1 will be out soon).
The same goes for the Hibernate docs (choose your version there).
I know that reference docs are not that popular, but especially the Spring guys do great work putting together speaking examples. They also have a blog post series called "Green Beans" which introduces Spring features one by one. Maybe this should be your starting point, together with their sample projects SVN repository - the "Petclinic" project uses Spring and Hibernate together.
I'd recommend POJOs in Action, by Chris Richardson. It's a few years old but it still covers what you need.
After reading a ton of blogs and getting frustrated by all the different ways people suggest configuring these projects, I finally just created a very basic example project which integrates Spring 3.0.5, Hibernate and Ehcache. It also enables JMX easily. Take a look...
https://github.com/lookfirst/fallback
I would recommend spring Frame work reference docs. secondly, download the Spring Source Code, set up the project, go thru the internals, try sample given with spring download, google help for spring samples or tutorials.
You Will be the Master!
I am just familiar with OSGi technology - never used but heard of it so many times. I've read several articles "for dummies" but I think I still fail to understand its use case completely. Maybe some of you could confirm if I understood it correctly.
Here is an example of what I might want to do.
Let us assume that I want to build a Java web application. Simple war. But, organized in such way that it contains different modules. Each module would contain different functionalities. Maybe each module would be packed as a separate jar, I am not sure.
Now, what I would like to have is UI part of the app capable of checking which of the modules are deployed too in order to show (or not) related menus, items, parts of pages, etc...
So, is the OSGi technology solution for this kind of problems or not? Is this what it is intended to be used for or am I off the track?
Thank you in advance for your answers.
Yes, OSGi technology is a solution for the kind of problem you mentioned in your question.
Eclipse is one solution that uses OSGi technology. In Eclipse, the UI would be an Eclipse Rich Client Platform (RCP), while the other modules would be Eclipse plug-ins. Each module would be a separate package that includes more components than a JAR.
You can use other solution platforms, or write all of the OSGi code yourself. The idea behind OSGi is to make your application more modular, so that you can update pieces of your application without having to update the entire application.
So, is the OSGi technology solution for this kind of problems or not? Is this what it is intended to be used for or am I of the track?
I would say this is exactly the kind of scenario OSGi caters for.
Look into the Eclipse RAP project, which runs on top of the Equinox OSGI container, and does the kind of thing you describe.
Some excellent tutorials are available on vogella.de.
Vaadin is an osgi based web framework in which you can accomplish this.
Alternatively you could have a look at the OSGI and Equinox book, it should contain enough info to help you roll your own solution.
I'm currently evaluating ivy, maven and buckminster to ease our build process. Conceptually buckminster seems the most advanced, but also to have quite a complexity.
I can't find so many first hand experiences to buckminster on the web, therefore my question to the Stackoverflow community.
We adopted buckminster for our build process in July.
Our set up was to use Ant being run by a CruiseControl server.
We chose it as we have multiple projects living in multiple repositories. We have several RCP products that use different combinations of these projects.
Managing the checkout (and build) for each of these products had to be run off the metadata which we were writing already (manifest files, product files). It was just too easy to get the build and dev metadata out of synch.
Building bundles and generating a product still is not easy to do by hand.
New starters need to be up and running quickly. Two+ days to set up a dev environment is not acceptable.
Overall, I found that it is a very powerful tool with poor documentation. There are lots of new concepts, and because it is a framework to plug tools into, some of those names for these concepts can be quite abstract.
However, buckminster absolutely excelled at solving the three problems detailed above.
Other additions:
It can bootstrap itself, as in: it can check itself out, given a minimal core
It seems to be under active development
Support via the mailing list is terse, but generally helpful.
It has a rudimentary scripting language. Very rudimentary.
On the downside (apart from the lack of docs):
it is still not mature - you find the occasional bugs, and some features which just should be there, but aren't.
I could not work out how to make the test bundle work
Testing OSGi products is still non-trivial and not easily made headless.
Overall, I would say that it took a while to bed in, but does an excellent job. I cannot compare it with Ivy or Maven, though Spring's adoption of OSGi may give critical mass in developer mindshare to Maven.
I have answered a few questions concerning buckminster, for help when you start.
We use buckminster running via Jenkins to build a KNIME (eclipse) update site with multiple plugins / features hosted in multiple repositories. Initial decision was because that it how the KNIME community contributions are built. There is a learning curve, but once it is running. A lot of our initial setup process was based on the instructions at Developing plugins - continuous integration with Jenkins
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What makes a module/service/bit of application functionality a particularly good candidate for an OSGi module?
I'm interested in using OSGi in my applications. We're a Java shop and we use Spring pretty extensively, so I'm leaning toward using Spring Dynamic Modules for OSGi(tm) Service Platforms. I'm looking for a good way to incorporate a little bit of OSGi into an application as a trial. Has anyone here used this or a similar OSGi technology? Are there any pitfalls?
#Nicolas - Thanks, I've seen that one. It's a good tutorial, but I'm looking more for ideas on how to do my first "real" OSGi bundle, as opposed to a Hello World example.
#david - Thanks for the link! Ideally, with a greenfield app, I'd design the whole thing to be dynamic. What I'm looking for right now, though, is to introduce it in a small piece of an existing application. Assuming I can pick any piece of the app, what are some factors to consider that would make that piece better or worse as an OSGi guinea pig?
Well, since you can not have one part OSGi and one part non-OSGi you'll need to make your entire app OSGi. In its simplest form you make a single OSGi bundle out of your entire application. Clearly this is not a best practice but it can be useful to get a feel for deploying a bundle in an OSGi container (Equinox, Felix, Knoplerfish, etc).
To take it to the next level you'll want to start splitting your app into components, components should typically have a set of responsibilities that can be isolated from the rest of your application through a set of interfaces and class dependencies. Identifying these purely by hand can range from rather straightforward for a well designed highly cohesive but loosely coupled application to a nightmare for interlocked source code that you are not familiar with.
Some help can come from tools like JDepend which can show you the coupling of Java packages against other packages/classes in your system. A package with low efferent coupling should be easier to extract into an OSGi bundle than one with high efferent coupling. Even more architectural insight can be had with pro tools like Structure 101.
Purely on a technical level, working daily with an application that consists of 160 OSGi bundles and using Spring DM I can confirm that the transition from "normal" Spring to Spring DM is largely pain free. The extra namespace and the fact that you can (and should) isolate your OSGi specific Spring configuration in separate files makes it even easier to have both with and without OSGi deployment scenarios.
OSGi is a deep and wide component model, documentation I recommend:
OSGi R4 Specification: Get the PDFs of the Core and Compendium specification, they are canonical, authoritative and very readable. Have a shortcut to them handy at all times, you will consult them.
Read up on OSGi best practices, there is a large set of things you can do but a somewhat smaller set of things you should do and there are some things you should never do (DynamicImport: * for example).
Some links:
OSGi best practices and using Apache Felix
Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
one key OSGi concept are Services, learn why and how they supplant the Listener pattern with the Whiteboard pattern
The Spring DM Google Group is very responsive and friendly in my experience
The Spring DM Google Group is no longer active and has moved to Eclipse.org as the Gemini Blueprint project which has a forum here.
When learning a new technology rich tooling gets you into things without big headaches.
At this point the community at ops4j.org provides a rich toolset called "PAX" which includes:
Pax Runner: Run and switch between Felix, Equinox, Knopflerfish and Concierge easily
Pax Construct: Construct, Organize & Build OSGi projects with maven easily
Pax Drone: Test your OSGi bundles with Junit while being framework independent (uses PaxRunner)
Then there are many implementations of OSGi compendium services:
Pax Logging (logging),
Pax Web (http service),
Pax Web Extender (war support),
Pax Coin (configuration),
Pax Shell (shell implementation, part of the next osgi release)
and much more.
.. and there is a helpful, framework independend community, - but thats now advertisement ;-)
This answer comes nearly 3 years after the question was asked, but the link I just found is really good, especially for starters using maven. A step-by-step explanation.
Is your existing application monolithic or tiered in seperate processes/layers?
If tiered, you can convert the middle/app-tier to run in an OSGi container.
In my team's experience, we've found trying to do web-stuff in OSGi painful. Other pain points are Hibernate and Jakarta Commons Logging.
I find the OSGi specs pretty readable and I recommend you print out the flowchart that shows the algorithm for class loading. I'll guarantee you'll have moments of, "why am I getting a NoClassDefFoundError?": the flowchart will tell you why.
Try http://neilbartlett.name/blog/osgibook/. The book has hands on examples with OSGi best practices.
Try http://njbartlett.name/files/osgibook_preview_20091217.pdf
OR
http://www.manning.com/hall/
The second is not a book i have read myself but I have heard good things about it.
The first was very useful for me. He takes you through the architecture initially and then it's hands on OSGi.
There are a couple of thinks to keep in mind if you are starting with OSGi.
As mentioned elsewhere in this thread, knowing about classloading is really important. In my experience everybody sooner or later runs into problems with it.
Another important thing to remember is: never hold references! Have a look at the whiteboard pattern on which the services concept of OSGi is build (see the link in one of the other answers).
In my experience you should not try to convert a monolitic application into an OSGi-based one. This usually leads to a badly and unmanageable mess. Start anew.
Download one of the freely available stand-alone OSGi implementations. I found Knopflerfish rather good and stable (I use it in many projects). It also comes with lots of source code. You can find it here: http://www.knopflerfish.org
Another good tutorial can be found here. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial
Peter Kriens of the OSGi Alliance gave a nice interview: http://www.infoq.com/interviews/osgi-peter-kriens. His homepage and blog (which is always a good read can be found here: http://www.aqute.biz
I really like the Apache Felix tutorials. However, I think in general leveraging OSGi in your application isn't one of those "let's use this framework, because it's hype" decision. It's more of a design question, but then everything that OSGi gives you in terms of design, you can have with vanilla Java as well.
As for the runtime, you cannot just add an existing application and make it OSGi enabled. It needs to be design to be dynamic. Spring DM makes it easy to hide that from you, but it's still there and you need to be aware of it.