U.S. Tech Blog ...

Lot of Application servers or containers deploy different mechanisms for runtime loading of classes and libraries...Understanding these mechanics is really important for resolving conflicts in Enterprise Applications and Runtime environments (ie:-J2EE envs , OSGi containers running on top of App servers ,etc)...Most of the modern Application containers deploy a method called "Bootstrapping" to isolate container specific and application specific runtime dependencies..What "Bootstrapping" effectively does is provide an "unpolluted" classpath for application modules so that they can work independently from container classpath , avoiding any conflicts which other wise would have occurred..(conflicts in the sense unresolved Classes, Class Cast exceptions ,unexpected initialization of code ie:- static initializers , etc )...This means that with "Bootsrapping" an application module can run a different version of a dependent library/class from a version that container depends on without affecting each other...To understand "Bootsrapping" one needs to have a good overall view on java class loading mechanisms..I came across the following article that nicely explains these concepts with several practical runtime deployment perspectives.. http://www.theserverside.com/news/1364680/Understanding-J2EE-Application-Server-ClassLoading-Architectures .. hope this would be useful for those who are interested.....

i found it very annoying to use a touchpad in Ubuntu specially when typing...To add to the trouble my laptop does not have a manual turnoff switch for touchpads.....i came across the following post which describes how to disable Synaptic touchpad with a GUI interface..

If you are too lazy to remember and run 'gpointing-device-settings' in terminal , add command into the Applications submenu by --> (right click) Applications --> Edit Menus --> New Item


Update :------------------------------------------------------------------------------------ although at first 'gpointing-device-settings' looked great , it had certain limitations(ie:- timeouts can't be set,configuration issues)..therefore i had to go for a more crude method..
use 'xinput' to find device id for your touch pad..
$xinput list
mine was 13 (ie:-AlpsPS/2 ALPS GlidePoint id=13 [slave pointer (2)). I used this id to disable touchpad using
$xinput set-prop 13 --type=int --format=8 "Device Enabled" 0

Use System --> Preferences --> Startup Applications to add a startup script if you want to disable your touchpad from start :)

Eclipse plugins architecture is an extended layer of OSGi. It basically wraps OSGi layer (such as Equinox) to provide a rich framework for it’s plugins and extensions. What that obviously means is , deepdown inside runs the same mechanics of imported/exported bundle packages and their dependency loading runtime as described/portrayed in OSGi specs/platforms. Eclipse plugin information is defined in a configuration file called plugin.xml .Eclipse’s plugin loader (or kernel) is an implementation of OSGi R4 specification that is responsible for loading and unloading plugins. However Plugin Loader does not load all the dependencies(ie:-classes/libraries) at the start-up since doing so would be an overhead for most of the systems (especially very large/complex systems). Plugin Loader employees a mechanism called “lazy loading” to load plugins and dependent classes and packages only when they are needed at the later most possible time. It actually do this by constructing a dependency hierarchy at startup by reading the information contained in plugin.xml of all the available plugins and loading them in to memory. So when a particular plugin wants to load classes from a different plugin (exported by the plugin/bundle) it would load them using the EclipsePlugin Registry (memory structure that was loaded at the startup) , as and when needed by the programming flow.
Eclipse’s way of dependency management is two fold , which are

1)Creating dependencies
-describes which external plugins are required by the plugin at hand. For example for the operation of a plugin A we may require external classes/packages exported by a specific plugin B ,which can be depicted as “Plugin B required by PluginA”. By doing so “plugin A” get exposed to all the packages/classes exposed by “plugin B” . This is similar to specifying [Require-Bundle: PluginB] in Plugin A’s MANIFEST.MF . Some times a plugin may only need several exported packages of a specific plugin ,not all of them ,which can be depicted as “package a,b,c of Plugin B required by PluginA” . This is similar to specifying [Import-Package: b.org.ui] in Plugin A’s MANIFEST.MF . However there’s an additional complication .For example If another plugin C exports a package with the same name "b.org.ui" ,then there’s a chance of conflict to arise since we are no longer depending on a specific plugin but a package.

2)Creating Extensions and Extension Points
-defines how the plugin at hand can be involved in extending the functionality provided by other plugins (extensions) and what points of contact can a plugin provide so that other plugins can augment their functionality using the core functionality given –( extension points) . In other words extension-point acts as a pluggable interface/abstraction for outside plugins, while extensions act as a plugged component that has enhanced functionality. We can define extensions and extension-points in plugin.xml file .A respective Extension-point is normally written according to a specific schema (defining extending class ,name,plugin specific parameters,etc ) and plugin extensions should be solely responsible to extend accordingly to their respective schemas of the extending extension points. For Example we can create a customized View Panel in Eclipse by extending "org.eclipse.ui.views" extension point of org.eclipse.ui plugin . In our plugin say “org.simple.demo” we can have the following extension defined in our plugin.xml to create our customized view.


For above plugin to work properly we have to create "org.simple.demo.views.DemoView" class and extend it accordingly as specified in the documentations to "org.eclipse.ui" package classes. (ie:- more specifically by extending org.eclipse.ui.ViewPart and overriding #createPartControl(Composite) method ) .if the extension plugin is successfully deployed , as defined in the extension ,our view panel should appear under “DemoCategory” with the name “Demo view Panel” and it would have the ”sample.gif” icon on the title bar of the panel . (by intuitive observation we can see that this extension schema allows us to define multiple views under same category by declaring the same category id on view tag’s attributes for each view. However as good practice you should always go through the schema documentation of the relevant extension points for further clarification) .
It would be very interesting to look into how our extended plugin actually works at runtime . As mentioned at the beginning plugin-loader would load necessary information about different plugins at startup (ie:-known as creating Eclipse ExtensionRegistry) . Our plugin is actually an extension of "org.eclipse.ui" plugin ,hence using the information gathered at the startup(ie:-extension information of all the plugins that has extended on org.eclipse.ui.views extension- point) "org.eclipse.ui" would load all it’s extended views into the main panel displaying each and every category and their symbolic representation of views under them. Actual View will only be loaded(using the ExtensionRegistry information ie:-class name respective to the extension) when a user actually clicks the relevant view entry on the main panel containing list of views. This is known as “lazy loading” ,where actual class, in this case org.simple.demo.views.DemoView is loaded on demand.

Note that if we plan to create a plugin manually we should precisely reflect our intentions(especially related to dependency management) in plugin.xml (which is the file that eclipse abstraction layer operates on) as well as MANFEST.MF( which is the file that underlying OSGi runtime operates on). This could be especially difficult if we consider the unintuitive specifications of bundle properties needed to be written in Manisfest.MF (as in exporting, requiring bundles, naming conventions,etc) as well as numerous xml tagging schemas needed in specifying extensions and extension points which will drastically vary on plugin we are going to extend. Fortunately Eclipse provides plugin developers with PDE (Plugin development Environment) which gives a nice an easy user interface to workwith together with a elegant set of tools to seamlessly integrate and extend plugins without much hassle. Eclipse Plugin Manifest Editor categorize itself into five main sections/pages in creating a new plugin .Changes made in this sections directly reflects in MANIFEST.MF most of the time.

• Overview - defines plugin name, id (uniquely identifies a plugin ) , version, description, etc. You can also optionally declare a plugin Activator class if you want system setup code to be put in

• Dependencies - responsible for creating plugin dependencies (ie:-Required plugins/bundles and imported packages)

• Runtime - Defining exported packages for the consumption of other plugins(ie:- export package) .Additionally you can define the bundle classpaths for external jars for use within the plugin.

• Extensions - defining extensions and related parameters.

• Extension Points - defining extension points for a plugin and it’s schema


[Snapshot of Plugin Manifest Editor]

Code behind Extension Points

You may wonder how a plugin can load the extensions (may be declared in itself or by other plugins – most of the time ) defined by the respective extension-point it has. As mentioned at the beginning answer lies in the Eclipse extension Registry which eclipse kernel builds at startup. For this to materialize extension Registry needs the Extension-point Name on which the extensions are declared and the respective Plugin-ID .Following code snippet shows the code needed to acquire the declared extensions.

IExtension[] extensions = Platform.getExtensionRegistry().getExtensionPoint(“org.eclipse.ui”, "views").getExtensions();

for (int i = 0; i < extensions.length; i++) {

IConfigurationElement[] configElements =
extensions[i].getConfigurationElements();
}

try {
view = (ViewPart) viewConfigElement.createExecutableExtension(“class”);

} catch (Exception e) {

       Log.logError(
"Failed to instantiate factory: "
+ viewConfigElement.getAttribute(“class”)
+ " in type: "
+ id
+ " in plugin: "
+ configElement.getDeclaringExtension()
.getNamespaceIdentifier(),e);
}