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.
Related
How would you implement a Plugin-system for your Java application?
Is it possible to have an easy to use (for the developer) system which achieves the following:
Users put their plugins into a subdirectory of the app
The Plugin can provide a configuration screen
If you use a framework, is the license compatible with commercial developement?
First you need an interface that all plugins need to implement, e.g.
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.
Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
Use OSGi.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed Apache Public License).
Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCP if you want a full Eclipse/SWT/JFace stack).
Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.
But if you want anything more than basic features, use one of the existing frameworks.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.
Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.
The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.
I built the project with a few goals in my mind :
it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
basic application monitoring about system health, email notifications in case of failures
How would you implement a Plugin-system for your Java application?
Is it possible to have an easy to use (for the developer) system which achieves the following:
Users put their plugins into a subdirectory of the app
The Plugin can provide a configuration screen
If you use a framework, is the license compatible with commercial developement?
First you need an interface that all plugins need to implement, e.g.
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.
Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
Use OSGi.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed Apache Public License).
Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCP if you want a full Eclipse/SWT/JFace stack).
Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.
But if you want anything more than basic features, use one of the existing frameworks.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.
Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.
The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.
I built the project with a few goals in my mind :
it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
basic application monitoring about system health, email notifications in case of failures
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 new whith OSGi, but it is interesting.
Is it possible to interact between osgi bundles and java application? If it is possible, how?
thanks!
The context is that I have a big Java SE application(author is another programmer) with many dependencies. First my goal is to add new functionality and second - change architecture. I'll try to use OSGi, but I don't want to write code twice, for that reason I want to write new code now as bundles. But use this new functionality from the old application.
Yes! Yes! and Yes! This is a perfect way to start taking advantage of OSGi and evolving towards a service based application.
It is trivial to create a framework with the 4.2 launcher API without even knowing which framework implementation you use. You get a Framework object then that is actually an OSGi Bundle and can provide you with a BundleContext. This you can use to install bundles. This all is described in the spec but you can find a lot concrete and excellent examples in Felix: http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html. Felix has been explicitly promoting embedded in apps since day one.
The hard part of this approach will be getting used to modularity and its restrictions. To be useful, you will have to share classes between OSGi bundles and your application; this requires explicit exporting of these shared packages from your application using the org.osgi.framework.systempackages.extra property. This property is the Export-Package header for your application.
Importing packages from bundles in the framework is not possible due to the class loading model in Java. This means your application code can only use services from the framework where the packages for those services are on the apps classpath.
The result of this is that new functionality tend to drift to bundles where there is full visibility: both the exported app packages as well as any bundles. However, this is probably exactly what you want.
So be aware of this potential pitfall. Embed, and then over time migrate all your code to bundles so that your application becomes only an OSGi launcher. However, be very aware of your the packages shared between the two environments.
Good luck and let us know how this goes.
I see OSGi as a structuring technology. You can use it to define the component structure of your application. So all of your app is effectively a collection of OSGi bundles. Hence interaction is not a problem, just different bits of your app interating in the normal way.
[Edited following comment clarification.]
You have a fundamental decision: is your OSGi code going to execute in the same process as the original or in a seperate process?
Separation implies freedom to structure the new code as you wish, exploiting OSGi, but at the cost of interprocess communication complexity and performance overheads. It's pretty likely that you will end up making substantial changes to the existing app in order to support remoting in some form. I don't see this as a great approach unless your OSGi code happens to be some kind of re-usable service that perhaps other remote clients would use.
If in the same process then I'd say that you need to bite the bullet and say that this is going to be a OSGi application. The amount of effort to take an existing app and make it run in OSGi need not be excessive.
Suppose you treated the existing application as one huge OSGi bundle? There would be some work on initialisation, but would the rest "just work"? If you do this as the first step then the real re-architecting and modularisation of the existing app is deferred. You then just expose the interfaces your new modules need, and where necessary consume services provided by the new modules. Immediately you are getting OSGi benefits by structuring the dependencies.
An application build with OSGi can interact in the same way as just two normal (Java) applications. So, by loading / saving files. Or when one of them is created as an OSGi http server, then just communicate through http with that (OSGi) server. Just think of it as you used to do, without OSGi included.
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.