See intermixed.
Christian Mallwitz wrote:
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 21, 2000 19:23
> > To: [EMAIL PROTECTED]
> > Subject: Re: How to do my own JSP processing
> >
> > Sounds like you are planning on inventing your own variant of
> > a servlet+JSP server, since you're wanting to change or ignore
> > many of the spec requirements.
> > And you will end up with an app that will only run in your
> > own server. Unless you like building servers as a hobby,
> > you've got a *lot* of hard work ahead of you.
> >
> > I would suggest you look at how you can architect your
> > application *within* the requirements of the servlet and
> > JSP specs. That way, you can focus on writing an app rather
> > than a server, and have some assurance that you can run that app
> > elsewhere if and when you outgrow Tomcat.
>
> Actually I have my own template language which is compiled to a JSP file.
> Everything is supposed to be as much Servlet 2.3 spec conformant as
> possible. Here is a simplistic view on my main servlet
>
> service()
> 1. begin database transaction
> 2. do some business logic
> 3. execute JSP file
> 4. commit transaction
> 5a. if commit successful send response content to the network
> 5b. if not generate error response (and discard result of JSP)
>
> The problems with 3.) are
> I.) the JSP files are located outside my servlet context
That one is a non-spec-compliant requirement -- all resources are supposed to be
addressable *within* a context. Depending on your OS and servlet container, you
might be able to "cheat" and simulate this with a symbolic link or something.
>
> II.) JSP execution must be buffered because the content is not be sent
> before the database transaction commits
You can do that already, by just setting the page buffer size big enough -- but
see below for an alternative approach.
>
> III.) the JSP execution must be able to set response header lines (e.g.
> cookie)
That's fine, as long as the response has been buffered and not committed yet.
>
> IV.) it should be possible in JSPs to use tag libraries and do all other
> things possible if the JSP is served directly by Tomcat
So you are essentially writing JSP source on the fly, and then wanting the
servlet container to execute them? Sounds like an overly complicated design to
me, but I presume you've determined that the extra layer is worth it.
>
> Because of
> I.) I cant use a "simple" servlet request dispatcher
> II.) forward() won't work because if the forward() returns the response is
> already committed and closed by the container
> III.) includes() won't do because I can't set headers
>
> On top of this I want my servlet to pick a JSP file, run it, capture the
> output and send this output be email before saying "sending email was
> successful." over HTTP.
>
> >From what I read about Jasper it should be possible to call it compile my
> JSPs and trigger their execution independent of the all of this is running
> in a servlet itself or a standalone application, right?
>
There isn't really such a thing as running the compiled JSP page in a
stand-alone application. The generated code relies on being run inside a
servlet context (i.e. for application-scope beans and such). In Tomcat's case,
the stand-alone compiler (jspc) generates compiled servlets and a bunch of stuff
that needs to be added to the web.xml file -- not a dynamic process, as you are
describing.
You might also want to look at an alternative architecture for organizing your
app. There are several frameworks available (such as Struts and Turbine within
the Apache realm) that use a model-view-controller (MVC) design pattern. For
example, to deal with the buffering problem, you would do something like this:
* Submit a request to the controller servlet
* Controller servlet dispatches to business logic that processes
that particular type of request
* Business logic initiates the transaction, performs the required
changes, and attempts to commit
* Based on the results, forward to a "success" page or a "failure"
page.
Note that the buffering issue goes away -- you will never have tried to execute
the "success" page unless the transaction succeeded. Also, you will be
separating the business logic and presentation logic portions of your app, which
will make it easier to maintain and enhance in the future.
Just a thought.
>
> Thanks
> Christian
> PS: I know it will be a nice piece of work ...
> --
> Christian Mallwitz INTERSHOP Communications Germany
> Senior Software Engineer phone: +49 3641 50 3453
Craig
