You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Vitousek <mv...@willamette.edu> on 2009/03/13 22:57:14 UTC

Code/Design Mapping in Tomcat

Greetings,

   First of all, this isn't a question about how to use Tomcat, but 
rather a research question about its architecture, so if this should be 
going to a different mailing list, please let me know.

   From working over the documentation available online and in the 
Tomcat javadocs, I've tried to make a possible high-level model of 
Tomcat's architecture, which is available in this pdf 
(http://www.willamette.edu/~mvitouse/tomcat_model.pdf). The high-level 
entities, or layers, in this model are defined as sets of Java classes 
that may use any resource inside the same layer (with cycles allowed), 
but may only use Java files in other layers if the object being 
referenced is in a layer below that of the referencing object. I'm sure 
that this graph isn't complete, and may be outright wrong in places, so 
if someone who is more intimate with the structure of Tomcat than I am 
could take a look at it and offer any suggestions they might have, I 
would be very grateful. This model doesn't have to be 100% accurate, as 
long as it generally reflects the architecture of the system, but if 
there are any gross violations or omissions here please let me know 
where I should look. I haven't given the contents of each layer here, 
for reasons I talk about below, but the basic components of each layer 
should be clear enough, e.g. the Host layer contains the Host class and 
related classes like HostConfig.

   Some background and context for this request: I'm a student working 
on a project to develop a constraint-based system to analyze the mapping 
between a high-level model of a system's architecture and the system's 
actual source code structure. The constraint system we have right now 
works by taking a graph of dependency relations in the high-level model 
of a program (represented as a set of binary relations), an extracted 
graph of the relations in the actual source of the program, and an 
incomplete set of initial mappings between the two. It then (ideally) 
can complete the mapping, that is, infer which high level entity 
contains each source component. This can allow us to find places where 
the high-level model is violated on the source level, or where the 
high-level model is incorrect. A previous experience in applying this 
method to a medium-sized software system, GenSet, as well as the formal 
definition and explanation of the system, is here 
(http://willamette.edu/~jflasset/research/papers/zhang04fse.pdf). We now 
want to apply this system to a much larger piece of code, like Tomcat, 
to see how well it scales to large, not-necessarily layered architectures.

Thanks very much for your time,
Michael Vitousek



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Code/Design Mapping in Tomcat

Posted by Michael Vitousek <mv...@willamette.edu>.
Thanks a lot; I'll add that one in. From the javadocs, it looks like 
there should be a dependency from the Service layer to the Server as 
well as vice versa, so I'll include that as well. I don't have a lot of 
direct experience working with Tomcat, so I'm most concerned that there 
could be important sections of the system that deserve their own layer 
that I've overlooked, like this, and if anyone knows of any other major 
components of the code that should definitely have a high-level entity 
associated with them, please point them out to me.

Michael Vitousek


Caldarale, Charles R wrote:
>> From: Michael Vitousek [mailto:mvitouse@willamette.edu] 
>> Subject: Code/Design Mapping in Tomcat
>>
>> if there are any gross violations or omissions here please 
>> let me know where I should look.
>>     
>
> You left out the Service layer; it should go between Server and Engine.  Connectors belong to a Service, not the singleton Server.
>
> This will be interesting to hear about as you progress.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Code/Design Mapping in Tomcat

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Michael Vitousek [mailto:mvitouse@willamette.edu] 
> Subject: Code/Design Mapping in Tomcat
> 
> if there are any gross violations or omissions here please 
> let me know where I should look.

You left out the Service layer; it should go between Server and Engine.  Connectors belong to a Service, not the singleton Server.

This will be interesting to hear about as you progress.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Code/Design Mapping in Tomcat

Posted by Mark Thomas <ma...@apache.org>.
Michael Vitousek wrote:
> Greetings,
> 
>   First of all, this isn't a question about how to use Tomcat, but
> rather a research question about its architecture, so if this should be
> going to a different mailing list, please let me know.

Here is fine.

A few comments.

Executors (shared thread pools) are missing.

I'd have expected the threads to be used by the connectors rather than
the startup block.

Context also uses Loader and Resources.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org