출처

http://blog.javastudy.co.kr/mgtech/tag/virtual%20host

 

 

■ Rewrite 사용예

1.www.ddobb.com:8000으로 들어오는 모든것을 leon.ddobb.com 으로 가도록 설정한 예 이다.

  : www.ddobb.com:8000 뒤에 붙는 모든것들은 그대로 두고 도메인만 변경되는 것이다.

<VirtualHost 192.168.1.100:8000>
  ServerAdmin webmaster@test.com
  DocumentRoot /supp1/webdocs/

  ServerName www.ddobb.com
  ServerAlias ddobb.com *.ddobb.co.kr
  RewriteEngine on
  RewriteRule     (.*)             https://leon\.ddobb\.com$1 [C]
  ErrorDocument 404 "http://www.ddobb.com/inedx.html"
</VirtualHost>

2. www.ddobb.com/aaa/bbb.jsp 라는 파일이 요청되면 www.ddobb.com/index2.html로 가도록 설정한 예이다.

<VirtualHost 192.168.1.100:80>
  ServerAdmin webmaster@test.com
  DocumentRoot /supp1/webdocs/

  ServerName www.ddobb.com
  ServerAlias ddobb.com *.ddobb.co.kr
  RewriteEngine on
  RewriteRule     /aaa/bbb.jsp             http://%{HTTP_HOST}/index2.html [C]
  ErrorDocument 404 "http://www.directsamsung.com/inedx.html"
</VirtualHost>

ACM 2005 Feb 에서..

온라인상으나 오프라인상이나 Trust는 상당히 중요하다. 아니, 상도에서는 제일 중요하다고 볼 수 있다.
이 기사는 Trust에 대해서 분석적으로 접근하여 전자 상거래의 유발의 순차적이고 관계성을 View로 보고 있다.
엔지니어에게는 상당히 추상적으로 느껴질 수 있을 것이다.

인터넷 사용에 대한 믿음은 전자 상거래 웹싸이트에 대한 자세와 특정 웹 벤더에 대한 신뢰가 그 벤더에 대한 사용 의지를 높여 방문을 자주 하게 되고, 이런 과정을 통해서 웹 벤더와 사용자간의 relationship을 형성한다. 이런 관계의 발전을 극대화하여 신뢰를 구축하게 되고, 이 신뢰를 통해서 전자 상거래를 이루게 하여, 제품 구매자와 제품 공급자가 서로 가치를 얻을 수 있는 상태를 얻도록 하는 것이 이 기사의 주된 내용디ㅏ.

결과적으로 신뢰는 기술적, 행동학적, 사회학적, 심리학적인 복잡한 현상으로서, 인간과 비인간간의 구조적인 상호관계를 이룰 수 있다고 믿고 있다. 즉 고객과 온라인 비즈니스 사업자가 긴 시간동안의 신뢰성을 가지도록 하는 것을 통해 온라인 비즈니스 사업자가 돈을 벌 수 있는 방법에 대해서 강조하고 있다.

사실 개인적으로 특정 전자 상거래를 구입하기 위해서는 그 동안의 정(情)을 생각하고 구매를 결정하는 경우가 많다. 같은 제품이고 같은 가격이면, 나랑 관계가 있고, 과거의 구매경험이 있는 경우를 생각하고 구매한다고 본다면, 어느 정도 맞을 수 있다고 본다.

또한, 인간적인 신뢰 관계를 웹 벤더와 고객간의 관계를 최대한 극대화 하여 상대방이 돈을 쓰도록 구매할 수 있는 좋은 효과적인 방법을 웹 벤더는 생각해야 한다. 그러기 위해서는 꾸준한 컨텐츠를 통해서 기반 인프라를 바탕으로 좋은 정보를 보내줌으로서, 잠재 구매자에게 어필을 하는 것이 중요하다. 구매 결정을 할 수 있는 건덕지를 웹 벤더가 적용하는 것이 좋을 것이다.

내가 하는 있는 TV분야에서는 어떻게 적용하는 것이 좋을까?  결국 구매력을 가진 잠재력을 최대한 늘리기 위해서, 그리고, 양방향 데이터 방송에 대한 접근을 편리하게 하고, 좀 더 친밀감있게 접근하여 장기적으로 데이터 방송에 친숙하게 하여 신뢰를 튼튼히 한다. 그리고, 실제 구매력이 필요한 시점에서 자연스럽게 구매를 할 수 있는 형태의 호소력이 있는 T-commerce 어플리케이션을 이용하는 것이 효과적이라고 생각한다.

출처 http://slacksite.com/other/ftp.html

Active FTP vs. Passive FTP, a Definitive Explanation

Contents:

• Introduction
• The Basics
• Active FTP
• Active FTP Example
• Passive FTP
• Passive FTP Example
• Other Notes
• Summary
• References
• Appendix 1: Configuration of Common FTP Servers

Introduction

One of the most commonly seen questions when dealing with firewalls and other Internet connectivity issues is the difference between active and passive FTP and how best to support either or both of them. Hopefully the following text will help to clear up some of the confusion over how to support FTP in a firewalled environment.

This may not be the definitive explanation, as the title claims, however, I've heard enough good feedback and seen this document linked in enough places to know that quite a few people have found it to be useful. I am always looking for ways to improve things though, and if you find something that is not quite clear or needs more explanation, please let me know! Recent additions to this document include the examples of both active and passive command line FTP sessions. These session examples should help make things a bit clearer. They also provide a nice picture into what goes on behind the scenes during an FTP session. Now, on to the information...

The Basics

FTP is a TCP based service exclusively. There is no UDP component to FTP. FTP is an unusual service in that it utilizes two ports, a 'data' port and a 'command' port (also known as the control port). Traditionally these are port 21 for the command port and port 20 for the data port. The confusion begins however, when we find that depending on the mode, the data port is not always on port 20.

Active FTP

In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.

From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

• FTP server's port 21 from anywhere (Client initiates connection)
• FTP server's port 21 to ports > 1023 (Server responds to client's control port)
• FTP server's port 20 to ports > 1023 (Server initiates data connection to client's data port)
• FTP server's port 20 from ports > 1023 (Client sends ACKs to server's data port)

When drawn out, the connection appears as follows:

In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4.

The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.

Active FTP Example

Below is an actual example of an active FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

There are a few interesting things to consider about this dialog. Notice that when the PORT command is issued, it specifies a port on the client (192.168.150.80) system, rather than the server. We will see the opposite behavior when we use passive FTP. While we are on the subject, a quick note about the format of the PORT command. As you can see in the example below it is formatted as a series of six numbers separated by commas. The first four octets are the IP address while the last two octets comprise the port that will be used for the data connection. To find the actual port multiply the fifth octet by 256 and then add the sixth octet to the total. Thus in the example below the port number is ( (14*256) + 178), or 3762. A quick check with netstat should confirm this information.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2
Connected to testbox2.slacksite.com.
220 testbox2.slacksite.com FTP server ready.
Name (testbox2:slacker): slacker
---> USER slacker
331 Password required for slacker.
Password: TmpPass
---> PASS XXXX
230 User slacker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PORT 192,168,150,80,14,178
200 PORT command successful.
---> LIST
150 Opening ASCII mode data connection for file list.
drwx------   3 slacker    users         104 Jul 27 01:45 public_html
226 Transfer complete.
ftp> quit
---> QUIT
221 Goodbye.

Passive FTP

In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.

In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.

From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

• FTP server's port 21 from anywhere (Client initiates connection)
• FTP server's port 21 to ports > 1023 (Server responds to client's control port)
• FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
• FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)

When drawn, a passive mode FTP connection looks like this:

In step 1, the client contacts the server on the command port and issues the PASV command. The server then replies in step 2 with PORT 2024, telling the client which port it is listening to for the data connection. In step 3 the client then initiates the data connection from its data port to the specified server data port. Finally, the server sends back an ACK in step 4 to the client's data port.

While passive mode FTP solves many of the problems from the client side, it opens up a whole range of problems on the server side. The biggest issue is the need to allow any remote connection to high numbered ports on the server. Fortunately, many FTP daemons, including the popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use. See Appendix 1 for more information.

The second issue involves supporting and troubleshooting clients which do (or do not) support passive mode. As an example, the command line FTP utility provided with Solaris does not support passive mode, necessitating a third-party FTP client, such as ncftp.

With the massive popularity of the World Wide Web, many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs. This can either be good or bad depending on what the servers and firewalls are configured to support.

Passive FTP Example

Below is an actual example of a passive FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

Notice the difference in the PORT command in this example as opposed to the active FTP example. Here, we see a port being opened on the server (192.168.150.90) system, rather than the client. See the discussion about the format of the PORT command above, in the Active FTP Example section.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2
Connected to testbox2.slacksite.com.
220 testbox2.slacksite.com FTP server ready.
Name (testbox2:slacker): slacker
---> USER slacker
331 Password required for slacker.
Password: TmpPass
---> PASS XXXX
230 User slacker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (192,168,150,90,195,149).
---> LIST
150 Opening ASCII mode data connection for file list
drwx------   3 slacker    users         104 Jul 27 01:45 public_html
226 Transfer complete.
ftp> quit
---> QUIT
221 Goodbye.

Other Notes

A reader, Maarten Sjouw, pointed out that active FTP will not function when used in conjunction with a client-side NAT (Network Address Translation) device which is not smart enough to alter the IP address info in FTP packets.

Summary

The following chart should help admins remember how each FTP mode works:

 Active FTP :
     command : client >1023 -> server 21
     data    : client >1023 <- server 20

 Passive FTP :
     command : client >1023 -> server 21
     data    : client >1023 -> server >1023

A quick summary of the pros and cons of active vs. passive FTP is also in order:

Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side.

Luckily, there is somewhat of a compromise. Since admins running FTP servers will need to make their servers accessible to the greatest number of clients, they will almost certainly need to support passive FTP. The exposure of high level ports on the server can be minimized by specifying a limited port range for the FTP server to use. Thus, everything except for this range of ports can be firewalled on the server side. While this doesn't eliminate all risk to the server, it decreases it tremendously. See Appendix 1 for more information.

References

An excellent reference on how various internet protocols work and the issues involved in firewalling them can be found in the O'Reilly and Associates book, Building Internet Firewalls, 2nd Ed, by Brent Chapman and Elizabeth Zwicky.

Finally, the definitive reference on FTP would be RFC 959, which sets forth the official specifications of the FTP protocol. RFCs can be downloaded from numerous locations, including http://www.faqs.org/rfcs/rfc959.html.

작성자: 김인태 (http://blog.naver.com/inking007)

제목: Axis WebService 설치및 테스트

참고 : http://www.javaworld.com/javaworld/jw-04-2003/jw-0411-axis_p.html

-------------------------------------------------------------------------

 

Axis 설치

 

1) Apache Tomcat 설치

   버전 4.1  이상 Full 버전으로 설치해야만 한다.

 

2) JDK 설치

   버전 1.3 이상으로 설치 해야만 한다.

 

3) Axis 다운로드 후 CLASSPATH를 설정한다.

 

c:\axis에 설치했다고 가정하면 다음과 같이 설정해 준다.

set AXIS_HOME=c:\axis
set AXIS_LIB=%AXIS_HOME%\lib
set AXISCLASSPATH=%AXIS_LIB%\axis.jar;%AXIS_LIB%\commons-discovery.jar;
    %AXIS_LIB%\commons-logging.jar;%AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\saaj.jar;
    %AXIS_LIB%\log4j-1.2.8.jar;%AXIS_LIB%\xml-apis.jar;%AXIS_LIB%\xercesImpl.jar;%AXIS_LIB%\wsdl4j.jar

set CLASSPATH=%CLASSPATH%;%AXISCLASSPATH%

 

CLASSPATH에 있는 xml-apis.jar 파일과 xercesImpl.jar 파일은 http://xml.apache.org/xerces2-j/ 에 접속해서 다운로드 받으면 된다.

 

4) c\axis\webapps\axis 디렉토리를 tomcat의 webapps에 복사한다.

 

5) 톰켓 실행

 

6) 테스트

 

> 연결 테스트

http://localhost:8080/axis

 

> 라이브러리 테스트

http;//localhost:8080/axis/happyaxis.jsp

 

> SOAP 테스트

http://localhost:8080/axis/services/Version?method=getVersion

다음과 같이 출력되어야 한다. (build date와 version등은 다를수 있다.)

  <?xml version="1.0" encoding="UTF-8" ?>
  <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
   <getVersionResponse
    soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <getVersionReturn
     xsi:type="xsd:string">
     Apache Axis version: 1.1 Built on Apr 04, 2003 (01:30:37 PST)
    </getVersionReturn>
   </getVersionResponse>
   </soapenv:Body>
  </soapenv:Envelope>

 

> AdminClient 테스트

cd c:\axis\stock 

java -cp %AXISCLASSPATH% org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd

ClassNotFoundException 오류가 발생한경우 CLASSPATH를 확인해 볼것

 

deploy가 성공했는지 확인한다.

http://localhost:8080/axis/servlet/AxisServlet

다음과 같이 웹서비스가 설치되었는지 확인해 본다.

  urn:xmltoday-delayed-quotes (wsdl) 
        test 
        getQuote

 

> 클라이언트 수행 테스트

java -cp .;%AXISCLASSPATH% samples.stock.GetQuote -lhttp://localhost:8080/axis/servlet/AxisServlet  -uuser1 -wpass1 XXX

 

실행결과가 55.25가 출력된 경우.. 성공!!

 

 

웹서비스를 알려면 SOAP, WSDL, WSDD 대해서 꼭 알아야 한다.

 

자세한 내용은 추후에 설명하도록 한다.

 

SOAP (Simple Object Access Protocol)

WSDL (Web Service Description Langauge)

WSDD (Web Service Deployment Descriptor)

 

프로그램을 작성하는 순서

 

1. 서버 Interface와 구현 Class를 작성한후 컴파일 한다.

 

2. 구현 클래스로 부터 WSDL 파일을 생성한다.

 

3. WSDL 파일로 부터 deploy.wsdd 파일을 생성한다.

 

4. deploy.wsdd 파일을 이용해서 웹서비스를 deploy하고 server-config.wsdd 파일을 생성 수정한다.

 

5. 구현클래스로 부터 client-side 클래스를 생성한다.

 

 

프로그램 작성 플로우

 

 

   

 

1) 자바 Interface와 자바 Implement 클래스 작성

//begin - HelloIF.java

package webservice.hello;

public interface HelloIF extends java.rmi.Remote {
    public String hello(java.lang.String name) throws java.rmi.RemoteException;
}
//end - HelloIF.java

 

//begin - HelloImpl.java

package webservice.hello;

public class HelloImpl implements HelloIF {
    public HelloImpl() {
    }

    public String hello(String name) {
        System.out.println(name);
        return "hi " + name;
    }
}

//end - HelloImpl.java

 

컴파일

javac -d . HelloImpl.java

컴파일 후 webservice/hello 디렉토리밑에 HelloImpl.class 와 HelloIF.class가 생성되었는지 확인한다.

 

생성된 class파일을 C:\lecture\Tomcat 4.1\webapps\axis\WEB-INF\classes 디렉토리에 패키지 디렉토리를 포함해서 복사한다.

 

2) 구현 클래스로부터 WSDL 작성

java org.apache.axis.wsdl.Java2WSDL -o c:\javaprogram\webservice\hello\Hello.wsdl -l http://localhost:8080/axis/services/Hello -n http://hello.webservice -pwebservice.hello http://hello.webservice webservice.hello.HelloIF

 

Java2WSDL 인자 (http://ws.apache.org/axis/java/reference.html)

인자	의미
-o 파일경로	wsdl 생성 위치
-l URL	client가 접속할 URL
-n  네임스페이스	WSDL의 타켓 네임스페이스
-p패키지 네임스페이스	네임스페이스와 네임스페이스 매핑
Target	인터페이스 이름

 

 

생성된 wsdl 파일

 

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://hello.webservice" xmlns:impl="http://hello.webservice" xmlns:intf="http://hello.webservice" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <!--WSDL created by Apache Axis version: 1.2alpha Built on Dec 01, 2003 (04:33:24 EST)-->    <wsdl:message name="helloResponse">       <wsdl:part name="helloReturn" type="xsd:string"/>    </wsdl:message>    <wsdl:message name="helloRequest">       <wsdl:part name="in0" type="xsd:string"/>    </wsdl:message>    <wsdl:portType name="HelloIF">       <wsdl:operation name="hello" parameterOrder="in0">          <wsdl:input name="helloRequest" message="impl:helloRequest"/>          <wsdl:output name="helloResponse" message="impl:helloResponse"/>       </wsdl:operation>    </wsdl:portType>    <wsdl:binding name="HelloSoapBinding" type="impl:HelloIF">       <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>       <wsdl:operation name="hello">          <wsdlsoap:operation soapAction=""/>          <wsdl:input name="helloRequest">             <wsdlsoap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://hello.webservice"/>          </wsdl:input>          <wsdl:output name="helloResponse">             <wsdlsoap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://hello.webservice"/>          </wsdl:output>       </wsdl:operation>    </wsdl:binding>    <wsdl:service name="HelloIFService">       <wsdl:port name="Hello" binding="impl:HelloSoapBinding">          <wsdlsoap:address location="http://localhost:8080/axis/services/Hello"/>       </wsdl:port>    </wsdl:service> </wsdl:definitions>

 

3), 4)  WSDL 파일로 부터 deploy.wsdd 파일 생성 및 client-side 자바 클래스 생성

 

java org.apache.axis.wsdl.WSDL2Java -o c:\javaprogram\webservice\hello\ -d Application -s c:\javaprogram\webservice\hello\Hello.wsdl

 

c:\javaprogram\webservice\hello 디렉토리 하위에 webservice/hello 새로운 디렉토리가 생성된것을 확인 할수 있다.

그 디렉토리에 deploy.wsdd 파일과 새롭게 생성된 자바 파일이 존재해야 한다.

 

WSDL2Java 인자

인자	의미
-o 디렉토리경로	wsdd 파일과 클래스파일이 생길 디렉토리
-d  scope	설치 영역 – Application, Request , Session
-s	wsdd 파일 생성
Target	wsdl 파일 경로

 

deploy.wsdd 파일 수정

 

wsdd 파일은 wsdl 파일만 가지고 생성되었기 때문에 실제 구현클래스가 무엇인지 제대로 설정이 안되어 있으므로 그부분을 수정해 주어야한다.

 

<deployment     xmlns="http://xml.apache.org/axis/wsdd/"     xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">     <!-- Services from HelloIFService WSDL service -->     <service name="Hello" provider="java:RPC" style="rpc" use="encoded">       <parameter name="wsdlTargetNamespace" value="http://hello.webservice"/>       <parameter name="wsdlServiceElement" value="HelloIFService"/>       <parameter name="wsdlServicePort" value="Hello"/>       <parameter name="className" value="webservice.hello.HelloImpl"/>       <parameter name="wsdlPortType" value="HelloIF"/>       <operation name="hello" qname="operNS:hello" xmlns:operNS="http://hello.webservice" returnQName="helloReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" >         <parameter name="in0" type="tns:string" xmlns:tns="http://www.w3.org/2001/XMLSchema"/>       </operation>       <parameter name="allowedMethods" value="hello"/>       <parameter name="scope" value="Application"/>     </service> </deployment>

 

서비스 디플로이먼트

java org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd

 

디플로이먼트 확인하기

http://localhost:8080/axis/servlet/AxisServlet

'Hello' 라는 서비스가 설치된것을 확인할 수 있다.

 

서비스 테스트하기

 

Understanding web.xml Files | 펌글	2004/11/23 11:22
http://blog.naver.com/joy7600/40008189699
http://www.shockrave.com/v1/handlers/index.cfm?id=19399&method=full   Understanding web.xml Files by Matt Horn Technical Writer Macromedia Deployment Descriptor Overview Deployment descriptors are text-based XML files whose elements describe how to deploy and assemble components into a specific environment. They also contain information about the components that can specify settings not contained in the code of the components themselves, such as initialization parameters and security settings. This section explains the various types of deployment descriptors found in J2EE-compliant systems and then focuses on the web.xml file, the web component deployment descriptor. Types of deployment descriptors Deployment descriptors come in several flavors as defined by the J2EE specification. There are three major deployment descriptors, which correspond to three major pieces of the J2EE: J2EE application deployment descriptor. J2EE applications contain one or more J2EE modules and one J2EE application deployment descriptor. The J2EE application deployment descriptor is stored as /META-INF/application.xml and is defined in the J2EE specification. Its major function is to point to the modules within the application. J2EE applications are typically stored and deployed as enterprise application archive (EAR) files. EJB module deployment descriptor. EJB modules contain one or more EJB components. The EJB module deployment descriptor is stored as /META-INF/ejb-jar.xml and is defined in the EJB specification. Its major function is to define and configure EJBs. EJB modules are typically stored and deployed as Java archive (JAR) files. Web module deployment descriptor. Web modules contain one or more web components (such as servlets, JSPs, or HTML files). The web module deployment descriptor is stored as /WEB-INF/web.xml and is defined in the Servlet specification. Its major function is to define the web component settings. Web modules are typically stored and deployed as web application archive (WAR) files. This article does not address the J2EE application client module and J2EE connector module, which also have their own deployment descriptors. Furthermore, Tag Library Descriptor (TLD) files which describe custom JSP tag libraries are not discussed. The following illustration shows two web modules, app1.war and app2.war, each containing an assortment of web components (such as JSPs, and servlets) as well as static web files (HTML files and GIFs), within a J2EE application. It also shows an EJB module with EJB components (app_ejbs.jar). Notice that just as each web and EJB module has its own deployment descriptor, so does the J2EE application. Why you need deployment descriptors Deployment descriptors relate installation and configuration information about applications to the application servers. They can also be used to convey information about the application to other people involved in the development process. If you want to create an application that can be deployed without the headache of manually configuring its components, then packaging it as a WAR, JAR, or EAR file is the best approach. Each of these files requires a deployment descriptor. Overlapping elements The following bulleted lists are meant to show the overlap of deployment descriptor elements. Common elements in all descriptors (web.xml, application.xml, and ejb- jar.xml): Icons Description Display name Elements in only web.xml and ejb-jar.xml deployment descriptors: Naming environment entries EJB references Connection factory references Security elements Elements in application.xml deployment descriptor only: Module descriptions Security roles Elements in web.xml deployment descriptor only: Servlet definitions Servlet mappings Error pages Form-based authentication configuration Elements in ejb-jar.xml deployment descriptor only: Transaction elements Persistence elements As you can see, there can be overlapping of elements in the deployment descriptors. Each of the modules have their own common elements such as descriptions, icons and display names. While these elements share element names and syntax, it is important to remember that they affect only the module whose deployment descriptor they are in. However, sometimes the modules define elements that interact with other module's elements. For example, the application.xml, ejb-jar.xml and web.xml files can all define security roles. It is the role of the application assembler to make sure that the descriptors complement one another rather than provide contradictory configuration information. For complete descriptions of the various XML files and their allowed values, you can view the DTDs in the module specifications. The elements of the web.xml file are described in detail in "web.xml Elements". The rest of this article provides information on the web application deployment descriptor file. For information on the EJB and J2EE deployment descriptors, refer to their respective specifications. Introduction to the web.xml File The web.xml file is used by the J2EE application server during deployment of a web module. It describes the web components used by that web module, environment variables, and security requirements. This information is stored as /WEB-INF/web.xml. For example, the default application's deployment descriptor might be stored as /usr/jrun/servers/default/default-app/WEB-INF/web.xml. You must add a web.xml deployment descriptor to any WAR file you want to deploy as a web application. You can then add your web module to a J2EE application, which has its own deployment descriptor (application.xml) in addition to the web module's web.xml. Who creates web.xml files JRun and the web component creator share in the creation of the web.xml deployment descriptor. Some but not all of the settings in the web.xml file can be created or edited programmatically by using JMC panels. For example, there is currently no panel to write user/role/group information to the web.xml file. For detailed information on which elements in a web.xml file can be defined by JMC panels, review the descriptions in the following sections. A table in third part of this series lists all the primary elements and shows which JMC panel defines that element. web.xml Elements The web.xml file can define the following information, as defined by the web application deployment descriptor data type definition (DTD) in the Servlet specification: Note the following syntax rules for a DTD: * Specify this element as many times as necessary (zero or more). This element is optional. ? Specify this element one time only. This element is optional. + Specify this element one or more times. This element is required if its super-element is used. Note: All web application deployment descriptors must begin with the following DOCTYPE declaration: The web.xml file contains the following types of elements: web-app element application elements servlet elements security elements environment variables EJB references These elements are described in the next two parts of this three-part series. The second installment discusses the types of elements contained in the web.xml file. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. Click here to read the next installment.   Understanding the web.xml Deployment Descriptor, Part 2 This is the second installment of a three installment series, and describes the syntax of web.xml files. This second installment has two parts. The continuation of this second installment can be viewed here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. web-app element <web-app>web.xml elements</web-app> <web-app> The web-app element wraps all other elements in the web.xml file. Each web.xml file contains a single web-app element, which is the root of the deployment descriptor and wraps all other elements in the file. Application elements Application elements define attributes that apply to an entire web application. General application elements General application elements allow you to specify a description and application name. When you create an application using the Create An Application panel in the JMC, you cannot set the general elements described in this section. You can set them in the Edit An Application panel or use a text or XML editor and edit the web.xml file directly. <description>description</description>? <display-name>name</display-name>? <description>description</description>? Provides a description of the web application. Define this element in the Application Description field on the Edit An Application panel of the JMC. <display-name>name</display-name>? Provides a short web application name. This element is intended for use in graphical programming tools. You define this element in the Application Display Name field on the Edit An Application panel of the JMC. Icon Icon elements are used in graphical programming tools to represent the web application. Application-level icon elements cannot be defined in the JMC. You can specify them by editing the web.xml file using a text editor or an XML editor. <icon>? <large-icon>file path</large-icon>? <small-icon>file path</small-icon>? </icon> <icon>? Defines an icon. <Large-icon>? Location within the web application of a 32x32 GIF or JPEG file containing an icon image. <Small-icon>? Location within the web application of a 16x16 GIF or JPEG file containing an icon image. Context-param* Context-param elements define application-level parameters. These parameters are available to servlets through the ServletContext object. You can also think of the servlet context as the web application container environment. You can define context-param elements in the JMC, as described below. <context-param>* <param-name>name</param-name> <param-value>value</param-value> <description>description</description>? </context-param> <context-param>* Defines a context parameter. <param-name> Specifies the parameter name. You define this element through the Variable Name field on the Application Variables panel in the JMC. <param-value> Specifies the parameter value. You define this element through the Variable Value field on the Application Variables panel in the JMC. <Description> Specifies the parameter description. This parameter cannot be set in the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". Welcome-file-list? The welcome-file-list element contains welcome-file elements, which specify one or more files to be used as the default welcome file (such as index.htm). You typically define welcome files through the JMC, using the File Settings panel for the web application (in the JMC, these are known as default documents). <welcome-file-list>? <welcome-file>file name</welcome-file>+ </welcome-file-list> <welcome-file-list>? Contains one or more welcome-file elements. <welcome-file>+ Specifies a default welcome file. Error-page* The error-page element maps an HTTP error code or a Java exception to a file. JRun displays this file upon encountering the error code or exception type. This element cannot be set in the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. For more information on how error pages are used, refer to Developing Applications with JRun. <error-page>* <error-code>HTTP error code</error-code> <exception-type>Java exception class</exception-type> <location>location</location> </error-page> <error-page>* Contains elements that define an HTTP error code or Java exception. <error-code> Specifies an HTTP error code. You specify either error-code or exception-type; you cannot specify both. <exception-type> Specifies a Java exception class. You specify either error-code or exception-type; you cannot specify both. <location> Specifies the location of the error-page in the web application. Session-config* The session-config element defines the session-timeout parameter for the web application. You can access this value through the getMaxInactiveInterval method of the HttpSession object. You define this element through the Session Timeout(min) field on the web Application Session panel in the JMC. Note that getMaxInactiveInterval returns a value in seconds while the session-timeout element is in minutes; for example, if you set session-timeout to 5, getMaxInactiveInterval returns 300. <session-config>* <session-timeout>timeout in minutes</session-timeout>? </session-config> <session-config>* Contains the session-timeout parameter. <session-timeout>? Specifies the session timeout interval in minutes. Servlet-mapping* The servlet-mapping element specifies the servlet that JRun invokes when it encounters the associated URL pattern. <servlet-mapping>* <servlet-name>name</servlet-name> <url-pattern>mapping pattern</URL-pattern> </servlet-mapping> <servlet-mapping>* Contains servlet mapping elements. <servlet-name> Specifies the registered servlet name (also known as the alias), as defined in the JMC or the servlet element. You define this element through the Virtual Path/Extension field on the Servlet URL Mappings panel in the JMC. <URL-pattern> Specifies a URL pattern. When a URL that matches URL-pattern is encountered, JRun invokes the associated servlet. You define this element through the Servlet Invoked field on the Servlet URL Mappings panel in the JMC. Mime-mapping* The mime-mappings element contains one or more extension/mime-type pairs, each of which associates a file extension with a MIME type. <mime-mapping>* <extension>extension</extension> <mime-type>mime type</mime-type> </mime-mapping> <mime-mapping>* Contains an extension/mime-type pair. <extension> Specifies a file extension. You define this element through the MIME Type Extension field on the MIME Type Mappings panel in the JMC. <mime-type> Specifies the MIME type associate with the extension. You define this element through the MIME Type field on the MIME Type Mappings panel in the JMC. For example, if you are creating a WAP applications, you might add the following MIME mappings: <mime-mapping> <extension>wml</extension> <mime-type>text/vnd.wap.wml</mime-type> </mime-mapping> <mime-mapping> <extension>wbmp</extension> <mime-type>image/vnd.wap.wbmp</mime-type> </mime-mapping> Taglib* The taglib element provides information on a tag library that is used by JSP pages within a web application. You cannot define the taglib element through the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. <taglib>* <taglib-uri>uri</taglib-uri> <taglib-location>location</taglib-location> </taglib> <taglib>* Contains elements that associate a taglib URI with a physical location. <taglib-uri> Specifies a URI that JSP pages use to identify the tag library in the taglib directive. For example, /eistaglib. <taglib-location> Specifies the location of the tag library's TLD file. For example, /WEB-INF/tld/eistaglib.tld. Resource-ref* The resource-ref* element declares a web application's reference to an external resource. You cannot define the resource-ref element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <resource-ref>* <description>description</description>? <res-ref-name>resource factory reference name</res-ref-name> <res-type>java class</res-type> <res-auth>CONTAINER or SERVLET</res-auth> </resource-ref> <resource-ref>* Contains elements that describe an external reference. <Description>? Specifies a brief description. <res-ref-name> Specifies the resource factory reference name. <res-type> Specifies the Java class of the data source. <res-auth> Indicates that the application performs a resource login programmatically (SERVLET) or JRun signs on automatically using principal mapping information provided by the deployer (CONTAINER). Servlet elements Servlet elements define servlets and their usage. You typically define servlet settings through the JMC. The servlet element has the following general form: <servlet>* sub-elements </servlet> This is the second installment of a three installment series, and describes the syntax of web.xml files. This second installment has two parts. The continuation of this second installment can be viewed here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files.   Understanding the web.xml Deployment Descriptor, Part 2 (continued) This is the continuation of the second installment of a three part series, and describes the syntax of web.xml files. The first part of the second installment can be found here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. The following sections describe the contents of the servlet element: General servlet elements Init-param* Load-on-startup? Security-role-ref* General servlet elements <icon>? <large-icon>file path</large-icon>? <small-icon>file path</small-icon>? </icon> <servlet-name>name</servlet-name> <display-name>name</display-name>? <description>description</description>? <servlet-class>fully qualified class name</servlet-class> <jsp-file>file name</JSP-file> <icon>? For more information on the icon element, refer to "Icon". You define these elements in the Large Icon and Small Icon fields on the Servlet Definitions panel of the JMC. Note that you cannot define the application-level icons in the JMC. <Servlet-name> Specifies the registered name of the servlet. Other servlets and JSP pages reference the servlet using either this name or its class name. Define this element in the Name field of the Servlet Definitions panel of the JMC. <Display-name>? Provides a short servlet name. Intended for use in graphical programming tools. Define this element in the Display Name field on the Servlet Definitions panel of the JMC. <Description>? Provides a description of the servlet. You define this element in the Description field on the Servlet Definitions panel of the JMC. <servlet-class> Specifies the fully qualified class name for the servlet. A servlet element can contain either servlet-class or JSP-file; it cannot contain both. Define this element in the Class Name field on the Servlet Definitions panel of the JMC. <JSP-file> Specifies the full path to a JSP file within the web application. A servlet element can contain either servlet-class or JSP-file; it cannot contain both. You define this element in the Class Name field on the Servlet Definitions panel of the JMC. Init-param* The init-param element defines servlet-level parameters. You typically define servlet parameters through the JMC. <init-param>* <param-name>name</param-name> <param-value>value</param-value> <description>description</description>? </init-param> <init-param>* Contains elements that define a servlet-level initialization parameter. <param-name> Specifies the parameter name. Define this element in the Init Arguments field on the Servlet Definitions panel of the JMC. <param-value> Specifies the parameter value. Define this element in the Init Arguments field on the Servlet Definitions panel of the JMC. <Description>? Specifies a description for the initialization parameter. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". Load-on-startup? The presence of this element indicates that JRun loads the servlet at startup. Define this element using the Servlet Preload Order dialog box from the Servlet Definitions panel in the JMC. For more information, refer to the JRun Setup Guide. <load-on-startup>optional sequence</load-on-startup>? <load-on-startup>? Specifies that JRun loads the servlet at startup time. You can optionally enclose a positive integer to indicate a relative loading sequence. JRun loads lower integers before higher integers. For example, the following code indicates that FredServlet gets loaded first, followed by TomServlet. <servlet> <servlet-name>FredServlet</servlet-name> ... <load-on-startup>1</load-on-startup> ... </servlet> <servlet> <servlet-name>TomServlet</servlet-name> ... <load-on-startup>2</load-on-startup> ... </servlet> Security-role-ref* The security-role-ref element declares a security role reference in the servlet code. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <security-role-ref>* <description>description</description>? <role-name>name</role-name> <role-link>role from security-role</role-link> </security-role-ref> <security-role-ref>* Contains a security role reference. <Description>? Specifies a brief description. <role-name> Specifies the security role reference used within the servlet's code. <role-link> Specifies the related role name, as defined in the user data store. Security elements Web.xml security elements specify the resources to be secured and the roles authorized to access secure resources. You cannot define these elements through the JMC. You specify them by editing the web.xml file using a text editor or an XML editor. For more information on the security elements in the web.xml file, refer to Developing Applications with JRun. Security-constraint* The security-constraint element associates security constraints with one or more web resource collections and has the following general form: <security-constraint>* sub-elements </security-constraint> The following discussions describe the contents of the security-constraint element: web-resource-collection+ Auth-constraint? web-resource-collection+ The web-resource-collection+ element identifies the resources and HTTP methods to which a security constraint applies. <web-resource-collection>+ <web-resource-name>name</web-resource-name> <description>description</description>? <URL-pattern>pattern</URL-pattern>* <http-method>method</HTTP-method>* </web-resource-collection> <web-resource-collection>+ Contains elements that identify the resources and HTTP methods to which a security constraint applies. <web-resource-name> Specifies the name of the web resource collection. <Description>? Specifies a description for the web resource collection. <URL-pattern>* Identifies the resources to be secured (for example, /store/*). <HTTP-method>* Specifies the HTTP method for which the security constraint applies. If you do not specify this element, JRun applies the security constraint to all methods. Auth-constraint? The auth-constraint element specifies the roles that can access the web resource collection. <auth-constraint>? <description>description</description>? <role-name>name</role-name>* </auth-constraint> <auth-constraint>? Contains elements that specify the roles that can access the collection. <Description>? Specifies a description for the constraint. <Role-name>* Specifies the roles that can access the resources affected by web-resource-collection. Login-config? The login-config element specifies authentication instructions. For complete examples of the login-config element, refer to Developing Applications with JRun. <login-config>? <auth-method>BASIC or FORM</auth-method>? <realm-name>name</realm-name>? <form-login-config>sub-elements</form-login-config>? </login-config> <login-config>? Contains elements that specify authentication instructions. <auth-method>? Specifies the user validation method. This can be either HTTP challenge/response (BASIC) or an HTML login form (FORM). If you specify FORM, you must specify the form-login-config element. <realm-name>? Specifies the realm name to use in HTTP BASIC authorization. If you omit this element, JRun uses the name of the JRun server hosting the application as the realm name. <form-login-config>? Specifies a login page and an error page through the following sub-elements: form-login-page specifies the path to a page containing a login form. form-error-page specifies the path to a page containing an error form. Environment entries The env-entry element declares application-level environment variables. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <env-entry>* <description>description</description>? <env-entry-name>name</env-entry-name> <env-entry-value>value</env-entry-value>? <env-entry-type>type</env-entry-type> </env-entry> <env-entry>* Contains elements that define the application's environment entry. <Description>? Specifies a description for the environment entry. <env-entry-name> Specifies the name of the environment entry. <env-entry-value>? Specifies the value of the environment entry. <env-entry-type> Specifies the fully-qualified Java type of env-entry-value. Legal values are as follows: java.lang.Boolean java.lang.String java.lang.Integer java.lang.Float java.lang.Double For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". EJB references The ejb-ref element declares a reference to an Enterprise JavaBean. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <EJB-ref>* <description>description</description>? <ejb-ref-name>name</EJB-ref-name> <ejb-ref-type>type</EJB-ref-type> <home>home interface</home> <remote>remote interface</remote> <ejb-link>ejb name</ejb-link>? </ejb-ref> <ejb-ref>* Contains elements that declare an EJB. <Description>? Specifies a description for the EJB. <ejb-ref-name> Specifies the JNDI name that servlets use to get a reference to the EJB. <ejb-ref-type> Specifies the Java class type of the referenced EJB. <home> Specifies the fully qualified name of the EJB's home interface. <remote> Specifies the fully qualified name of the EJB's remote interface. <ejb-link>? Specifies that the reference is linked to an EJB in an encompassing J2EE application package. The value of this element must be the ejb-name of an EJB in the J2EE application package. Unsupported elements The following list outlines web.xml elements that are named in the Java Servlet Specification, version 2.2 but are not supported by JRun: distributable user-data-constraint This is the continuation of the second installment of a three part series, and describes the syntax of web.xml files. The first part of the second installment can be found here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. Understanding the web.xml Deployment Descriptor, Part 3 This is the third part of a three-part series. This installment discusses using environment variables, creating web.xml files, and shows complete examples of web.xml files. The first installment introduced the basics of deployment descriptors. The second installment covered the syntax of web.xml files. Environment Variables There are two kinds of environment variables available to components within web modules that you can set in the web.xml deployment descriptor. These are: Component-specific. These parameters can only be accessed from a single web component (such as a servlet or JSP) within the module. In the deployment descriptor, they are tagged as the init-param sub-elements inside the servlet element. Container-specific. These variables can be accessed from all web components within the servlet container environment. They can be tagged as either env-entry or context-param elements in the deployment descriptor. These environment variables are explained in the sections that follow. Component-specific parameters Component-specific parameters are set in the init-param element of the web.xml deployment descriptor. This element must be within the servlet element. You can define values and names for any number of parameters. For example, you could define a component-specific parameter in a deployment descriptor as follows: <servlet> <init-param> <param-name>EmailAddress</param-name> <param-value>sales@Macromedia.com</param-value> </init-param> </servlet> Component-specific parameters are accessible through the ServletContext object's getInitParameter() method. You could write code in that specific web component that extracts the value of this parameter as follows: String addy = this.getInitParameter("EmailAddress"); Container-specific environment variables Container-specific environment variables can be used to provide configuration information to all web components (such as servlets and JSPs) within a web application or servlet container environment. There are two available container-specific environment variables: Container parameters Application environment variables Both types of variables can be accessed from any web component in the servlet container environment, however, they are accessed in different ways, described in the sections that follow. Container parameters Container parameters are set in the context-param element of the web.xml deployment descriptor. You can define names and values for any number of parameters. Accessing container parameters only returns strings. For example, you could define a container parameter in a deployment descriptor as follows: <context-param> <param-name>footerPage</param-name> <param-value>/data/foot11-00.html</param-value> </context-param> Container parameters are accessible through the ServletContext object's getInitParameter() method. You could write code in that specific web component that extracts the value of this parameter as follows: ServletContext context = this.getServletContext(); String footer = context.getInitParameter("footerPage"); While this appears very similar to the component-specific parameters, remember that these parameters can be accessed from any web component within the servlet container environment. Application environment variables Application environment variables are set in the env-entry element of the web.xml deployment descriptor. You can define names and values for any number of parameters. Accessing application environment variables can return several types of objects. With the env-entry-type sub-element, you can reference one of the following types of objects: Boolean String Integer Double Float The env-entry-type sub-element provides a built-in mechanism for validating the object's type. This validation takes place at deployment time. As an example, you could define an application environment variable in a deployment descriptor as follows: <env-entry> <env-entry-name>headerPage</env-entry-name> <env-entry-value>/data/head11-00.html</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry> Application environment variables are accessed in the java:comp/env context through a JNDI lookup rather than from a ServletContext object. You could write code in any web component within the servlet container environment that extracts the value of this application environment variable as follows: InitialContext context = new InitialContext(); String header = (String) context.lookup("java:comp/env/headerPage"); The JNDI lookup method expects the type specified by the <env-entry-type> element and will throw an exception if the returned value isn't of that type. Creating a web.xml File The web.xml file is created both by the JMC and the programmer since the JMC does not have panels that can make all the changes. The easiest way to create a web.xml file is to let JRun do most of the work. The general process of creating a web.xml file follows. 1 Create an application in the JMC using the Create An Application panel. This creates a skeleton web.xml file for the application. 2 Use the Edit An Application panel to add the description and display-name elements to your web.xml deployment descriptor. 3 Use JMC panels to make any other changes to the web application settings. The following table can be used as a general guideline showing which elements can be defined by which JMC panel. For more information on which sub-elements can be defined by the JMC, refer to the specific element's description beginning in the below list.   web.xml element JMC panel icon Cannot be defined using the JMC display-name Edit An Application description Edit An Application distributable Cannot be defined using the JMC context-param Application Variables* servlet Servlet Definitions* servlet-mapping Servlet URL Mappings session-config web Application Session mime-mapping MIME Type Mappings welcome-file-list File Settings error-page Cannot be defined using the JMC taglib Cannot be defined using the JMC resource-ref Cannot be defined using the JMC security-constraint Cannot be defined using the JMC login-config Cannot be defined using the JMC security-role Cannot be defined using the JMC env-entry Cannot be defined using the JMC ejb-ref Cannot be defined using the JMC * Some, but not all, sub-elements can be set in the JMC panel. 4 Use a text editor or XML editor to define elements in the web.xml file that cannot be defined by the JMC. Examples of web.xml Files This section provides a basic example of a web.xml file and a security example. For more web.xml file examples, refer to the Java Servlet Specification, version 2.2. Basic example The following example web.xml file contains basic information. <web-app> <display-name>JRun Demo</display-name> <description>JRun Demo</description> <session-config> <session-timeout>30</session-timeout> </session-config> <mime-mapping> <extension> txt </extension> <mime-type> text/plain </mime-type> </mime-mapping> <mime-mapping> <extension> html </extension> <mime-type> text/html </mime-type> </mime-mapping> <welcome-file-list> <welcome-file> index.html </welcome-file> </welcome-file-list> </web-app> Security example The following web.xml file contains entries that enable authentication. <web-app> <display-name>Security Default</display-name> <description>Default application for testing security</description> <session-config> <session-timeout>30</session-timeout> </session-config> <mime-mapping> <extension> txt </extension> <mime-type> text/plain </mime-type> </mime-mapping> <mime-mapping> <extension> html </extension> <mime-type> text/html </mime-type> </mime-mapping> <error-page> <error-code>401</error-code> <location>/Unauthorized.html</location> </error-page> <error-page> <error-code>403</error-code> <location>/Forbidden.html</location> </error-page> <login-config> <auth-method> FORM </auth-method> <realm-name> Sales </realm-name> <form-login-config> <form-login-page> /login.html </form-login-page> <form-error-page> /loginerror.html </form-error-page> </form-login-config> </login-config> <security-constraint> <web-resource-collection> <web-resource-name>SalesInfo</web-resource-name> <url-pattern>/servlet/Sn*</URL-pattern> <http-method>GET</HTTP-method> <HTTP-method>POST</HTTP-method> <description>Sales Info Resource</description> <auth-constraint> <role-name>manager</role-name> <description>Managers only</description> </auth-constraint> </web-resource-collection> </security-constraint> <welcome-file-list> <welcome-file> index.jsp </welcome-file> <welcome-file> index.html </welcome-file> </welcome-file-list> <servlet> <servlet-name> SecureSnoop </servlet-name> <servlet-class> SecureSnoop </servlet-class> <security-role-ref> <role-name> MGR </role-name> <role-link> manager </role-link> </security-role-ref> </servlet> </web-app> This installment discussed using environment variables, creating web.xml files, and showed complete examples of web.xml files. The first installment introduced the basics of deployment descriptors. The second installment covered the syntax of web.xml files.