Run JSP stored in a database

[nobrentl]

Within the Tomcat environment I am trying to load JSP code that is
stored in a database. I can retrieve the code via JDBC into a string,
now I wish to run it. I could save the code to a file and then
redirect to the file, but that seems very inefficient.

For anyone wondering why I would wish to do this .... I have user
defined/changing forms which a JavaBean code generates into JSP. These
forms change often and their JSP page content is stored to a relational
database structure that tracks many parameters associated with the form
layout and content.

I have investigated using <%include and <%jsp:include to call a JSP
which can spill out the JSP I want to run, but neither of these
directive re-interprets the resulting output.

I know there must be a way to do this, but much web surfing has not yet
got me to the answer.

Thanks,
Brent

 

[Roedy Green]

I know there must be a way to do this, but much web surfing has not yet
got me to the answer.

There is a very old way we used to use often in DOS. I don't know if
it is still supported. You create a RAM drive, a hunk of RAM that is
addressed like a large floppy. That way you don't have to change your
access methods, but you do get the speed.

Are such beasts still available?

 

[Roedy Green]

I know there must be a way to do this, but much web surfing has not yet
got me to the answer.

Other approaches:

1. study the source code to find out where your womb reads the JSP
file off disk. See if there is any sign of plug-in there to get it
elsewhere. See if you can find docs on the interface now you know
some of the relevant names.

2. make a custom version of your womb that can be fed a JSP file in
RAM. It could be as kludgy as a magic file name that it calls a method
on instead of using the file system. Problem here is endless
maintenance.

3. invent some sort of JSP include so there is a disk-based stub, but
most of the stuff comes in from ram via the include.

 

[Roedy Green]

I know there must be a way to do this, but much web surfing has not yet
got me to the answer.

For a short JSP, all you are talking about is one extra physical i/o
to do the write. The read will come from cache. The main overhead is
the file create, close and open.

The rule is, don't optimise before you are forced to, unless of course
you can do it with no extra effort, with no decline in readability.

 

[nobrentl]

Thanks. I appreciate your feedback. The RAM drive thought occurred to
me, but I have to deploy this in various environments and I'd don't
want worry about supporting a RAM drive on varients of Windows, Linux &
Unix. As you stated this may not necessarily be a performance issue.
However, it does become a file management and a potential security
issue. There must be a simple solution to this. It's really no
different than having your HTML/JSP source served from a database
repository.

Thanks, Brent

 

[Andrea Desole]

For anyone wondering why I would wish to do this .... I have user
defined/changing forms which a JavaBean code generates into JSP. These
forms change often and their JSP page content is stored to a relational
database structure that tracks many parameters associated with the form
layout and content.

I would prefer to translate into an own xml language, and then use xslt

I have investigated using <%include and <%jsp:include to call a JSP
which can spill out the JSP I want to run, but neither of these
directive re-interprets the resulting output.

it might be a typo, but you should try <jsp:include. This include is
dynamic, and therefore is executed when the page is executed. This has
to work. Also check that the location of the page is correct.

 

[nobrentl]

Thanks, but I have already tried this. Based on my testing, the
*output* of "include" and "jsp:include" is not re-interpreted. An
XML/XSLT solution would still require generating the XSLT and saving it
to the database, retrieving it and running the XML through it which
leaves me with the same problem of pulling code stored in a database
through to Tomcat and having to save it in a temporary file. Also,
these are not just display only output forms, rather they are data
entry forms which also contain Applets and JavaScript. Thanks. Brent

 

[Andrea Desole]

Thanks, but I have already tried this. Based on my testing, the
*output* of "include" and "jsp:include" is not re-interpreted. An
XML/XSLT solution would still require generating the XSLT and saving it
to the database, retrieving it and running the XML through it which
leaves me with the same problem of pulling code stored in a database
through to Tomcat and having to save it in a temporary file. Also,
these are not just display only output forms, rather they are data
entry forms which also contain Applets and JavaScript. Thanks. Brent

well, I'm afraid that either you have to check your server or I don't
get the point.
I just tried the following pages:

test.jsp:

<jsp:include page="test2.jsp"/>

test2.jsp:

Hello

I loaded test.jsp and I got "Hello", as expected. Then I changed
test2.jsp into:

Hello, world

I refreshed test.jsp and I got

Hello, world

After all, the definition is clear: <jsp:include means that the page is
included at run time.

With XSLT maybe you might have to save your data in a temporary file
(and it's not sure either), but you wouldn't have the problem of
jsp-including, or jsp-compiling. You should just implement the logic to
convert the xml into html via xslt. Applets and JavaScript shouldn't be
a problem.
What I have to admit, though, is that it's probably a lot of work.

 

[Thomas Hawtin]

Thanks, but I have already tried this. Based on my testing, the
*output* of "include" and "jsp:include" is not re-interpreted. An
XML/XSLT solution would still require generating the XSLT and saving it
to the database, retrieving it and running the XML through it which
leaves me with the same problem of pulling code stored in a database
through to Tomcat and having to save it in a temporary file. Also,
these are not just display only output forms, rather they are data
entry forms which also contain Applets and JavaScript. Thanks. Brent

Using the standard API, there is no requirement for the source of XSLT
to be a file. If you use imported or included stylesheets you will also
need to set an entity resolver (for creating the transformer, not the
document it will process).

Tom Hawtin

 

[Roedy Green]

For anyone wondering why I would wish to do this .... I have user
defined/changing forms which a JavaBean code generates into JSP. These
forms change often and their JSP page content is stored to a relational
database structure that tracks many parameters associated with the form
layout and content.

It sounds like you are doing a COMPILE for every page emitted. Is that
so?

If that is so, I hope your volume is very low and is guaranteed to
stay that way. The alternative is instead of generating JSP to
generate Java, and compiling and running to generate the page, you
generate the page directly and interpretively with a single
precompiled Servlet. If you have only a limited number of tags that
might not be that much harder.

Your interpreter might be boosted by parser, but it sounds as if your
data are already in tidy form.

see http://mindprod.com/jgloss/parser.html

 

[nobrentl]

The scenario you describe indicates that the contents of test2.jsp is
"Hello". Try having the contents as:

out.println("out.println(\"hello\");");

Now run your test. My test results show the output to be:

out.println("hello")

But what I am looking for is "hello". That's to say that test2.jsp is
included, is it not run and then the output included. Why is that
important me? If I am to pull my JSP source from a database, I would
be out.print'ing a string variable that had the contents of what I
wanted to run. Hope I am making sense. Thanks, Brent

 

[nobrentl]

Thanks Roedy. Actually we have a set of tables that define what
fields, prompts, forumula and validation are on the data entry form and
where things are placed. Also each varient has an "as-of-date" which
says, depending on what time period (sort-of like an accounting period)
you are working in, this is going to be the layout. Clear as mud?
Then we generate the JSP code (via a JavaBean) required to produce this
form for each varient and save it to the database. That JSP includes
HTML, JavaScript, JDBC queries & updates as you would expect in any
coded data entry page. We do this so as to not be re-rolling the form
every time it is needed. That would be very slow and we typically have
100 to 400 concurrent users hitting our app. Having said this, the
form layouts change weekly according to what users need.

I suppose we could save each varient form to a uniquely named file and
save the file name to the database and then redirect to the form, but
something about having users dynamically creating the JSP and saving it
to the app server file structure concerns me. While I search for a
better solution this is what we are doing. However, I believe it is a
security risk and I know that in the near future we will face
installing in an environment where this "breaks the rules" of an
entity's security or IT administrator.

Thanks for your feedback,
Brent

 

[JScoobyCed]

Within the Tomcat environment I am trying to load JSP code that is
stored in a database. I can retrieve the code via JDBC into a string,
now I wish to run it. I could save the code to a file and then
redirect to the file, but that seems very inefficient.

For anyone wondering why I would wish to do this .... I have user
defined/changing forms which a JavaBean code generates into JSP. These
forms change often and their JSP page content is stored to a relational
database structure that tracks many parameters associated with the form
layout and content.

What about generating a Servlet class?
WHat happen to your JSP file when it is first run? Your test.jsp becomes
a test_jsp.java and then is compiled by Tomcat to become a
test_jsp.class in the work/org/apache/jsp folder (other app servers have
similar way of working)
Have you triied generating such file and store it to the DV? Then, there
might be a way to have Tomcat load it by an include of test.jsp.
Ok, I don't have time to try now, but it might worht trying it

Good luck

 

[nobrentl]

I appreciate your feedback JSC. I will have to think about this and
test it. I will report results in a couple of days. Brent

 

[Andrea Desole]

The scenario you describe indicates that the contents of test2.jsp is
"Hello". Try having the contents as:

out.println("out.println(\"hello\");");

Now run your test. My test results show the output to be:

out.println("hello")

which is correct

But what I am looking for is "hello". That's to say that test2.jsp is
included, is it not run and then the output included. Why is that
important me? If I am to pull my JSP source from a database, I would
be out.print'ing a string variable that had the contents of what I
wanted to run. Hope I am making sense. Thanks, Brent

okay, sorry, but maybe I should get this clear.
Let's stay with the hello example, which seems to fit. What I don't
understand is why it is not enough to write in test2.jsp

out.println("hello")

After all, the real content that you want to show is hello. The rest is
just logic that you build to show your content. So, if you have some
content to send to println, can't you put in your jsp something like:

<%
String stringVariableWithContent;
// ...
// whatever code needed to build stringVariableWithContent
// ...
out.println( stringVariableWithContent ):
%>

 

[nobrentl]

In your example the "stringVariableWithContent" would be JSP, for
example it might contain:

<% out.println("hello") %>

or just

out.println("hello")

This means that the out.println is out printing JSP. Like a JSP which
was doing a

out.println("<% out.println(\"hello\"); %>");

Based on our testing that JSP kindly passed through to the browser.
Regardless of the syntax and regardless of whether a basic "include" or
"jsp:include" is used, we get the same result. Which is to say, both
includes just "include", they don't "exec" (using Unix lingo) which is
what I am after.

Of course, in real life the JSP would be much more complex than our
example, but if the basic result can be achieved then perhaps the
complex will work.

Thanks for the followup. Brent

 

[Andrea Desole]

In your example the "stringVariableWithContent" would be JSP, for
example it might contain:

<% out.println("hello") %>

or just

out.println("hello")

That's something I'm missing. You want a piece of code to generate
test2.jsp (still talking about the example), and test2.jsp should then
be included by test.jsp. This means that test2 is not generating any
other jsp, right? So it's enough for test2 to have

<% out.println("hello") %>

If you want test2 to generate an extra jsp, test3, you can't write in test2

out.println("out.println(\"hello\")")

because test3 will have to be a separate file, so you will have to
println to a separate file on the hard disk.

 

[nobrentl]

I think you are on track, but your question "test2 is not generating
any other jsp?" leads me to think we are not totally thinking on the
same wavelength as that really should not matter. Or stated another
way, may be, may be not. Fundamentally we are looking to take a JSP
page stored in whole or part as a record on a database, read it via
JDBC and then interpret it just as if it were doing a redirect to that
JSP source as a page on disk. The test.jsp scenario is just trying to
get the most elemental part of this working. When a proof of that
scenario works it should be possible to mix and match JSP in a script
with that from a data source, or even construct JSP dynamically on the
fly.

Brent

 

[Andrea Desole]

I think you are on track, but your question "test2 is not generating
any other jsp?" leads me to think we are not totally thinking on the
same wavelength as that really should not matter. Or stated another
way, may be, may be not. Fundamentally we are looking to take a JSP
page stored in whole or part as a record on a database, read it via
JDBC and then interpret it just as if it were doing a redirect to that
JSP source as a page on disk. The test.jsp scenario is just trying to
get the most elemental part of this working. When a proof of that
scenario works it should be possible to mix and match JSP in a script
with that from a data source, or even construct JSP dynamically on the
fly.

Okay, let's see if I finally got it. You want test2.jsp to get some jsp
content from a database and interpret it? I don't think you can do it.
JSP compilers assume that the page is in a physical file. If test2 is
the page that takes the content it can't be the same page that serves
it. There is not even an api for that, because the jsp compiler is
specific to the server. The only think you can do is to take the content
from the JSP and save it on a file that will be included or forwarded to.

 

[nobrentl]

Having a Servlet gives the same result. The output of a servlet is
sent to the browser, not the JSP interpretive engine.