|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 13
Messages: 13
Messages: 13
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Article: OSGi for Beginners
"OSGi for Beginners" is the first of a series of articles aimed at teaching developers how to create OSGi bundles, including dependencies included with the bundles.The Seven-Word and Twenty-Four-Second explanations of OSGi
OSGi is a component framework for Java.
The twenty-four second explanation: OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.
Rats. Twenty-seven seconds, no matter how fast I run through - I just can't talk quickly enough. What's worse, the explanation doesn't explain why one wants a module system in the first place.
Why a Module System?
Module systems provide version support for distributed bundles (where "bundle" goes way beyond "OSGi bundle" - I'm using the term to refer to any application.) Dependency hell is also an issue; lifecycle is ... interesting.
All of these things are important; versioning still hasn't made it into web services, EJB versioning is enforced via JNDI, but few use it (nobody in the wild that I know of), jar dependencies are managed normally with parallel jar deployments (except for JCA and WARs, both of which have different ways of managing dependencies).
Java EE has solutions, although not necessarily good ones: WARs and JCA can contain jar files, EJB jars can refer to other jar files through their manifests, and of course app servers can provide a higher-level class repository; versioning is provided through JNDI as long as you're not using different versions of the same web app or web services. Lifecycle exists for webapps (load-on-startup servlets, context listeners) and JCA, but EJB 3.1 might have a lifecycle mechanism - it's not sure yet.
And we all know that Java EE is a hammer that fits everything.
OSGi and JSR-277 are attempts to standardize module deployments for Java, without forcing a Java EE mindset, and without Java EE's weaknesses regarding dependencies and versioning and - for that matter - lifecycle.
|
|
|
Message #252162
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
Nice. Just 2 days ago I was looking for something like this. Thanks a lot. Now we can change the #java factoid for osgi that currently says: OSGi is a module system for Java, defined by http://www.osgi.org/ . It's a lot cooler than you'd think, even despite Eclipse relying on it for bloody well everything. Naturally, the quality of its documentation in inversely proportional to the usefulness of the framework itself.
|
|
|
Message #252164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Module Systems?
I am new to OSGi, could someone please give an example of these module systems.
What would be the big difference between a Module System and a struts app? I'm not even sure if that is a good comparison, but a comparison of the Module System alternative would be helpful as well b/c I do not think I understand the problem well enough to understand the article or anyone's future answers.
Any additional information, links, and/or tutorials would be appreciated as well.
Cheers,
SEan
|
|
|
Message #252166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
Nice article! It certainly shows the power and possibilities of OSGi.
One thing I do wonder is, won't it be hard to make the bundles of just the right granularity for just the other bundles that just happen to need some sort of shared functionality?
I mean bundles that just have different requirements might need a simple bundle or a 'boosted bundle' (with same functionality, but just a little bit more than the simple bundle). In the end how well could it be maintained, any ideas on this yet?
|
|
|
Message #252167
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Module Systems?
Think of OSGi modules as "live" code that you deploy in bundles. The OSGi core pulls modules from a URI either in response to a user action or based on a schedule. A "bundle" is just a .jar file containing your Java code, a manifest file, and at least one class that's "OSGi-aware".
The bundles can contain any type of Java classes/objects. They can be deployed and activated simultaneously or with a delay in between. The goal is to provide a mechanism for deployment of "live" code without having to manually start/stop an application or container.
Here is an example for understanding the problem: you ship a few hundred thousand Blu-Ray players with software already enabled. You have a bug fix that needs to be deployed by June, and that must be active in September. OSGi provides facilities/APIs for managing all this in a very simple manner.
As far as your application is concerned, unless you're doing the actual bundle management you have no reason to worry about OSGi. Write your app as you'd normally would, then create a bundle and deploy it. If all is working well, neither you nor your end-users should care about OSGi.
Cheers,
pr3d4t0r
Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade and Amazon best-seller Dec. 2007:
The Tesla Testament by Eugene Ciurana
|
|
|
Message #252173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Awesome
Thanks Eugene, just what I was looking for. This article now makes much more sense.
|
|
|
Message #252200
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can your webapp use the appserver's OSGi implementation?
Can your webapp take advantage of the built-in OSGi implementation of appservers like WebSphere or Glassfish rather than including an implementation like Equinox in your web application?
|
|
|
Message #252201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Can your webapp use the appserver's OSGi implementation?
Can your webapp take advantage of the built-in OSGi implementation of appservers like WebSphere or Glassfish rather than including an implementation like Equinox in your web application? Well, it depends on the nature of the integration. There are three ways to use OSGi plus web applications:- Embed an OSGi container into a web application. This means the .war has to have access to all of the bundles you want installed. It also means that you might have more than one OSGi container in a given servlet container.
- Embed a servlet engine in OSGi - and install servlets as OSGi services via an http bridge.
- Use the Spring Application Platform, which allows you to have the best of both worlds - you install OSGi bundles and locate their services via Spring from within your web application.
|
|
|
Message #252367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
We've used OSGi for two years and I'm impressed that, even though the technology is new, the bundles run unchanged in all the major OSGi containers available.
It solved all the dependency and life cycle problems we had with EJB, without enforcing any of the lame restrictions.
Go OSGi!
|
|
|
Message #252457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept.
I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally.
Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped?
Cheers,
David
Flux - Java Job Scheduler. File Transfer. Workflow.
|
|
|
Message #252475
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept.
I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally.
Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped?
I'm just getting started with OSGi myself but the bundles I've created could be restarted after being stopped.
|
|
|
Message #252538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: OSGi for Beginners
Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept.
I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally.
Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped?
I'm just getting started with OSGi myself but the bundles I've created could be restarted after being stopped.
Yep - a stopped bundle is just stopped. It's easy to restart.
|
|
|
Message #254114
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BundleClassLoader and class versions
Hi,
I am new to OSGi and using Knopflerfish. I really liked this article. It mentions separating interface from implementation as two separate bundles. In Knopflerfish it helps avoiding to refresh all installed bundles when you update your implementation bundle as client bundles only interface with the interface bundle.
In my project, I'm using internal dependencies which bring me to my question. I get a java.lang.LinkageError while trying to use the same dependent library (JTS) in two different bundles. Is there a way to share and manipulate objects with third-party-datatypes when the same jar(s) exist on both bundles... I return a Geometry object which is not accessible at client side bundle as BundleClassLoader gets agitated over different class versions!
The exception I get is:
java.lang.LinkageError: loader constraint violation: when resolving field "g1" the class loader (instance of org/knopflerfish/framework/BundleClassLoader) of the referring class, com/abc/klm/Place, and the class loader (instance of org/knopflerfish/framework/BundleClassLoader) for the field's resolved type, com/vividsolutions/jts/geom/Geometry, have different Class objects for that type.
Did someone face this situation? Any comments will be highly appreciated.
|
|
|
Message #254253
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: BundleClassLoader and class versions
Ok, the solution to class version conflicts at different bundles was actually resolved quite simply by converting the required third party (LGPL) library into an OSGi bundle. The dependent bundles then receive the same class object at runtime and no conflicts occur. The BND tool by Peter Kriens came in handy.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
