> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 29, 2001 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
>
>
> On Thu, 29 Mar 2001, Mel Martinez wrote:
>
> > activities that should be orthogonal. The only
> > dependency should be that the Compiler is a consumer
> > of the products of the Mangler.
>
> +1
If we treat the embedded implementation of Mangler as a separate class,
which I think is a good idea, each style of JSP compilation works with a
triad of somewhat dependant classes. An X-Compiler, an X-Context and an
X-Mangler. If we're playing games with the name of the generated class, like
decorating it with a version number, then some other part of the system
needs to understand the Mangling scheme as well. ClassName does some of this
work now, finding out what the 'real' name of the class is.
Perhaps a Kit pattern is in order?
Refactoring Mangler is highly desireable from my day job point of view, too,
since the current mangling scheme can cause problems on Windows. Although we
might be able to move to Linux for developers desktops soon.
[BTW, I have to thank you for the performance work on Tomcat 3.3. We're
starting a new strategic cycle, and evaluating what platforms and
technologies to persue in the next 12 months. We were preparing arguments
about the value access to source of open software, the recruiting value of
working with 'cool' technology, career development, and so forth. But just
to be thorough, I took our worst behaved JSP page, which happens to be our
home page, and benchmarked it under several engines. TC33 blew the doors off
the competition, up to levels of 177 concurrent connections, at which point
the benchmark tool starting melting down.]
>
> > I think the problem starts with the idea to make a
> > JspLoader that 'loads JSP files just as if they were
>
> JspLoader is a special thing - it's a great idea ( well, the
> new model used by JspInterceptor does the same thing
> in a much cleaner way ).
>
> But in any case, should be independent of everything
> else - just a component that may be used by the
> "container adapter" classes.
>
> Costin
DIP, the dependencies should be on interfaces, not on classes.
-SMD
--
Someone else added this stuff <g>:
<><><><><><><><><><><><><><><><><><><><><>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. <><><><><><><><><><><><><><><><><><><><><>
