What are the possibilites for application-level control of resources
like JSP-resources?
This would open up for e.g. creating a wiki-like application, where each
wiki-page is a valid JSP-page, which is created dynamically and stored
elsewhere than within the deployed WAR-file.
If anyone fancy this type of functionality - or have tried to implement
it by whatever means possible - please make a statement!
-----
I consider creating my own custom-modification of Tomcat including
functionality for application-level control of resources - see the below
sketch. I kind of think upon a modified 'JspServlet' hidden behind a
nice interface so as to avoid fiddling directly with JSP-compilation and
so on.
Is this possible?
How hard is it to implement?
Are there alternatives?
If you care to comment, I would like to here some opinions from people
with insight into the internals of Tomcat.
Morten Sabroe Mortensen
----- BEGIN: Idea for application-level control of resources: -----
My idea is this:
A web-resource like e.g. a JSP-page is to be obtained by the
servlet-engine from the web-application through an interface like this:
/**
* Description of a resource within the context of a servlet-engine.
*/
public interface Resource
{
/**
*
*/
long getTimeModification()
throws
IOException;
/**
*
*/
long getSize() //optional, possibly nice-to-have
throws
IOException;
/**
*
*/
InputStream getInputStream(String path)
throws
IOException;
}
When a user-agent addresses e.g. a JSP-page, a 'ResourceManager' set by
the application is requested by the servlet-engine with the purpose of
delivering the resource:
ServletContext (modified - Tomcat-specific):
void setResourceManager(ResourceManager resourceManager) ...
ResourceManager getResourceManager() ...
Resource getResourceAsResource(String path)
{
Resource res=null;
{
ResourceManager resourceManager=getResourceManager();
if (resourceManager!=null)
{
res=resourceManager.getResource(path);
}
}
return res;
}
void addResourceListener(ResourceListener l)
void removeResourceListener(ResourceListener l)
void fireResourceUpdate(ResourceEvent ev)
interface ResourceManager:
Resource getResource(String path) ...
interface ResourceListener:
void onResourceUpdate(ResourceEvent ev) ... //event-object must
contain path-information
There could be two strategies for accessing a resource:
1) Each time a resource like e.g. a JSP-page is requested, the
servlet-engine performs a lookup for the 'Resource' object and uses
'getTimeModification()' to determine, if the JSP-page has changed and
therefore should be re-compiled and re-loaded. The resource could also
have been removed completely, which would result in no 'Resource' object
being found and 'null' returned - in which case the page no longer
exists.
2) The application always notifies the servlet-engine about changes to
resources. If a resource like e.g. a JSP-page is changed or removed, the
application calls 'fireResourceUpdate()' which again trickers all
'ResourceListener' instances, where the servlet-engine itself per
default has a specific listener added and this listener makes the
servlet-engine perform a lookup for the 'Resource' as in 1).
The 'ResourceManager' could implement a chain-of-responsibility, but
this can be left to the specific application and does not need to be
part of the interface between the servlet-engine and the
web-application.
Interesting types of resources include JSP-pages/-fragments and
tag-libraries.
As I see it, the 'Resource'-type of interface could also be in play,
when Tomcat differs between obtaining resources from an unpacked
WAR-file to when the WAR-file is actually unpacked within the
file-system and JSP-pages are added or changed directly within the
file-system. Tomcat must have something like my 'Resource'-functionality
already, but possibly not expressed as an interface between Tomcat and
web-applications. When moving to a "live" repository like a file-system,
the 'Resource.getTimeModification()' comes into play. There is a
possibility for a unification here.
----- END: Idea for application-level control of resources. -----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
