Skip to main content

MANIFEST.MF in Plain Java, EJB, OSGi - catching the drift

While reading about OSGi, I realised how the importance of MANIFEST.MF has grown over time. The once only-a-jar-information file has had its ups and downs. When I was in school, *chapter jar* was an "assignment" / "reference". It wasn't worth a class' time spent on it. Today a whole new technology relies on this humble text file.

Past: Long long ago, in stone age (yeah I am exaggerating), the MANIFEST.MF was auto-generated while jar-ing. More or less it was not used. Well, yeah if you are developing a java application to be distributed to end-users (the jars you used to double click, which are so replaced by jnlp a.k.a WebStart apps now). This file would give a place to specify the class path
Manifest-Version: 1.0
Created-By: 1.4.2 (Sun Microsystems Inc.)
Main-Class: com.big.long.package.MyAppMain
Class-Path: mod1.jar mod2.jar lib/lib.jar
This will be set when running
java -jar myapp.jar
which other wise would have to be something like 
java -jar myapp.jar -cp all_the_jars_to_be_in_classpath

Another *advanced* usage was in Applets. For an applet developer, to include modular jars in your applets' class path. (if you have one enough to make up its own jar, and enough that it is using custom or third party library jars;I am no more into applets but, replaced by jnlp too.. I guess? Or may be done soon. Look at JavaFX)

Near Past: Then came EJBs. These *were* soo cool! (Sorry you EJB lovers, if any, still reading this.. I Love Spring Beans). EJB spec emphasised MANIFEST.MF to level 2. The WAR files and EJB jars would share common librarys by packaging them in the same EAR and referencing them in MANIFEST.MF's class path. For example, a app-dto.jar is common to both app-web.jar and app-ejb.jar the EAR would contain a app.ear, app-web.war, app-ejb.jar, and app-dto.jar, the app-ejb.jar file would have a MANIFEST.MF that looks like
Manifest-Version:1.0
Class-Path: TradeInfo.jar
(And then, you know, Spring came and EJBs lost the war, people lived happily ever after.. :P But the MANIFEST.MF din't lives on..)

Now: we have OSGi which is basically only a spec. It defines some more metadata (headers) in this MANIFEST.MF. A Typical file looks like
Manifest-Version: 1.0
Bundle-Name: HelloWorld
Bundle-Activator: HelloActivator
Bundle-SymbolicName: HelloWorld
Bundle-Version: 1.0.0
Import-Package: org.osgi.framework
So to learn OSGi, all you need to learn is these headers and what they mean. This as you can realize by now is only metadata defined by the spec. The implementations will actually use these.

Future: MANIFEST.MF is not going anywhere. It is here to stay. Look at Equinox Extension for Eclipse Plugin development. It adds more headers like Eclipse-PlatformFilter, Eclipse-LazyStart. Spring dm Server adds its own functionality on top of Equinox, to features like bundle personality, library importing etc. There may be more of these coming. But all in the The very humble MANIFEST.MF we are talking about is silently delivering a new purpose.
Labels:

Popular posts from this blog

One page Stock

Alright.. That was a long absence. The whole last week I dint blog. I dint go away. I was "occupied". I was learning stock trading. Its very fascinating. I have a good weeeked blog for you all. Here is my experience. I can literally hyper-link every word from the following paragraphs, but I am writing it as simple as I can so you can look up the italicised words in wikipedia . I got a paper trading account from a brokerage firm . You need one brokerage account first. Then it can be an Equity account where all your money is yours or a Margin account , where some of the money is lent by the brokerage firm. Then I get Buying power , which is the dollor value of how much stocks you can buy. I can make profit by simple rules. Buy when Price is low. Sell when price is high. There is another more intersting way of earning money. Selling short . Thats when price is not high, per say, but when are confident that the price WILL go down. then buy back when its lowest. This is what
Read More >>

Appcache manifest file issues/caveats

Application cache (appcache) is a powerful feature in HTML5. However, it does come with baggage. Many (see links below) advocated ferociously against it due to tricky issues it comes with. For someone who is just testing waters, these issues may throw them off grid. Knowing them before hand helps reduce some unpredictable effects.
Read More >>

classpath*: making your Modular Spring Resources

Spring gives multiple options to load XML resources for building contexts. the reference documentation does explain this feature quite well. However, I am taking my shot at explaining the different practical scenarios ( by order of growing modularisation) For Example, A simplest Spring based web Context Loader can be configured with resources like this <context-param> <param-name>contextConfigLocation</param-name> <param-value>applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> You just need to put applicationContext.xml in WEB-INF/ folder of your webapp. However, Typically an application is n-tiered. You can also have multiple files setup and in relative paths. like <param-value> context-files/applicationContext.xml context-files/dao.xml context-files/service.xml </param-value>
Read More >>