Friday, 17 October 2014

RestKit install - RKValueTransformers file not found

Adding the RestKit framework to an Xcode project manually, i.e. without using CocoaPods, results in project build errors similar to these:

Compile RKEntityMapping.m
'RKValueTransformers.h' file not found
  In file included from /.../RestKit-0.23.3/Code/CoreData/RKEntityMapping.m:21
  In file included from /.../RestKit-0.23.3/Code/CoreData/RKEntityMapping.h:22

Compile RKManagedObjectImporter.m
'RKValueTransformers.h' file not found
  In file included from /.../RestKit-0.23.3/Code/CoreData/RKManagedObjectImporter.m:26

Up to and including version 0.20.3, adding the RestKit framework downloaded as a source zip file from GitHub required a few simple steps (todo: link) and worked easily on several projects.

Following the same procedure to add version 0.23.3 resulted in the errors shown above. 

Both files, i.e. RKValueTransformers.h and RKValueTransformers.m, are still referenced from the RestKit.xcodeproj but are not bundled into the zipped source.

It turns out that beginning with version 0.22.0, these 2 files were extracted from RestKit project into its own project on GitHub:
The project needs to be downloaded separately (i.e. when not using CocoaPods for installation).
The two files can be simply copied into this directory under the RestKit:


Unfortunately, that does not solve the whole problem. Apparently, packaging of the source code was changed and no longer includes dependencies such as AFNetworking, SOCKit and others.
So, if you persist in your stubbornness (as does this author) and still prefer to integrate RestKit into your project without CocoaPods, you're facing a very daunting option: download all dependencies manually and add them to the sub-directories inside the RestKit-0.23.3/Vendor.

Luckily, there is a faster way (only takes few minutes): the trick is to use CocoaPods to bring all dependencies into a helper project and then simply copy files into the target .

  • create a new simple project in Xcode. The template does not matter, Single View Application is fine. Project name just for example: RestKitPodsInstall
  • install CocoaPods (if the Mac does not have the package already):
    sudo gem install cocoapods
  • cd into the project directory, i.e. the directory that contains the Xcode project file (e.g. RestKitPodInstall.xcodeproj)
  • create a Podfile:
vi Podfile

platform :ios, '5.0'
pod 'RestKit', '~> 0.23.3'

(change the version to the latest available or whatever is needed)

  • install RestKit into the helper project by running:
pod --verbose install

It should finish with something like this:

Integrating client project

[!] From now on use `RestKitPodInstall.xcworkspace`.

Integrating target `Pods` (`RestKitPodInstall.xcodeproj` project)
  • copy, one by one, content of sub-directories in the Pods directory of the helper project to the target project. Keep in mind that the RestKit source already has placeholder directories for dependencies under the Vendor subfolder. The example below assumes that a manually downloaded RestKit-0.23.3 source code was placed under the Library directory in the target project named Algonquin. The current directory is the project directory of the helper project. (Also note the / at the end of the copied source directory)
mac:RestKitPodInstall vit$ cp -R Pods/AFNetworking/ /Users/vit/iOS-Projects/Algonquin/Algonquin/Library/RestKit-0.23.3/Vendor/AFNetworking

mac:RestKitPodInstall vit$ cp -R Pods/ISO8601DateFormatterValueTransformer/ /Users/vit/iOS-Projects/Algonquin/Algonquin/Library/RestKit-0.23.3/Vendor/ISO8601DateFormatterValueTransformer

mac:RestKitPodInstall vit$ cp -R Pods/RKValueTransformers/ /Users/vit/iOS-Projects/Algonquin/Algonquin/Library/RestKit-0.23.3/Vendor/RKValueTransformers

mac:RestKitPodInstall vit$ cp -R Pods/SOCKit/ /Users/vit/iOS-Projects/Algonquin/Algonquin/Library/RestKit-0.23.3/Vendor/SOCKit

mac:RestKitPodInstall vit$ cp -R Pods/TransitionKit/ /Users/vit/iOS-Projects/Algonquin/Algonquin/Library/RestKit-0.23.3/Vendor/TransitionKit

After all copying is done, the target project should have the structure similar to this:

Algonquin (it's the target project)
| Algonquin
| | main.m
| | VTAppDelegate.h
| | (other source files)
| | Library
| | | RestKit-0.23.3
| | | | RestKit.xcodeproj
| | | | Code
| | | | Resources
| | | | (other files)
| | | | Vendor
| | | | | AFNetworking
| | | | | | AFNetworking
| | | | | | | AFHTTPClient.h
| | | | | | | AFHTTPClient.m
| | | | | | | (other source files)
| | | | | | LICENCE
| | | | | |
| | | | | RKValueTransformers
| | | | | | Code
| | | | | | | RKValueTransformers.h
| | | | | | | RKValueTransformers.m
| | | | | | LICENSE
| | | | | |
| | | | | (rest of dependencies)
| | | (other libraries)
| Algonquin.xcodeproj
| AlgonquinTests

The target project should not be opened in Xcode during this procedure. When the copying complete, open the target project in Xcode. The project should compile without failures (assuming of course that RestKit was already previously configured and that is just a replacement to a newer version).

Friday, 22 August 2014

Ehcache CacheManager with same name already exists in the same VM

keys: Java, Ehcache, CacheManager name, multiple configurations

Straight to the point:

Explicitly providing a CacheManager name in an Ehcache configuration file allows to avoid the "CacheManager with same name already exists in the same VM" error after upgrading to Ehcache version 2.5 and later.
The CacheManager name should be specified in each Ehcache config file via the name attribute of the top-level ehcache element, for example:

<ehcache name="http-filter-cache"
    xmlns:xsi="" xsi:noNamespaceSchemaLocation="ehcahce.xsd">
    <defaultCache />
This works regardless whether a singleton or multiple instances of CacheManager are created.

In detail:

Ehcache is a widely used open-source caching solution for enterprise Java applications.
Most known examples, perhaps arguably, would be using Ehcache as a second-level Hibernate cache and the cache implementation in Apache Camel.
Version 2.5 was enhanced with a new feature called Automatic Resource Control. The ARC (finally) allowed to specify heap and disk allocations in bytes rather than in elements (as well as for Off Heap storage).

After upgrading a Java web application to take advantage of the new version, we encountered a problem that manifested in failures of numerous JUnit tests. Launching the web application also started to fail.

Examining log files revealed the following error message:

CacheManager with same name already exists in the same VM. Please provide unique names for each CacheManager in the config or do one of following:

1. Use one of the CacheManager.create() static factory methods to reuse same CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.

The application included 2 Ehcache configuration files each containing a default cache definition as well as several other named caches. At first, a suspicion was that the problems were caused by having more than one default cache (each file contains a default cache definition). Since the default caches are unnamed, there might have been a collision. That's however proved to be a totally wrong lead.

Proceeding to examine the source code of net.sf.ehcache.CacheManager class, we came across this javadoc comment in class constructors:

Since 2.5, every newly created CacheManager is registered with its name (uses a default name if unnamed), and trying to create multiple CacheManager with same names (or multiple unnamed CacheManagers) is not allowed and throws an exception.

Looking further into the source code and stepping in with the debugger, we discovered that CacheManager now maintains a static Map<String, CacheManager> class variable to store every instance of the class created in the JVM using the name specified in a configuration as the key (the map is named CACHE_MANAGERS_MAP as of version ehcache-core 2.6.9).

All constructors and the factory methods utilize the map to return a CacheManager object according to the specs. The CacheManager provides two kinds of instantiation modes: creating a new instance on each call or returning an existing object (singleton). (More on CacheManager creation modes can be found on a Ehcache website).

Regardless of the creation mode, i.e. instance or singleton, the CacheManager name must be unique.

Surprisingly, considering that the change is quite well documented, the Ehcache documentation does not spell out, at least not readily, how to assign a name to a CacheManager instance.
The answer was found in the ehcache.xsd schema that specifies the optional name attribute for the ehcache element:
    <xs:element name="ehcache">
            <xs:attribute name="name" use="optional"/>
                <xs:element maxOccurs="1" minOccurs="0" ref="diskStore"/>
When the name attribute is specified for the the top-level ehcache element, a CacheManager constructor will use its value as the name for the CacheManger instance and as the key when registering the object in the static CACHE_MANAGERS_MAP map. Otherwise, i.e. when the name attribute is omitted, CacheManager will use a default value, __DEFAULT__, as the name. If the app is designed to use a single ehcache configuration, it will not cause any trouble. However, there are cases when it's preferable to use multiple cache configuration files. In which case it will result in the error when the name attribute is not used.

To avoid the problem, each Ehcache configuration should specify a name. The fragment from a configuration file below is an example:
<ehcache name="http-filter-cache" xmlns:xsi="" xsi:noNamespaceSchemaLocaton="ehcache.xsd">
   <!-- CacheManager configuration
       (omitted from the sample)
And in conclusion, a friendly suggestion to the Ehcache development team: maybe the name attribute should be made mandatory rather than optional to avoid the problem described in this post.

Tuesday, 5 August 2014

Spring Framework Annotation-based Configuration

With seemingly en masse transition of Java Spring framework users to annotation-based configuration, it sometimes can be quite frustrating to find yourself in a corner when a context configuration easily achievable with XML, can not be realized via annotations.
These are 2 examples:

  • configuring multiple service instances of the same class (not the prototype scope kind of multiplicity).
  • auto wiring of a service implementation based on a configuration parameter.
The first case:

Suppose there is a need to have 2 service beans of the same service implementation. (Of course, to have sense, the bean instances need to be distinct, for example by setting their instance variables to different values).
With an XML config, that can be easily achieved by declaring 2 beans with different ID values, for example:
<bean class=“DocumentServiceImpl” id=“documentService”/>
<bean class=“DocumentServiceImpl” id=“loggingDocumentService”>
    <property name=“shouldLogRequests” value=“true”/>

Then, these beans can be configured for injection either in XML via the ref parameter:

<bean class=“DocumentServiceController”>
    <property name=“documentService” ref=“documentService”/>
    <property name=“loggingDocumentService” ref=“loggingDocumentService”/>

Or alternatively, even autowiring like this:

public class DocumentServiceController {
 private DocumentService baseDocumentService;

 private DocumentService loggingDocumentService;

The same simply cannot be done via type-level annotations (or, at least not as easily).
This is an annotation based configuration similar to the XML above:
public class BaseDocumentService implements DocumentService {

However, since the @Service annotation takes only a single String parameter, there is simply no way to instantiate a second bean of the same class assigning it a different name or id.

Even though this seems to be a conscious design choice of Spring framework architects (see below; note, the emphasis is the author's), it still can be maddeningly frustrating while looking for a solution.

From a Spring doc at 4.11.3 Fine-tuning annotation-based autowiring with qualifiers
For a fallback match, the bean name is considered as a default qualifier value. This means that the bean may be defined with an id "main" instead of the nested qualifier element, leading to the same matching result. However, note that while this can be used to refer to specific beans by name, @Autowired is fundamentally about type-driven injection with optional semantic qualifiers. This means that qualifier values, even when using the bean name fallback, always have narrowing semantics within the set of type matches; they do not semantically express a reference to a unique bean id. Good qualifier values would be "main" or "EMEA" or "persistent", expressing characteristics of a specific component - independent from the bean id (which may be auto-generated in case of an anonymous bean definition like the one above).

So, to comply with this design, the following approach should be used to achieve the goal of having multiple service bean instances of the same class:

  • Create a new implementation that extends the base service class.
  • Define a post construct method in this new class that sets parameters that would make a second instance to be different.

public class LoggingDocumentService extends DocumentServiceImpl {
   public void postConstruct() {

Okey, that is not too high price for switching to annotations-based configuration. It actually may promote a better object design, i.e. using subclassing to extend the behaviour of a class rather than using an instance variable and if-else statements for controlling its logic (though it’s not always possible).

Let’s now look at the second scenario.
Under this scenario, there are two different implementations of the same interface (see example below).
Suppose there is also a controller that should be configured via an environment property to use a particular service implementation. For instance, setting an environment configuration property, say document.service.caching.enabled=true, should result in Spring injecting the service implementation that provides document caching capabilities.

public class BaseDocumentService implements DocumentService {
public class CachingDocumentService extends BaseDocumentService {

public class DocumentServiceController {
    private DocumentService documentService;

When using XML configuration, this can be easily achieved by, by way of illustration, using a SpEL expression:

<bean class="BaseDocumentService" id="baseDocumentService" />
<bean class="CachingDocumentService" id="cachingDocumentService" />
<bean class="DocumentServiceController" id="documentServiceController">
    <property name="documentService" ref="#{'${document.service.caching.enabled}'=='yes' ? 'cachingDocumentService' : 'baseDocumentService'}" />

With annotations-based Spring configuration, we would need to annotate an instance variable in the controller using the @Qualifier annotation:

public class DocumentServiceController {
    private DocumentService documentService;

Had the @Qualifier annotation accepted property placeholders, that would be the end of the story.
Unfortunately, Spring architects decided not to resolve placeholders in the @Qualifier. Neither there is support for SpEL expressions.
Good news is that it's still possible to solve this task, bad news is that the solution is quite verbose.

First, we would need to implement a FactoryBean<T> interface:

@DependsOn({"baseDocumentService", "cachingDocumentService"})
public class DocumentServiceFactory implements FactoryBean<DocumentService> {
    private boolean enableDocumentCaching;

    private DocumentService baseDocumentService;

    private DocumentService cachingDocumentService;

    public DocumentService getObject() throws Exception {
        return enableDocumentCaching ? cachingDocumentService : baseDocumentService;

    public Class<?> getObjectType() {
        return DocumentService.class;

Second, the qualifier on the service reference in the controller needs to specify the factory bean rather than a service bean. Note though, the type of the reference remains of the service interface (i.e. not of the factory):

public class DocumentServiceController {
    private DocumentService documentService;

A drawback of this solution is that at runtime there still going to be 2 beans in the memory while only one will be served by the factory to the controller. However, considering that service bean implementations should not take up too much memory since they need to be thread-safe (i.e. limited number of instance variables), that drawback should not represent a tangible problem.
And forerunning a potential question: Why would it be desired to have an annotation-only Spring configuration? True, typically in medium and large applications it's not practical. But in small programs, like a job or utility, the program becomes tidy when everything is configured through annotations. The other main usage  is for JUnit tests. It's impractical to bring up the whole context of a large application for running a JUnit, so instead of creating a myriad of test-specific contexts, it's much productive to have JUnits fully configurable via annotations.

Saturday, 4 January 2014

Xcode Build for iOS - conditional copy of resource files based on Build Configuration

A brief: Use Run Script build phase in Xcode to selectively copy resource files, such as Settings.bundle, security certificates, etc., depending on the build configuration, e.g. Debug or Release.
How-To: Project Navigator: select a project, select a target, select Build Phases tab; menu: Editor > Add Build Phase > Add Run Script Build Phase.

In detail:
Couple days ago I needed to make a minor change to how we compile/build our iOS app. The app has a few settings but all of them for development only. While preparing a submission to Apple, we wanted to remove the app from the Settings view on iPad completely. The challenge was to keep the settings for developer builds. This proved to be a bit more difficult than expected. Hence, a post to document how it can be done as well as a few things learned about Build Project settings, Targets, Build Configurations, Schemes, logs etc. in Xcode (v5).  

For an iOS app to have an entry to the standard Settings view, the app needs to include a Settings.bundle file (which is actually a directory on the file system, by the way). When the file is added to a project (any file for that matter actually), Xcode allows to selectively include it into the project's targets. Normally, an Xcode project would have the main target (named after the app) and a test target. So, one way to conditionally include a file, Settings.bundle in my case, into the build is to duplicate the main target and use that duplicated target for developer builds only. For example, let's say our app name is iStockFutures and by default the main target is iStockFutures. We could've duplicated that target into iStockFutures-Dev and kept the Settings.bundle file as a member of the iStockFutures-Dev target only. A sample screenshot is shown below.

That would accomplish the task. But there is drawback - having multiple targets means that developers have to be mindful when adding new files (any new file) and better not forget to include it into both targets. When running the app in Xcode, the dev target then should be used but when committing code to a build server, it had better be tested on both targets. Needless to say, my development team was not thrilled on that prospect. 

Luckily, there is a more transparent way:

The build process in Xcode includes multiple phases. One of them is Copy Bundle Resources. The phase has a list of resource files to copy. When the Settings.bundle was added to the project, Xcode automatically included it into that list. Unfortunately, Xcode 5 does not allow to have multiple versions of the list based on Configuration, e.g. Release or Debug. Not sure why Apple didn't do it, after all, such capability exists and is widely used in Build Settings. Anyway, this can be easily achieved by using a Run Script phase. Run Script is a feature in Xcode that allows to execute a custom script while building a Product (i.e. an App). Multiple script languages are supported (see the link above) but since all what we need to do is to copy a file, ah, sorry, I meant a directory, we just going to use the standard /bin/sh.
To create a Run Script phase, select the project in the Project Navigator, then make sure that a target is selected (otherwise the menu will be greyed out/disabled).
Then use the Editor menu to add a Run Script phase: Editor > Add Build Phase > Add Run Script Build Phase

When it's added, expand the Run Script phase and add this script (modify it as needed, of course) that copies Settings.bundle if build is run in Debug configuration:

echo "Checking configuration to determine whether to copy Settings.bundle: CONFIGURATION=$CONFIGURATION"
if [ "$CONFIGURATION" == "Debug" ]; then
echo "Copying ${SRCROOT}/${PRODUCT_NAME}/Settings.bundle directory to ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app"
cp -R ${SRCROOT}/${PRODUCT_NAME}/Settings.bundle ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle
echo "Settings.bundle directory has been copied."
echo "Skipped copying Settings.bundle - not required for $CONFIGURATION configuration."

Now, remove the Settings.bundle from the target, iStockFutures in the sample app.
(There are at least 2 ways to do that - either edit the list under Copy Bundle Resources or select Settings.bundle in Project Navigator and uncheck all targets in the File Inspector's Target Membership [View > Utilities > Show File Inspector]).
This is important:

  • Run Product > Clean before running Product > Build, otherwise the Settings.bundle copied before will still be packaged into the app.
  • Uninstall the app from the device and/or simulator - that will remove the app entry from the Settings app.

Also, if you played with the solution presented first, i.e. a dev target, remember to remove that dev target.

Let's build the product in Debug configuration first and look into Xcode build log files to verify the script is being run.

Hint: Where to find Xcode build logs: from the menu: View > Navigators > Show Log Navigator

Select the default group and the All Messages option: 

This is it for building in Debug configuration.

To fully complete the work we need to verify it builds correctly in Release configuration as well. It can be done by running a command-line build configured to Release (a default configuration setting on the Project) on the team's CI (Continuous Integration) server. But of course a better approach is to test it on a developer's Mac beforehand.
An Xcode's feature called Scheme comes handy here (more info). It allows to maintain multiple sets of targets each configured to a specific Build Configuration, i.e. Debug or Release.

A new scheme can be created via the Product > Scheme menu.

Select Product > Scheme > Edit Scheme…, then Duplicate one of the existing schemes (1) and change the Build Configuration to Release (2):


After creating and configuring a new scheme, make it active by selecting it in Product > Scheme > iStockFutures-Release menu.
Build the app by running Product > Clean and Product > Build. When completed, check the build log file.

That should be all.

Ok, that's not been very complicated, why it took more time than expected? That's because a bulk went into attempting to figure out and tinkering with Xcode environment variables. 

Here is a couple things that helped.

How to print all Xcode environment variables:
Open a Terminal window, change the directory to the project directory, i.e. the one that contains <project_name>.xcodeproj file and run this command:

xcodebuild -project iStockFutures.xcodeproj -target "iStockFutures" -showBuildSettings > iStockFutures-build-settings.txt

All Xcode settings will be saved in the specified file. Replace iStockFutures with your project, of course.

Official Xcode Build Settings Reference doc from Apple:

And a last tip - for successful builds the log file does not show too many details. However, add a faulty Run Script build phase, something like this for example:

cp ${SRCROOT}/file-that-doesnot-exist.txt ${BUILT_PRODUCTS_DIR}/file-that-doesnot-exist.txt

Build fails and the log file can be expanded to see quite a bit of details; it might be handy in understanding how the build works:


By the way, the Run Script approach can be used to copy not only Settings.bundle but other environment-specific files. For example, we also used the script to copy Development and UAT/Production security certificates that we use for 2-way SSL/TLS authentication.

Monday, 10 December 2012

Running statistics on Oracle tables from Java program.

Oracle database query optimizer relies heavily on statistics. These statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Normally, having correct and up-to-date statistics falls under DBA responsibilities (Oracle recommends automatic statistics gathering). However, there are cases when it might be necessary to update statistics manually, and moreover, at runtime directly from a Java program. For example, when data had been reloaded into the tables and now need to be accessed from a Java batch program while database instance is not configured for automatic statistics update. Below is an example of Java code that implements a method to gather statistics for a particular table. The code is based on the JdbcDaoSupport class from Spring framework but it is a simple convenience and author's preference - there is nothing that would prevent from porting this code to the standard plain JDBC implementation.
 * Copyright 2012 VT Enterprise Software Consulting Inc.
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * See the License for the specific language governing permissions and
 * limitations under the License.

package com.vtesc.examples.db;

import java.sql.Types;

import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.SqlParameter;
import org.springframework.jdbc.core.namedparam.MapSqlParameterSource;
import org.springframework.jdbc.core.namedparam.SqlParameterSource;
import org.springframework.jdbc.core.simple.SimpleJdbcCall;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

 * Demonstrates invocation of dbms_stats.gather_table_stats procedure
 * to gather an Oracle table statistics.
 * @author Vitali Tchalov
public class JavaOracleStats extends JdbcDaoSupport {
  * Updates statistics for table in schema using
  * Oracle dbms_stats.gather_table_stats procedure.
  * @param schema
  * @param table
 @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
 public void gatherTableStats(String schema, String table) {
  JdbcTemplate jdbcTemplate = new JdbcTemplate(getJdbcTemplate()

  SimpleJdbcCall gatherStats = new SimpleJdbcCall(jdbcTemplate)
    .useInParameterNames("ownname", "tabname")
    .declareParameters(new SqlParameter("ownname", Types.VARCHAR),
     new SqlParameter("tabname", Types.VARCHAR));
  SqlParameterSource in = new MapSqlParameterSource().addValue("ownname",
    schema).addValue("tabname", table);


This is a fully tested and usable code. But I plan to package this example along with a JUnit test, Spring context file and other artefacts and will publish when ready.

Friday, 14 September 2012

Frequently used SQL DDL statements

A collection of reference examples of SQL DDL (Data Definition Language) statements frequently used in application development to create and alter database tables, synonyms, constraints, indexes etc. 
Note: The statements have been tested on Oracle 11G database; most probably should work with other relational databases. Some of the datatypes used in the samples are Oracle-specific and would require some tweaking.

-- Create a table
  tx_id      NUMBER(10, 0) NOT NULL,
  stock_id   NUMBER(10, 0) NOT NULL,
  tx_date    DATE          NOT NULL,
  currency   VARCHAR2(5)   NOT NULL,
  price      NUMBER(9, 2)  NOT NULL,
  price_2    NUMBER

-- Create a table with a PK (Primary Key) on a single column
  stock_id      NUMBER(10, 0) NOT NULL,
  symbol        VARCHAR2(5)   NOT NULL,
  stk_exchange  VARCHAR2(5)   NOT NULL,
  currency      VARCHAR2(5)   NOT NULL,
  CONSTRAINT stock_id_pk PRIMARY KEY (stock_id)

-- Add a PK (Primary Key) to already existing table
ALTER TABLE tx_history ADD CONSTRAINT tx_history_pk PRIMARY KEY (tx_id)

-- Create a table with a FK (Foreign Key) to another table
  rec_id        NUMBER(10, 0) NOT NULL,
  stock_id      NUMBER(10, 0) NOT NULL, -- FK to STOCK table
  trade_date    DATE          NOT NULL,
  open_price    NUMBER(9, 2)  NOT NULL,
  close_price   NUMBER(9, 2)  NOT NULL,
  CONSTRAINT stock_history_stock_fk FOREIGN KEY (stock_id) REFERENCES stock (stock_id) ENABLE VALIDATE

-- Add a FK (Foreign Key) to already existing table to reference another table
ALTER TABLE tx_history ADD CONSTRAINT tx_history_stock_fk FOREIGN KEY (stock_id) REFERENCES stock (stock_id) ENABLE VALIDATE
-- Drop (delete) a table

-- Add a new column to an existing table

-- Drop a column

Wednesday, 15 August 2012

NoClassDefFoundError and ClassNotFoundException errors when running standalone Java programs

This post is intended as a collection of various cases related to Java CLASSPATH issues that cause NoClassDefFoundError and ClassNotFoundException errors that are often mysterious and sometimes quite difficult to troubleshoot. 
The addressed cases go beyond trivial causes of missing jar files or mistyped package names.

Case I - A standalone Java program is packaged into a jar file. The JAR includes a seemingly correct manifest specifying the main class and the program classpath as in the sample below:


Manifest-Version: 1.0
Main-Class: com.vtesc.batchjobs.daily.txprocessor.Launcher
Class-Path: . ./txprocessor.jar ./lib/spring.jar ./lib/commons-logging.jar ./lib/ojdbc6.jar d:/common/lib/dbaccess.jar

The txprocessor.jar file is correctly built by an Ant build script and has a totally correct structure and contents:

Everything seems to be perfectly fine but when run, it fails with classloader errors (Java version "1.6.0_29"):

D:\batchjobs\txprocessor>java -jar txprocessor.jar
Exception in thread "main" java.lang.NoClassDefFoundError: com/vtesc/batchjobs/daily/txprocessor/Launcher
Caused by: java.lang.ClassNotFoundException: com.vtesc.batchjobs.daily.txprocessor.Launcher
        at Method)
        at java.lang.ClassLoader.loadClass(
        at sun.misc.Launcher$AppClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
Could not find the main class: com.vtesc.batchjobs.daily.txprocessor.Launcher. Program will exit.

The returned error displaying the "Could not find the main class" message can be actually quite misleading as it may make you to suspect some problem with the main class. However, in this case it has absolutely nothing to do with the main class. The cause of the error is actually in the Manifest file on the Class-Path: line:


Hard-coding an absolute path to a library is a very bad practice in itself but specifying the path without indicating a protocol causes the total failure. By default, the Java platform uses the class for loading program classes. As its name implies, the URLClassLoader uses another system class, for specifying the resource location. The URL class complies with a number of RFC documents and it requires the file:/ protocol to be specified for file system resources.

The problem can be corrected by prefixing the absolute path to the dbaccess.jar file with the file:/ protocol as shown below:

Manifest-Version: 1.0
Main-Class: com.vtesc.batchjobs.daily.txprocessor.Launcher
Class-Path: . ./txprocessor.jar ./lib/spring.jar ./lib/commons-logging.jar ./lib/ojdbc6.jar file:/d:/common/lib/dbaccess.jar

Yet, a better way would be not to use absolute paths. Case in point, using the Windows specific path here will confine this Java program to the Windows platform which goes against the Java platform-independence principle.
But we live in a world which is far from perfect and sometimes one finds himself forced to follow requirements even if they go against best practices and common sense.