Feeds:
Posts
Comments

Archive for May, 2011

I was reading up on JMS of late. The more I read the more I got confused about the usage of terms persistent and durable in the context of JMS. Then I found this blog which cleared my issues. Thanks Nigel for the great post. :). Anyway here is the gist of that blog I committed to my memory.

  • Persistent apply to messages while durable apply to subscriptions.
  • Queues don’t have durable/ non-durable distinction because consumer always gets a durable subscription.
  • For queues:
  1. Persistent : Message will be saved on disk and sent later if consumer is inactive.
  2. Non-persistent : Messages will be saved in-memory and sent later if consumer is inactive. But they will not survive a broker re-start.
  • For topics:
  1. Persistent & Durable : Message will be saved both on-disk and in-memory and sent later if subscriber is inactive.
  2. Persistent  & Non-Durable : Message will not be saved either in-memory or on disk and any inactive subscriber at the moment of message receipt at broker will not receive the message.
  3. Non-persistent & Durable : Message will be saved in-memory and sent later if subscriber is inactive. So it will not survive a broker re-start.
  4. Non-persistent & Non-Durable : Message will not be saved either in-memory or on disk and any inactive subscriber at the moment of message receipt at broker will not receive the message. Similar to Persistent & Non-Durable case.
  • In all these cases message is sent immediately if subscriber is active.

Read Full Post »

I use Maven Bundle plugin a lot since our projects are OSGi based. Basic idea I had of this plugin is that this plugin makes an OSGi bundle out of a normal jar (basically by augmenting the META-INF file) if we do declare exported and private package information correctly in it’s configuration section in the POM declaration. Normal procedure followed would be to copy the configuration from an existing POM and tweaking it according to the current project requirements. My knowledge about it was just about it until recently. It was when I bumped up on a strange issue one day I was forced to read more on the subject and fortunately solution was not that far away with the amount of comprehensive documentation and FAQ section found at plugin’s site [1].

So why am I making a blog out of this if all what you want to know is well documented somewhere else?

Well, mostly to document some points which do matter, in a concise point form as a future self reference rather than going through the lengthy documentation every time when my memory fails me. (Not a rare occurance I would say.. :)).

So here goes.. My points with bullets.. :).

  • <Export-Package> will copy the packages to the bundle and export them in the MANIFEST while <Private-Package> will copy the packages to the bundle even-though they will not be exported.
  •  If you want a class to be included in the bundle make sure the package that it lives in is present in either of these instructions or otherwise it will not get included in the bundle.
  •  If <Export-Package> and <Private-Package> overlaps <Export-Package> takes precedence.
  • Using negation “!” in <Export-Package> declaration will result in package being not included bundle and not exported as well.
  • If a negation following an non-negated package declaration overlaps with the non-negated package declaration, the negated package pattern will not take effect. Always put negations first in  <Export-Package> instruction to avoid these kind of issues.
  •  Plugin generates the Import-Package bundle manifest header based on the Java imports present in the classes of the bundle so generally it’s not needed to specify it explicitly.
  • If a referenced packages do not need to be available for at runtime for bundle to perform its intended task (e.g: only a test scoped class using the package which is only needed during test runs..) use negation inside not to import it.
  • If you need to import a package not referenced by any class in bundle use resolution:=optional directive after the package name as follows.

org.external.package;resolution:=optional

   The bundle would resolve even if the package is not present at runtime.

  • Use to import a dynamically loaded class (e.g: Using Class.forName()) given that it’s exported in originating bundle. Generally using “*” wild-card would do, since it will enable loading any dynamically loaded class in other bundles given that the package it lives in has been exported by those bundles.

So that’s about it for my notes. If you want a good tutorial have a look at [2] as well. By the way in case you are wondering about the issue I had, the second point sums it up pretty nice. :).

[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

[2] http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin

Read Full Post »

An earlier post dealt with how a file can be copied to a product during a feature installation during a p2 provisioning action. This post expands on that. Although natives touchpoint has got a copy instruction it only works with files. But it has got an unzip instruction which can be used to unzip a zip file to a given target at feature installation time. So we can workaround the limitation of copy instruction using unzip by having a zip file of the folder to be copied inside the feature.

Following is a sample p2.inf configuration to unzip a folder called configFolder to configurations directory in the product.

instructions.configure = \

org.eclipse.equinox.p2.touchpoint.natives.unzip(source:${installFolder}/

configFolder.zip,target:${installFolder}/configurations);

Read Full Post »

This post will describe how to install additional files such as configuration files, licenses etc. to a product along with a equinox feature installation. The files of interest is described below.

1. p2.inf

This file can be used to declare provisioning actions. More information about p2.inf format can be found at [1].  Various installation actions can be done by using touchpoints. A touchpoint presents an interface between p2 and a particular runtime configuration. Currently there are two touchpoints which contain instructions to performed, org.eclipse.equinox.p2.touchpoint.natives (os level instructions) and org.eclipse.equinox.p2.touchpoint.eclipse (p2 level instructions). Instructions fall in to one of the phases “install”, “uninstall”, “configure”, “unconfigure” in the p2 engine phases. Many of these instructions accept arguments.
Comprehensive documentation about touchpoints can be found at [2].

For this discussion we use natives touchpoint’s copy instruction. There is a particular syntax that has to be followed when specifying a instruction.

Citing from documentation..

 As an example – an “install” instruction for a bundle might consist of the following statement:

installBundle(bundle:${artifact});

* installBundle is the action name
* bundle is the parameter name
* ${artifact} is the parameter value. The value ${artifact} signifies the use of a pre-defined variable named “artifact”.

Now let’s specify we need to copy conf.xml file to configuration folder upon feature installation.

instructions.configure =  \ org.eclipse.equinox.p2.touchpoint.natives.copy(source:${installFolder}/

conf.xml,target:${installFolder}/configuration/conf.xml,overwrite:true);

Here we have specified this instruction should be carried out in “configure” phase using instructions.configure directive. ${installFolder} is one of the predefined variables defined in all the phases which denotes the root folder for current profile.

2. build.properties

The role of the build.properties file is to map development-time structures in a bundle’s project onto the structures described in the bundle’s manifest and needed at runtime. It’s documentation can be found at [3]. In this case we configure it to copy our configuration file to the generated feature during feature build. Important thing to note is that build.properties file is used at build time while p2.inf is used at feature installation time to perform similar jobs.

We use a feature specific property root to indicate to list the files and folders to be copied to the root of the generated artifacts. Documentation about rootfiles can be found at [4].

Here are the entries in the build.properties used in this example.

custom=true
root=file:conf.xml

From documentation..

‘custom=true’  – indicates that the build script is hand-crafted as opposed to automatically generated. Therefore no other value is consulted.

“file:” prefix is used to denote a relative path while “absolute:” prefix is used to denote an absolute path. Relative paths are taken relative to the containing feature.

With these configurations in place we are ready to build the feature and provision it in to the respective profile.

[1] http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata

[2] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_actions_touchpoints.html

[3] http://help.eclipse.org/helios/topic/org.eclipse.pde.doc.user/reference/pde_feature_generating_build.htm

[4] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_rootfiles.htm

Read Full Post »

Working with svn externals

Viewing current svn externals recursively.

  • svn propget svn:externals -R

Add a svn external

Note that conf folder should not already present in the svn. Also note the current working directory notation ‘.’ at the end. This will create a conf folder which is an svn external in current directory.

Removing a svn external

  1. svn propedit svn:externals
  2. Remove the external property definition in pop up editor and save.
  3. Commit the change.

Read Full Post »

Some Common SVN Issues

Problem : svn: warning: Working copy ‘xxx’ locked

Solution : Run a svn cleanup. If that fails..
1. Get a svn diff of local modifications to a patch.
svn diff > patch.diff
2. Delete folder containing locked resource path from the file system. Do not use svn delete.
rm <folder-containing-locked-resource>
3. Run a svn update
svn up
4. Apply local modifications to working copy.
patch -p0 -i patch.diff

Problem : svn: warning: ‘xxx’ is already a working copy for a different URL after adding a svn:external

Solution : In this case you might have done a mistake in setting the external. An external property to download an already existing folder will  cause this error. If this is the case..
1. Remove the svn external
* svn propedit svn:externals
* Remove external definition in the editor and save it.
* Do a svn update
svn up
* Now commit
svn ci

2. Delete folder from svn and file system
svn delete
rm -rf <folder-having-svn-external>
3. Set new external. This time without the folder. For example.
svn propset svn:externals ‘conf http://sample.org/trunk&#8217; .
This time since there is no existing ‘conf ‘ folder it will not conflict with the external.

Read Full Post »