tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Date Sat, 16 Jun 2012 15:28:44 GMT
2012/6/15 Mark Thomas <>:
> All,
> Servlet 3.1 looks like it is going to introduce 'overlays' or something
> similar along the lines of the enhancement request [1].
> Tomcat already has aliases, VirtualDirContext and resource JAR support -
> each implemented slightly differently. Things are already rather messy
> and will get worse if we build on what we currently have. I have
> therefore been looking at a new Resources implementation for Tomcat 8
> that is not based on DirContext.
> Along the way I have noticed a few related refactorings that will be
> required / would make life easier. They are:
> 1. Move Loader and Resources from Container to Context
>   The docs already state these are only for Contexts and they don't
>   make much sense on other Containers.


> 2. Move Mapper to o.a.catlina.connector.mapper
>   It is only used here and removing DirContext means it will have a
>   hard dependency on o.a.c.resources (or wherever the new implemenation
>   goes) so can't stay in o.a.tomcat.util

Most of Mapper is agnostic on whatever technology if behind it.
MappingData class stores Objects instead of Host, Context etc.

Having a DirContext there already means that this abstraction is
leaking, so I do not mind the move.

I wonder whether interfaces and implementation will be separate, so
that Mapper were not really "hard" dependent on implementation

BTW, maybe "o.a.c.resource".
We have "resources" packages elsewhere (Jasper, javax.servlet.**) and
they contain some supplementary data, not code.  The
o.a.naming.resources package is an exception.

> I'd like to complete these before I start the main refactoring to a) do
> things in stages b) do the bigger refactoring from a slightly cleaner start.
> The broader refactoring aims to provide aliases, overlays, resource JARs
> and anything else along those lines through a common interface with the
> implementations going directly to the file system. Access via URLs will
> also be supported but direct access to the file system will be
> preferred.

How are you going to handle unpacked WARs ?
Some abstraction will still be needed. I wonder how much will it
differ from DirContext.

DirContext served it purpose, but it looks that it requires too much
plumbing (dealing with Names etc). I wonder whether it can survive as
a facade to new API. (Though I do not yet know a valid purpose to keep
such facade).

org.apache.naming.* will survive, because Tomcat still needs JNDI support .

URLs are needed per Servlet API, so they cannot be removed. Does our
"jndi" schema need DirContext as underlying implementation?

I noticed the following commit in archives:
so we have to deal with such schema combinations as "jar:jndi:".

IIRC there was once a person who complained that our "jndi" schema was
clashing with some other implementation of "jndi" schema in an
application where he was trying to embed Tomcat. I cannot find that
thread in the archives though.

I wonder what will happen with org.apache.naming.JndiPermission

> I have some rough ideas for this. My plan is to commit the
> new classes as I go along so folks can comment and provide feedback but
> only commit the changes to existing classes once I have everything working.


Though if it is work in progress maybe some comments/summaries will be
needed to understand how it is going to be integrated with existing

> Since this is fairly major work, any objections before I start?
> Cheers,
> Mark
> [1]

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message