Hi All,
The storage interface is really a thing that I look forward for having. But how I see it (thanks to Dasarath who mentioned the original idea) this Storage interface should be coupled with store /  retrieve methods in the engine (or such a central component)
Then we can have any kind of Storage implementation associated with an instance of the engine and expect it to behave accordingly. The correct storage instance can be kept in the engine conetext. have a look at the code I am proposing.

class engine{
// Lot of methods here....

public Object store(Object obj) {
  return this.getEngineContext().getStorage().put(obj);
}
public Objectstore(Object key) {
  return this.getEngineContext().getStorage().get(key);
}
}

in this case the user (probably the handlers) need not think of the underlying storage mechanism. Which implementation of the storage to use will be in the server.xml. Hence high end servers can have more robust storages (say a jdbcStorage) and low end ones can have simpler ones (like the fileStorage).

Serializing the contexts is a different matter. They can use the store and retrieve facilities if they want to but I will prefer them to have a standard serialization since the contexts are part of the systems run time environment. IMHO this storage thing is a facility provided by Axis and does not come directly under the axis runtime environment.

thoughts ??

--
Ajith Ranabahu

Reply via email to