--- Steve Downey <[EMAIL PROTECTED]> wrote:
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> >
> > 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?
>
Ah yes, the venerable ToolKit!
This is basically what I'm going for, with two tiers:
- a static, default layer of factory methods that is
independent of the runtime adaptor scheme. This is
done via factories in a subclass of Constants. This
layer has default behavior that is configurable via
standard configuration properties (both via -D and via
resource file).
- a run-time layer of factory methods that overrides
the default layer based on run-time options such as
init-params. This is to be implemented in a subclass
of Options.
This pattern allows each adapter (i.e. JspC,
JspInterceptor) to adopt just the shared behavior that
is necessary by extending/re-implementing it's own
'options'-layer factories.
I must admit to not being totally sure whether
co-opting the current 'Constants' and 'Options' class
families is the best naming for this, but they do
clearly indicate the difference in scope. I could
break the factory methods out into separate, new
'ConstantsToolkit' and 'OptionsToolkit'
class/interface types, but since they would parallel
the original, I don't see the real advantage.
> 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.
>
I ran into that some time back (mangling issues) and
was one of my motivations for doing this refactoring
earlier in my day-job implementation of JspServlet
(tc3.3). The result of that effort works very well
and I'm borrowing heavily from it for this effort, but
this time I'm trying to put more support for (and
steal ideas from) other adapter options.
> 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.]
>
That is always good stuff to hear! Costin deserves a
lot of the credit here, since that performance gain is
primarily (probably) coming from his JspInterceptor
implementation. I know we can never get JspServlet to
be completely as fast, but we should be able to get it
much closer than it currently is.
>
> > 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.
>
90% of the time I agree. Some abstractions require
base or abstract classes, though, if part of the
specification fixes actual behavior. This is often
the case when initialization must follow a fixed
pattern (i.e. a certain type of constructor signature
or other life-cycle methods must be supported).
This can sometimes be avoided if the interface is
well-thought out. For example, the problem with the
current Mangler interface is that it does not support
any way to input the core parameters (the jsp URI and
the scratchdir) from which it's method must derive
their data. In other words, we want a factory method
that works like so:
publc static Mangler createMangler(
String uri,String dir){..}
but we need a predictable way to communicate the
params to the created instance. There are three ways
to fix this in order to support abstract creation
through factory methods.
1) rewrite the Mangler interface to have an
init(String,String) method or 'setJspUri(String)' and
'setOutputDir(String)' methods - this would be
optimal, but would break existing implementations of
Mangler.
2) create a default basic or abstract implementation
of Mangler (call it 'JspMangler' or whatever) and give
it a public constructor that takes the params. The
factory method then becomes:
public static JspMangler createJspMangler(
String, String){...}
The problem with this one is that it forces all new
Mangler implementations to subclass JspMangler. This
is not necessarily a bad thing.
3) create a new interface called JspMangler (or
whatever) and adding the missing initialization/setter
method(s). This results in a factory method that
looks the same as in (2) and only forces new
implementatons to 'implement' JspMangler.
I'm opting for strategy #3.
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
