before digging inside the problem better i clarify my context -

i have been working with one of my projects, where i have a several configurations which suppose to be different in different deployment environment, for example – to make my service avail, user has to define his database, his content index directory, server port, ip address and few more.

all these configurations were kept within the spring bean declaration scope. though few of them were moved to the properties file through ext-util namespace handler.

previously to make those configuration changeable i kept those files under WEB-INF/classes so it overrides the default bundled resource.

but still it wasn’t user friendly, since my user has to change one xml document to add more index services also he has to edit different configurations from java properties file.

again when i started bundling jetty with my whole application i found it is tricker to keep those xml outside of application, since i don’t wanna make my user confused with lot of xml files. and i have to keep few xml out of  my classpath context, so spring has to load my configuration from my “config/index-configuration/” directory.

though by default spring can do it over “file:///absolute/path/to/file.xml” since spring is using java URL class to locate this resource.  but in my case i can’t put any aboslute path.
so i found a simple way out there to support relative path reference.

previously i had the following xml document -

now i have replaced them with the following change -

if you observe closely you will find “extfile:///” protocol reference, which is not standard url protocol. so to make it work i used the following bunch of code and configuration -

1. i have created a class “Handler” under the “com.ideabase.repository.core.protocols.extfile” package.
this package and class name is conventional, though you can change them lets sun explain about it.

2. i wrote the following code -

public class Handler extends URLStreamHandler {
protected URLConnection openConnection(final URL pURL) throws IOException {
final String path = pURL.getPath();
final URL resourceUrl;
if (path.startsWith(“/./”)) {
resourceUrl = new File(path.substring(1, path.length())).toURL();
} else {
throw new RuntimeException(“Unsupported url schema. currently you can ” +
“use only extfile:///./path/to/somewhere/in”);
}
return resourceUrl.openConnection();
}
}
3. i registered my protocol package through the system property -

System.setProperty(“java.protocol.handler.pkgs”, “com.ideabase.repository.core.protocols”);

now have a look on the main applicationContext.xml

if you observe closely again you could find the difference, on the normal case i have used relative path reference. so it must be from classloader or if it is loaded through file system based resource locator it will be located from the file system.

but now i can use cross context (relative file system and class loader path reference) resource file path reference. you can see i have imported “indexer-beans.xml” from the application relative path “config/index-configuration/…” where “data-access-layer-beans.xml” is loaded from the class loader.
now have a quick look on my configuration directory, to get an idea how i have improved configuration ability.

hope this will help you to solve similar problem.

for example

function get(pUpdate, pUrl, pParams) {
new Ajax.Updater(pUpdate, pUrl, {parameters: pParams});
}

if you want to regenerate this exception you can invoke this function with the following arguments -

get(“abc”, “http://abc”)

so why this crap ?

the main reason is in your code where you mentioned about “parameters” and which is not supposed to be null. you better write the following code -

function get(pUpdate, pUrl, pParams) {
var options = new Array();
if (pParams != null) {
options["parameters"] = pParams;
}

new Ajax.Updater(pUpdate, pUrl, options);
}
that will take away your javascript exception.

best wishes,

after implementing this stuff, i replaced “render(:partial => …)” with the following method -

render_from_cache_or_render(:cache_key =>”cache key”, :cache_expire_after => ConstantHelper::TAG_CLOUD_EXPIRED_IN, # minutes :partial => “….”)

let’s have a look on my implementation -

def render_from_cache_or_render(p_args)

return render(p_args) if true == p_args[:cache_off]

# check from cache
cache_key = p_args[:cache_key]
cached_content = CacheService.get_cache(cache_key)

if not cached_content.nil? and not cached_content.empty?
return cached_content
else
content = render(p_args)
# cache expire time if defined
cache_expire_time_in_minutes = p_args[:cache_expire_after] || 60
CacheService.add_cache(cache_key, cache_expire_time_in_minutes, content)
return content
end
end

actually, my implemented “CacheService” class is simply storing all cache in a hash map.
when some cache was requested for peek, cache expiry was checked before returning the cached value.

for CacheService implementation look at the bottom of my post.

anyway, after implementing and utilizing this stuff, i gained 70+ requests capability per second. fyi, before applying cache it was around 10 per second.

module Cache
class Item
attr_accessor :key, :expire_time, :content, :created_on

def initialize(p_key, p_expire_time, p_content)
@key = p_key
@expire_time = p_expire_time * 60 # in minutes
@content = p_content
@created_on = Time.now
end
end
end

class CacheService
@@CACHES = {}
@@CACHE_EXPIRE_TIMES = {}

def self.add_cache(p_key, p_expire_time, p_content)
cache_item = Cache::Item.new(p_key, p_expire_time, p_content)
@@CACHES[p_key.to_sym] = cache_item
end

def self.get_cache(p_key)
# load content from cache
cached_content = @@CACHES[p_key.to_sym]
return nil if cached_content.nil?

# verify cache validity
return cached_content.content if not expired?(cached_content)
return nil
end

private
def self.expired?(p_cache)
# find time difference
time_difference = Time.now – p_cache.created_on
return true if time_difference > p_cache.expire_time
end
end

best wishes,

so the pretty simple job i did is the following lines of code block -

def initialize(p_params = {})
super()
unless p_params.empty?
p_params.each do |key, value|
eval %(
self.#{key} = value
)
end
end
end

surprisingly my instance variable declaration became soooooo simple and easy.

update:
i didn’t know that self.send(“#{key}=”, value) does the same job, obviously send is prefer way to do this job.

Visitor design patter is used to traverse through the object structure. it is used to separate the iterating logic from the object.

Let’s imagine, you have the following object structure :

class Tree {

private List mBranches;

public List getBranches() {

return mBranches;

}

}

how we usually iterate through this list of objects, lets think like following code -

// ….

final List branches = tree.getBranches();

for (final Branch branch : branches) {

// …

}

// …

visitor design pattern emphases API designer to hide underlying object structure and iterating logic. now let’s see how we can implement the above example using visitor design pattern:

interface Visitor {

void visit(final Branch pBranch);

}

interface Visitable {

void accept(final Visitor pVisitor);

}

class Tree implements Visitable {

// … previous code

public void visit(final Visitor pVisitor) {

for (final Branch branch : mBranches) {

pVisitor.visit(branch);

}

}

}

now my concern is to make it “n” depth. so it will become a real tree with “n” depth, where can traverse branches and leafs. who is it possible over visitor dp.

here is simple extension over visitor patter, which will enable visitor to visit “n” depth hierarchical object structure.

let’s define our interfaces:

interface Visitor {

void visit(final int pDepth, final TreeItem pItem);

}

interface Visitable {

void accept(final Visitor pVisitor);

}

our tree class:

class Tree implements Visitable {

private TreeItem mRootItem;

// … setter getter

class TreeItem {

private String name;

// .. Setter getter

private List
mTreeItems;

// .. Setter getter

}

public void accept(final Visitor pVisitor) {

visitRecursivlyTreeItem(0, pVisitor, mRootItem);

}

private visitRecursivlyTreeItem(int pLevel, final Visitor pVisitor, final TreeItem pItem) {

pVisitor.visit(pLevel, pItem);

for (final TreeItem item : pVisitor.getTreeItems()) {

visitRecursivlyTreeItem(pLevel + 1, pVisitor, pItem);

}

}

}

That’s all