tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Hill <>
Subject Re: Can JSP code be served from a DB instead of files?
Date Tue, 28 Dec 2010 03:10:56 GMT
This reminds me back when I was working RND on the silverstream app server.
We stored everything in the DB. I am not sure on the specifics but I think
we only stored pre-compiled in the db with some sever specific meta for url
binding. I know it's no help but I couldn't resist.

On Mon, Dec 27, 2010 at 6:51 PM, David Wall <> wrote:

>  Yes. You'll need to extend BaseDirContext in
>>>> org.apache.naming.resources. For some examples, see FileDirContext and
>>>> WarDirContext in the same package.
>>> Thanks for the pointers, Mark.  From what you are saying, this would be
>>> a Tomcat-specific solution.  I was hoping for something that would work
>>> in standard way so it would be portable.
>> I'm not sure there is going to be a pure-Java, container-agnostic
>> solution. There is certainly nothing in the servlet spec that will help
>> you with this, so your solution is likely to be either
>> container-specific, or not a container-related solution (like using a
>> db-based filesystem mounted at the OS level).
> Thanks, Chris.  Yeah, I figured this could be a tough one as there cannot
> be too many folks who want to store their JSPs in a database.  It's a first
> for me and it seems like forever I've been doing JSP/servlets... ;-)
>  While we use Tomcat ourselves,
>>> we've had users who run on other containers.  I'll take a look though
>>> since maybe it's something that can be plugged into other containers,
>>> too.
>> Good luck. In either case, a DataSourceDirContext would be a nice
>> addition to Tomcat. ;)
> Indeed!  You guys have done a wonderful job with Tomcat, that's for sure.
>  I think we'll muddle along with writing the JSPs to the filesystem for now
> and see what sort of issues pop up in the future.  The higher priority for
> us now is to make those generated JSPs do something useful!
> Thanks for your answers and consideration...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message