I tried to respond to this earlier today, but
aparently my mail message got zapped into the
netherworld.
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Apr 2001, Mel Martinez wrote:
> > I am writing the jasper34 refactoring proposal. I
> am
> > late on getting it checked in because I have been
> > distracted by other issues (job hunting, for one).
> I
> > am nearly ready to submit it though. It is
> currently
> > in the form of a UML class model generated with
> > Together. I will submit it in html form inside
> the
> > tomcat 3.3 proposals directory for review.
> >
>
> Mel, could you bring me up to date on a couple of
> issues regarding this
> proposed proposal :-)?
>
> * Are you planning on supporting the new JSP 1.2
> features?
> If not, this isn't going to be of much use for
> Tomcat 4.0.
>
The toolkit refactoring strategy is agnostic as to JSP
1.2 or 1.1 features. That is the point. This model
should make it EASIER to replace existing features and
behavior with new implementations. Thus, while not
aimed specifically at providing JSP 1.2 features, this
should help get there.
> * Are you planning on maintaining compatibility with
> JDK 1.1? I don't personally like the idea of
> Tomcat 4.0's
> JSP environment being constrained by this --
> either in the
> internal code of Jasper itself, or in the
> generated code
> for the servlet associated with each page.
>
One of the benefits of the Abstract Factory pattern is
to remove dependencies on particular language version
or platform dependencies. The toolkit itself must be
written to be compatible with jdk1.1, as required for
tomcat 3.x. However, any given *implementation* of a
service provided by the toolkit can ignore jdk1.1 and
use nothing but the latest and greatest Java language
features. Such an implementation could even be used
on tomcat 3.3 - but in that case, the factory method
that instantiates that service needs to be prepared to
supply an alternative in the jdk1.1 case. Since it is
likely a tc4 version of this will use a specific
subclass of the toolkit to add new services, it can
just ignore this issue. For overriding existing
services with new implementations, that is done simply
by setting a config property so again, tc4 would not
have to concern itself with backward compatibility at
all.
The whole thing is analogous to the way AWT and JFC
factories work, except this is much smaller and
simpler. :-)
I hope this is helpful.
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
