10 clues showing that you are doing OSGi in the wrong manner - Jerome Moliere
by mfrancis on Sep 21, 2011
- 1,843 views
This presentation aims to show common pitfalls in OSGi architecture and development and how to avoid them. It involves concrete use cases and their solutions. Antipatterns, bad designs , bad tooling ...
This presentation aims to show common pitfalls in OSGi architecture and development and how to avoid them. It involves concrete use cases and their solutions. Antipatterns, bad designs , bad tooling will be presented during this session... This session is user oriented and aimed to give concrete feedbacks and good practices...
Accessibility
Categories
Upload Details
Uploaded via SlideShare as Adobe PDF
Usage Rights
© All Rights Reserved
Statistics
- Likes
- 3
- Downloads
- 124
- Comments
- 2
- Embed Views
- Views on SlideShare
- 1,843
- Total Views
- 1,843
As software architect, learning is continous.
Mentor/J has done a huge work of reengineering with OSGi foundations....
This presentation is like advertising for a set of tools than anything else. Not very convincing. The author is still very vague.
I emphasize one thing: OSGi should be transparent to any business application developer.
Anyway, let’s see how to do OSGi in the good manner.
....................................................................
Item 1 - Start levels
....................................................................
- First, read carefully Chapter 11 - Launching OSGi using start levels
(OSGi in Depth : http://www.manning.com/alves/)
- Second, if you haven’t understand, then ask your Mentor (http://stackoverflow.com/questions/7462259/how-is-the-osgi-bundle-start-level-defined)
’It isn’t practical to use FileInstall in a production application. I recommend you use a more stable and repeatable mechanism for installing bundles, e.g. by reading a configuration file containing a list of bundle locations with start levels. (Even better of course: stop relying on start levels altogether -- the fact that you have to use them usually indicates that you have done something wrong). – Neil Bartlett Sep 18 ’11 at 19:35’
- Third, still not understand - read this :
The framework uses settings known as Start Levels to organize the startup of the bundles. The framework exists at a specified level and the bundles are assigned to start at a specific level. The framework begins at level 0 with no bundle started. Next, the Framework will move to start level 1. All bundles assigned to start level 1 will then be started in some order. The framework will progress through each of the levels until it reaches the designated framework start level. The designated framework start level is determined by the osgi.startLevel property. The bundles that are started during the start level processing are those which have had a start level specifically assigned, and which have been marked to persistently start.
....................................................................
Item 2 - Bad logging usage
....................................................................
- First, read (http://blog.kornr.net/index.php/2008/12/09/understanding-the-osgi-logging-service) to understand what is OSGi Log Service.
--> the logging service is often seen as a unusable toy-like API.
- Second, use the out-of-the box Equinox ExtendedLogService (http://eclipsesource.com/blogs/2009/03/24/tip-osgi-log-service/)
....................................................................
Item 3 - Required-Bundle
....................................................................
Read carefully : 5.5 Working with dependencies (http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/ch05s05.html)
Then you have two choices : use Import-Library or Import-Bundle
Yes, Business Enterprise Applications are not Hello Words examples.
If you don’t know how to design Enterprise Applications, read the free chapter 6 - OSGi and Spring DM for enterprise applications (http://manning.com/cogoluegnes/samplechapter6.pdf)
....................................................................
Item 4 - Versioning
....................................................................
- It’s an old topic that every OSGi novice already practiced.
- http://www.osgi.org/blog/2009/12/versions.html
....................................................................
Item 5 - Spring-DM usage
....................................................................
- This is an advanced topic. Before, you must know a minimum of Spring-DM.
- Regarding OSGi Declarative Service, contrary as you indicated in your book at the end of page 73, the XML files are in the OSGI-INF directory and not in OSGI-OPT (http://www.amazon. fr/OSGi-Conception-dapplications-modulaires-Java/dp/2212133286).
- How did you do to transform the XML Spring-DM injection files to XML Declarative Services injection files? (http://romjethoughts.blogspot.fr/2010/11/osgi-declarative-services.html)
- What Declarative Services implementation have you used? (http://romjethoughts.blogspot.fr/2010/11/osgi-declarative-services.html)
....................................................................
Item 6 - Not using Bnd ?
....................................................................
In OSGi land, there are lots of options...PDE, Maven, BND...
Choice of tooling will be like your choice of religion...Remember emacs vs. vi
Read : OSGi for Eclipse Developers (http://www.eclipsecon.org/2009/sessions?id=266)
....................................................................
Item 7 - Not using Web Console ?
....................................................................
In OSGi land, there are lots of options....See item 6.
Explore Eclipse’s OSGi console : http://www.ibm.com/developerworks/library/os-ecl-osgiconsole/index.html
http://www.knopflerfish.org/releases/3.2.0/docs/bundledoc/httpconsole/index.html
....................................................................
Item 8 - Are you really using modules ?
....................................................................
A modular application is, in essence, one that’s divided into several pieces with the connections between the pieces being controlled and well defined.
If you don’t know how to design Enterprise Applications, read the free chapter 6 - OSGi and Spring DM for enterprise applications (http://manning.com/cogoluegnes/samplechapter6.pdf)
....................................................................
Item 9 - Are you really using modules ?
....................................................................
Same as item 8. Don’t repeat your self.
Designing OSGi enterprise applications isn’t so different from developing “standard” enterprise applications: OSGi people don’t pretend that the world was waiting for them in order to write modular applications. Nevertheless, anyone can learn from the strict modular approach of OSGi [p. 180].
....................................................................
Item 10 - Still not understands versioning ?
....................................................................
Same as item 4. Don’t repeat your self.
Where are the clues.
....................................................................
Item Last - My bonus
....................................................................
Before reengineering applications you :
- Need more OSGi MasterClass (to go beyond Declarative Services for example and to learn more on Blueprint Services (standardization of Spring-DM))
- Like SPRING, ’Static, single-version module resolution is usually sufficient — Most applications do not need to add or remove modules dynamically at run time, nor do they need to use multiple versions of the same module simultaneously’ (The future of Java Modularity - http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01)
- Need more practice in Java IRM tools to be able to measure memory footprint (see my comments at http://www.slideshare.net/mentorj/osgi-con).
- FUD against SPRING may lead to very bad design decisions.
....................................................................
Happy reengineering with OSGi foundations.... 1 year ago