Hi,
As I mentioned some time ago, there is one configuration change I would
like to get in before any code freeze.
The idea is to define a "context profile" - containing common settings for
a group of contexts.
In order to implement this, there are few minimal changes in the code (
use new paths ) and the packaging ( different way to package the jars ).
The change will be in the lib/ layout, and few additions to the
server.xml file.
Benefits:
1. Simpler configuration: you don't have to manually configure each
individual context ( or force the same config for all applications ). It
is already common to define different log files and authentication for
different contexts, etc. Instead, you can define properties (i.e. modules
and module configurations ) for groups of applications.
2. Fix few issues with the new class loader ( confusion between
common/shared, classes duplicated in diferent directories, etc )
3. Inter-context calls. You can call getContext() and invoke requests in
different contexts - but that will fail if you use any atribute that
belongs to the context class loader. A solution is to have the jars in
the common CLASSPATH - but that's very bad because it'll force all
applications to see that jar. With profiles, you can define what jars a
group of contexts will share.
4. Jars provided to applications. A number of webapps expect jaxp, other
don't - you'll be able to define what libs are available to a group of
servlets ( the default will probably remain "nothing" ).
I am proposing the following layout for lib/:
lib/ -> executable jars used to start tomcat ( start-tomcat.jar,
stop-tomcat.jar, etc)
lib/common -> jars shared by container and all webapplications ( similar
with the global CLASSPATH ). ( tomcat-core.jar )
lib/container -> modules and jars used by modules ( including jaxp.jar,
etc)
lib/webapps -> jars shared by all web apps ( minimal set )
lib/webapps/foo -> jars specific to each group of web applications
lib/container/foo -> modules specific to a group of web applications
I am also proposing few changes in the jar structure:
- tomcat.utils: move all the top level "org.apache.tomcat.utils" in
specific packages ( require changes in import lines ).
- Split tomcat-utils in few components.
- jasper.jar will be separated in jasper-runtime.jar and jasper.jar
( to follow the general structure of tomcat, jasper.jar will contain the
translator, jasper-runtime will be similar with facade.jar )
Overall, I expect the impact on the current code to be minimal (
i.e. cosmetic changes - different package names, diferent layoyt ), with
no major code change.
The change will also address few security issues ( in sandboxed
environment, fewer permissions to classes visible in the web application).
This is probably the most significant change in the "usablity
enhancement" category. All changes will be completed in about a week.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
