Backward incompatible changes

[Vincent Partington <vincentp@xs4all.nl>]

Hi everyone,

I am in the process of changing a whole number of small (and slightly
larger) things with GNUJSP. It seems I'm finally starting to understand
this whole class loader business, thanks to a number of you that gave me
hints and good examples. At the same time, I want to clean up some parts
of the code, and tighten security. For this to happen, I have to make a
number of backward incompatible changes. I'd like to hear your opinions
about this before just changing it all.

1) The classfiles en compiler.classpath init parameters will be replaced
with the more aptly named "repository" init parameter. Should I keep the
old names for backward compatibility for a while, or shall I just
replace it and clean the code?

2) The compiler en compiler.options init parameters will be consolidated
into one init parameter named "compiler". The syntax will be more
flexible, and the argument list for the builtin java compiler can also
be set with it, e.g.:
compiler=builtin-javac -classpath %classpath%:%repository% -d
%repository% -deprecation %source%
or:
compiler=/usr/local/bin/jikes -classpath %classpath%:%repository% +E +V %source%

3) The default value for the checkuri parameter will be set to "true".
This will tighten security, but may break some sites where the
directories are called "servlet", "jsp" or "gnujsp".

4) The jsp class loader will be modified in two ways:
   - classes whose name does not start with "_jsp." will be passed
     directly to the next class loader.
   - instead of directly trying the system class loader, the servlet
     class loader will be tried first (by calling
     JSPServlet.getClass().getClassLoader()).

Please let me know what you think about these changes. Please keep in
mind that GNUJSP is still beta software (and will stay that way until
JSP 1.0 comes out), and that is the reason why I feel I still have the
chance to make these changes easily.

Regards, Vincent.