Flash Builder 4 Released
Checkout cool new features ...
- Data-centric development
- Network Monitor
- Flex Unit Integration
And tons of new enhancements
- Code Refactoring
- Integration with CS design tools
- Rich visual layout, skinning and styling
- Powerful coding tools
and many many more. Find out here >
Omniture SiteCatalyst Building Blocks in One Page
In this article I will make an attempt to provide you an overview of SiteCatalyst building blocks. After reading this article if you feel comfortable using few SiteCatalyst terminologies, then I have made a justification to my job by writing this. Lets start ...
SiteCatalyst is a web analytics software which helps you measure, analyze web usage.
Building blocks of SiteCatalyst are Traffic Variables (sProps), Success Events and Conversion Variables (eVars).
Traffic Variables, previously known as sProps, helps you track site traffic activity, ie Page Views, Visits and Unique Visitors. Traffic variables helps you segment/breakdown traffic activity into one of these three buckets. Traffic variables are not persistent in nature. That means from one page to another they do not retain their values. SiteCatalyst comes with predefined traffic variables like Page Name, Page Type etc. In addition to this it provides 50 customizable traffic variables to send your own custom data to measure traffic.
Along with measuring traffic, every web site has a definite key performance indicator (KPIs) associated with it. For example, an online store's KPI is orders, revenue and units sold etc. Where as a an online education's KPI could be number of users watching a newly launched course demo video. Lets see how Success Events and Conversion Variables are used in combination to measure KPIs.
Success Events counts the number of times visitors complete an action on your site, its the kind of action which describes the sole existence of your site. Success events are always numbers in nature. After an activity, lets say a shopping cart check out, you inform SiteCatalyst saying Purchase event occurred, then it increments its value by one. There are 8 predefined success events like purchase, add item to shopping cart etc. and 20 custom events which could be used for defining your own custom event.
Like traffic variables, which helps you segment/breakdown traffic activity, success events can be broken down by using conversion variables. Traffic Variables can NOT be used for segmenting success events. Lets reiterate, traffic variables are used for tracking and segmenting traffic activity. Where as success events and conversion variables together are used in measuring and segmenting KPI related information.
So how are conversion variables different from traffic variables ? Unlike traffic variables, conversion variables are persistent in nature. Once you set a value, the value will stick to it until you ask SiteCatalyst to forget about it. Whenever a success event occurs, each and every conversion variables associated with it gets the credit. For example, when you add an item to the shopping cart, lets say your city will be stored in one of the conversion variable. Before you check out you search for many other items, go back n forth in the site and so on, but the value remains in the variable. At the end once you check out, a purchase event is fired which gives credit to the value of the conversion variable that is your city. There are 50 such conversion variables available that can be used to measure KPIs.
I hope you found this useful. With this understanding we will be able discuss slightly advanced topics such as Data Correlations, Campaign Tracking and Products in the next post.
Eclipse Plug-in Fragments
Consider building an UI plug-in which has lot of Mac OS X and Windows specific SWT code, or localizing a plug-in for different languages, or building a dialog whose layout is locale dependent. All these problems share a common characteristic, they either depend on a platform or a locale or similar such fact.
When we have few lines of such platform specific code and very few such instances, easy way out is to put the conditional logic. However this isn't helpful when have too much of these. We will start seeing conditional logic all over the code and it starts rotting very quickly.
Next best solution is to extract platform specific code out to a new plug-in. Even though this solution is lot more cleaner compared to the above, it comes with its own cost. Lets call the original plug-in as platform independent plug-in and the new plug-in containing the extracted code as the platform dependent plug-in. If we look at the dependent plug-in more closely, the code it contains is extracted from the "core" of the independent plug-in. Hence to compile dependent plug-in, all the core packages of independent plug-in has to be exported. Exposing a core package is not at all a good practice as it will be available for everyone to consume.
OSGi Release 4 has introduced a new concept called Fragment Bundles to resolve this issues. A Fragment is a incomplete plug-in, it can not stand on its own. It has to attach itself to a Host plug-in. A Host plug-in should be complete, a non-fragment plug-in. Fragment will have complete visibility of all packages of host plug-in. At runtime, its classes are merged into the internal classpath of the host plug-in.
How to create Fragment plug-ins in Eclipse?
Goto File > New > Other > Fragment Project.
Enter an appropriate Fragment Plugin ID and click on Next, choose the Host Plugin ID and we are done. If we look at the generated MANIFEST.MF, we will notice a new "Fragment-Host" property added, and "Bundle-Activator" removed, as it gets activated by the Host plugin itself.
OSGi Bundle State Machine
This post is from my OSGi notes, hope you will find it useful.
A bundle starts its journey on sending a install command, it enters INSTALLED state, is an intermediate state and usually bundles will not spend much time here. The dotted line in the state machine shows that any bundle in the INSTALLED state will automatically transition to RESOLVED state.
RESOLVED state is reachable only if following conditions are met.
1. JRE requirement of the bundle should be available in the framework.
2. Import packages of the bundle are available and their versions are same as what is required.
3. Dependent bundles are available, either in RESOLVED state or can be RESOLVED.
If any of the above criteria doesn't satisfy, bundle moves back to INSTALLED state.
To start, a bundle can either be in INSTALLED or RESOLVED state. If the bundle is in INSTALLED state, it will be automatically resolved before starting. STARTING means bundle is in the process of being activated. In this state, start method of the bundle activator will be called. Once started bundle automatically reaches ACTIVE state, this is where bundle spends most of its life time. An ACTIVE state doesn't mean something is running. It all depends on what is launched by the start method of the bundle activator.
On issuing a stop command, bundle transitions to STOPPING state while framework executes stop method of the bundle activator. After finishing stop method, bundle automatically moves to RESOLVED state.
uninstall command removes the bundle from the framework.
Class Loader Architecture Comparison – Java, J2EE and OSGi
I am getting introduced to OSGi by an excellent book, OSGi in Practice, being written by Neil Bartlett. You can get a draft copy of this book from Neil's site. Thanks you so much Neil for releasing this book for free.
Having seen Java, J2EE for a long time, and now that I am getting familiar with OSGi, I am really excited to share my new learning. In this post I have made an attempt to compare the class loaders of Java, J2EE and OSGi at a very high level.
Java
Beginning with java, it has a hierarchical class loader.
Basically you ask your parent before you load anything yourself. If parent has it, you don't have a choice of using your own but to use the same. For example, your program is using java.lang.String. System class loader first checks with extension loader. As extension loader doesn't have it, it delegates the call to Bootstrap loader. Bootstrap loader returns with a success as it has loaded String class from rt.jar.
This kind of tree like class loader supports delegation, visibility and uniqueness principle inherently. I am stopping here as I am more interested in comparing. But before we move on, lets look at the short comings of this approach.
Conflicting classes
You have a program, running on JRE 1.6, it needs latest and greatest xerces 2.9 explicitly. You have bundled the xerces jar with your program, and its included in the classpath. But during runtime, older version of xerces classes are getting loaded irrespective of your settings. You guessed it right! Its because JRE 1.6 ships xerces and it is already loaded by extension class loader. This is the primary problem of hierarchical class loader, at runtime all jars become a long list of files which is searched in a sequential order in the order of their loading.
Explicit dependencies can not be defined
Lets say your program needs Apache commons-logging, xerces and a long list of popular open source components. When you ship your product, either you have to build the stack yourself and hand it over to the customer or communicate this through a user documentation. The so called logical unit of a java program, the jar, lacks the place holder in its meta data to include information about its dependency.
Version dependency problem
Problem gets complicated when you explicitly need commons-logging 1.1.1, xerces 2.9 and so on, and your program is supposed to be part of a larger system which already has these libraries and their versions are not same as yours. You will have sleep less night in recompiling your program with those libraries to co-exist. Phew !! I have been through this many times.
Entire jar is exposed
When you are building java libraries you want the user to use only few classes which are meant be used. But today Java doesn't have any mechanism to define access specifiers at a class level. Once the jar is in the classpath all core classes can be seen and instantiated.
J2EE
Now lets see what J2EE has done to take it forward. J2EE has kept the basic design principle of Java as is and has defined enterprise application features like security, transactions and so on, on top of it. So class loader remains hierarchical but with support for isolation across multiple applications in the same container.
Application A, lets say an ear, has its own class loader and has loaded war and sar inside it. Another Application B, another ear, has its own class loader and can not see Application A's classes. Now if you have a need to share classes between these two applications, either you have to make them use the same class loader or push the shared classes up in the hierarchy to system class loader. By doing this the entire container will be able to see those shared classes even though other applications doesn't necessarily need them. JBoss has introduced unified class loader to address the same problem. But you have to be a pro to use that! Usually this is solved by duplicating jars.
OSGi
Now we will see what OSGi framework has defined on top of Java which gives solutions to all of the problems discussed above.
OSGi is a module system for Java. These modules are called as bundles in OSGi. A bundle corresponds to a single Jar file. Bundles metadata is defined in jars MANIFEST.MF. Metadata contains
1. Name of the bundle.
2. Version of the bundle.
3. A list of export and import list. List of classes that bundle wants to expose and use respectively.
4. And miscellaneous information like vendor, copyright, contact information and so on.
Having defined the basic unit of OSGi, lets look at the OSGi class loader architecture. Class loader in OSGi is a graph, unlike a hierarchical tree structure of Java and J2EE. Each bundle has its own class loader. For example bundle B defines an export list and bundle A imports it. When A requests a class to be loaded which is present in B, immediately call will be delegated to the class loader of B. As there is no long list of classes organized in a hierarchical structure anymore, it proves to be very fast and efficient. The process of resolving dependency based on import and export metadata is called resolution process. Its a complex procedure taken care by the OSGi framework.
Inherent advantage of having this kind of class loader is
1. Export is defined with a version attribute, where as imports can specify a range of versions. This allows a bundle to say I need a library having a version between x and y.
2. All packages in a bundle need not stick to a version while exporting. Package org.gok can be exported under 0.9 and another package in the same bundle org.goh can be exported as 1.1.
3. Same library having different versions can be there in the application side by side
Apart from this, bundles in OSGi also has a well defined life cycle enabling them to be very dynamic in nature.
Hoping to post more learning in the future ...
Adobe DevSummit @ Chennai and Hyderabad
DevSummit is happening this 24th November at Chennai and 1st December at Hyderabad for the first time. Don’t miss this unique opportunity to hear from the Adobe Flash Platform experts and gain valuable insights into the design and development of richer RIAs.
What's in it for you?
- Technical Sessions covering the latest developments on Adobe Flash Platform
- Lightning talks and deep dive sessions from various experts in the Adobe community
- If you are relatively new to Flex, you wouldn't want to miss the tutorial-oriented sessions. Feel free to bring your laptop and do-it-yourself along with the speaker
- And what’s more, all delegates will get a complimentary copy of Flex Builder 3 Professional Licence (non commercial)
Find out more information here.
Application versioning using subversion and maven
A project with a daily build needs to have a mechanism to track its binaries. This example shows how this can be achieved very easily if the project is hosted on subversion and using maven as its build tool. Application major versions like 1.0 or 2.0 can be appended with subversion revision number to mark each build. Lets say 1.0 (build 289), where 289 is the subversion revision number.
First, add the buildnumber-maven-plugin to the build part of the maven pom.xml, as shown below. This plugin gets the subversion revision number of the checked out code and populates that in ${buildNumber} variable. Please take a look at the configuration details of the plugin here.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<doCheck>false</doCheck>
<doUpdate>true</doUpdate>
</configuration>
</plugin>
</plugins>
</build>
Populate ${buildNumber} to the jar's manifest Implementation-Version like below.
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
<manifestEntries>
<Implementation-Version>1.0 (build ${buildNumber})</Implementation-Version>
</manifestEntries>
</archive>
</configuration>
</plugin>
Resulting MANIFEST.MF might look like below.
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: shylu Build-Jdk: 1.6.0_13 Implementation-Version: 1.0 (build 289)
Version number embedded in jar's manifest this way can be easily accessed through java to display in jsp or to implement getVersion() API. Pick any class in that package and do the following to get the version.
<classname>.class.getPackage().getImplementationVersion()
or within the class
this.getClass().getPackage().getImplementationVersion()
JAXB unmarshal with Schema Validation
Many times user inputs are taken through XML. As users are free to enter any thing in the file, checking the correctness of the XML is very crucial. XML Schema and DTD help us do this.
I had come across a situation where I had to take inputs from a XML where certain attribute of an element should be unique across the XML. Here is a sample.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://gok.org"
xmlns:tns="http://gok.org"
elementFormDefault="qualified">
<complexType name="student">
<sequence>
<element name="name" type="string" />
</sequence>
<attribute name="id" type="string" use="required" />
</complexType>
<element name="College">
<complexType>
<sequence>
<element name="students" type="tns:student" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
<unique name="studentid">
<selector xpath="tns:students"/>
<field xpath="@id"/>
</unique>
</element>
</schema>
This schema ensures that student ids are unique.
Lets consider a sample XML data which adheres to this schema but with duplicates.
<?xml version="1.0" encoding="UTF-8"?><tns:College xmlns:tns="http://gok.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://gok.org gok.xsd">
<tns:students id="1">
<tns:name>a</tns:name>
</tns:students>
<tns:students id="1">
<tns:name>b</tns:name>
</tns:students>
</tns:College>
If you use JAXB, with default settings, to unmarshal this, it will not throw any exception. To unmarshal with schema validation you have to set the schema explicitly like below.
Unmarshaller unmarshaller = context.createUnmarshaller();
unmarshaller.setSchema(SchemaFactory.newInstance(
XMLConstants.W3C_XML_SCHEMA_NS_URI).newSchema(
new File("src/main/resources/gok.xsd")));
Then you will get an exception like below.
Caused by: org.xml.sax.SAXParseException: Duplicate unique value [1]
declared for identity constraint of element "College".
Advantage of doing this strict validation through JAXB is, all the validations are taken care by JAXB. You simply unmarshal and start working with your data. If the unmarshal fails you know user has done a mistake, simply throw an error and enjoy ...
CruiseControl: No modifications found, build not necessary
After a week long investigation finally I got maven build with all reports working. Its a multi module project, so merging all the reports was a big challenge. Parent pom.xml is worth a post, I will upload it sometime.
I integrated this with CruiseControl. As soon as the jetty server came up build went through fine, everybody received a mail. I replied to it saying CruiseControl is live. But to my bad luck, after the wait period, even though svnbootstrapper found some changes in the repository, project controller said no modification. Please note line 10 and 13.
2009-01-22 16:06:54,431 [Project test thread] INFO Project - Project test: in build queue 2009-01-22 16:06:54,432 [Project test thread] INFO ProjectController - test Controller: build progress event: in build queue 2009-01-22 16:06:54,443 [BuildQueueThread] INFO BuildQueue - now adding to the thread queue: test 2009-01-22 16:06:54,517 [Thread-54] INFO Project - Project test: bootstrapping 2009-01-22 16:06:54,518 [Thread-54] INFO ProjectController - test Controller: build progress event: bootstrapping 2009-01-22 16:06:56,105 [Thread-54] INFO SVNBootstrapper - U ... 2009-01-22 16:06:56,117 [Thread-54] INFO SVNBootstrapper - U ... 2009-01-22 16:06:56,105 [Thread-54] INFO SVNBootstrapper - U ... 2009-01-22 16:06:56,117 [Thread-54] INFO SVNBootstrapper - U ... 2009-01-22 16:07:10,145 [Thread-54] INFO SVNBootstrapper - Updated to revision 1864. 2009-01-22 16:07:11,101 [Thread-54] INFO Project - Project test: checking for modifications 2009-01-22 16:07:11,102 [Thread-54] INFO ProjectController - test Controller: build progress event: checking for modifications 2009-01-22 16:07:12,033 [Thread-54] INFO Project - Project test: No modifications found, build not necessary. 2009-01-22 16:07:12,034 [Thread-54] INFO Project - Project test: idle 2009-01-22 16:07:12,034 [Thread-54] INFO ProjectController - test Controller: build progress event: idle 2009-01-22 16:07:12,035 [Project test thread] INFO Project - Project test: next build in 5 hours 2009-01-22 16:07:12,035 [Project test thread] INFO Project - Project test: waiting for next time to build 2009-01-22 16:07:12,036 [Project test thread] INFO ProjectController - test Controller: build progress event: waiting for next time to build
After struggling a bit I realized my subversion server was lagging behind by a day. I reset the date in SVN, and CC cruised along without any glitches.
svn: Item is not readable
My svn server had a simple authentication and authorization like below.
svnserve.conf
[general] anon-access = read auth-access = write password-db = passwd authz-db = authz realm = My First Repository
authz
[groups] admin = shylu [/] @admin = rw
With this configuration svn log command always failed with a "svn: Item is not readable" error.
Problem is, even though anon-access has read permission in svnserve.conf, authz file must explicitly specify read permission to everyone like below.
new authz
[groups] admin = shylu [/] * = r @admin = rw