On Wed, 20 Dec 2000, Nick Bauman wrote:
> Okay, thanks for the clarification. Not sure I understand why it wasn't
> just merged into SimpleMapper, but maybe in the rush to release things get
> dog-eared sometimes.
It was intentional.
SimpleMapper1 is not just a patch to SimpleMapper, is a whole new module
that replaces SimpleMapper.
We used the 2 in paralel for a while ( and I had about 2 other versions on
a private workspace ). Each mapper had certain advantages - SimpleMapper
was well tested ( but ugly ), SimpleMapper1 was a bit better.
I kept the "1" because I'm sure it'll be followed by a SimpleMapper2 - I
didn't had the time to optimize the mapper, and SimpleMapper1 was low
enough in profiler ( compared with other areas that had bigger overhead).
Now it's time to take another look - but it's not a very big priority ( I
expect it to be <5% ).
We can have other mappers as well - for example, a SimpleMapper12 may
take advantage of 1.2 collections. A TreeMapper may use a tree structure
and a better alghoritm. A SingleContextMapper may be specialized for small
embeded tomcats with only one context. A CustomMapper may be
hand-optimized for a certain application.
In other words - evolution. Instead of trying to create the perfect
mapper, we should try multiple choices and choose the best set.
( the evolution can take place after release - when someone decides it's
time to write the fastest mapper ).
Since we are talking about mapper, a very important thing in tomcat3.x
design is the fact that you can have a "global" mapper, that is doing both
context, request and authentication mapping using the same data structure.
This will allows us to increase the performance by using better data
structures and not restricting the matching alghoritm.
Other containers are spliting it( host -> context -> request +
authentication ).
Costin
