If the content is indeed static, using the 'static include' is your "best practice".
That is, only if what's being included is static, and not just the content itself (which perhaps isn't your case?). Read this link, my two posts towards the bottom...
https://coderanch.com/t/351594/Servlets/java/passing-parameters-included-jsp-file As for leveraging the app server... I worked with iPlanet app server a bit, and there was a way to get it to cache pages, not only based on requested page, but on the parameters sent to that page...
Two example URLS:
mysecuredpage?group=admin and that results in a file that includes resources 1,2,3 and 4
mysecuredpage?group=user which resulted in the inclusion of resources 1 and 2 only
One the second request for either of these URLS, iPlanet would recognize it had already satisfied this request once before, and you could set it to serve the cached copy.
If you need finer-grained control over this than your app server provides (perhaps the URI has no defining parameters), I suppose some sort of application level caching could be done. Someone else suggested using regular FileIO and reading in the contents. You could then cache this 'blob' of text for 'faster' retrieval.
But you'd have to convince yourself that your cache would be more performant that the code used by the app server to do dynamic includes. This includes issues like:
will
java file i/o be faster than potential native methods used by the app server?
will the search time in your cache be faster than the app server finding a file on the file system?
even better.. maybe the app server already caches some items. Would you be doing an end-run around this mechanism?
will the memory footprint of your cache destroy any gain you might realize?
how do you manage the cache size?
You paid $$$ for your server... can you assume it will do a better job?
[ February 27, 2003: Message edited by: Mike Curwen ]