RE: Storing JSPs in a Database

[Petr Jiricka <pe...@netbeans.com>]

(Maybe this should be going to tomcat-dev rather than general, so I'm CC-ing
tomcat-dev.)

I thought that the most straightforward solution could be to register your
URLStreamHandlerFactory, which handles your specific protocol, and this
protocol connects to the database to get the files. Then you would set the
server document root URL to your specific URL (handled by your
URLStreamHandler) and the server should would just pick up all the resources
from your handler. 

I tried something like this a few months ago (even though my case was
simpler, because I just used a standard http URL as a docbase, connecting to
another webserver), and it worked fine for the servlet engine as long as I
didn't use JSPs (this makes sense, since I don't think you should need
anything like getRealPath() to get resources). 

But the JSP engine seems to be rather specific, so it didn't work. I'm not
sure how exactly the JSP engine internals work, but I saw java.io.File many
times in JspReader. Does this mean that the JSP page needs to be a
java.io.File ? How does it work with unexpanded .war files then ? It looks
like java.io.File is used to get the last modified date of the page. But
couldn't there be a workaround for this ? Suppose JspReader worked with URLs
instead of files, then the date would be determined based on the URL scheme,
you would only need some "plugin", which would return last-modified dates
for specific schemes. This "plugin" could be installed to Tomcat in a
similar way a URLStreamHandlerFactory is plugged into JDK.

Could someone please explain how all this works ? Or am I just missing
something ?

Thanks 
Petr

> -----Original Message-----
> From: Danno Ferrin [mailto:shemnon@earthlink.net]
> Sent: Thursday, February 10, 2000 11:53 PM
> To: general@jakarta.apache.org
> Subject: Re: Storing JSPs in a Database
> 
> 
> Yes this is possible, but there is defiantly some lifting 
> involved that
> may be strenuous.
> 
> You would need to re-write whole sections of
> org.apache.jasper.runtime.JspServlet.  Instead of getting the name of
> the jsp from the ServletRequest methods you would use the 
> request params
> to get it.  And you would need to marshal the stream or create a temp
> file for the parsing, which would involve overriding
> JspCompilerContext.getResourse or something like that.  you would also
> need to make sure that the servlet compiles the first instance and
> report all other requests as unchanged.  Unless you add a 
> last modified
> timestamp or use a trigger to put the jspname in a dirty jsps 
> table or a
> simple dirty flag in the existing column.  the timestamp is 
> the easiest
> solution since it integrates with existing APIs, just be sure the two
> systems are reasonably synched with the time.
> 
> You are not restricted to using the request parameter for the 
> page name,
> using the extra path info works, like
> http://www.server.com/myapp/runJSPServlet/MYJSP  where the servlet is
> "/MYJSP"  You could even in theory server an entire web-app from a
> database, but you would need to do some heavy lifting on the 
> tomcat end.
> 
> --Danno
> 
> Joaquim Carvalho wrote:
> > 
> > Hello,
> > 
> > Can I store the JSPs in a database instead of disk and have they run
> > through
> > a servlet?
> > 
> > To make it more clear:
> > 
> > Supose I have a database with JSPs in a table with two 
> columns: JSP Name
> > and
> > JSP source (the full text of the JSP).
> > 
> > I want to be able to do something like:
> > 
> > http://www.server.com/myapp/runJSPServlet?name=MYJSP
> > 
> > Where runJSPServlet would fetch from the Database the text 
> of MYJSP and
> > "somehow" have it processed and executed as if it was 
> stored on disk.
> > 
> > Can I avoid having to save the JSP text to disk and  do a redirect?
> > 
> > Did I explain well enough?
> > 
> > J
> > 
> > --
> > Joaquim Ramos de Carvalho
> > Instituto de Historia e Teoria das Ideias / Centro de Informatica e
> > Sistemas da Universidade de Coimbra.
> > Tel: 351+39+790066. email: joaquim@dei.uc.pt
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>