--- Steve Downey <[EMAIL PROTECTED]> wrote:
>
> doing some static analysis, based on class use of
> other classes, it looks
> like this constellation of classes could easily be
> factored out into their
> own package:
>
> org.apache.jasper.compiler.Compiler
> org.apache.jasper.compiler.Mangler
> org.apache.jasper.compiler.CommandLineCompiler
> org.apache.jasper.compiler.JspCompiler
> org.apache.jasper.compiler.JavaCompiler
> org.apache.jasper.compiler.JikesJavaCompiler
> org.apache.jasper.compiler.SunJavaCompiler
> org.apache.jasper.compiler.JspCompilationContext
> org.apache.jasper.JspEngineContext
> org.apache.jasper.CommandLineContext
> org.apache.jasper.JasperEngineContext
>
> Based on actual use, it looks to me like Mangler and
> Compiler should be
> merged. There are no instances of Compiler that do
> not implement the Mangler
> interface.
>
Steve,
Thanks for the analysis. I agree that the above
classes for the most part seem misplaced in their
current packages.
I disagree, though, about merging Mangler with
Compiler, though. One of the things I like LEAST
about the current implementation is that Compiler and
Mangler are implemented together. That makes it
difficult to plug-in an alternative naming scheme
without messing with the Compiler or vise-versa, and
yet name mangling and the compilation are two distinct
activities that should be orthogonal. The only
dependency should be that the Compiler is a consumer
of the products of the Mangler.
Also, I'd like to break up JspCompilationContext. It
has turned into a 'god' interface in that it tries to
be all things to all people.
I think the problem starts with the idea to make a
JspLoader that 'loads JSP files just as if they were
classes'. That then broke down into creating a Jsp
Compiler that turned JSP files into classes. That
finally breaks down when you realize that you have to
have an actual javac compiler to turn the .java files
into classes. The JspCompilationContext (originally
the JspEngineContext) was an attempt to tie all these
together with one big payload to carry information
around with. But all that information isn't needed in
every place and further, some of that information
would be better and more efficiently retrieved
elsewhere than from the JspCompilationContext.
By this I mean that currently the
JspCompilationContext provides information relevant to
the page life cycle such as the JspFile, the
OutputDir, Servlet Class and Package names, etc. etc.
- yet JspCompilationContext is a _request_ level
object! It is created once for every request! This
has got to be refactored.
Basically, there are some distinctly separate services
used during the jsp page life cycle and the request
life cycle that should be factored out and made
distinct from each other.
More later. I've got to go interview someone.
Cheers,
Mel
> The classes that implement JspCompilationContext
> look to me like they don't
> all belong in the same package, unless everything
> here is in the same
> package. They are interface classes between the
> Jasper compiler and the
> outside invoker of the compiler.
>
>
> Here are the classes I'm talking about
>
> http://www.panix.com/~sdowney/compilers.gif
>
> and the entire compiler package
>
>
http://www.panix.com/~sdowney/org.apache.jasper.compiler.gif
>
> (courtesy Together J)
>
>
>
> <><><><><><><><><><><><><><><><><><><><><>This
> electronic mail transmission
> may contain confidential information and is intended
> only for the person(s)
> named. Any use, copying or disclosure by any other
> person is strictly
> prohibited. If you have received this transmission
> in error, please notify
> the sender via e-mail.
<><><><><><><><><><><><><><><><><><><><><>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
