Guide To Web Development With Java Understanding

Website Creation 2nd Edition Tim Downey download

https://ebookbell.com/product/guide-to-web-development-with-java-
understanding-website-creation-2nd-edition-tim-downey-24008132

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Guide To Web Development With Java Understanding Website Creation 1st

Edition Tim Downey Auth

https://ebookbell.com/product/guide-to-web-development-with-java-
understanding-website-creation-1st-edition-tim-downey-auth-2626180

Tapestry 5 A Stepbystep Guide To Java Web Development With The

Developerfriendly Apache Tapestry Framework Alexander Kolesnikov

https://ebookbell.com/product/tapestry-5-a-stepbystep-guide-to-java-
web-development-with-the-developerfriendly-apache-tapestry-framework-
alexander-kolesnikov-4108380

Tango With Django 2 A Beginners Guide To Web Development With Django 2

Leif Azzopardi

https://ebookbell.com/product/tango-with-django-2-a-beginners-guide-
to-web-development-with-django-2-leif-azzopardi-26856500

Tango With Django A Beginners Guide To Web Development With Python

Django 19 1st Edition Leif Azzopardi

https://ebookbell.com/product/tango-with-django-a-beginners-guide-to-
web-development-with-python-django-19-1st-edition-leif-
azzopardi-5709570
Tango With Django A Beginners Guide To Web Development With Python
Django 19 Leif Azzopardi David Maxwell

https://ebookbell.com/product/tango-with-django-a-beginners-guide-to-
web-development-with-python-django-19-leif-azzopardi-david-
maxwell-6770378

Learn React With Typescript A Beginners Guide To Reactive Web

Development With React 18 And Typescript 2nd Edition 2nd Carl Rippon

https://ebookbell.com/product/learn-react-with-typescript-a-beginners-
guide-to-reactive-web-development-with-react-18-and-typescript-2nd-
edition-2nd-carl-rippon-47936932

Complete Vuejs 2 Web Development Practical Guide To Building Endtoend

Web Development Solutions With Vuejs 2 1st Edition Mike Street

https://ebookbell.com/product/complete-vuejs-2-web-development-
practical-guide-to-building-endtoend-web-development-solutions-with-
vuejs-2-1st-edition-mike-street-7336226

Learn React With Typescript 3 Beginners Guide To Modern React Web

Development With Typescript 3 Carl Rippon

https://ebookbell.com/product/learn-react-with-typescript-3-beginners-
guide-to-modern-react-web-development-with-typescript-3-carl-
rippon-10479096

Rust Web Development With Rocket A Practical Guide To Starting Your

Journey In Rust Web Development Using The Rocket Framework Karuna
Murti

https://ebookbell.com/product/rust-web-development-with-rocket-a-
practical-guide-to-starting-your-journey-in-rust-web-development-
using-the-rocket-framework-karuna-murti-43768604
Texts in Computer Science

Tim Downey

Guide to Web
Development
with Java
Understanding Website Creation
Second Edition
Texts in Computer Science

Series Editors
David Gries, Department of Computer Science, Cornell University, Ithaca, NY,
USA
Orit Hazzan , Faculty of Education in Technology and Science, Technion—Israel
Institute of Technology, Haifa, Israel
More information about this series at http://www.springer.com/series/3191
Tim Downey

Guide to Web
Development with Java
Understanding Website Creation
Second Edition

123
Tim Downey
School of Computing
and Information Sciences
Florida International University
Miami, FL, USA

ISSN 1868-0941 ISSN 1868-095X (electronic)

Texts in Computer Science
ISBN 978-3-030-62273-2 ISBN 978-3-030-62274-9 (eBook)
https://doi.org/10.1007/978-3-030-62274-9
1st edition: © Springer-Verlag London Limited 2012
2nd edition: © Springer Nature Switzerland AG 2021
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, expressed or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with regard
to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
To Bobbi, my sweetheart, with all my love.
The magic continues.
Preface

This book is about developing web applications. Over the years, more and more
frameworks have appeared that hide the details of the communication between the
browser and the server. These packages are fantastic for developing applications,
but an understanding of the underlying process can help understand the reason that
frameworks do what they do.
In writing this book, I read the Spring documentation in detail and reviewed many
questions from Stack Overflow. The problems I encountered were that many sear-
ches did not return the most current version of documentation. Frequently, I had to
check that I wasn’t reading about version 1 features instead of version 5. Similarly,
many relevant answers to questions are buried deep in the search results, since older
answers have been around much longer and appear at the top of the search.
My hope is that this book will present material from the basics of HTML and
HTTP to the intricacies of web services in a step-by-step manner, adding only a few
details at a time. Some topics have multiple implementations that produce similar
results. I hope that the distinctions between these implementations are made clear.
The book develops a framework in the first few chapters and then switches to the
Spring framework for implementing websites. There are many frameworks on the
market. Spring is popular and Spring Boot is an excellent introductory package.
I want students to understand the actual details that a framework hides, and to use a
framework to solve problems. In the future, when they are introduced to other
frameworks, they will understand them better.
I am grateful to the community of web developers, who have provided all the
excellent tools for creating web applications: Apache, Tomcat, Hibernate, Java
Servlets, Java Server Pages, NetBeans, Eclipse, Log4j, Apache Commons, Google
web services, FedEx web services, PayPal web services, JBoss Community, Spring,
and Maven.
I am thankful to Bobbi, my sweetheart, for all of her love and support. Without
Bobbi, this book would not have been finished. I also want to thank Kip Irvine for
encouraging me to write. Without Kip, this book would not have been started.

Miami, USA Tim Downey

vii
Contents

1 Web Applications and Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Content Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Hypertext Markup Language . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Basic Tags for a Web Page . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 What is the HT in HTML? . . . . . . . . . . . . . . . . . . . . . 12
1.3 HTML Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Representing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.3 Transmitting Data Over the Web . . . . . . . . . . . . . . . . . 19
1.4 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1 Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.1 Maven Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.2 Maven Web Application . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.3 Maven from the Command Line . . . . . . . . . . . . . . . . . 24
1.5.4 Maven in an IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.5.5 Maven: Adding A Servlet Engine . . . . . . . . . . . . . . . . 26
1.6 Processing Form Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.1 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.2 Initialising Form Elements . . . . . . . . . . . . . . . . . . . . . 30
1.7 The Truth About JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7.1 Servlet for a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7.2 Handling a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.8 Tomcat and IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.8.1 Web Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.10 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ix
x Contents

2 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1 Sending Data to Another Form . . . . . . . . . . . . . . . . . . . . . . . . 46
2.1.1 Action Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.1.2 Hidden Field Technique . . . . . . . . . . . . . . . . . . . . . . . 49
2.1.3 Sending Data to Either of Two Pages . . . . . . . . . . . . . 53
2.2 Using a Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.2.1 Controller Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.2.2 JSP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.3 JSPs Versus Servlets . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.4 Controller Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.5 Servlet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.2.6 Servlet Directory Structure . . . . . . . . . . . . . . . . . . . . . 71
2.2.7 Servlet Engine for a Servlet . . . . . . . . . . . . . . . . . . . . 74
2.3 Maven Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.3.1 Automatic Deployment . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.2 Debugging Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.5 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3 Java Beans and Member Variables . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.1 Application: Start Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2 Java Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2.1 Creating a Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.2.2 Using the Bean in a Web Application . . . . . . . . . . . . . 90
3.3 Application: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.1 Mapping: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.2 Controller: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.3.3 Data Access in a View . . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.4 Views: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4 Application: Default Validation . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4.1 Java Bean: Default Validation . . . . . . . . . . . . . . . . . . . 96
3.4.2 Controller: Default Validation . . . . . . . . . . . . . . . . . . . 98
3.5 Member Variables in Servlets . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.1 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.2 The Problem with Member Variables . . . . . . . . . . . . . 100
3.5.3 Local Versus Member Variables . . . . . . . . . . . . . . . . . 103
3.6 Application: Shared Variable Error . . . . . . . . . . . . . . . . . . . . . 104
3.6.1 Controller: Shared Variable Error . . . . . . . . . . . . . . . . 104
3.7 Application: Restructured Controller . . . . . . . . . . . . . . . . . . . . 107
3.7.1 Creating the Helper Base . . . . . . . . . . . . . . . . . . . . . . 108
3.7.2 Creating the Controller Helper . . . . . . . . . . . . . . . . . . 109
3.7.3 Views: Restructured Controller . . . . . . . . . . . . . . . . . . 112
3.7.4 Controller: Restructured Controller . . . . . . . . . . . . . . . 114
Contents xi

3.7.5 Restructured Controller Analysis . . . . . . . . . . . . . . . . . 114

3.7.6 File Structure: Restructured Controller . . . . . . . . . . . . . 114
3.8 Model, View, Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.10 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.1.1 Power of Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.1.2 Injection Through Autowiring . . . . . . . . . . . . . . . . . . . 123
4.2 Application: Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.2.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2.2 Command Line Arguments . . . . . . . . . . . . . . . . . . . . . 133
4.2.3 Main Class: Command Line . . . . . . . . . . . . . . . . . . . . 133
4.3 Application: Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.3.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3.2 Servlets and Controllers . . . . . . . . . . . . . . . . . . . . . . . 137
4.3.3 Static Content Locations . . . . . . . . . . . . . . . . . . . . . . . 139
4.3.4 Location of the View Pages . . . . . . . . . . . . . . . . . . . . 139
4.3.5 Request Data Interface . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3.6 Bean Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3.7 Singleton Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.3.8 Retrieving HTTP Variables . . . . . . . . . . . . . . . . . . . . . 150
4.4 Application: Spring Restructured Controller . . . . . . . . . . . . . . . 151
4.4.1 Modified Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.5 Maven Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.5.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.5.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.7 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5 Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.1 Eliminating Hidden Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.1.1 Session Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.1.2 Spring Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.1.3 Modifying the Controller . . . . . . . . . . . . . . . . . . . . . . 175
5.2 Controller Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.2.1 Encapsulating with Methods . . . . . . . . . . . . . . . . . . . . 179
5.2.2 Multiple Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.3 POST Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.3.1 POST Versus GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.3.2 Using Post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
xii Contents

5.4 Replacing the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

5.4.1 Adding to the Model . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.4.2 Model in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.4.3 Model in a Controller . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.5 Navigation Without the Query String . . . . . . . . . . . . . . . . . . . . 196
5.5.1 Using Path Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.5.2 Default Request Mapping . . . . . . . . . . . . . . . . . . . . . . 198
5.6 Session Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.6.1 Class Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.6.2 Parameter Annotation . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.6.3 Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.6.4 Conversational Storage . . . . . . . . . . . . . . . . . . . . . . . . 204
5.6.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.7 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.7.1 Logback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.7.2 Configuring the Logger . . . . . . . . . . . . . . . . . . . . . . . . 207
5.7.3 Retrieving the Logger . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.7.4 Adding a Logger in the Bean . . . . . . . . . . . . . . . . . . . 212
5.8 Application: Enhanced Controller . . . . . . . . . . . . . . . . . . . . . . 213
5.8.1 Views: Enhanced Controller . . . . . . . . . . . . . . . . . . . . 214
5.8.2 Model: Enhanced Controller . . . . . . . . . . . . . . . . . . . . 216
5.8.3 Controller: Enhanced Controller . . . . . . . . . . . . . . . . . 218
5.9 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
5.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.11 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6 Validation and Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.1 Required Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.1.1 Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.1.2 Required Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.2 Application: Required Validation . . . . . . . . . . . . . . . . . . . . . . . 240
6.2.1 Views: Required Validation . . . . . . . . . . . . . . . . . . . . 241
6.2.2 Model: Required Validation . . . . . . . . . . . . . . . . . . . . 242
6.2.3 Controller: Required Validation . . . . . . . . . . . . . . . . . . 243
6.3 Additional Binders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.3.1 Custom Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.3.2 Custom Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.4 Java Persistence API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.1 JPA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.2 Persistent Annotations . . . . . . . . . . . . . . . . . . . . . . . . 256
6.4.3 Accessing the Database . . . . . . . . . . . . . . . . . . . . . . . 259
6.4.4 Data Persistence in Hibernate . . . . . . . . . . . . . . . . . . . 275
6.5 Application: Persistent Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Contents xiii

6.5.1 Views: Persistent Data . . . . . . . . . . . . . . . . . . . . . . . . 277

6.5.2 Repository: Persistent Data . . . . . . . . . . . . . . . . . . . . . 278
6.5.3 Controller: Persistent Data . . . . . . . . . . . . . . . . . . . . . 278
6.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
6.8 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
7 Advanced HTML and Form Elements . . . . . . . . . . . . . . . . . . . . . . 287
7.1 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.2 HTML Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.2.1 In-Line and Block Tags . . . . . . . . . . . . . . . . . . . . . . . 289
7.2.2 General Style Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
7.2.3 Layout Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
7.3 Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
7.3.1 Adding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
7.3.2 Defining Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
7.3.3 Custom Layout with CSS . . . . . . . . . . . . . . . . . . . . . . 303
7.4 Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
7.4.1 Input Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
7.4.2 Textarea Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.4.3 Select Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.5 Spring Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7.5.1 Spring Input Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7.5.2 Spring Textarea Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 315
7.5.3 Spring Select Elements . . . . . . . . . . . . . . . . . . . . . . . . 315
7.5.4 Initialising Form Elements . . . . . . . . . . . . . . . . . . . . . 316
7.6 Bean Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.6.1 Bean Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.6.2 Filling the Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7.6.3 Accessing Multiple-Valued Properties . . . . . . . . . . . . . 319
7.7 Application: Complex Elements . . . . . . . . . . . . . . . . . . . . . . . . 320
7.7.1 Controller: Complex Elements . . . . . . . . . . . . . . . . . . . 320
7.7.2 Views: Complex Elements . . . . . . . . . . . . . . . . . . . . . 321
7.7.3 Model: Complex Elements . . . . . . . . . . . . . . . . . . . . . 324
7.8 Validating Multiple Choices . . . . . . . . . . . . . . . . . . . . . . . . . . 326
7.9 Application: Complex Validation . . . . . . . . . . . . . . . . . . . . . . . 327
7.9.1 Model: Complex Validation . . . . . . . . . . . . . . . . . . . . 327
7.9.2 Views: Complex Validation . . . . . . . . . . . . . . . . . . . . 328
7.9.3 Controller: Complex Validation . . . . . . . . . . . . . . . . . . 329
7.10 Saving Multiple Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
7.11 Application: Complex Persistent . . . . . . . . . . . . . . . . . . . . . . . 332
7.11.1 Model: Complex Persistent . . . . . . . . . . . . . . . . . . . . . 332
7.11.2 Views: Complex Persistent . . . . . . . . . . . . . . . . . . . . . 332
xiv Contents

7.11.3 Repository: Complex Persistent . . . . . . . . . . . . . . . . . . 333

7.11.4 Controller: Complex Persistent . . . . . . . . . . . . . . . . . . 334
7.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
7.13 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
8 Accounts–Cookies–Carts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8.1 Retrieving From The Database . . . . . . . . . . . . . . . . . . . . . . . . 344
8.1.1 Finding a Row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
8.1.2 Validating a Single Property . . . . . . . . . . . . . . . . . . . . 346
8.1.3 Retrieving a Record . . . . . . . . . . . . . . . . . . . . . . . . . . 347
8.2 Application: Account Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
8.2.1 Model: Account Login . . . . . . . . . . . . . . . . . . . . . . . . 350
8.2.2 Views: Account Login . . . . . . . . . . . . . . . . . . . . . . . . 352
8.2.3 Controller: Account Login . . . . . . . . . . . . . . . . . . . . . 353
8.3 Removing Rows from the Database . . . . . . . . . . . . . . . . . . . . . 355
8.3.1 Delete Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8.3.2 Delete Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8.3.3 Controller: Delete Record . . . . . . . . . . . . . . . . . . . . . . 356
8.4 Application: Account Removal . . . . . . . . . . . . . . . . . . . . . . . . 357
8.4.1 Views: Account Removal . . . . . . . . . . . . . . . . . . . . . . 357
8.4.2 Controller: Account Removal . . . . . . . . . . . . . . . . . . . 357
8.5 Account Number in Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.5.1 Handler Modifications for the Path . . . . . . . . . . . . . . . 359
8.5.2 Model: Path Controller . . . . . . . . . . . . . . . . . . . . . . . . 362
8.5.3 Controller: Path Controller . . . . . . . . . . . . . . . . . . . . . 362
8.5.4 Views: Path Controller . . . . . . . . . . . . . . . . . . . . . . . . 364
8.6 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
8.6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
8.6.2 Cookie Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
8.7 Application: Cookie Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.7.1 View: Cookie Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.7.2 Showing Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
8.7.3 Setting Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
8.7.4 Deleting Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
8.7.5 Finding Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
8.7.6 Path Specific Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 372
8.8 Application: Account Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 373
8.8.1 Views: Account Cookie . . . . . . . . . . . . . . . . . . . . . . . 373
8.8.2 Controller: Account Cookie . . . . . . . . . . . . . . . . . . . . 374
8.9 Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
8.9.1 Cart Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
8.9.2 Create Cart Item Database . . . . . . . . . . . . . . . . . . . . . 384
8.9.3 Model: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . 386
Contents xv

8.10 Application: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

8.10.1 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
8.10.2 Controller: Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
8.10.3 Controller: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . 393
8.10.4 Views: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . 395
8.10.5 Shopping Cart: Enhancement . . . . . . . . . . . . . . . . . . . 400
8.11 Persistent Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
8.12 Application: Persistent Shopping Cart . . . . . . . . . . . . . . . . . . . 402
8.12.1 Model: Persistent Shopping Cart . . . . . . . . . . . . . . . . . 402
8.12.2 Views: Persistent Shopping Cart . . . . . . . . . . . . . . . . . 403
8.12.3 Repository: Persistent Shopping Cart . . . . . . . . . . . . . . 405
8.12.4 Controller: Persistent Shopping Cart . . . . . . . . . . . . . . 405
8.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
8.14 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
9 Web Services and Legacy Databases . . . . . . . . . . . . . . . . . . . . . . . . 411
9.1 Application: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.1.1 Model: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.1.2 Handler: Process Google Maps . . . . . . . . . . . . . . . . . . 413
9.1.3 Views: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . 413
9.1.4 API Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
9.2 FedEx: Rate Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
9.2.1 Expanding the WSDL File . . . . . . . . . . . . . . . . . . . . . 416
9.2.2 FedEx: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
9.2.3 Application: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.2.4 Model: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.2.5 Views: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
9.2.6 Controller: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
9.3 PayPal Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
9.3.1 Credentials: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
9.3.2 Application: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . 431
9.3.3 Controller: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
9.3.4 Views: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
9.3.5 Application: PayPal with Oauth . . . . . . . . . . . . . . . . . 434
9.4 Legacy Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
9.4.1 Eclipse Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
9.4.2 Install the Database Driver . . . . . . . . . . . . . . . . . . . . . 443
9.4.3 Hibernate Console . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
9.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
9.6 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
10 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
10.1 Spring: Object Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
10.2 Classpath and Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
xvi Contents

10.2.1 Usual Suspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

10.2.2 What is a Package? . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3.1 Configuring MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3.2 MySql Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
10.4 Old School . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
10.4.1 Validation the Hard Way . . . . . . . . . . . . . . . . . . . . . . 456
10.4.2 Initialising Complex Elements . . . . . . . . . . . . . . . . . . . 463
10.4.3 Application: Old SchoolInitialised Complex
Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
10.5 Source Code of Complicated Controllers . . . . . . . . . . . . . . . . . 480
10.5.1 Servlet for a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
10.5.2 Controller Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
10.5.3 Restructured Controller . . . . . . . . . . . . . . . . . . . . . . . . 484
10.5.4 Spring Restructured Controller . . . . . . . . . . . . . . . . . . 485
10.5.5 Enhanced Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 486
10.5.6 Persistent Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 488
10.5.7 Complex Persistent Controller . . . . . . . . . . . . . . . . . . . 490
10.5.8 Account Path and Shopping Cart . . . . . . . . . . . . . . . . . 493

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Web Applications and Maven
1

This chapter explains how information is sent between a browser and a server. It
begins with descriptions of the request from a browser and a response from a server.
Each has a format that is determined by the Hypertext Transfer Protocol [HTTP].
Basic HTML tags are introduced next, followed by HTML forms for collecting
data. Data is easily passed from one page to another, but the data cannot be
processed without a dynamic engine like a servlet engine. Maven is introduced as a
development environment that easily incorporates a servlet engine into an appli-
cation. Using Maven, a web server can be started that hosts a web application that
can be compiled and run. The chapter explains markup languages, with a detailed
description of the Hypertext Markup Language [HTML], which sends formatted
content from the server to the browser. An important feature of HTML is its ability
to easily request additional information from the server through the use of hypertext
links. HTML forms are covered. These send data from the browser back to the
server. Information from the form must be formatted so that it can be sent over the
web. The browser and server handle encoding and decoding the data.
Simple web pages cannot process form data that is sent to them. One way to
process form data is to use a web application and a Java Server Page [JSP]. In a
JSP, the Expression Language [EL] simplifies access to the form data and can be
used to initialise the form elements with the form data that is sent to the page.
JSPs are processed by a program known as a servlet engine. The servlet engine
receives the request and response data from the web server and processes the
request from the browser. The servlet engine translates all JSPs into programs
known as servlets.
Servlets and JSPs must be run from a servlet engine. Maven has the ability to
embed a Tomcat servlet engine into the application.

© Springer Nature Switzerland AG 2021 1

T. Downey, Guide to Web Development with Java, Texts in Computer Science,
https://doi.org/10.1007/978-3-030-62274-9_1
2 1 Web Applications and Maven

1.1 Hypertext Transfer Protocol

Whenever someone accesses a web page on the Internet, two computers commu-
nicate. One computer has a software program known as a browser, the other
computer has a software program known as a web server. The browser sends a
request to the server and the server sends a response to the browser. The request
contains the name of the page that is being requested and information about the
browser that is making the request. The response contains the page that was
requested (if it is available), information about the page, and information about the
server. Figure 1.1 depicts the aspects of the request and response.
When the browser makes the request, it mentions the protocol that it is using:
HTTP/1.1. When the server sends the response, it also identifies the protocol it is
using: HTTP/1.1. A protocol is not a language; it is a set of rules that must be
followed. For instance, one rule in HTTP is that the first line of a request will
contain the type of request, the address of the page on the server and the version of
the protocol that the browser is using. Another rule is that the first line of the
response will contain the version of the protocol that the server is using, a numeric
code indicating the success of the request and a sentence describing the code.
Protocols are used in many places, not just with computers. When the leaders of
two countries meet, they must decide on a common protocol in order to commu-
nicate. Do they bow or shake hands when they meet? Do they eat with chopsticks or
silverware? It is the same situation for computers, in order for the browser and
server to communicate, they must decide on a common protocol.

Fig. 1.1 The request and response have specific formats, as specified by HTTP
1.1 Hypertext Transfer Protocol 3

1.1.1 Request Format

The request from the browser has the following format in HTTP:

a. The first line contains the type of request, the name of the requested page and
the protocol that is being used.
b. Subsequent lines are the request headers. They contain information about the
browser and the request.
c. A blank line in the request indicates the end of the request headers
d. In a POST request, additional information can be included after the blank line.

Typical information that is contained in the request headers is the brand of the
browser that is making the request, the types of content that the browser prefers, the
languages and character set that the browser prefers and the type of connection that
is being used. The names of these request headers are User-agent, Accept,
Accept-language and Accept-charset, respectively (Table 1.1).

1.1.2 Response Format

The response from the server has the following format in HTTP:

a. The first line contains the protocol being used, the status code and a brief
description of the status.
b. Subsequent lines are the response headers. They contain information about the
server and the response.
c. A blank line in the response indicates the end of the response headers.
d. In a successful response, the content of the page will be sent after the blank line.

Typical information that is contained in the response headers is the brand of the
server that is making the response, the type of the file that is being returned and the
number of characters that are in the file. The names of these response headers are
Server, Content-Type and Content-length, respectively (Table 1.2).

Table 1.1 Common request headers

User-agent Identifies the type of browser that made the request
Accept Specifies the MIME types that the browser prefers
Accept-language Indicates the user’s preferred language, if multiple versions of the
document exist
Accept-charset Indicates the user’s preferred character set. Different character sets can
display characters from different languages
4 1 Web Applications and Maven

Table 1.2 Common response headers

Server Identifies the type of server that made the response
Content-type Identifies the MIME type of the response
Content-length Contains the number of characters that are in the response

1.1.3 Content Type

The server must also identify the type of information that is being sent. This is
known as the Content Type. Different content types define text, graphics, spread-
sheets, word processors and more.
These content types are expressed as Multipurpose Internet Mail Exten-
sions [MIME] types. MIME types are used by web servers to declare the type of
content that is being sent. MIME types are used by the browser to decode the type
of content that is being received. If additional data is included with the request, the
browser uses special MIME types and additional request headers to inform the
server. The server and browser will each contain a file that has a table of MIME
types with the associated file extension for that type.
The basic structure of a MIME type is a general type, a slash and a specific type.
For example, the general type for text has several specific types, for plain text,
HTML text and style sheet text. These types are represented as text/plain, text/html
and text/css, respectively. When the server sends a file to the browser, it will also
include the MIME type for the file in the header that is sent to the browser.
MIME types are universal. All systems have agreed to use MIME types to
identify the content of a file transmitted over the web. File extensions are too
limiting for this purpose. Many different word processor programs might use the
extension .doc to identify a file. For instance, .doc might refer to an MS WORD
document or to an MS WORDPAD document. It is impossible to tell from the
extension which program actually created the program. In addition, other programs
could use the .doc extension to identify a program: for instance, WordPerfect could
also use the .doc extension. Using the extension to identify the content of the file
would be too confusing.
The most common content type on the web is HTML text, represented as the
MIME type text/html.

1.2 Markup Language

I am confident that most students have seen a markup language. I remember my

days in English composition classes: my returned papers would always have cryptic
squiggles written all over them (Fig. 1.2).
1.2 Markup Language 5

Fig. 1.2 Editors use markup to annotate text

Some of these would mean that a word was omitted (^), that two letters were
transposed (a sideways '' S ',' enclosing the transposed letters), or that a new para-
graph was needed (a backwards, double-stemmed '' P '). ' These marks were invalu-
able to the teacher who had to correct the paper because they conveyed a lot of
meaning in just a few pen strokes. Imagine if a program could accept such a paper
that is covered with markup, read the markup and generate a new version with all
the corrections made.
There are other forms of markup languages. The script of a play has a markup
language that describes the action that is proceeding while the dialog takes place.
For instance, the following is a hypothetical script for the 3 Stooges:

Moe: Oh, a wise guy, huh? <Pulls Larry’s hair>

Larry: It wasn’t me. <Hits Curly in the stomach>
Moe: What are you doing? <Tries to poke Curly in the eye>
Curly: Nyuk, nyuk, nyuk. <Places hand in front of eyes>
Moe: Ignoramus. <Bonks Curly on top of the head>

Every markup language has two parts.

a. The plain text

b. The markup, which contains additional information about the plain text.

1.2.1 Hypertext Markup Language

HTML is the markup language for the web. It is what allows the browser to display
colours, fonts, links and graphics. All markup is enclosed within the angle brack-
ets <and>. Directly adjacent to the opening bracket is the name of the tag. Addi-
tional attributes can be included after the name of the tag and before the closing
bracket.
HTML tags are intermixed with plain text. The plain textis what the viewer of a
web page will see. The HTML tags are commands to the browser for displaying the
6 1 Web Applications and Maven

text. In this example, the plain text ‘This text is strong’ is enclosed within the
HTML tags for making text look strong:

<strong> This text is strong</strong>

The viewer of the web page would not see the tags, but would see the text
rendered strongly. For most browsers, strong text is bold, and the sentence would
appear as:
This text is strong
HTML has two types of tags: singletons and paired tags.
Singletons have a limited amount of text embedded within them as attributes or
they have no text at all. Singletons only have one tag. Table 1.3 gives two examples
of singleton tags.
Paired tags are designed to contain many words and other tags. These tags have an
opening and a closing tag. The text that they control is placed between the opening and
closing tags. The closing tag is the same as the opening tag, except the tag name is
preceded by a forward slash /. Table 1.4 gives four examples of paired tags.

Table 1.3 Examples of singletons

Tag Explanation
<br> Insert a line break into the document
<input> Insert a form element into the document. This is a tag that has additional
attributes, which will be explained below

Table 1.4 Examples of paired tags

Tag Explanation
<strong> strong </strong> Typically, the enclosed text is rendered in a thicker
font
<ins> inserted </ins> Typically, the enclosed text is rendered with an
underline
<em> emphasised </em> Typically, the enclosed text is rendered in an italic font
<p> paragraph </p> The enclosed text will have at least one empty line
preceding it

Table 1.5 Two essential form element types

Type Example
text <input type=''text'' name=''hobby'' value=''''>
The value attribute is the text that appears within the element when the page is
loaded
submit <input type=''submit'' name=''nextButton'' value=''Next''>
The value attribute is the text that appears on the button in the browser
1.2 Markup Language 7

1.2.2 Basic Tags for a Web Page

We are very sophisticated listeners. We can understand many different accents. We

can understand when words are slurred together. However, if we were to write out
the phonetic transcription of our statements, they would be unreadable. There is a
correct way to write our language, but a sophisticated listener can detect and correct
many errors in pronunciation.
For instance, most English speakers would understand me if I asked the question
Jeet yet?
In print, it is incomprehensible. A proper response might be
No, joo?
Or,
Yeah, I ate.
As we become more proficient in a language, we are able to understand it, even
when people do not enunciate clearly.
In the same way, all markup languages have a format that must be followed in
order to be correct. Some language interpreters are more sophisticated than others
and can detect and correct mistakes in the written format. For example, a paragraph
tag in HTML is a paired tag and most browsers will render paragraphs correctly,
even if the closing paragraph tag is missing. The reason is that paragraph tags
cannot be nested one inside the other, so when a browser encounters a new <p> tag
before seeing the closing </p> for the current paragraph, the browser inserts a
closing </p> and then begins the new paragraph. However, if an XML interpreter
read the same HTML file with the missing </p> tag, the interpreter would report
an error instead of continuing to parse the file. It is better to code all the tags that are
defined for a well-formed HTML document, than to rely on browsers to fill in the
missing details.
Standard Tags
The HTML specification defines a group of standard tags that control the structure
of the HTML document. These three tags contain all the information for the page.

<html> html code </html>

The html tags enclose all the other tags and text in the document. It only contains
the following two sections.

<head> browser command tags </head>

The head tags enclose tags that inform the browser about how to display the
entire page. These control how the page appears in the browser, but do not
8 1 Web Applications and Maven

contain any content for the page. This paired tag belongs within the paired html
tags.
<body> body tags </body>

The body tags contain all the plain text and HTML tags that are to be displayed
in the browser window. This paired tag belongs within the paired html tags.
While the body section contains the normal HTML tags discussed in this chapter,
like strong and em, the head section contains special markup tags that indicate
how the browser should display the page. The meta and title tags belong in the head
section.

<title> title text </title>

The title tags enclose the text that will display in the title bar of the browser
window.

<meta charset = ''UTF-8''>

The meta tag is a singleton that indicates extra information for the browser. This
tag can be repeated to include different information for the browser. A standard
page should include a meta tag with charset='' utf-8 '.' This indicates the character
set for the language that is being used to display the page.
HTML Validation
The WWW Consortium [W3C] publishes the HTML standard and provides tools for
HTML validation that will test that a page has the correct HTML structure. In order
to comply with the HTML specification, all web pages should have the following
structure.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>Simple Page</title>
</head>
<body>
<p>
This is a <em>simple</em> web page.
</body>
</html>

a. The DOCTYPE defines the type of markup that is being used. It precedes the
html tag because it defines which version of HTML is being used.
1.2 Markup Language 9

b. All the tags and plaintext for the page are contained within the paired html
tags.

i. Place a head section within the paired html tags.

A. Place a paired title tag within the head section.

B. Place a singleton meta tag for the character set within the head section.

ii. Place a body section within the paired html tags.

c. The DOCTYPE and meta tags are required if the page is to be validated by W3C
for correct HTML syntax. Go to https://www.w3.org to access the HTML
validator.

There is no excuse for a web page to contain errors. With the use of the vali-
dation tool at https://www.w3.org, all HTML pages should be validated to ensure
that they contain all the basic tags.
Layout versus Style
Two types of information are contained in each HTML page: layout and style. The
basic layout is covered in this chapter; advanced layout and style are covered in
Chap. 7. Style information contains things like the colours and font for the page.
The recommended way to handle style and layout is to place all the layout tags in
the HTML page and to place all the style information in a separate file, called a
style sheet. For the interested student, the HTML and style information from
Chap. 7 can be read at any time.
Hypertext Markup Language Five [HTML5] is the latest version of the HTML
standard. In the previous versions, tags could specify the style of a page. In the new
version, those tags have been deprecated. In order to validate that a page conforms
to version 5, the tags that specify specific style cannot be used.
In previous versions of the HTML standard, different DOCTYPE statements
could be used for HTML pages: strict and transitional. The strict one was the
recommended one, since it enforced the rule that all style information be contained
in a separate file. Version five has no choices for the DOCTYPE: all pages must use
strict HTML. All pages for this book will use the new DOCTYPE for HTML5.

<!DOCTYPE HTML>

Word Wrap and White Space

Most of us type text in a word processor and let the program determine where the
line breaks belong. This is known as word wrap. The only time that we are required
to hit the enter key is when we want to start a new paragraph.
Browsers will use word wrap to display text, even if the enter key is pressed.
Browsers will treat a new line character, a tab character and multiple spaces as a
10 1 Web Applications and Maven

single space. In order to insert a new line, tab or multiple spaces in an HTML page,
markup must be used: if it is not plain text, then it must be placed in markup.
Browsers take word wrap one step further. Browsers will compress all con-
secutive white space characters into a single space character. The common white
space characters are the space, the tab and the new line character. If five spaces start
a line, they will be compressed into one space.
The following listing contains a web page that has a poem.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>A Poem</title>
</head>
<body>
Roses are red
Violets are blue
This could be a poem
But not a haiku
A haiku has a fixed structure. The first line has five
syllables, the second line has seven syllables and the
third line has five syllables. Therefore, the previous
poem cannot be a haiku.
</body>
</html>

Even though the poem has four lines, the poem will appear as one line in the
browser. This is because no markup was added to indicate that one line has ended
and another line should begin. The browser will wrap to a new line if the poem
would extend beyond the right margin of the browser.

Try It
https://bytesizebook.com/guide-boot/ch1/poem.html

Fig. 1.3 How the poem will appear in the browser

1.2 Markup Language 11

Open the link in a browser and view the poem (Fig. 1.3). Resize the window and
note how the browser will break the text in different places. If the window is large
enough, the entire page will be displayed on one line.
Line Breaks
Two of the tags that can start a new line are <br> and <p>. The <br> tag is short
for breakand starts a new line directly under the current line. It is a singleton tag, so
it does not have a closing tag. The <p> tag is short for paragraphand skips at least
one line and then starts a new line. It is a paired tag, so it is closed with
the </p> tag.
As was mentioned above, browsers have the ability to interpret HTML even if
some tags are missing. The closing paragraph tag is such a tag. It is not possible to
nest one paragraph inside another, so if the browser encounters two paragraph tags
without closing tags, as in <p> One <p> Two, then it will interpret this as <
p> One </p> <p> Two </p>. Even the validators at w3.org will accept HTML
that does not have closing paragraph tags.
Listing 1.1 contains the HTML page for the poem, using markup for line breaks
and paragraph tags.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>A Poem</title>
</head>
<body>
<p>
Roses are red<br>
Violets are blue<br>
This could be a poem<br>
But not a haiku<br>
<p>
A haiku has a fixed structure. The first line has five
syllables, the second line has seven syllables and the
third line has five syllables. Therefore, the previous
poem cannot be a haiku.
</body>
</html>

Listing 1.1 A four-line poem with markup for line breaks HTML
12 1 Web Applications and Maven

Fig. 1.4 How the formatted poem will appear in the browser

When displayed in a browser, each line of the poem will appear on a separate line.
The paragraph that follows the poem will still be displayed using word wrap, since
no line breaks were inserted into it.

Try It
https://bytesizebook.com/guide-boot/ch1/poem_formatted.html
Open the page in a browser to see how it looks (Fig. 1.4). Resize the window and
note that the poem displays on four lines, unless the window is very small.
Most browsers have an option for viewing the actual HTML that was sent from
the server. If you view the source, you will see the same HTML code that was
displayed in Listing 1.1.

1.2.3 What is the HT in HTML?

The HT in HTMLstands for Hypertext. Hypertext is the ability to click on a link in

one page and have another page open. If you have ever clicked on a link in a web
page to open another page, then you have used a hypertext link.
A hypertext linkhas two parts: the location of the new page and the link text that
appears in the browser. The location of the pages is specified as a Uniform Resource
Locator [URL], which contains four parts: protocol, server, path and name. The
protocol could be http, ftp, telnet or others. The protocol is followed by a colon and
two slashes (://). After the protocol is the server. The server is followed by a slash
and the path of the directory that contains the resource. The name of the resource
follows the path. protocol://server/path/name.
The URL of the hypertext link is not displayed in the web page, but it is
associated with the underlined text on the web page. Another way to say this is that
the URL has to be included in the markup, since it does not appear as plain text.
1.2 Markup Language 13

Anchor Tag
The tag for a hypertext link is the paired tag <a> , which is short for anchor.

<a href=''hidden_URL_of_a_file''>
Visible text in browser
</a>

Note that the text that is visible in the browser is not inside a tag, but that the
URL of the file is. This is an example of a tag that has additional information stored
in it. The additional information is called an attribute. The URL of the page is
stored in an attribute named href. Attributes in HTML tags provide extra infor-
mation that is not visible in the page in the browser.
This agrees with the basic definition of HTML as having plain text and tags. The
tags contain extra information about how to display the plain text. In this case,
when the user clicks on the plain text, the browser will read the URL from the href
and request that page from the server.
It may not seem apparent why this tag is called an anchor tag. An anchor tag in
HTML is like the anchor of a ship. The anchor for a ship connects two parts: the
ship, which is visible from the surface of the water, and the bottom of the ocean.
When the anchor is in use, it is not in the ship, it is in the bottom of the ocean. The
anchor HTML tag connects the visible text in the browser to the physical location
of a file.
Absolute and Relative References
The href attribute of the anchor tag contains the URL of the destination page. When
using the anchor tag to reference other pages on the web, you must know the
complete URL of the resource in order to create a link to it. However, depending on
where the resource is located, you may be able to simplify the address of the page
by using a relative reference.
Absolute
If the resource is not on the same server, then you must specify the entire URL,
starting with http://. This is known as an absolute reference.

<a href=''https://server.com/path/page.html''>
Some Page Somewhere on the web
</a>

Relative to the Root

If the resource is on the same server, but is not descended from the current
directory, then include the full path from the document root, starting with a /.
14 1 Web Applications and Maven

<a href=''/path/from/root/page.html''>
Some Page on the Current Server
</a>

In the Current Folder

If the resource is in the same directory as the HTML page that references it, then
only include the file name, not the server or the directory.

<a href=''page.html''>
Some Page
</a>

Descended from the Current Folder

If the resource is in a subdirectory of the directory where the HTML page that
references it is located, then include the name of the subdirectory and the file name.

<a href=''subdir/of/current/dir/page.html''>
Some Page in Some Subdir
</a>

References have three types.

a. Absolute
b. Relative from document root
c. Relative from current directory.

Just a few rules determine the kind of reference.

a. If the URL begins with a protocol (like http://, ftp://, or telnet://), then it is an
absolute reference to that location.
b. If the URL begins with a /, then it is a relative reference from the document root
of the current server.
c. In all other cases, the URL is a relative reference from the current directory.

Calculating Relative References

To calculate a relative reference, start with the absolute reference of the current
page and the absolute reference to the new page. For instance, suppose that the
current page and the next page are referenced as
https://www.bytesizebook.com/guide-boot/ch1/poem.html
https://www.bytesizebook.com/guide-boot/ch1/poem_formatted.html
1.2 Markup Language 15

To find the relative reference, start from the protocol in each reference and
remove all common parts. The protocol and server are the same, so remove them.
The entire path is the same, so remove it. For these two references, the common
parts are https://www.bytesizebook.com/guide-boot/ch1/, so the relative reference
is poem_formatted.html.
Consider these two references:
https://www.bytesizebook.com/guide-boot/ch1/poem.html
https://www.bytesizebook.com/guide-boot/ch1/OnePage/First.jsp
To calculate the reference, remove the protocol and server, since they are the
same. Remove the path, since the path of the first is contained in the path to the
second. The relative reference is OnePage/First.jsp.
Consider the same references, but in a different order:
https://www.bytesizebook.com/guide-boot/ch1/OnePage/First.jsp
https://www.bytesizebook.com/guide-boot/ch1/poem.html
The protocol and server can be removed, but not the path. The path of the first
reference is not contained completely within the path to the second. The reference
can be created two ways.

a. Include the path in the relative reference: /guide-boot/ch1/poem.html

b. Use the special symbol .. to indicate to go up one folder in the path:../
poem.html.

To improve portability, it is better to avoid adding the web app folder to ref-
erences. In this case, it is better to use the second technique.
At some point you will need to decide which is more important, portability or
legibility. Consider these references:
https://www.bytesizebook.com/guide-boot/ch1/OnePage/First.jsp
https://www.bytesizebook.com/guide-boot/ch2/jspController/Controller.jsp
The two possible relative references are

a. /guide-boot/ch2/jspController.jsp
b. ../../ch2/jspController.jsp.

When the relative references become more complicated, it becomes a personal

preference for deciding which reference to use.
16 1 Web Applications and Maven

Fig. 1.5 An entry form from

FIU

1.3 HTML Forms

If you have ever logged into a web site, then you have used an HTML form to
supply your username and password. A form will have places where a user can
enter data. These are known as form elements and can be for one line of text, several
lines of text, drop down lists and buttons. The form in Fig. 1.5, which is from
Florida International University, uses several form elements for lines of text and a
button for submitting the data to the server.
1.3 HTML Forms 17

1.3.1 Form Elements

The form and the form elements are defined using HTML tags. The opening form
tag is <form> and the closing tag is </form>. Plain text, other HTML tags and
form element tags can be placed between the opening and closing form tags. HTML
has many form elements, but only two of them will be introduced now. Table 1.5
defines the two essential form elements: text and submit. Additional form elements
are covered in Chap. 7.
Each of these has the same tag name (input) and attributes (type, name, value).

a. The HTML tag name is input.

b. Many different form elements use the input tag. The type attribute identifies
which form element to display.
c. A form can include several form elements. The name attribute should be a
unique identifier for the element.
d. The value attribute stores the data that is in the element. The value that is hard
coded in the element is the value that is displayed in the browser when the
HTML page is loaded.
e. The name and value attributes identify the data being sent to the server. When
the form is submitted, the data for this element will be sent as name = value.
The value that will be sent will be the current data that is displayed in the
element.

Listing 1.2 is an example of a simple web page that has a form in it.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>First Form</title>
</head>
<body>
<form>
<p>
This is a simple HTML page that has a form in it.
<p>
Hobby: <input type=''text'' name=''hobby''
value=''''>
<input type=''submit'' name=''confirmButton''
value=''Confirm''>
</form>
</body>
</html>
18 1 Web Applications and Maven

Fig. 1.6 A form with a text box and a submit button

Listing 1.2 A web page with a form

The form has an input element of type text with a name of hobby and an input
element of type submit with a name of confirmButton. The name that appears on the
button is Confirm. Note that HTML tags, plain text and form elements are included
between the opening and closing form tags.

Try It
https://bytesizebook.com/guide-boot/ch1/OnePage/SimpleForm.html
The page will display a text box and a submit button (Fig. 1.6). Open the page in a
browser, enter some data in the text box and submit the form.

1.3.2 Representing Data

In a two-dimensional world, it is very easy to create lists of data. For example,

Table 1.6 displays a list of colour preferences in a table.
How would these be written in a one-dimensional world? In other words, how
would all of this data be combined into one string of text?
In addition to the data that is in the table, the structure of the table would also need
to be stored in the string. This table has four rows and two columns. There would
need to be a way to indicate the end of one row and the start of the next. There would
need to be a way to indicate the end of one column and the start of the next.
One technique for data formatting is to choose special characters to represent the
end of a row and the end of a column. It doesn’t matter which characters are used,
as long as they are different. It is also helpful if the characters that are chosen are not
common characters. For example, the ampersand and equal sign could be used.

Table 1.6 A table of colour foreground black

preferences
background white
border red
link blue
1.3 HTML Forms 19

a. & separates rows containing name=value pairs.

b. = separates the two columns in a row, name from value.

Using this technique, the above list could be represented as a string. The
structure of the table is embedded in the string with the addition of special
characters.

foreground=black&background=white&border=red&link=blue

1.3.3 Transmitting Data Over the Web

When the user activates a submit button on a form, the data in the form elements is
sent to the server. The default destination on the server is the URL of the current
page. All the data in the form elements is placed into one string that is sent to the
server. This string is known as the query string. The data from the form is placed
into the query string as name=value pairs.

a. Each input element of type text or submit with a name attribute will have its data
added to the query string as a name=value pair.
b. If many name=value pairs are in the query string, then they are separated by an
ampersand, &.
c. If a form element does not have a name attribute, then it is not sent to the server.
d. In the default case, the query string is sent to the server by appending it to the
end of the URL. A question mark separates the end of the URL from the start of
the query string.

If the user entered skiing in the hobby element and clicked the Confirm button of
the form, then the query string that is sent from the browser would look like the
following string.

hobby=skiing&confirmButton=Confirm

A question mark and the query string are appended to the URL. The request sent
to the browser would contain the following URL.
https://store.com/buy.htm?hobby=skiing&confirmButton=Confirm
If the user had entered the hobby as water skiing, then the query string would
appear as the following string.

hobby=water+skiing&confirmButton=Confirm

Note that the space between water and skiing has been replaced by a plus sign.
A space would break the URL in two. This is the first example of a character that
cannot be represented normally in a URL; there will be other characters that must
20 1 Web Applications and Maven

Fig. 1.7 After entering data and clicking the button, the query string will appear in the URL

be translated before they can be entered in a query string. Please be aware that the
browser does this translation automatically and that the server will do the reverse
translation automatically. This is known as URL encoding and URL decoding.

Try It
https://bytesizebook.com/guide-boot/ch1/OnePage/SimpleForm.html
Open the form, enter a hobby and click the Confirm button. The same page will
redisplay, but the query string will be appended to the URL (Fig. 1.7).
Many first time observers will think that nothing is happening when the submit
button on the form is clicked, except that the value that was entered into the text
box has disappeared. In reality, a new request for the same page was made to the
server with the query string, containing the data from the form appended to the
URL of the request. A complete request was made by the browser; a complete
response was sent by the server.

1.4 Web Application

A web application consists of a required directory structure. Additional files and

directories can be added to a web application, but the directory structure is the same
for all web applications.

1.4.1 Directory Structure

The root directory can have any name, like FirstApp, but the subdirectories must
have the names WEB-INF, lib and classes as shown in Fig. 1.8.
The root directory (i.e. FirstApp) of the web application is the location for public
HTML files, like index.html. The WEB-INF directory is not visible from the web.
1.4 Web Application 21

Fig. 1.8 A web application

has a specific directory
structure

The lib directory is the location for features that extend the servlet engine by
including Java Archive [JAR] files. JAR files are actually zip archives with the
extension .jar that can be read by the Java Virtual Machine [JVM]. Typically, a
developer who wants to add a feature to the servlet engine will package all the
necessary class files in a JAR. Then, anyone who wants to incorporate the new
feature into the servlet engine only has to place the JAR into a specific directory in
the web application where the servlet engine can find it. The classes directory
contains the Java classes that you write for your web application.
An optional file is the web.xml file, which traditionally initialised the web
application. In recent years, emphasis has moved away from the web.xml file and is
focused on Java to initialise the web application. The file can still initialise a web
application, but its use will be avoided in this book.
An optional directory is named META-INF. It contains additional configuration
details and is located in the root directory at the same level as the WEB-INF
directory.
The root directory is visible directly from the Internet with the exception of the
WEB-INF and META-INF directories. Public HTML files are placed in the root of
the web application. Any file that is placed in the root folder can be accessed from
the web.
web.xml
The traditional configuration file for the web application is named web.xml and
belongs in the WEB-INF directory. It can contain XML that defines special features
for the web application, such as initialisation parameters and security access roles.
XML is similar to HTML, but it has no predefined tags. Each application defines its
own tags.
The web application structure is defined in the Java Servlet specification. Since
version 3.0, many of the tags that were normally in the web.xml file can be replaced
with Java annotations. One of goals of Spring Boot is to use the new annotations to
simplify web application configuration and avoid adding configuration to the web.
xml file.
The latest versions of popular IDEs, like NetBeans and Eclipse, do not include
the web.xml file by default. It is assumed that all necessary configuration infor-
mation can be implemented using annotations.
22 1 Web Applications and Maven

1.5 Maven

Web applications are hosted in servlet engines. Each servlet engine will have a
special location for web applications. For the Tomcat servlet engine, web appli-
cations should be located in a directory named webapps. For other servlet engines,
check the documentation to determine where web applications should be placed.
NetBeans and Eclipse are Java IDEs for Java and contain development envi-
ronments that support servlet engines and run web applications. All web applica-
tions in each IDE will automatically be added to the correct location for the servlet
engine.
Instead of choosing one IDE and learning its idiosyncrasies, this book will use
Maven. Projects created using maven are recognized by most IDEs. While IDEs
may have specialized commands for running an application, they also support using
Maven commands to run a Maven project.
Maven uses a common structure for the location of project files, regardless of the
type of project. Maven has a command named package that will create the final
version of the project, according to the type of project. The advantage of Maven is
that all projects have a common directory and file structure, making it easier for a
developer to concentrate on the implementation of the application and not on the
structure of an application. Maven allows a developer to learn one set of commands
for developing a project, without having to learn the details of multiple IDEs.

1.5.1 Maven Introduction

Creating applications that require multiple JAR files can be difficult, because of all
the dependencies between JAR files. A JAR file might be required for compiling,
while additional JAR files are needed at run time. Finding all the relevant JAR files
and ensuring that are in the application is a time-consuming task.
Maven is a tool that facilitates adding JAR files to an application. Maven
maintains a registry of JAR files, so it is easy to find a file. Maven records the
dependencies of JAR files and adds all the related JAR files to the library. As time
progresses, JAR files are updated. Maven makes it easy to upgrade the JAR files in
an application.
Table 1.7 contains common terminology that is useful when developing a project
with Maven.

1.5.2 Maven Web Application

Typically, a new Maven project is created from an archetype. Since this book deals
with web applications, the first Maven project will be based on the webapp-javaee7
archetype. An archetype is defined by its Group ID, Artifact ID, and Version. All
1.5 Maven 23

Table 1.7 Maven terminology

Archetype An archetype contains the base files for a standard application type. It is used to
build a new project from a starting point of existing files, instead of creating all
the files from scratch. The idea of an archetype is to allow a developer to start
writing application specific code sooner
Dependency The files of an archetype are commonly packaged in a JAR file. The new
project depends on these JAR files, so they are called dependencies. When
starting a project from an archetype, the required dependencies will be
downloaded from a central repository automatically. The downloaded JAR
files may have additional dependencies. All additional dependencies will be
downloaded as needed
Plugin Most dependencies are needed to run the project, while some dependencies are
needed to build the project. The ones required for building are known as
plugins. For example, testing an application is not needed in the final package
of the application, it is only needed while developing the project. The testing
dependency is included in the application as a plugin
Lifecycle Maven processes many phases when building and distributing a project. Some
of these phases are initialize, compile, test, package, verify, install, and deploy,
among others. Taken together, these phases are know as a lifecycle
Goal Goals are commands to be used in Maven. Maven has some built-in goals and
each dependency defines its own goals. For example, Maven has goals for the
phases in its lifecycle, like compile, test, package, install and deploy, among
others
Group ID A dependency has a top-level name, like a URL, such as org.apache.tomcat.
embed or javax.servlet. The group might contain many dependencies
Artifact ID Within a group, each dependency has a unique identifier. The ID of the group
along with the ID of the artifact uniquely identify the dependency. It is similar
to a package name and a class name in Java in that both are needed to identify a
class
Version Over time, dependencies are updated. Sometimes the update is not backwards
compatible. As such, all the old versions are kept and the new dependency is
added with a new version number. Even a very old project that uses many
outdated dependencies will run, since it can still access the old dependencies
for the time when it was created
pom.xml The pom file is the configuration file for Maven. Using XML, it contains all the
top-level dependencies requested for the application. Additional dependencies
for the top-level dependencies will be added to the application, but not to the
pom file. A new dependency can be added to the file by using the standard
XML syntax and include the Group Id, Artifact Id, and Version for the
dependency. The central Maven repository is a good resource for finding the
information on many artifacts

Table 1.8 Coordinates for Group ID org.codehaus.mojo.archetypes

the Maven webapp archetype
Artifact ID webapp-javaee7
Version 1.1
24 1 Web Applications and Maven

three together are know as the coordinates for the artifact. Table 1.8 lists the
coordinates for the maven webapp archetype.
Maven can run from the command line or from inside a popular IDE. Most IDEs
have an option to create a Maven project, so the focus will be on the Maven
commands and not the IDE commands. The Maven commands can always be run
from the command line. Most IDEs will have the ability to run a Maven command.

1.5.3 Maven from the Command Line

This section on running Maven from the command line shows that Maven is
independent of any IDE. The commands that are used by Maven at the command
line are the same commands that are used by an IDE to execute Maven goals. It is
instructive to see how Maven works on its own, independent of any other frame-
works. Download Maven from https://maven.apache.org.
From the command line, create a new web application by running maven with
the maven-archetype-webapp archetype. The parameters to the generate command
start with -D. The first three parameters are used to identify the created webapp, and
they can be set to any values. The last parameter specifies the archetype for creating
the application.

$ mvn archetype:generate
-DgroupId=org.bytesizebook.com.guide.boot\
-DartifactId=basic-webapp\
-DpackageName=com.bytesizebook \
-DarchetypeArtifactId=maven-archetype-webapp

The archetype is simple. It does not create a lot of folders and files. All Maven
projects have a pom.xml file that defines the dependencies for the project. The
common location for source files is src/main. The archetype created the java
and webapp folders. Figure 1.9 shows the directory structure of the web
application.

Fig. 1.9 Directory structure

a basic webapp
1.5 Maven 25

With newer versions of the web application standard, only the webapp folder is
created containing an index.html file. The index file is the default page that appears
when the web application is started. It usually contains hypertext links to other files
available in the web application.
Maven uses the same basic structure for all the different types of applications it
creates. The directory structure is not the same as the directory structure of a web
application. When Maven executes the package goal, it will create a WAR file that
contains the required directory structure for a web application.

$ cd basic-webapp
$ mvn package
...
[INFO] Packaging webapp
[INFO] Assembling webapp [basic-webapp]
[INFO] Processing war project
[INFO] Copying webapp resources
[INFO] Webapp assembled in [17 msecs]
[INFO] Building war: /
repos/basic-webapp/target/basic-webapp-1.0-SNAPSHOT.war
[INFO] - - - - - - - - - – - - - - - - - - - - - - - - – - - - - - - - - - - - - - - - - - - - - -
---------
[INFO] BUILD SUCCESS
[INFO] - - - - - - - - - – - - - - - - - - - - - - - - – - - - - - - - - - - - - - - - - - - - - -
--------
[INFO] Total time: 1.216 s
[INFO] - - - - - - - - - – - - - - - - - - - - - - - - – - - - - - - - - - - - - - - - - - - - - -
--------

Figure 1.10 shows the contents of the WAR file and the standard structure of a
web application. It is similar to Fig. 1.8, except it is missing the lib folder, because
no additional JAR files have been added to the project.
The pom file contains all the top-level dependencies for the application.
Table 1.9 lists the dependencies added by the webapp archetype.

Fig. 1.10 Directory structure

of webapp WAR
26 1 Web Applications and Maven

Table 1.9 Dependencies in basic Webapp

Artifact Id Description
javaee-web-api Dependency that adds the ability to create servlets
maven-compiler-plugin Plugin that adds the ability to compile code
maven-war-plugin Plugin that adds the ability to generate WAR files
maven-dependency-plugin Adds the ability to add additional dependencies

1.5.4 Maven in an IDE

While it is instructive to understand that Maven is a stand-alone tool, most

developer’s prefer to use an IDE instead of working from the command line.
Popular IDEs typically have options to create a Maven project from an archetype
and to open an existing Maven project. They also have the ability to run Maven
goals on a project.
The steps in the previous section could all have been done directly in an IDE.
For example, these steps could be used in NetBeans. Other IDEs would have
similar steps.

a. Open the wizard to create a new Maven project from a webapp archetype.
b. In the wizard, specify the same coordinates for the webapp-javaee7 archetype
that were used above. This is easier in the IDE since an artifact can be searched
by Id and the remaining coordinates are supplied.
c. In the wizard, enter the coordinates for the new project. Create the project.
d. Once the project is created, right-click on the project name in the project win-
dow and find the Run Maven menu. Select the sub-menu for Goals and type
package. This will create the WAR file for the application.

Each IDE has different options for running applications. The feature set for each
IDE is different from other IDEs. Choose one that you like, they all run Maven
projects.

1.5.5 Maven: Adding A Servlet Engine

A servlet engine is needed in order to process dynamic content. A popular servlet

engine is Tomcat, which is an Apache project. Maven has a plugin for adding the
Tomcat servlet engine to an application. By adding this plugin to the pom file, the
application can start its own Tomcat engine and display dynamic content. The
default port for Tomcat is 8080, which can be changed by adding a configuration
section to the plugin.

<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
1.5 Maven 27

<version>2.2</version>
<configuration>
<port>8282</port>
</configuration>
</plugin>

Run the install command again and then issue the tomcat7:run com-
mand. Perform these actions either from the command line or from an IDE.

$ mvn install
$ mvn tomcat7:run
...
[INFO] Running war on https://localhost:8282/basic-webapp
[INFO] Using existing Tomcat server configuration
[INFO] create webapp with contextPath: /basic-webapp
Jun 14, 2020 2:27:45 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [''http-bio-8282'']
Jun 14, 2020 2:27:45 PM org.apache.catalina.core.StandardService
startInternal
INFO: Starting service Tomcat
Jun 14, 2020 2:27:45 PM org.apache.catalina.core.StandardEngine
startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.47
Jun 14, 2020 2:27:46 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [''http-bio-8282'']

The output of the command lists the URL for application. Figure 1.11 shows the
welcome page displayed in a browser. The host is localhost, indicating that the
tomcat server is running on the current machine. The port is the same as the one
listed in the configuration section of the plugin.
This is a web application with an embedded servlet engine. When run, it serves
the files that it has. The examples presented so far in this book could be added to the
web application and could be viewed from a browser. Figure 1.12 shows the
location of the current files in the application.

Fig. 1.11 Basic webapp welcome page

28 1 Web Applications and Maven

Fig. 1.12 Location of

current files in application

1.6 Processing Form Data

If the data from a form is sent to a simple HTML page, then the data that was sent
from the browser cannot be retrieved. In order to process the data, the page should
be a JSP or a Servlet in a web application hosted on a servlet engine.

1.6.1 JSP

A Java Server Page [JSP] contains HTML tags and plain text, just like a regular
web page. In addition, a JSP can contain Java code that is executed when the page
is displayed. As long as it is contained in a web application hosted in a servlet
engine, a JSP will be able to process the form data sent to it.
JSP Location
For now, the location of JSPs will be in the root directory of the web application,
not in the WEB-INF directory. The WEB-INF directory is not accessible directly
through a web browser. It is possible to place a JSP inside the WEB-INF directory
so that access to the JSP can be restricted, but it requires more configuration that
will be covered in a later chapter.
Accessing Form Data
Starting with the servlet specification 2.0, a language was added to JSPs that
simplifies access to objects that are available to a JSP. This language is known as
the Expression Language [EL]. EL statements start with a dollar sign and are
surrounded by curly braces.

${EL-statement}
1.6 Processing Form Data 29

The EL statement for accessing data in the query string uses the word param and
the name of the form element that contained that data.

${param.name_of_element}

Consider the query string of hobby=water+skiing. To retrieve the value of

the hobby parameter from the query string, insert ${param.hobby} anywhere
inside the JSP.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>First JSP</title>
</head>
<body>
<form>
<p>
This is a simple HTML page that has a form in it.
<p>
The hobby was received as: <strong>${param.hobby}</strong>
<p>
Hobby: <input type=''text'' name=''hobby''
value=''''>
<input type=''submit'' name=''confirmButton''
value=''Confirm''>
</form>
</body>
</html>

The source code for this page looks just like the HTML page that contained the
simple form in Listing 1.2, except that it includes one instance of an EL statement,
${param.hobby}, and has the extension jsp instead of html. These changes
allow the value that is present in the query string to be displayed in the browser.
This is an example of a dynamic page. It changes appearance based upon the data
entered by the user.

Try It
https://bytesizebook.com/guide-boot/ch1/OnePage/First.jsp
Type in a hobby and click the Confirm button. The form data will be added to the
query string and sent back to the current page. Figure 1.13 shows the value that is in
the query string being displayed in the body of the JSP.
30 1 Web Applications and Maven

Fig. 1.13 The value from the query string is displayed in the page

1.6.2 Initialising Form Elements

Using the ${param.hobby} syntax, it is possible to initialise a form element with the
value that was sent to the page. The trick is to set the value attribute of the form
element with the parameter value: value=''${param.hobby}''. The value
attribute holds the data that will appear in the form element when the page is
loaded.

<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>Initialized JSP</title>
</head>
<body>
<form>
<p>
This is a simple HTML page that has a form in it.
<p>
The hobby was received as: <strong>${param.hobby}</strong>
<p>
Hobby: <input type=''text'' name=''hobby''
value=''${param.hobby}''>
<input type=''submit'' name=''confirmButton''
value=''Confirm''>
</form>
</body>
</html>
1.6 Processing Form Data 31

Try It
https://bytesizebook.com/guide-boot/ch1/OnePage/FormInitialized.jsp
Before entering a hobby in the form element, examine the source of the page in the
browser. Note that the value for the hobby element is the empty string.

<form>
<p>
This is a simple HTML page that has a form in it.
<p>
The hobby was received as: <strong></strong>
<p>
Hobby: <input type=''text'' name=''hobby''
value=''''>
<input type=''submit'' name=''confirmButton''
value=''Confirm''>
</form>

Now enter a hobby and click the Confirm button (Fig. 1.14).
Open the source of the page in the browser. You will see that the value that was
sent from the browser to the server is now hard coded in the form element. Try a
hobby that has multiple words, too.

<form>
<p>
This is a simple HTML page that has a form in it.
<p>
The hobby was received as: <strong>water skiing</strong>
<p>
Hobby: <input type=''text'' name=''hobby''
value=''water skiing''>
<input type=''submit'' name=''confirmButton''
value=''Confirm''>
</form>

Remember to use the quotes around the values. If the quotes are omitted and the
value has multiple words in it, then only the first will be placed in the element.
Never write the value as value=${param.hobby}; always include the quotes.

Try It
https://bytesizebook.com/guide-boot/ch1/OnePage/FormInitializedBad.jsp
In this example, the quotes have been omitted for the value. To see the problem,
enter more than one word in the hobby element.
32 1 Web Applications and Maven

Fig. 1.14 The input element is initialised with the value from the query string

In Fig. 1.15, you will see that the correct value is displayed in the plain text, but
that the value in the form element is incorrect. For example, if the hobby is entered
as water skiing, then the form element will only display water.
The reason becomes clear when the HTML code for the form element is viewed
in the browser:

<input type=''text'' name=''hobby'' value=water skiing>

Without the quotes around the value attribute, the browser sees the following
attributes: type, name, value and skiing. The browser doesn’t know what the skiing
attribute is, so the browser ignores it. Compare this to the correct format for the
input element:

<input type=''text'' name=''hobby'' value=''water skiing''>

Now the browser sees the correct attributes: type, name and value.

Fig. 1.15 The input element is not initialised properly for values that have multiple words
1.7 The Truth About JSPs 33

1.7 The Truth About JSPs

JSPs look like HTML pages, but they can generate dynamic content. Whenever a
page has dynamic content, a program is working in the background to create it.
HTML pages are plain text. If a JSP is not in a web application, then it is a simple
HTML page. The dynamic content cannot be processed and would be treated as
plain text.
JSPs are abstractions: they are translated into Java programs known as servlets.
The program that translates them into servlets is known as the servlet engine. It is
the task of the servlet engine to translate the JSPs into servlets and to execute them.
Servlets only contain Java code. All the plain text from the JSP has been
translated into write statements. The EL statements have been translated into
complicated Java expressions.

1.7.1 Servlet for a JSP

Listing 1.3 contains a segment of the servlet that was created by the servlet engine
for the last page. The contents of the page can be seen in the out.write state-
ments. For the complete listing of the servlet look in the appendix.

...
out.write(''<!DOCTYPE HTML>\n'');
out.write(''<html>\n'');
out.write('' <head>\n'');
out.write('' <meta charset=’utf-8’>\n'');
out.write('' <title>Initialized JSP</title>\n'');
out.write('' </head>\n'');
out.write('' <body>\n'');
out.write('' <form>\n'');
out.write('' <p>\n'');
out.write('' This is a simple HTML page that ''
+ vhas a form in it.\n'');
out.write('' <p>\n'');
out.write(v The hobby was received as: <strong>'');
out.write((String) org.apache.jasper.runtime.
PageContextImpl.proprietaryEvaluate(
''${param.hobby}'', String.class,
(PageContext)_jspx_page_context, null, false));
out.write(''</strong>\n'');
out.write('' <p>\n'');
out.write('' Hobby: <input type=’text’ name=’hobby’ \n'');
out.write('' value='''');
out.write((String) org.apache.jasper.runtime.
34 1 Web Applications and Maven

PageContextImpl.proprietaryEvaluate(
''${param.hobby}'', String.class,
(PageContext)_jspx_page_context, null, false));
out.write(''’>\n'');
out.write('' <input type=’submit’ name=’confirmButton’ \n'');
out.write('' value=’Confirm’>\n'');
out.write('' </form>\n'');
out.write('' </body>\n'');
out.write(''</html>'');
} catch (Throwable t) {
...

Listing 1.3 Code for the HTML portion of a JSP

It is actually a complicated matter to generate dynamic content. The EL statement in
the JSP is responsible for the dynamic content. In the above servlet, the actual Java
code for the EL statement of ${param.hobby} is

out.write((String) org.apache.jasper.runtime.
PageContextImpl.proprietaryEvaluate(
''${param.hobby}'', String.class,
(PageContext)_jspx_page_context, null, false));

The beauty of a JSP is that the servlet engine implements most of the details
automatically. The developer can simply write HTML statements and EL state-
ments to generate programs that can process dynamic data.

1.7.2 Handling a JSP

Web servers know how to deliver static content, but need separate programs to
handle dynamic content. Common web servers are Apache and Microsoft Internet
Information Server. Apache is the most popular web server software on the market.
If a request for a JSP is made to the web server, then the web server must send the
request to another program to complete the request. In particular, if a web page has
a form for entering data and sends that data to a JSP, then a special program known
as a servlet engine will handle the request.
A servlet engine is a program running on the server that knows how to execute
JSPs and servlets. Some popular servlet engines are Tomcat, GlassFish, and JRun.
JSP Request Process
When the user fills in data in a form and clicks a button, a request is made from the
browser to the web server (Fig. 1.16).
1.7 The Truth About JSPs 35

Fig. 1.16 The browser

makes a request to the server
for a dynamic page

The web server recognises that the extension of the request is .jsp, so it calls a
servlet engine to process the JSP. The web server administrator must configure the
web server so that it sends all .jsp files to the servlet engine (Fig. 1.17). The .jsp
extension is not magical; it could be set to any extension at all.
The web server sends the request information that it received from the browser to
the servlet engine. If this were a request for a static page, the server would send a
response to the browser; instead, the server sends the response information to the
servlet engine. The servlet engine takes this request and response information and
sends a response back to the browser (Fig. 1.18).
Putting all the steps together gives the complete picture of how a request for a
JSP is handled: the request is made; the server calls another program to handle the
request; the other program, which is known as a servlet engine, sends the response
to the browser (Fig. 1.19).
Servlet Engine Response
Inside the servlet engine, steps are followed to take the request information and
generate a response. The servlet engine must translate the JSP into a servlet, load
the servlet into memory, encapsulate the data from the browser and generate the
response.
Translating the JSP: The servlet engine must translate all JSPs into servlets. The
servlet engine will keep a copy of the translated servlet so that the engine does not
need to retranslate the JSP on every request. The servlet engine will only create the
servlet when the servlet does not exist or when the source JSP has been modified.
Loading the Servlet: A servlet is loaded into memory upon the first request made
to it after the servlet engine has been started or restarted. The servlet .class file is
stored on disk. Upon the first request to the servlet, the .class file is loaded into
memory. Once a servlet has been loaded into memory, it will remain in memory:
waiting for calls to its methods. It is not removed from memory after each request;
this enables the servlet engine to process requests faster.
Request and Response Information: The web server sends the request infor-
mation that it received from the browser to the servlet engine. The server also sends
the response information to the servlet engine. The servlet engine takes this
information and creates two objects: one that encapsulates the request information
and one that encapsulates the response information. These two objects are all that
Other documents randomly have
different content
 File.
Greek, ῥινάριον, ῥίνη, ῥινίον; Latin, lima, limula.
In compound fracture with protrusion of bone Celsus says:
‘Should any small piece of bone protrude, if it is blunt it should be
reduced to its place. If it is sharp its point should first be cut off if it
is long, and if short it should be filed. “In either case it should be
smoothed with the raspatory.”’ (Si longius est, praecidendum; si
brevius, limandum, et utrumque scalpro laevandum.)
The application of the raspatory to smooth the bone after the use of
the file shows that it must have been more of the nature of a rasp
than a file which was used for bones. Scribonius Largus speaks of a
wood file or rasp used in reducing a hart’s horn to powder (Comp.
cxli):
Ad lumbricos satis commode facit et santonica herba, quae non
viget, et cornum cervinum limatum lima lignaria.
Files were largely used in dental work. All the surgeons state that
where a tooth projects above its fellows it should be filed down;
Galen says that for this purpose he has invented an olivary pointed
file of steel: σιδήριον ἐποίησα ῥινίον πυρηνοειδές (xiv. 871).
Aetius copies Galen’s chapter word for word (II. iv. 30). Paul (VI.
xxviii) says the file (ῥινάριον) may be used to remove tartar from
teeth.
There are several files of steel in the Naples Museum which are
classed among the surgical instruments. Many Roman files of steel
which have been found in London are now in the Guildhall Museum.
Some of these have transverse edges like our own files. Other extant
specimens have coarse frets on them, like our wood rasps. Pl. XLII.
fig. 1 shows one in the Guildhall collection, which is of the rasp
variety.
 Forceps for extracting Weapons.
Greek, βελουλκόν (sc. ὄργανον).
Paul has a most interesting chapter on the extraction of weapons,
and in it he mentions a special instrument for extracting weapons,
evidently a forceps:
‘If the head of the weapon has fixed in the flesh, it is to be drawn
out with the hands, or by laying hold of the appendage which is
called the shaft, if it has not fallen off. This part is commonly made
of wood. When it has fallen off we make the extraction by means of
a tooth forceps, or a stump forceps, or a forceps for extracting
weapons (βελουλκοῦ), or any other convenient instrument. And
sometimes we make an incision in the flesh around it in the first
place, if the wound do not admit the instrument’ (VI. lxxxvii).
It is true that etymologically we are only entitled to translate
βελουλκοῦ by ‘weapon-extractor’, but its association with the other
two forceps shows pretty conclusively that a forceps is meant, and
Celsus says weapons are to be extracted with the forceps under
similar conditions. In the picture of Aeneas wounded, found in a
house at Stabiae and now in the Naples Museum, the surgeon, Iapix,
is engaged in extracting a weapon from the wound in the thigh of
the hero. The instrument he is using is a long forceps with crossed
legs (Pl. XLIV).

Periosteal Elevator for the Pericranium.

Greek, ὑποσπαθιστήρ, σπαθιστήρ.
The hypospathister was an elevator for separating the pericranium
from the calvarium. It gave the name to a formidable operation in
which it was used, viz. hypospathismus. This operation is described
by Galen, Aetius, and Paul, by the latter (VI. vi) best of all. Paul is
the only one who mentions the instrument by name. The operation
consisted in making three vertical incisions, one down each side of
the forehead and one down the centre. Next the skin was raised
along with the pericranium from the whole of the front of the
forehead with the hypospathister (ὑποσπαθιστήρ), and the vessels
lying in the raised flaps were subcutaneously divided by a knife
passed under them, with its back to the skull. The elevator by which
the pericranium was separated is called by Paul ὑποσπαθιστήρ. The
operation is mentioned by Epiphanius, a bishop of Alexandria in the
fourth century, by whom the instrument is referred to as σπαθιστήρ.

Impellent.
Greek, διωστήρ.
In his chapter on the extraction of weapons, one of the most
remarkable chapters in the whole of his works, Paul mentions an
impellent for forcing an arrow head through a part so as to extract it
at the side opposite to that by which it went in.
‘If the head of the weapon has passed to the other side and it is
found impossible to extract it by the way it entered, having divided
the parts opposite we extract it through the middle of them, either
extracting it in the manner spoken of (i. e. with forceps), or we
make an opening by means of the weapon itself, pushing it by the
shaft, or, if that has come away, by an impellent instrument
(διωστῆρος), taking care not to divide a nerve, artery, vein, or any
important part; for it would be malpractice if, in extracting the
weapon, we should do more mischief than the weapon itself had
done. If the weapon has a tang, which is ascertained by examination
with the probe, having introduced the female part of the impellent
instrument and engaged it, we push the weapon forwards, or, if it
has a socket, the male part’ (τὴν θήλειαν τοῦ διωστῆρος καθέντες
καὶ ἐναρμόσαντες ὠθήσομεν τὸ βέλος εἰ δὲ αὐλὸν τὸν ἄρρενα).
Impellents formed an important part of the armamentarium of the
surgeon, at least down to the time of Scultetus, and in his works and
in those of Albucasis and Paré there are numerous figures of these
instruments. None of these quite agree with the idea of the
instrument which one gathers from Paul’s description. It would seem
to have been a very simple affair, probably a plain rod of metal
pointed at one end and hollowed at the other, the pointed end being
introduced into the socket of an arrow where it possessed one, the
hollow end being fitted over the tip of the tang in cases where the
arrow was tanged.

Arrow Scoop.
Greek, κυαθίσκος Διοκλεῖος.
A scoop for extracting arrow heads is thus described by Celsus (VII.
v):
Latum vero telum, si conditum est, ab altera parte educi non
expedit, ne ingenti vulneri ipsi quoque ingens vulnus adiiciamus.
Evellendum est ergo genere quodam ferramenti quod Διοκλείου
κυαθίσκον Graeci vocant, quoniam auctorem Dioclem habet: quem
inter priscos maximosque medicos fuisse iam posui. Lamina, vel
ferrea vel etiam aenea, ab altero capite duos utrimque deorsum
conversos uncos habet; ab altero duplicata lateribus, leviterque
extrema in eam partem inclinata quae sinuata est, insuper ibi etiam
perforata est. Haec iuxta telum transversa demittitur; deinde ubi ad
imum mucronem ventum est paulum torquetur, ut telum foramine
suo excipiat; quum in cavo mucro est, duo digiti subiecti partis
alterius uncis simul et ferramentum id extrahunt et telum.
‘But a broad weapon if buried should not be extracted from a
counter opening, lest to one large wound we add another; therefore
it is to be extracted with a special variety of instrument which the
Greeks call the Scoop of Diocles, since Diocles invented it. I have
already stated that he was one of the most eminent of the old
practitioners. Its blade of iron, or even of bronze, has at one end
two hooks, one at each side turned backwards. At the other end it is
folded over at the sides, and the end is slightly curved up towards
that part which is bent. Moreover in it there is a perforation. This is
introduced crosswise near the weapon, then when it comes near the
point it is twisted a little so that it receives the point in the hole.
When the weapon is in the cavity two fingers placed under the
hooks at the other end simultaneously extract both the instrument
and the weapon.’
This description seems very definite until we attempt to reconstruct
the instrument, when it becomes evident that more than one
construction may be put on some parts of it. Pl. XLV, fig. 4, shows
the instrument as conceived by me.
 CHAPTER IX

BLADDER AND GYNAECOLOGICAL

INSTRUMENTS

Catheter.
The catheter is very frequently referred to. Galen (xiv. 787) thus
describes it:
‘When urine is not passed on account of excessive dilatation of the
bladder so that it cannot contract, we draw off the urine with a
catheter. Therefore an instrument like the Roman letter S is let down
into the bladder by the urethra. A thread is passed into it which has
in its tip a little wool dipped in urine. Then it is drawn out and the
urine follows it like a guide.’
This method of preparing the catheter and the reasons for so doing
are discussed at somewhat greater length in the following selection
from Paul (VI. xix):
‘Wherefore taking a catheter proportionate to the age and sex we
prepare the instrument for use. The mode of preparation is this:
having bound a little wool round with a thread and introduced the
thread by means of a sharp rush into the pipe of the catheter, and
having cut off the projecting parts of the wool with a pair of scissors,
we put the catheter into oil. Having then placed the patient on a
convenient seat and used fomentation, if there be no contra-
indication we take the catheter and introduce it direct down to the
base of the penis, then we must draw the penis up to the umbilicus
(for at this part there is a bend in the passage), and in this position
push the instrument onwards. When in the perinaeum it approaches
the anus we must bend the penis with the instrument in it down to
its natural position, for from the perinaeum to the bladder the
passage is upwards, and we must push the instrument onwards till
we reach the cavity of the bladder. We afterwards take out the
thread fastened into the opening of the catheter, in order that the
urine, being attracted by the wool, may follow as happens in
syphons.’
It is occasionally, in cases of cancer of the prostate, of service to
adopt this proceeding to prevent the eye of the catheter from
getting blocked before the bladder is entered, but it is strange that
Galen should have fallen into the mistake of thinking that it is
necessary to set up a syphon action, as he was well aware of the
expulsive power possessed by the bladder; in fact, his explanation of
the physiology of urination is almost up to date.
Celsus gives a good description of the catheter both male and
female (VII. xxvi):
Res vero interdum cogit emoliri manu urinam, quum illa non redditur,
aut quia senectute iter eius collapsum est, aut quia calculus vel
concretum aliquid ex sanguine intus se opposuit: ac mediocris
quoque inflammatio saepe eam reddi naturaliter prohibet. Idque non
in viris tantummodo, sed in feminis quoque interdum necessarium
est. Ergo aeneae fistulae fiunt; quae ut omni corpori ampliori
minorique sufficiant, ad mares tres, ad feminas duae medico
habendae sunt; ex virilibus maxima decem et quinque digitorum,
media duodecim, minima novem, ex muliebribus maior novem,
minor sex. Incurvas vero esse eas paulum, sed magis viriles,
oportet, laevesque admodum; ac neque nimis plenas neque nimis
tenues.
There are fine specimens of the catheter, both male and female, in
the Naples Museum. The male catheter is from the ‘House of the
Physician’ in Pompeii. It is 24 cm. in length and is about the size of a
No. 11 English. It has two gentle curves, so that it closely resembles
the instrument reintroduced by Petit in the eighteenth century. See
Pl. XLV, fig. 1. A catheter of similar shape, but broken in three
pieces, was found by some workmen at Baden in the Seventies.
They were given by Dr. Wagner, of Baden, to Mr. Atkinson, M.P.,
London, and are possibly now in some English collection (Brunner,
op. cit. p. 42).
In the excavation of the Roman Military Hospital at Baden, 1893, a
fragment of a catheter was found, and is now in the possession of
M. Kellersberger. It consists of the curved part of a catheter, and it is
13 cm. long and about the size of a No. 10 English. The curve is
considerably greater than that of the Naples specimen (Un Hôpital
Militaire Romain, planche ix).
The female catheter in the Naples Museum is 0·98 m. long, and of
the same diameter as the male one. It is straight (Pl. XLV, fig. 2).

Bladder Sounds.
Had the ancients solid bladder sounds? They must have been well
aware of the characteristic grating sensation conveyed to the skilled
hand on striking a stone with a metal instrument, for we have
several references in the classics to the manœuvre of pushing back,
by means of a catheter, a stone impacted in the urethra. Rufus of
Ephesus (Περὶ λιθιώσης κύστεως) says of impacted urethral calculus:
‘Those that are stuck fast push back with the catheter if you prefer
not to do lithotomy’ (ἐρείδοντας οὖν εἰ μὴ θέλοις τέμνειν ἀπῶσαι τῷ
αὐλίσκῳ). Soranus (II. xviii) says if a stone is the cause of dystocia
we must push it out of the neck of the bladder into the bladder with
a catheter (καθετήρ). The word Rufus uses puts it beyond doubt
that a hollow tube is meant, or we might have argued that καθετήρ
did not necessarily mean a hollow tube, since Hippocrates uses it in
the sense of a uterine plug (ii. 830). Yet strange to say, the
sensation conveyed to the hand and ear on striking a stone with a
metal instrument is nowhere definitely given as a cardinal symptom
by a classical writer.
Rufus describes the symptoms of vesical calculus at length and
finishes with instructions for searching the bladder. The word he
uses (μήλωσις) at first sight seems to indicate that this was done
with a sound, but it turns out to be bimanual rectal examination only
which he describes. The use of the sound as a staff in lithotomy, or
as a dilator of a strictured urethra, was not known to the ancients,
and thus we have no evidence from the literature that a solid bougie
existed. Some instruments have come down to us, however, which
seem undoubted solid bladder sounds. There are three sounds of
bronze in the Naples Museum, which have the identical appearance
of our modern bladder sounds. It might be argued that these have
not quite the shape of the catheter described by the ancients, but
there is an instrument in the Mainz Museum against which even this
objection cannot be brought. It is a solid sound of the double
curvature described by Celsus, and is identical in shape with the
catheter from the Pompeian surgeon’s house (Pl. XLV, fig. 3).

Lithotomy Scoop.
Greek, λιθουλκός; Latin, uncus, ferramentum quo in sectione
calculus protrahitur.
Celsus thus describes the extraction of calculus through a perineal
incision by means of a lithotomy scoop:
Quum vero ea patefacta est, in conspectum calculus venit; in cuius
colore nullum discrimen est. Ipse si exiguus est, digitis ab altera
parte propelli, ab altera protrahi potest; si maior, iniiciendus a
superiore parte uncus est, eius rei causa factus. Is est ad extremum
tenuis, in semicirculi speciem retusae latitudinis; ab exteriore parte
laevis, qua corpori iungitur; ab interiore asper, qua calculum attingit.
Isque longior potius esse debet; nam brevis extrahendi vim non
habet. Ubi iniectus est in utrumque latus inclinandus est, ut appareat
an calculus teneatur; quia si apprehensus est, ille simul inclinatur.
‘When it is opened there comes into view the calculus, the colour of
which is unmistakeable. If it is small it is to be pushed by the fingers
from one side and pulled from the other. If too large the hook for
the purpose is to be put in above it. The hook is slender at the end
and flattened out in the shape of a semicircle, smooth externally
where it comes in contact with the tissues, rough internally where it
meets the calculus. The hook should be pretty long, for a short one
has no power of extraction. When it has been inserted it should be
inclined to either side, so that it may be seen whether the calculus is
caught, because if it is held it also is inclined to the side’ (VII. xxvii).
The above passage gives a very complete account of the lithotomy
scoop. The only thing it leaves undecided is the breadth. Was it a
broad, spoon-like scoop, or was it a hook-like instrument? That the
latter was the case is proved by the following passage also from
Celsus (VII. xxvi):
Nonnunquam etiam prolapsus in ipsam fistulam calculus: quia
subinde ea extenuatur non longe ab exitu inhaerescit. Eum, si fieri
potest, oportet evellere vel oriculario specillo, vel eo ferramento quo
in sectione calculus protrahitur.
‘Sometimes also a stone slips into the urethra itself and lodges near
the meatus, because at that part there is a constriction. It should if
possible be extracted either with an ear probe, or with the
instrument for the extraction of calculus in lithotomy.’
This shows that the scoop must have been quite a narrow
instrument, or it could not have passed into the urethra. It must
have had very much the same appearance as the modern
‘Ferguson’s Scoop’. We have two extant specimens of the ancient
lithotomy scoop in the Naples Museum, one of which is shown in Pl.
IV; and in the marble ex voto tablet in the Athens Museum, to which
I have already referred, there is a representation of a manubriolus
curved so as to serve as a lithotomy scoop (Pl. XLVI, fig. 2). Rufus of
Ephesus mentions this form of scalpel handle.

Lithotomy Forceps.
Was there a forceps for extracting calculus from the bladder? The
sixteenth-century translation of Aetius (IV. iv. 94) by Cornarius has
the following passage, under the treatment of calculus in the female:
Et tunc paululum supra pudendi alas, quo loco calculus occurrit
sectionem facito et per calcularium forcipem extrahito.
The original Greek of this part of Aetius has not yet been published,
but from a pretty intimate knowledge of Cornarius’s methods I have
a strong suspicion that ‘calcularium forcipem’ may be a free
translation of λιθουλκός, as in the following passage in Paul:
‘Sometimes from the pressure of the finger or fingers at the anus
the stone starts out readily at the same time as the incision is made,
without requiring extraction. But if it does not of itself start out we
must extract it with the instrument called the stone extractor’ (τοῦ
λιθουλκοῦ) (VI. lx).
Adams translates λιθουλκός by ‘forceps for extracting stone’, but this
is not quite a justifiable translation. The instruments whose names
end in -ουλκός, and which are derived from ἕλκω, are certainly in
many instances forceps, e. g. βελουλκός, a forceps for extracting
weapons, but in other cases they are as certainly not. I need only
refer to ἐμβρυουλκός, which is conclusively described as a hook for
extracting the dead foetus. Thus while it is possible that the
λιθουλκός may have been a forceps, the etymology of the word does
not entitle us to translate by any term more definite than ‘stone
extractor’. Galen (xiv. 787) uses the word λιθολάβος, which has a
more definite meaning. The majority of words compounded of
-λάβος means some variety of forceps, e. g. σαρκολάβος, tumour
vulsellum. The etymological evidence thus leaves the matter open,
with a slight balance in favour of there having been a forceps. I
should have had no hesitation in translating λιθολάβος to mean a
forceps, had it not been that Celsus evidently had no cognizance of a
stone forceps. Galen, however, lived after Celsus, and we may note
that the Arabians used such an instrument. Albucasis says that if the
stone does not start out it must be seized with a forceps or a hook,
and failing removal by these means it is to be broken up with
forceps. One forceps in the Naples Museum, from the house of the
physician, seems to be suited for the operation (Pl. XLVI, fig. 3). The
handles are short in proportion to the blades, and it seems better
suited to grasp some substance inside the bow than between the
jaws. The unfinished condition of the tips of the handles indicates
that they had been inserted into handles of wood.

Lithotrite.
Latin, ferramentum.
A sort of chisel by which a calculus was split is thus described by
Celsus:
Si quando autem is maior non videtur nisi rupta cervice extrahi
posse, findendus est; cuius repertor Ammonius ob id λιθοτόμος
cognominatus est. Id hoc modo fit: uncus iniicitur calculo sic ut facile
eum concussum quoque teneat, ne is retro revolvatur; tum
ferramentum adhibetur crassitudinis modicae, prima parte tenui, sed
retusa, quod admotum calculo, et ex altera parte ictum, eum findit.
‘If at any time it seems too large and impossible to be extracted
without splitting the cervix, it is to be split. The originator of this is
Ammonius, hence called the lithotomist. It is performed in this
manner. A scoop is put over the calculus in such a way that it easily
holds it even when struck from sliding back; then there is applied an
instrument of moderate thickness, slender at the tip, but blunt,
which being placed against the calculus and struck on the other end
splits it’ (VII. xxvi).
The above paragraph really gives us all the information we possess
about the instrument. It is evidently a slender chisel. A passage in
Aretaeus (Morb. Chron. ii. 9) is held by some to refer to lithotripsy
(digital). The reading, however, is dubious.

Rectal Speculum.
Greek, ἑδροδιαστολεύς, μικρὸν διόπτριον, κατοπτήρ.
The earliest mention of the rectal speculum is to be found in the
treatise on fistula by Hippocrates:
Ὕπτιον κατακλίνας τὸν ἄνθρωπον κατοπτῆρι κατιδὼν τὸ
διαβεβρωμένον τοῦ ἀρχοῦ.
‘Laying the patient on his back and examining the ulcerated part of
the bowel by means of the rectal speculum’ (iii. 331).
Again, a little further on, he mentions its use in the treatment of
piles; and Paul (VI. lxxviii) says:
‘With regard to blind fistulae Leonidas says: “We dilate the anus, as
we do the female vagina, with the anal or small speculum”’ (τῷ
ἑδροδιαστολεῖ (τῷ μικρῷ διοπτρίῳ λέγω) διαστεῖλαι τὴν ἕδραν ὡς
γυναικεῖον κόλπον).
There is a rectal speculum in the Naples Museum (No. 78,031). It is
a two-bladed instrument, working with a hinge in the middle. It is
O·15 m. in length, and the greatest stretch of the blades is O·07 m.
It represents an instrument used to dilate the vagina as well as the
rectum, and got its name ‘small dilator’ in contradistinction to the
other vaginal speculum, which we shall see was worked by a screw,
and was called the speculum magnum. The rectal speculum was also
called κατοπτήρ, in contradistinction to the vaginal speculum which
was called διόπτρα. In Galen’s Lexicon they are explained as follows:
Κατοπτῆρι, τῷ καλουμένῳ ἑδροδιαστολεῖ, ὥσπερ γε καὶ διόπτρα ὁ
γυναικῶν διαστολεύς.
‘The catopter, which is called the anal dilator, in the same way as the
diopter is called the female dilator.’
Pl. XLVI, fig. 1 shows one of two similar rectal specula from Pompeii
(Naples Museum).

Vaginal Speculum.
Greek, διόπτρα; Latin, speculum magnum matricis (late).
Soranus is the first author who makes mention of the speculum
specially made for the vagina. The original Greek of this chapter of
Soranus is lost, but we have a Latin translation of it preserved to us
by Moschion. The heading of this chapter in Soranus, which was No.
xxxiv, was Περὶ διοπτρισμοῦ. I shall give part of this chapter from
Moschion:
Qua Disciplina Organo aperiendae sint Mulieres.
Scio me retro ad inspiciendam altitudinem mulieris frequentius
organi mentionem fecisse quod Graecitas dioptran vocat. Et quoniam
nisi insinuata fuerit disciplina quatenus hoc ipsud fieri possit,
occurrente necessitate obstetrices facere non audent, idcirco placuit
nobis ut etiam hoc gynaeciis adderemus, ut ex rebus huic corpori
necessariis nihil dimisisse videamur. Itaque supinam iactans eam
quae inspici habet, accipies fasciam longam et in media parte eius
duobus laqueis factis, ita ut inter se cubitum unum habeant laquei
illi, duabus vero manibus mulieris missis, medietatem quae interest
cervici eius inducis. Deinde reliqua fasciae sub anquilas missa ad
manus alligabis, ita ut patefacti pedes ventri eius cohaereant. Deinde
accepto organo et uncto priapisco, quem Graeci loton dicunt, in
aliquantum ad prunas calefacere (debes), deinde sine quassatione
priapiscum inicere, susum scilicet axe posito, iubere etiam ministro
ut aperiendo organo axem torquere incipiat, ut paulatim partes ipsae
aperiantur. Cum vero post visum organo tollere volueris, ministro
iubere ut iterum axem torqueat quo organum claudi possit, ita
tamen ut cum adhuc in aliquantum patet sic auferatur, ne universa
clusura aliquas teneat et nocere incipiat.
We have also preserved by Paul a chapter by Archigenes on abscess
of the womb (VI. lxxiii), in which the different parts of the speculum
are again named, and from it also we learn that there were different
sizes of the instrument proportioned to suit different ages. The
patient having been fixed in the lithotomy position in the manner
described by Soranus:
‘The operator is to make the examination with a speculum (διόπτρα)
proportioned to the age of the patient. The person using the
speculum should measure with a probe the depth of the woman’s
vagina, lest the priapiscus of the speculum (τοῦ τῆς διόπτρας λωτοῦ)
being too long it should happen that the uterus be pressed on. If it
be ascertained that the tube is longer than the woman’s vagina,
folded compresses are to be laid on the labia in order that the
speculum may be laid on them. The priapiscus is to be introduced
while the screw (τὸν κοχλίον) is uppermost. The speculum is to be
held by the operator. The screw is to be turned by the assistant, so
that the blades of the tube (τῶν ἐμπλησμάτων τοῦ λωτοῦ) being
separated, the vagina may be expanded.’
We have little difficulty in recognizing among the instruments found
in Pompeii three of the vaginal specula referred to in these
passages. All are excellent specimens of the instrument maker’s skill.
They are in the Naples Museum. The first discovered (No. 78,030)
was found in the house of the physician at Pompeii. The blades are
at right angles to the instrument (Pl. XLVII), and when closed form a
tube the size of the thumb. On turning the screw a cross-bar forces
the two upper blades outwards, till sufficient dilation is got for
operative purposes. The diameter of the tube at its maximum of
expansion is 0·09 m. The whole instrument is 0·23 m. long. Another
instrument on a similar principle but with a quadrivalve priapiscus
was discovered in 1882 (Pl. XLIX). It is 0·315 m. long. It is now fixed
by oxidation, so that the blades cannot be moved. On turning the
screw the lower blades could be drawn downwards, at the same
time separating slightly, while the upper blades diverged also (No.
113,264 Naples Mus.). Lately a third, similar to that shown in Pl.
XLVII, has been found in Pompeii. Note that the screw in the three-
bladed instrument is a left-handed one. That in the four-bladed
instrument is right-handed. This causes right-handed motion to open
the instrument in either case. There is, however, an instrument
similar to these trivalve instruments in the museum at Athens. It
differs in having the screw right-handed (Pl. XLVIII). Mr. Bosanquet,
late of the British Institute of Archaeology at Athens, was kind
enough to procure me a photograph of this instrument, but he tells
me that there is no satisfactory account of its provenance and its
authenticity is doubtful. It seems possible that it is a copy of one of
the Naples specimens by some one who has omitted to observe that
the screw in these is left-handed.

Traction Hook for Embryo.

Greek, ἐμβρυουλκός; Latin, uncus.
Celsus has an interesting chapter on the removal of the foetus in
difficult labour. He says (VII. xxix):
Tum, si caput proximum est, demitti debet uncus undique laevis,
acuminis brevis, qui vel oculo, vel auri, vel ori, interdum etiam fronti
recte iniicitur; deinde attractus infantem educit. Neque tamen
quolibet is tempore extrahi debet. Nam, si compresso vulvae ore id
tentatum est, non emittente eo, infans abrumpitur, et unci acumen
in ipsum os vulvae delabitur; sequiturque nervorum distentio, et
ingens periculum mortis. Igitur, compressa vulva, conquiescere;
hiante, leniter trahere oportet; et per has occasiones paulatim eum
educere. Trahere autem dextra manus uncum; sinistra intus posita
infantem ipsum, simulque dirigere eum debet.
‘Then if the head presents there ought to be inserted a hook,
smooth all round, with a short point which is properly fixed in the
eye or the ear or the mouth, sometimes even in the forehead, which
being drawn on extracts the child. Nor is it to be drawn on without
regard to circumstance. For if the attempt is made with an undilated
cervix, not getting exit the foetus is broken up, and the point of the
hook catches on the cervix and inflammation follows and much
danger of death. Therefore, it is necessary with a contracted cervix
to wait quietly, with a dilated one to make gentle traction, and
during these times to extract it gradually. The right hand ought to
make the traction on the hook, the left place inside to draw the child
and at the same time to direct it.’
The following passage in Soranus shows that it was customary also
to insert a second hook opposite the first and to make traction on
both at the same time:
‘The best places for the insertion of the hooks are in head
presentations, the eyes, the occiput, and the mouth, the clavicles,
and the parts about the ribs. In footling cases the pubes, ribs, and
clavicles, are the best. Warm oil having been applied as a lubricant
the hook is to be held in the right hand; the curvature concealed in
the left hand is to be carefully introduced into the uterus, and
plunged into some of the places mentioned till it pierce right through
to the hollow part beneath. Then a second one is to be put in
opposite to it (καταπείρειν δὲ καὶ ἀντίθετον τούτῳ δεύτερον), in
order that the pulling may be straight and not one-sided’ (II. xix).
Aetius (IV. iv. 23) and Paul (VI. lxxiv) copy this.
Hippocrates (ii. 701) bids us break up the head with a cephalotribe
in such a way as not to splinter the bones, and remove the bones
with bone forceps; or, a traction hook (τῷ ἑλκυστῆρι) being inserted
near the clavicle so as to hold, make traction but not much at once,
but little by little, withdrawing and again inserting it.
There are three traction hooks from Pompeii in the Naples Museum.
One of these is given in Pl. L, fig. 1. They are of steel, with handles
of bronze. Hooks on the same principle, and differing in appearance
very little from the Pompeian hooks, are still used by veterinary
surgeons.

Decapitator.
Of transverse presentations, Celsus says:
Remedio est cervix praecisa; ut separatim utraque pars auferatur. Id
unco fit, qui, priori similis, in interiore tantum parte per totam aciem
exacuitur. Tum id agendum est ut ante caput deinde reliqua pars
auferatur.
‘The treatment is to divide the neck so that each part may be
extracted separately. This is done with a hook which, though similar
to the last, is sharpened on its inside only, along its whole border.
Then we must endeavour to bring away the head first, and then the
rest of the body.’
Decapitation has now given way before Caesarean section; but the
decapitator, little altered since the days of Celsus, still finds a place
in surgical instrument catalogues.
Paul and Aetius both mention division at the neck, but do not
describe a special instrument. A ring knife for dismembering the
foetus has already been discussed among the cutting instruments;
but this seems to be a different variety with a handle, which it is
convenient to discuss in proximity to the embryo hook. Pl. L, fig. 2
shows a knife on this principle in the Bibliothèque Nationale.

Cranioclast.
Greek, πίεστρον, ἐμβρυοθλάστης, θλάστης;
The cranioclast is mentioned by Hippocrates (ii. 701).
Σχίσαντα τὴν κεφαλὴν μαχαιρίῳ ξυμπλάσαι ἵνα μὴ θραύσῃ τῷ
πιέστρῳ καὶ τὰ ὀστέα ἕλκειν τῷ ὀστεουλκῷ.
‘Opening the head with a scalpel, break it up with the cranioclast in
such a way as not to splinter it into fragments, and remove the
bones with a bone forceps.’
The nature of the cranioclast is pretty well indicated by this passage,
and in Galen’s Lexicon we find πιέστρῳ defined as τῷ ἐμβρυοθλάστῃ
καλουμένῳ. I give drawings from Albucasis of a ‘forceps to crush the
child’s head’ (Pl. LI, fig. 3).

Cephalotribe.
Whether or not the instrument last described was used also for the
operation of cephalotripsy, or whether there was a special
instrument, we cannot say, but it is certain that the operation of
crushing the head and delivering the child without removing the
bones was practised. In Aetius (IV. iv. 23) cephalotripsy is thus
described:
‘But if the foetus be doubled on itself and cannot be straightened, if
the head is presenting, break up the bones of it without cutting the
skin. Then to some part of it fix on a traction hook and make
traction, and the legs becoming straightened out we get it away.’
Though there is an essential difference between the operations of
cephalotripsy and cranioclasie there is no essential difference
between the instruments necessary for carrying out the same, and it
is possible that the instrument used may be the same as the last.
The cephalotribe figured by Albucasis is not essentially different from
his cranioclast (see Pl. LI, fig. 4).
 Midwifery Forceps.
Had the Greeks and Romans a forceps for extracting the child alive?
Probably not. We have no mention of any such instrument by
Soranus or Paul, both accomplished obstetricians, nor can any
description of such an instrument be found in the voluminous
pseudo-Hippocratic works on women. Adams, in a note to Paul, III.
lxxvi, says that though the Roman and Greek writers do not mention
the forceps, Avicenna does so, and he says that a forceps was dug
up in the house of an obstetrix at Pompeii bearing a considerable
resemblance to the modern forceps. The only passage I have met
with in the slightest degree supporting the notion that the ancients
ever delivered the child alive with instruments is one in the pseudo-
Hippocratic treatise De Superfoetatione, where we are told that:
‘If the woman has a difficult labour, and the child delay long in the
passage and be born not easily but with difficulty and with the
mechanical aids (μηχαναῖς) of the physician, such children are of
weak vitality, and the umbilical cord should not be cut till they make
water or sneeze or cry’ (i. 465).
We are not entitled to translate μηχαναῖς by ‘instruments’, because it
may mean any mechanical aid such as a fillet, or even assistance
with the fingers of the accoucheur; but, even granting that it refers
to instruments, it might mean no more than, e. g., the embryo hooks
already described. With them, terrible as they were, the child must
frequently have been born alive, though mutilated. A child would
have had a far better chance of being born alive with them than with
the murderously toothed forceps of Albucasis (Pl. XLI, figs. 3, 4),
with which probably no child could have been born alive. As regards
the statement that Avicenna knew of the forceps, his directions are
that the fillet is to be applied, and, if that fail, the forceps is to be
put on and the child extracted with it. If that fail, the child is to be
extracted by incision, as in the case of a dead foetus. This passage,
says Adams, puts it beyond doubt that the Arabians were acquainted
with the method of extracting the child alive with the forceps.
This is, however, not quite correct. A full consideration of Avicenna’s
words seems to me to lead to the conclusion that he is describing no
more than extraction with a craniotomy forceps. If the forceps fail
the child is to be extracted by incision, as in the case of a foetus
already dead (and decomposed so that the forceps would not hold).
As regards Adams’ statement that a forceps like ours was dug up in
Pompeii one may ask, ‘Where is that forceps now?’ It is certainly not
in the Naples Museum, where all the finds from Herculaneum and
Pompeii have been stored since the excavations were commenced.
Adams has probably been misled by some notice of the ‘Pompeian
forceps’ (Pl. XLIII), which many consider adapted for removing the
cranial bones when the child’s head is broken up in cephalotripsy. It
is, however, a sequestrum forceps.

Uterine Curette.
Hippocrates (ed. Van der Linden, vol. ii, p. 394) says:
If the menses form thrombi ... we must wind the skin of a vulture or
a piece of vellum round a curette and curette the os uteri (καὶ περὶ
ξύστραν περιειλίξας γυπὸς δέρμα ἢ ὑμένα, διαξύειν τὸ στόμα τῶν
μητρέων).
ξύστρα may of course mean the strigil, and some forms of strigil,
such as the one shown in Pl. XXV, fig. 1, are not ill adapted for the
purpose.

Instrument for destroying foetus in utero.

Greek, ἐμβρυοσφάκτης; Latin, aeneum spiculum.
Apart from the destruction of the foetus in criminal abortion, which
was so common at Rome in the time of the Empire, we have
mention of an instrument for legitimately producing the death of the
foetus from humane motives before forced delivery. It is mentioned
by Tertullian in his sermon De Anima, and the passage is so
interesting that I give it in full. It is, moreover, an example of the
unexpected places in which information regarding the surgery of the
ancients crops up. Tertullian is arguing that the foetus is alive in
utero, and does not, as others hold, simply take on life in the act of
birth, and to support his conclusions he uses the following
argument:
Denique et mortui eduntur quomodo, nisi et vivi? qui autem et
mortui, nisi qui prius vivi? Atquin et in ipso adhuc utero infans
trucidatur necessaria crudelitate, quum in exitu obliquatus denegat
partum; matricida, ni moriturus. Itaque et inter arma medicorum et
organon est, quo prius patescere secreta coguntur tortili
temperamento, cum anulo cultrato, quo intus membra caeduntur
anxio arbitrio, cum hebete unco, quo totum facinus extrahitur
violento puerperio. Est etiam aeneum spiculum, quo iugulatio ipsa
dirigitur caeco latrocinio; ἐμβρυοσφάκτην appellant de infanticidii
officio, utique viventis infantis peremptorium. Hoc et Hippocrates
habuit et Asclepiades et Erasistratus et maiorum quoque prosector
Herophilus et mitior ipse Soranus, certi animal esse conceptum,
atque ita miserti infelicissimae huiusmodi infantiae, ut prius occidatur
ne viva lanietur.
‘Finally there are cases of children that are dead when they are born,
how so unless they have also lived? For who are dead unless they
have previously been alive? And yet, an infant is sometimes by an
act of necessary cruelty destroyed when yet in the womb, when
owing to an oblique presentation at birth delivery is made impossible
and the child would cause the death of the mother unless it were
doomed itself to die. And accordingly there is among the appliances
of medical men an instrument by which the private parts are dilated
with a priapiscus worked by a screw, and also a ring-knife whereby
the limbs are cut off in the womb with judicious care, and a blunt
hook by which the whole mass is extracted and a violent form of
delivery in this way effected. There is also a bronze stylet with which
a secret death is inflicted; they call it the ἐμβρυοσφάκτης (foeticide)
from its use in infanticide, as being fatal to a living infant.
Hippocrates had this (instrument), Asclepiades and Erasistratus, and
of the ancients also Herophilus the anatomist, and Soranus, a man
of gentler character. Who, being assured that a living thing had been
conceived, mercifully judged that an unfortunate infant of this sort
should be destroyed before birth to save it from being mangled
alive.’
We have here apparently a different instrument from the
embryotome, which we saw was a form of knife. This is a pointed
spike-shaped instrument. It must have had much the shape of one
of the huge bodkins in the Naples Museum (Pl. LI, fig. 1).

Apparatus for fumigating the Uterus and Vagina.

Fumigation formed an important part of the treatment of all varieties
of disease of the uterus and vagina. The notion that the uterus was
an animal within the body which could wander about on its own
initiative and which was attracted by pleasant smells and repelled by
disagreeable smells, was responsible for much of the treatment of
gynaecological diseases by the ancients. To make a fumigation,
Hippocrates directs us to take a vessel which holds about four
gallons (δύο ἑκτέας), and fit a lid to it so that no vapour can escape
from it. Pierce a hole in the lid, and into this aperture force a reed
about a cubit in length so that the vapour cannot escape along the
outside of the reed. The cover is then fixed on the vessel with clay.
Dig a hole about two feet deep and sufficiently large to receive the
vessel, and burn wood until the sides of the hole become very hot.
After this remove the wood and larger pieces of charcoal which have
most flame, but leave the ashes and cinders. When the vessel is
placed in position, and the vapour begins to issue out, if it is too hot
wait for some time; if, however, it be of the proper temperature the
reed should be introduced into the uterine orifice and the fumigation
made. Oribasius, quoting Antyllus (Coll. X. xix) varies the treatment
somewhat by placing a vessel similarly prepared underneath an
obstetrical chair, which had an opening in the seat, allowing a leaden
pipe connected with the tube of the fumigating vessel to be passed
into the vagina.
A fumigating apparatus of a more portable nature is mentioned by
Soranus (xxiii) who tells us that Strato, a pupil of Erasistratus, used
to place in a small vessel of silver or bronze, closed by a cover of tin,
herbs of various kinds, and, having adjusted a small tube to the
vessel, the mouth of the tube was placed in the vagina, and the
vessel was then gently heated. Soranus admits that severe burning
might follow this practice if unskilfully used.

Pessaries.
Greek, βάλανος, πεσσόν, πεσσός; Latin, pessum, pessus, pessulum.
Pessaries are frequently mentioned. They are usually bags filled with
medicaments and not mechanical supports. However, in ii. 824,
Hippocrates says that prolapse of the womb is to be reduced and the
half of a pomegranate is to be introduced into the vagina. Soranus
says that in prolapse Diocles was accustomed to introduce into the
vagina a pomegranate soaked in vinegar. He also says that a large
ball of wool may be introduced after reduction, and Aetius,
Oribasius, and Paul copy him.
Hippocrates (iii. 331) says that in cases of fistula in ano, after the
introduction of a medicated plug of lint, a pessary of horn is to be
inserted (βάλανον ἐνθεὶς κερατίνην). This would appear to be partly
to distend the rectum, but partly also most likely to carry
medicament, like the leaden tubes full of medicaments which were
inserted into the uterus.
A pessary of bronze was found in Pompeii (Pl. LI, fig. 2), and is
described by Ceci. It is hollow and has a plate perforated with holes
(evidently for stitching it on a band, to fix it round the body). Heister
figures a similar instrument. It is impossible to say whether this
specimen was intended for rectal or vaginal use.
 CHAPTER X

SUTURES, ETC.

Sponge.
Greek, σπόγγος; Latin, spongia.
Sponges were used for many purposes. Paul (VII. iii) says they
should be fresh and still preserve the smell of the sea. They were
applied with water, wine, or oxycrate to agglutinate wounds, and
also soaked in asphalt and set fire to and applied to wounds to stop
haemorrhage.
Galen (De Simp. xi) says he has seen haemorrhage stopped by
applying a sponge dipped in asphalt to a bleeding wound and setting
fire to it, and leaving the unburnt part to cover the wound. Celsus
says a sponge dipped in oil and vinegar or cold water relieves gouty
swellings. He also recommends a sponge dipped in vinegar or cold
water for stopping haemorrhage.
Dioscorides says that fistulae may be dilated with sponge tents.
Scribonius Largus says that in epistaxis the nose may be plugged
with sponge:
Proderit et spongeae particulam praesectam apte forfice ad
amplitudinem et patorem narium figuratam inicere paulo pressius ex
aceto per se (xlvi).
Soranus (xli) says haemorrhage from the uterus may be stopped
with a sponge tent:
Ὁπότε τρυφερὸν καὶ καθαρὸν σπογγάριον ἐπιμήκες ὡσαύτως
διάβροχον ὡς ἐσωτάτω παρεντιθέναι προσήκει.

Sutures.
Celsus (V. xxvi) says sutures should be of soft thread not overtwisted
that they may be the more easy on the part: ‘Ex acia molli non nimis
torta quo mitius corpori insidat’. They were made of flax. The
apolinose described by Hippocrates (iii. 132) is directed to be made
of crude flax (ὠμολίνου), the strands of which were stronger than
those of dressed lint. This also is what Paul used for the deligation of
arteries.
Galen alludes to sutures of wool, and Paulus Aegineta in the
operation for ectropion says:
‘Afterwards we unite the divided parts with a needle carrying a
woollen thread, being satisfied with two sutures.’
We have no mention of catgut being used for this purpose, though
that substance was early known to the Greeks. The Homeric harp
was strung with catgut. In fact χορδή, the term for harp-string,
simply means intestines. Paul used a woman’s hair in a needle to
transplant hairs in trichiasis (VI. xiii). Horsehair was used to raise a
pterygium in Paul VI. xviii, but it is not mentioned as being used for
suturing wounds.

Serres Fines.
Greek, ἀγκτήρ; Latin, fibula.
Celsus (V. xxvi) in describing the closing of wounds says:
Nam si plaga in molli parto est, sui debet, maximeque si discissa
auris ima est, vel imus nasus, vel frons, vel bucca, vel palpebra, vel
labrum, vel circa guttur cutis, vel venter. Si vero in carne vulnus est
hiatque, neque in unum orae facile attrahuntur, sutura quidem aliena
est; imponendae vero fibulae sunt; ἀγκτῆρας Graeci nominant; quae
oras paulum tamen contrahant, quo minus lata postea cicatrix sit.
‘Suture is indicated if the lesion is in a soft part, especially in the
lobule of the ear, or the ala nasi, or the forehead, or cheek, the edge
of the eyelid, or the skin over the throat, or the abdominal wall. But
if the wound is in a muscular part and gape, and the edges cannot
easily be opposed, suture is contraindicated, and fibulae (Graece
ἀγκτῆρας) are to be used in order that the cicatrix afterwards may
not be wide.’
We have here contrasted two methods of closing a wound, and the
conclusion is readily arrived at that sutures in the first case and
some metal contrivance in the second are intended. Celsus goes on
to say, however:
Utraque optima est ex acia molli, non nimis torta, quo mitius corpori
insidat. Utraque neque nimis rara, neque nimis crebra iniicienda.
‘Both are best made of soft thread, not too hard twisted that it may
sit easier on the tissues, nor are too few nor too many of either of
them to be put in.’
A consideration of various passages in which the Greek authors use
the term leaves a distinct impression on one’s mind that a metal
clasp is intended. Thus Paul (VI. cvii), in treating of compound
fractures, says that if a large portion of the bone is laid bare we use
fibulae and sutures (ἀγκτῆρσι καὶ ῥαφαῖς). It must be confessed,
however, that the words of Celsus render it difficult for us to assert
with certainty that fibulae were metal clasps, and we find ancient
commentators in equal difficulty. Fallopius and Fabricius d’
Aquapendente think fibulae mean interrupted sutures. Guido de
Cauliac thinks they mean metal clasps. There is just the possibility
that a contrivance like our harelip pin with a figure of eight thread
may be indicated. This would satisfy both sides of the question. If
fibulae were metal clasps, however, we have several varieties of
ancient fibulae that might have been used for closing wounds. That
most suited for the purpose in hand seems to me to be one
consisting of a small bar terminating in two hooks. Several of these
from Roman London are in the Guildhall Museum (Pl. LII, figs. 5, 6,
7). They represent a useful form of ‘clip’ still in use by cyclists, and
they could be applied to wounds to act on the principle of
Malgaigne’s hooks for the patella. A modicum of support for this
view may be derived from the fact that whereas Galen, from whom
the above passage on compound fractures is quoted by Paul, uses
the word ἀγκτῆρσι, the codices of Paul almost unanimously have
ἀγκίστροις. Fourteen out of fifteen give the latter rendering.

Band of Antyllus.
In the interesting dissertation which Oribasius gives on the subject
of phlebotomy (Med. Collect. vii) he states that Antyllus directs us to
apply a ligature of two fingers’ breadth round the arm when going to
let blood at the elbow. He says that they are mistaken who affirm
that the same effect may be produced by applying the band below,
for the veins will not then swell even if the arm be fomented. When
going to bleed at the ankle the ligature is to be applied at the knee.
When the blood does not flow well he advises us to slacken the
bandage if too tight. This is the famous ‘band of Antyllus’.
It is mentioned also in the pseudo-Hippocratic treatise on Ulcers (iii.
328):
‘When you have opened the vein and after you have let blood and
have loosened the fillet (ταινίαν) and yet the blood does not stop.’
Paul also mentions the band, including one round the neck when the
veins of the forehead are to be opened for ophthalmia. So far as we
know the fillet was nothing more than a plain strip of linen or some
such material, but Deneffe, commenting on two bronze fibulae which
were found in the grave of the surgeon of Paris, conjectures that
they may have been used to fix the fillet in venesection. I give
figures of these after Deneffe, but it seems to me that these buckles
are more likely to have belonged to the straps of a portable
instrument-case of canvas or leather which had disappeared. One is
a neat little heptagonal fibula, 2·8 cm. in its widest part, with a
tongue 27 mm. long (Pl. LII, fig. 2). The other fibula is in the form
of a penannular ring, formed by a two-headed serpent curved on
itself so that the two heads look at each other, separated from each
other by a space of a few millimetres (Pl. LII, fig. 8). Opposite the
heads there is a small rectangular opening to receive the end of the
strap. There is no tongue. It may have been fixed by a metal bar
attached to the other end of the strap.

Sieves and Strainers.

Greek, ἠθμός, κυρτίς; Latin, cribrum.
Scribonius Largus mentions sieves of different sizes. In ch. xc a small
one is mentioned:
Contunditur hic cortex per se et cribratur tenui cribro.
In other places larger sizes are mentioned:
In his macerantur res quae infra scriptae sunt, contusae et
percribratae grandioribus foraminibus cribri (cclxix).
Marcellus (De Medicamentis, xxxiii. 9) says:
Pulverem facito, et cribello medicinali omnem pulverem cerne et
permisce, et cum vino vetere calefacto locum inline.
There are large numbers of sieves and strainers in bronze and
earthenware in the Naples Museum.
Paul (VII. xx) says oil of sesame is to be prepared from sesame
pounded, softened, and pressed in a strainer with screws (διὰ
κυρτίδων τῶν κοχλιῶν). The word κυρτίς literally means a basket or
wicker eel-trap. Here it must mean a strainer.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com