LIBRARY ieee;

USE ieee.std_logic_1164.all;

ENTITY iic001 IS

 PORT
 (
  clk   : IN  STD_LOGIC;                                        
  start  : IN  STD_LOGIC;                                        
  restart  : IN  STD_LOGIC;                                        
  data  : INOUT  STD_LOGIC_VECTOR(7 DOWNTO 0);                                        
  inoutda  : BUFFER STD_LOGIC;                                        
  busy  : OUT  STD_LOGIC;                                        
  scl   : INOUT  STD_LOGIC;                                                             
  sda   : INOUT  STD_LOGIC;
  continue   : OUT  STD_LOGIC
 );
 
END iic001;

ARCHITECTURE jet OF iic001 IS

 SIGNAL i : integer range 0 TO 32 := 0 ;--step status word

BEGIN

 p0:process(clk,start,restart)
 variable j : integer range 0 TO 8 := 0 ;
 variable data_signal : STD_LOGIC_VECTOR(7 DOWNTO 0);
 begin
  if clk'EVENT AND clk = '1' then
  
   if inoutda = '1' then--data input enable
    data <= (others => 'Z');
   end if;
   
   if i = 0 then                      
    inoutda <= '1';--init
     if start = '0' then
     scl <= 'Z';
     sda <= 'Z';
     busy <= '0';
     continue <= '0';
    else           --start
     scl <= 'Z';
     sda <= '0';
     i <= 1;
     busy <= '1';
     data_signal := data;
    end if; 
   end if;
   
   if i = 1 then--address and read or write status
    scl <= '0';     
    i <= 2;
   end if;

   if i = 2 then
    scl <= '0';
    if j <= 7 then
     sda <= data_signal(7-j);
     j := j+1;
    end if;
    i <= 3;
   end if;
   
   if i = 3 then
    scl <= 'Z';
    i <= 4;
   end if;
    
   if i = 4 then
    scl <= '0';
    if j = 8 then
     j := 0;
     i <= 5;
    else
     i <= 2;
    end if;
   end if;   

   if i = 5 then
    sda <= 'Z';
    i <= 6;      
   end if;
   
   if i = 6 then
    scl <= 'Z';
    i <= 7;
   end if;
   
   if i = 7 then--slave react
    scl <= '0';
    if sda = '0' then
     if data_signal(0) = '1' then
      i <= 8;--choose read process
     else
      i <= 31;--choose write process
     end if;
    else
     i <= 0;
    end if;
   end if;
   
   if i = 8 then--read process
    i <= 9;
   end if;
   
   if i = 9 then
    scl <= 'Z';
    i <= 10;
    inoutda <= '1';
    continue <= '1';
   end if;
   
   if i = 10 then
    scl <= '0';
    if j <= 7 then
     data_signal(7-j):= sda;
     j := j+1;
    end if;
    if j = 8 then
     j := 0;
     i <= 12;
     inoutda <= '0';
     data <= data_signal;
    else
     i <= 11;
    end if;
   end if;
   
   if i = 11 then
    i <= 9;
   end if;

   if i = 12 then
    if start = '1' then
     sda <= '0';
     i <= 13;--choose continue read
     continue <= '0';
    else
     i <= 32;--choose end
     sda <= '0';
    end if;
   end if;

   if i = 13 then--continue read
    scl <= 'Z';
    i <= 14;
   end if;
   
   if i = 14 then
    scl <= '0';
    i <= 15;
   end if;
   
   if i = 15 then
    sda <='Z';
    i <= 9;
   end if;
   
   if i = 32 then--end
    scl <= 'Z';
    i <= 0;
   end if;

   
   
   
   
   
     
  end if;  
 
 
 end process p0;
 
 
 
END jet;
 

幅度概率分布（APD）测量技术是分析不同特性的骚扰源对不同制式的数字通信系统的影响的新方法。本文介绍了国际无线电干扰特别委员会（CISPR）关于APD技术标准制订的最新进展，侧重于APD测量方法、APD测量限值的确定以及APD测量仪的基本技术规范三个方面，对于APD技术的进一步研究及应用推广具有一定的参考价值。

    引言

    APD是AmplitudeProbabilityDistribution的缩写，即幅度概率分布。它是一个用来描述无线电骚扰统计特性的参量，定义为“骚扰幅度超过某个规定电平的时间概率的累积分布”。APD测试是目前最新的干扰测试方法，与典型的测量方法，如:准峰值检波等常规研究方法相比较，能更好地描述干扰本身的统计特性，突破了准峰值测量的局限性；采用数理统计的方法研究干扰源的本质，为研究分析不同特性的骚扰源对不同制式的通信系统的影响开辟了新的途径。

    CISPR规定的各种骚扰测量限值都以峰值、准峰值、平均值或有效值来表示，其目的是为了保护广播、电视、通信系统和其它电子设备的正常运行。准峰值反映了人的耳朵和眼睛对干扰的主观感觉；通信系统和电子设备根据信噪比来要求电磁环境，这里的噪声常用有效值、平均值、峰值等表示。这些量值对评价模拟系统是有效的，但是很难与误码率建立联系。随着社会的进步，数字系统已大大发展，而数字系统是用误码率来评价系统性能的，只有确定了干扰的幅度统计特性才能确定数字通信系统的误码率，并且找出误码率和系统输入信噪比的关系，因此与衡量数字通信系统性能直接有关的是干扰的幅度统计特性，而非传统的准峰值、平均值。APD测试就是用来测量干扰模型的统计特性的，是评估数字通信系统性能的最优方案之一。

    APD测量方法[1]

    APD测量是针对频率点进行的。APD分析仪连接在骚扰测量仪（测试接收机或频谱仪）的中频包络检波输出端，对中频包络分层测量，各层幅度对应于接收机输入端的电平。APD分析仪的结构有二种，一是用比较器+计数器，比较器数即分层数;二是使用A/D变换器+计数器+存储器，分层数即A/D变换器的分辨率，例如8位A/D变换器可有256层。

    APD测量结果如图1和图2所示，横轴是层电平，纵轴是幅度超过某层电平的概率。由曲线可知超过低电平层的概率大，超过高电平层的概率小。骚扰增强，曲线向右移动。

    图1  用APD作符合测试的方法之一

    图2  用APD作符合性测试的方法二

    其中APD定义的限值点有二个参数:电平限值Elimit和概率限值Plimit。用APD作符合性测试时有两种方法。

    方法一（如图1所示）:确定Plimit,测量Plimit条件下的电平E。如果E

    方法二（如图2所示）:确定Elimit，测量超过Elimit的概率P。如果P

    APD限值的确定[1]

    只有确定了APD和通信接收抗误码率BER之间的相关性，才可导出APD限值的确定方法。

    首先测出通信接收机的误码率BER，测试方法见图3。测量结果见图4，横轴为接收到的有用信号电压U，纵轴是误码率。图4中最右边曲线为没有EUT干扰时的误码率。接收到的有用信号越大，误码率越小。右边4条曲线是EUT发出不同强度干扰时的误码率。干扰越大，曲线越右移。由图4可知，在确定误码率为10-2条件下，有EUT干扰时必须增加有用信号强度U，在可接受的性能降低的极限情况下需增加U。

    图3  通信接收机误码率BER的测试方法

    图4  通信接收机误码率和接收到的有用信号的测试结果

    图5  用频谱仪和APD分析测量EUT干扰的APD值

    图6  EUT干扰的APD值测量结果

    然后再用频谱仪和APD分析仪测量EUT干扰的APD值，测量方法见图5。测量结果见图6，横轴为干扰电压，纵轴是概率，最左边曲线是EUT不工作情况，右边4条曲线是EUT发出不同强度干扰时的APD。由图6可知当概率确保在10-2条件下，干扰的层电压增加了V。

    实验和仿真结果证明:当误码率和干扰概率相等的情况下，测误码率时U的增加量U和测APD时干扰V的增加量V有很明显的相关性。因此可以利用这种相关性来确定APD的限值点。通常要求通信系统话音传输的BER为10-2，数据传输的BER为10-4。由此可规定APD的概率限值Plimit分别为10-2,10-4。再根据二者的相关性，由图6中的V,得出与Plimit10-2和10-4相应的两个电平限值Vlimit值。

    APD测量仪的规范[1]

    3.1APD测量仪的指标要求

    以上分析了CISPR关于APD测量方法、APD限值的确定的进展，下面进一步介绍APD测量仪的指标要求。

    APD测量功能可作为测量设备的附加功能，附加到现有测量仪器或使用一体化测量仪器上。APD测量功能可由两种方法实现:一种使用比较器和计数器，如图7所示，设备确定超出一组预设电平的概率，电平的数目等于比较器的数目;另一种使用A/D变换器、逻辑电路、存储器，如图8所示，该设备也可提供预设电平的APD图，电平的数目取决于A/D变换器的分辨率（如8bit变换器提供256级电平）。

    图7  APD测量电路（比较器、计数器）框图

    图8  APD测量电路（A/D变换器）框图

    3.2APD测量功能的规范

    如果能够判定设备或设备系列可能造成对数字通信系统的干扰，APD测量就可应用于这些产品。下面是应用于APD测量功能的规范。

    （1）幅度动态范围:大于60dB。

    幅度的动态范围定义为获得APD的必要范围。动态范围的上限应大于要测量的骚扰的峰值电平，下限应低于产品委员会规定的骚扰限值电平。根据CISPR11中，对于ISM设备，group2，ClassB，峰值限值规定为110dBμV/m，加权限值指定为60dBμV/m。因此提议动态范围大于60dB，并有10dB余量。

    （2）幅度精度（包括阀值电平设置误差）:优于±2.7dB。

    （3）骚扰最大测量时间:≥2min，测量中断时间小于总测量时间的1%。

    CISPR11为1GHz以上的微波烹饪器具的峰值测量制订的最大保持时间为2min一周期，因而APD的测量时间的最小值为2min。因为计数器或存储器的数量是有限的，对于长测量周期，连续测量可能有困难，因此，在测量中断时间小于总测量时间的1%的条件下，允许间断测量。

    （4）APD测量功能可分配至少两级电平，能够同时测量所有预设电平的概率，预设电平的分辨率优于:0.25dB。

    （5）最小可测概率:10-7。

    为获得有意义的测量结果，测量过程中出现约100次取值是必要的。因此最小可测概率计算如下:

    假定测量时间2min，采样率10M/s，概率确定为

    100/(12010106)～10-7。

    （6）采样率:≥10M/s（分辨带宽1MHz）。

    理想情况下，使用要保护的无线设备的等效带宽测量骚扰的APD。然而，对于1GHz以上的频率范围频谱分析仪的分辨带宽指定为1MHz，因而采用率应大于10M/s。

    （7）推荐规范:使用A/D变换器时，测量结果显示的幅度分辨率优于:0.25dB。

    APD结果显示的分辨率取决于动态范围和A/D变换器的分辨率。例如，使用8bitA/D变换器，动态范围60dB时，显示的分辨率小于0.25 dB（60 dB/256）。

    总结

    传统的测量方法，如准峰值检波、有效值检波，是测量干扰对系统影响的最终结果，与干扰的本质有关，还同系统的性能有关，这给无线干扰的测量带来了不确定因素。随着无线技术的发展，干扰的研究是测量行业面临的突出问题——必须寻找新的测量方法，对其进行评估，而APD测量结果是干扰本身的统计特性，与系统性能无关，所以更具有广泛性和适宜性，但APD技术现在只是摸索阶段，标准化和产品化进程相对缓慢。

    根据CISPR的进展可知，有关APD的内容有三部分:

    （1）APD测量仪的指标要求——CISPR/A分会已于2006.2.24全部通过，不久就会写进第二版CISPR16-1-1中。

    （2）APD测量方法——已进入CDV阶段，即将付与投票，建议加入CISPR16-2-3中。

    （3）APD限值的确定（APD与BER的关系）——CISPR/A分会已写出指南，发给各产品委员会，等待他们提出建议。限值确定以后，将加入CISPR-16-3中。

    国内的测量界同仁们应积极跟踪APD技术，制订相关测试标准，研制相关仪器仪表，开展相关的测试工作，更好地服务于干扰的测量和研究，为无线电监测和设备检测提供更科学、更准确的测量方法和手段。

    参考文献

    [1]CISPR/A/594/DC:Guidancefor applying the APD method to compliance testing and for developing APD emission limits.

    [2]CISPR16-1-1Ed.2: Specification for radio disburbance and immunity measuring apparatus and methods-Part 1-1: Radio disturbance and immunity measuring apparatus - Measurement apparatus.

30MHz电磁波具有复杂的传播特性：

 

30MHz电磁波是短波和超短波的分界，可以通过地波传播和天波传播。

地波传播时，30MHz电磁波表现出复杂的反射和绕射现象。

有很多设备，如对讲机，利用其绕射进行近距离通信。

 

天波传播时，30MHz电磁波处于电离层反射频率的边缘。

白天电离层密度较大，通过电离层反射，可以达到很好的通信质量。

电离层密度较小时不能对其形成反射。

但可以通过电离层散射传播。

也可以透过电离层使用卫星通信。

 

信道色散：

 

信道中主要有两类衰落：大尺度衰落和小尺度衰落。

 

大尺度衰落是由于在大范围内移动而引起的平均信号能量的减少或路径损耗，这种现象产生的原因是收、发端之间地表轮廓的影响，通常称接收机被这些突出物“遮挡”了。

小尺度衰落是指信号的幅值、相位的动态变化，这种变化是由于收、发端之间空间位置的微小变化(小至半个波长)引起的。

小尺度衰落表现为两种机制：信号的时延扩展和信道的时变特性。

 

直射波损耗：

直射波传播损耗可看成自由空间的电波传播损耗：

 

绕射波损耗：

各种障碍物对电波传输所引起的损耗。

 

菲涅尔余隙：

图中x表示障碍物顶点P至直线TR之间的垂直距离，在传播理论中x称为菲涅尔余隙。

（a）     负余隙

（b）    正余隙

 

障碍物引起的绕射损耗与菲涅尔余隙之间的关系：

当横坐标x/x1>0.5时，则障碍物对直射波的传播基本上没有影响。当x=0时，TR直射线从障碍物顶点擦过时，绕射损耗约6dB；当x<0时，TR直射线低于障碍物顶点，损耗急剧增加。其中x1称菲涅尔半径（第一菲涅尔半径）

 

反射波相位损耗：

      

       反射波与直射波的行距差为：

             

             

       两路信号到达接收天线的时间差换算成相位差为：

散射波损耗：

 

       散射波产生于粗糙表面，小物体或其他不规则物体。实际的通信系统中，树叶、街道标志和灯柱等会引发散射。

 

多径效应：

       设发射机发出的信号为：

       则接收机接收端收到的合成信号为：

 

 

 

式中      为第i条路径的接收信号；     为第i条路径的传输时间；     为第i条路径的相位滞后.

     和       随时间的变化与发射信号的载频周期相比，通常要缓慢得多，所以，可以认为是缓慢变化的随机过程。

所以      可写成：

 

 

 

 

市区传播衰耗：

 

在城市街道地区，电波传播衰耗取决于传播距离、工作频率、基地站天线有效高度、移动台天线高度以及街道的走向和宽度等。

OM模型中，给出了准平滑地形，市区传播衰耗中值的预测曲线族。但OM模型适用的范围：频率150MHZ ~1500MHZ（可扩展到3000MHz），基地站天线高度为30~200米，移动台天线高度为1~10米，传播距离为1~20千米的场强预测。 

综上：

30MHz电磁波信道的复杂性和多变性，很难用一准确的模型来描述它。可以采用统计的方法对信道进行描述，并建立信道的统计模型。

 

Longley-Rice模型：

       Longley-Rice模型的计算基于计算机的统计模型，可以用来仿真计算30MHz信号的模拟预测。

Longley-Rice模型以传播理论为依据，同时结合了数千组实测数据，因此称其为半经验预测模型Longley-Rice模型预测损耗值的计算基于不同传播范围：①在视距内，以反射传播机制为主，用双线模型计算；②在超视距，以衍射传播机制为主，但对于不规则地形 ，有两种理论用于计算衍射损耗，它们分别适用于非球形但光滑的地面和非常不规则的地面，用刀口模型计算，超视距衍射损耗计算结果是以上两种理论计算结果的加权 ；③对于更远距离(大大超出地平线)，以前向散射传播机制为主。

Longley-Rice模型中的实测数据大多数取自10～1000 MHz的频率范围，其中20～100 MHz的数据涉及 5--50 km的距离和 1～9m的收、发信天线高度 ；较高频段的数据涉及 5～1 000 km的距离，10～1500m的发射天线高度和 3～9 m的接收天线高度．数据来源于世界各地，但主要是美国，多数为移动记录结果．Longley-Rice模型给出了参考衰减值的计算公式及不同环境下相关修正因子的详细说明，公式中所使用的参数包括：不规则地形参数、频率、收发信机天线高度和表面折射率等．同时还引入了反映介质特性的两个参数：介电常数和导电率．

以传播理论为依据，加上极其丰富的实测数据，使得 Longley-Rice模型使用范围得到了拓展，其适用范围如下：频率范围为 20～40000 MHz，收发信机天线高度为0.5～3 000 m，覆盖半径为 1～2 000 km，表面折射率为 250～400 Ns．

（有一个估算公式，没找到）。

SQL0440

A SQL0444 error indicates that the procedure with compatible arguments could not be found. This error does not indicate a serious problem, and it usually occurs at run time. There are two common causes:

• CREATE PROCEDURE statement was not issued to define a procedure at the current server. Therefore DB2 is unable to locate the procedure.

  Solution: Issue the missing CREATE PROCEDURE statement.

• The procedure is invoked with an incorrect number of agruments. That is, you may have provided an incorrect number of input or output parameters, or you may have provided an improper data type in one of the parameters. Therefore, DB2 could not find a procedure with the matching arguments to invoke.

  Solution: Check the CREATE PROCEDURE statement and make sure you are passing the correct number of input and output parameters with proper data types.

Here is an example of the second situation where an incorrect number of parameters are passed to the procedure during runtime. This example uses the sample stored procedures OUT_LANGUAGE and ALL_DATA_TYPES that are shipped with the DB2 product. You may locate the source code in /instance_home/sqllib/samples/java/jdbc/SpServer.java, and the corresponding CREATE PROCEDURE statements in /instance_home/sqllib/samples/java/jdbc/SpCreate.db2 on UNIX platforms, where instance_home is your instance home directory. On Windows, the default location of the files are in C:\Program Files\IBM\SQLLIB\samples\java\jdbc\SpServer.java and C:\Program Files\IBM\SQLLIB\samples\java\jdbc\SpCreate.db2.
Listing 41. SQL0440 example: Calling the OUT_LANGUAGE() and ALL_DATA_TYPEs procedure on Windows

D:\>db2 call out_language() SQL0440N No authorized routine named "OUT_LANGUAGE" of type "PROCEDURE" having compatible arguments was found. SQLSTATE=42884 D:\>db2 call all_data_types (32000, 2147483000, 21478483000, 100000, 2500000) SQL0440N No authorized routine named "ALL_DATA_TYPES" of type "PROCEDURE" having compatible arguments was found. SQLSTATE=42884

Let's take a look at why SQL0440 is returned. First look at the CREATE PROCEDURE statement to confirm what parameters each of the stored procedures expects.
Listing 42. SQL0440 example: CREATE PROCEDURE statements for OUT_LANGUAGE and ALL_DATA_TYPES procedures

CREATE PROCEDURE OUT_LANGUAGE (OUT LANGUAGE CHAR(8)) SPECIFIC JDBC_OUT_LANGUAGE DYNAMIC RESULT SETS 0 DETERMINISTIC LANGUAGE JAVA PARAMETER STYLE JAVA NO DBINFO FENCED THREADSAFE READS SQL DATA PROGRAM TYPE SUB EXTERNAL NAME 'SpServer.outLanguage' CREATE PROCEDURE ALL_DATA_TYPES ( INOUT small SMALLINT, INOUT intIn INTEGER, INOUT bigIn BIGINT, INOUT realIn REAL, INOUT doubleIn DOUBLE, OUT charOut CHAR(1), OUT charsOut CHAR(15), OUT varcharOut VARCHAR(12), OUT dateOut DATE, OUT timeOut TIME) SPECIFIC JDBC_ALL_DAT_TYPES DYNAMIC RESULT SETS 0 NOT DETERMINISTIC LANGUAGE JAVA PARAMETER STYLE JAVA NO DBINFO FENCED THREADSAFE READS SQL DATA PROGRAM TYPE SUB EXTERNAL NAME 'SpServer.allDataTypes'

From the CREATE PROCEDURE statements, you can see that:

1. The OUT_LANGUAGE procedure expects one output parameter of type char.
2. The ALL_DATA_TYPES procedure expects 5 input/output parameters, and 5 output parameters, where each of the argument types expected is shown above.

For input parameters, provide a proper value with the correct data type. For output parameters, use a '?' for each output parameter. For input/output parameters, since they are used for both input and output purposes, provide the proper value as if you are just passing a value for an input parameter. Therefore, you should call each of the procedures like below:
Listing 43. SQL0440 example: Calling the OUT_LANGUAGE and ALL_DATA_TYPES procedures properly

D:\>db2 call out_language(?) Value of output parameters -------------------------- Parameter Name : LANGUAGE Parameter Value : JAVA Return Status = 0 D:\>db2 call all_data_types (32000, 2147483000, 21478483000, 100000, 2500000, ?, ?, ?, ?, ?) Value of output parameters -------------------------- Parameter Name : SMALL Parameter Value : 16000 Parameter Name : INTIN Parameter Value : 1073741500 Parameter Name : BIGIN Parameter Value : 10739241500 Parameter Name : REALIN Parameter Value : +5.00000E+004 Parameter Name : DOUBLEIN Parameter Value : +1.25000000000000E+006 Parameter Name : CHAROUT Parameter Value : S Parameter Name : CHARSOUT Parameter Value : SCOUTTEN Parameter Name : VARCHAROUT Parameter Value : MARILYN Parameter Name : DATEOUT Parameter Value : 09/27/2005 Parameter Name : TIMEOUT Parameter Value : 11:30:16 Return Status = 0

For more information about how to call procedures from the Command Line Processor (CLP), see this URL: http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.udb.doc/ad/t0007055.htm.

The installation validation utility failed to connect to your library server or resource manager database.

Info: Project structure did not need migration: eclient.
Info: Project structure did not need migration: eclient82.
 J2EE version level migration successful: eclient.
 Migration was completed for platform:/resource/eclient/META-INF/application.xml.
 J2EE version level migration successful: eclient82.
 Migration was completed for platform:/resource/eclient82/WebContent/WEB-INF/web.xml.
Info: Project structure did not need migration: eclient.
Info: Migration was not required for platform:/resource/eclient/META-INF/application.xml.

 

 

J2CA0106E: A 5.0 DataSource was attempted to be used in a WebModule that was not level 2.3

Technote (FAQ)   Problem When a Web application tries to use a data source in WebSphere® Application Server V5.0, V5.1 or V6.0, the following error may occur: J2CA0106E: A 5.0 DataSource was attempted to be used in a WebModule that was not level 2.3   Cause WebSphere Application Server V5.0 and V5.1 support servlets that comply with the Servlet 2.2 or Servlet 2.3 specifications. WebSphere Application Server V6.0 supports servlets at the Servlet 2.2, 2.3, or 2.4 specifications. You can review the differences between the Servlet specifications here. In WebSphere Application Server V5.0, V5.1 and V6.0, servlets at the 2.2 specification level cannot use a standard data source. Such servlets must use a data source that is defined as a Version 4 data source. In the JDBC Provider configuration in the administrative console, you can create either Data Sources or Data Sources (Version 4). Standard data sources are sometimes referred to as Version 5 data sources. The application developer must decide which Servlet specification level to use. The selection is made when packaging the application using the Application Server Toolkit, WebSphere Studio Application Developer (WSAD), Rational® Application Developer (RAD), or a third-party development tool. The Application Server Toolkit or the development tool will generate a deployment descriptor, web.xml, for the Web application. The web.xml is generated differently depending on the Servlet specification level that is chosen. WebSphere Application Server will read the web.xml to determine the specification level of the servlet at runtime. If the servlet is at the 2.2 specification level and tries to use a standard data source, the J2CA0106E error will occur.   Solution To resolve the problem, you can create a Version 4 data source and have the application use it instead of the standard data source. You can also use the Application Server Toolkit or your development tool to migrate your web application to the Servlet 2.3 or 2.4 specification. To determine which Servlet specification your application is using, check the web.xml packaged within the .war file. For a Servlet 2.2 application, you will see: <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> For a Servlet 2.3 application, you will see: <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> For a Servlet 2.4 application, you will see: <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

改变：
· 需要JDK1.2或更高版本
· 增加FILTER机制
· 增加应用程序生命周期事件
· 增加新的国际化支持
· 增加有关inter-JAR依赖关系的规定
· 澄清了加载类的规则
· 增加新的错误和安全属性
· 废弃HttpUtils类
· 增加了各种各样有用的方法
· 扩展和澄清了几个DTD行为
· 其他有关Server开发商的有关说明改动

与J2EE的关系
· Servlet API 2.3成为J2EE 1.3的核心API
· 在web.xml中定义了J2EE相关的deployment descriptor
· <resource-env-ref>标记被用来支持如Java Messaging System (JMS)所必须的"administered objects"
· <res-ref-sharing-scope>标记规定了对于资源引用的访问方式
· <run-as>规定了EJB调用者的安全特性
· 大部分的Servlet开发者不需要关心这些J2EE标记

过滤器(filters)
Servlet API 2.3中最重大的改变是增加了filters，filters能够传递request或者修改response。 Filters并不是servlets；它们不能产生response。 你可以把过滤器看作是还没有到达servlet的request的预处理器，或从servlet发出的response的后处理器。 一句话，filter代表了原先的"servlet chaining"概念，且比"servlet chaining"更成熟。 filter能够:
· 在servlet被调用之前截取servlet
· 在servlet被调用之前查看request
· 提供一个自定义的封装原有request的request对象，修改request头和request内容
· 提供一个自定义的封装原有response的response对象，修改response头和response内
· 在servlet被调用之后截取servlet
· 对serlvet进行分组管理;每个servlet或每组servlet可以配置多个filters

javax.servlet.Filter实现了以下方法：
· public void init(FilterConfig filterConfig)throws ServletException：
初始化操作
· public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain)throws java.io.IOException,ServletException：执行实际的过滤的操作
· public void destroy()：释放资源

每个request和response都会传到filter的doFilter()方法中, 也就是说在FilterChain对象中包含着所有将被执行的filters。一个filter可以在doFilter()方法中对request和response进行处理。 (它能够通过调用其他的方法获得数据，或赋予获得的对象新的行为。) 然后，当前的filter调用chain.doFilter()方法把控制权传递给下一个filter。 在调用返回时, filter能够在doFilter()方法结束的地方，对response进行附加的处理，例如，对response进行日志管理。如果filter想停止request处理过程并获得对response的完全控制，则不要去调用下一个filter。

filter能够通过包装request和/或response对象来提供自定义的行为，改变某个方法的调用实现影响以后的request操作动作.API 2.3提供了新的HttpServletRequestWrapper和HttpServletResponseWrapper类来协助实现；这两个类提供了所有request和response方法的缺省实现, 并且缺省地代理了所有对原有request和response的调用。这意味着要改变一个方法的行为只需要从封装类继承并重新实现一个方法即可。封装类在处理request和生成response方面为filters提供了极大的控制方式。对所有的request的执行过程进行记录的一个简单的日志过滤器的例子代码如下：
当server调用init()方法时, filter把config的引用保存到config变量中, 在后面用到的doFilter()方法中将使用这个变量获得ServletContext.。doFilter()方法中的实现很简单：对request进行计时并在处理完成的时候记录下来。 要使用filter, 必须在web.xml文件中定义<filter>标记, 如下所示:[pre]
<filter>
    <filter-name>log</filter-name>
    <filter-class>LogFilter</filter-class>
</filter>[/pre]
上述定义告诉server名字为log的filter的实现类是LogFilter类，然后使用<filter-mapping>标记把注册过的filter与特定的URL映射模式或servlet名对应起来：
[pre]
<filter-mapping>
    <filter-name>log</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>[/pre]
这个配置使filter对所有发送到server的请求起作用(包括静态请求和动态请求)，达到了日志过滤器的作用。 当你访问一个简单的页面上时，输出的日志有可能如下：

Request to /index.jsp: 10

生命周期事件
Servlet API 2.3第二个意义重大的改变是增加了应用程序生命周期事件，即当servlet contexts和sessions被初始化或释放时，当向context或session上添加或删除属性的时候，通知"listener"对象.

Servlet生命周期事件与Swing的事件机制类似。对ServletContext生命周期进行观察的监听器必须实现 ServletContextListener接口。这个接口有两个方法：
· void contextInitialized(ServletContextEvent e)：当Web application第一次准备处理requests的时候(例如：Web server启动并且context被加载和重新加载时)。 本方法返回之前不开始处理Requests
· void contextDestroyed(ServletContextEvent e)：在Web application要被关闭的时候(例如：当Web server关闭或当一个context被移去或重新加载的时候)。本方法调用时Request处理已经停止.

传入这些方法的ServletContextEvent类只有一个返回被初始化或被移去的context的getServletContext()方法。

对ServletContext属性生命周期进行观察的监听器必须实现ServletContextAttributesListener接口，这个接口有三个方法：
· void attributeAdded(ServletContextAttributeEvent e)：当属性被加到servlet context上时调用
· void attributeRemoved(ServletContextAttributeEvent e)：当属性被从servlet context上移走时调用
· void attributeReplaced(ServletContextAttributeEvent e)：当servlet context上的属性被另一个属性所代替的时候调用

继承于ServletContextEvent的ServletContextAttributeEvent类，增加了getName()和getValue()方法,这两个方法使监听器得到正在被改变的属性的相关信息。现在对于需要同步应用程序状态(context属性)的应用程序来说，如数据库处理，能够方便的在这个地方进行统一的处理。

session listener model与context listener model类似。在session事件模型中, 有一个拥有两个方法的HttpSessionListener接口：
· void sessionCreated(HttpSessionEvent e)：当session创建时被调用
· void sessionDestroyed(HttpSessionEvent e)：当session被释放时或无效时被调用

这些方法接受一个拥有返回被创建或被释放的session的getSession()方法的HttpSessionEvent类实例。可以使用这些方法实现一个对Web application中所有的活动用户进行跟踪的管理者接口。

session事件模型还有一个HttpSessionAttributesListener接口，这个接口有三个方法。这些方法告诉监听器属性何时改变,何时能够被使用：
· void attributeAdded(HttpSessionBindingEvent e)：当属性被加到session上时调用
· void attributeRemoved(HttpSessionBindingEvent e)：当属性被从session上移去时调用
· void attributeReplaced(HttpSessionBindingEvent e)：当session上的属性被另一个属性所代替的时候调用

与你所猜想的一样, HttpSessionBindingEvent类继承于HttpSessionEvent接口,并且加入了getName()和getValue()方法. 唯一一点不一样的地方是事件类的名字是HttpSessionBindingEvent，而不是 HttpSessionAttributeEvent。合理的解释是：原有的API已经存在了一个名为HttpSessionBindingEvent的事件类， 因此这个事件类被重用。 

生命周期事件的一个实际应用由context监听器管理共享数据库连接。在web.xml中如下定义监听器：[pre]
<listener>
    <listener-class>com.acme.MyConnectionManager</listener-class>
</listener>[/pre]server创建监听器的实例接受事件并自动判断实现监听器接口的类型。要记住的是由于监听器是配置在deployment descriptor中，所以不需要改变任何代码就可以添加新的监听器。监听器的例子如下:

监听器保证每新生成一个servlet context都会有一个可用的数据库连接,并且所有的连接对会在context关闭的时候 随之关闭。

API 2.3新增的HttpSessionActivationListener监听器接口的目的是处理在server之间传送的session。实现HttpSessionActivationListener的监听器在session要被钝化(移动)和session在其它的主机上要被激活(开始活动)的时候被通知。使用这个接口可以在JVM之间长久保存没有进行序列化的数据，或者是在移动session前后对序列化的对象执行一些附加的操作。这个接口有两个方法：
· void sessionWillPassivate(HttpSessionEvent e)：session将被钝化。 此时session已经超出了service的管理范围
· void sessionDidActivate(HttpSessionEvent e)：session已经被激活。此时session还没有进入service的管理范围

这个监听器接口与其他的监听器接口在原理上类似。然而与其它监听器不同的是，钝化和激活的调用很有可能发生在两个不同的server中!

选择字符编码方式
API 2.3对处理不同语言的表单提交方式的迫切需要提供了新方法，request.setCharacterEncoding(String encoding)，告诉server一个request的字符编码。字符编码也叫做字符集，反映了字节到字符的映射模式。server能够使用指定的字符集正确的解析参数和POST数据。缺省情况下，server使用常用的Latin-1(ISO 8859-1)字符集解析参数。然而这只能在使用西方和欧洲的语言的情况下正常工作。当浏览器使用其他的字符集时，假设在request的Content-Type头中传送编码信息，但是没有多少浏览器这样做。通过使用这个方法，servlet能够通知server使用哪一种字符集，server只需关注其余部分。例如, servlet从以Shift_JIS编码方式的表单接受并读取Japanese参数的代码如下：[pre]
// Set the charset as Shift_JIS
req.setCharacterEncoding("Shift_JIS");

// Read a parameter using that charset
String name = req.getParameter("name");[/pre]
记住在调用getParameter()方法或getReader()方法之前设置编码。setCharacterEncoding()对于不支持的编码会抛出java.io.UnsupportedEncodingException。

JAR dependencies
通常情况下，WAR文件(Web application归档文件，在API 2.2中加入)需要各种JAR类库对server提供必要的支持和正确的操作。例如，一个使用ParameterParser类的Web application需要在它的classpath存在cos.jar文件。使用WebMacro的Web application需要webmacro.jar文件。在API 2.3之前，这些要用到的从属文件必须在文档中说明(相当于每个人都要读说明文档!) 或者是每个Web application不得不把它所需要的所有的jar文件包含在自身的WEB-INF/lib目录中(完全无必要的使Web application变得膨胀起来)。

在Servlet API 2.3中，可以通过WAR文件中的META-INF/MANIFEST.MF文件来表示从属的jar文件与WAR文件之间的关系。 这是定义jar文件依赖关系的标准方法，但是在API 2.3中，WAR 文件必须正式的支持上述的机制。如果一个规定的从属条件不能够被满足，server能够在拒绝Web application的发布，而不是在运行时刻产生晦涩难懂的错误消息。 The mechanism allows a high degree of granularity（不知如何翻译）。例如，可以指定一个可选包的特定的版本作为Web application的从属包，那么server就必须以一种算法找到所指定的那个包。

Class loaders
在这儿虽然只改动了一点点，但是影响很大：在API 2.3中，一个servlet容器必须确保server的实现类对于Web application所使用的类是不可见的。换句话说，class loaders应该被独立的保存起来。

这听起来好像没什么，但是这样做消除了Web application的classes和server classes之间可能存在冲突的机会。在使用XML解析器上这已经成为一个严重的冲突问题。每个server都需要一个XML解析器解析web.xml文件，并且许多Web applications也使用XML解析器对XML数据进行读，写或其他处理。如果解析器支持不同版本DOM或SAX，就可能导致无法挽回的冲突。规定不同的类的独立性很好的解决了这个问题。

新的错误属性
在Servlet API 2.2中引入了几个request属性，引入的属性在满足<error-page>规定的条件时，能够被Servlet和JSP所用到。它的作用是让你可以在Web application中配置当出现特定的错误类型和特定的异常类型时，可以显示个用户指定的页面：[pre]
<web-app>
<!-- ..... -->
    <error-page>
        <error-code>404</error-code>
        <location>/404.html</location>
    </error-page>
    <error-page>
        <exception-type>javax.servlet.ServletException</exception-type>
        <location>/servlet/ErrorDisplay</location>
    </error-page>
<!-- ..... -->
</web-app>[/pre]
由<error-page>标记所规定的的在<location>标记中的servlet能够使用下表的三个属性：
· javax.servlet.error.status_code：错误类型的整形值
· javax.servlet.error.exception_type：产生错误的异常类的实例
· javax.servlet.error.message：异常信息字符串

使用这些属性,servlet能够自定义错误页面，例:
设想一下，如果错误页面中能够包含产生异常的堆栈信息或者包含导致问题产生的servlet的URI(导致问题产生的servlet的URI通常都不是最开始进行请求的那个URI)，情况如何？在API 2.2中是不可能的。而API 2.3中可以从以下表的两个属性获得这些信息：
· javax.servlet.error.exception：实际的异常掷出的Throwable对象
· javax.servlet.error.request_uri：导致问题产生的资源的URI字符串对象

这些属性能够让错误页面包含异常的堆栈信息和产生问题的资源的URI。下面的servlet例子使用了新属性。
新的安全属性
Servlet API 2.3增加了两个新的request属性，有助于一个使用HTTPS连接的servlet获得有关的某些信息。对于使用HTTPS加密的servlet，server支持下面列出的新加的request属性：
· javax.servlet.request.cipher_suite：HTTPS所使用的密码组
· javax.servlet.request.key_size：加密算法所使用的密钥长度

servlet可以在程序中使用这些属性决定是否一个网络连接拥有足够的安全强度。应用程序可以拒绝加密位数不够长或使用不信任算法的那些连接。例如，下面的方法判断连接是否使用了不低于128位长度的密钥进行加密。
细微的调整
在API 2.3中还存在一些细微的调整之处。首先，在HttpServletReques类中定义了新的四个静态的不可变的字符串型的常量：BASIC_AUTH，DIGEST_AUTH，CLIENT_CERT_AUTH，和FORM_AUTH。与之对应的是用来获得客户端使用哪一种认证方式的getAuthType()方法的代码可以如下书写：
与API 2.2兼容，原有的判断方式同样能够使用，但是不符合代码的规范性。注意将"BASIC"放在equals()之前能够避免在getAuthType()方法返回null的时候产生空指针异常：
另一个API 2.3中的改变是HttpUtils类，这个类不再被推荐使用。HttpUtils可以被认为是一组静态方法的集合，这些方法有时非常有用，但是可以把他们放到其他更合适的地方。 API 2.3把这些功能移到了request对象中，显得更为合理。request对象中的新方法如下：
· StringBuffer req.getRequestURL()：返回一个从request信息中获得的包含原始· request URL的StringBuffer对象
· java.util.Map req.getParameterMap()：返回一个包含request参数的不可变的Map对象。参数名和参数值分别对应Map对象中的关键字和值。但是不能确定拥有多个参数值的参数的处理方式，很可能，所有的值由一个String[]对象表示。

这些方法使用新加的req.setCharacterEncoding()方法来处理字符编码转换。

API 2.3同样增加了两个关于ServletContext的新方法，这两个新方法可以得到context的名字和context的资源列表
· String context.getServletContextName()：返回在web.xml中定义的context的名字
· java.util.Set context.getResourcePaths()：返回context中所有可用的资源路径，返回值类型为一个包含String对象的不可变的Set对象。每个String对象的内容以斜线(’/’)开始并相对于context的根目录

response对象也增加了一个新的方法，这个方法增加了对response buffer的程序上的控制。API 2.2中引入了res.reset()方法重置response和清空response的内容，头和状态码。API 2.3添加了res.resetBuffer()方法只用来清空response内容: 
· void res.resetBuffer()：清空response buffer，不清空头和状态码。如果response已经被输出，掷出IllegalStateException异常。

最后，在一组专家们长期的辩论后，Servlet API 2.3确定了当一个不在context根目录的servlet调用res.sendRedirect("/index.html")的时候，将会产生什么行为。在Servlet API 2.2 中对一个不完整的路径如"/index.html"发出请求，将会被servlet container转换成一个完整的路径，但是没有说明context路径是如何被转换的。如果context中的servlet要访问的路径是"/index.html"，redirect URI将这个路径转换成相对容器的根目录(http://server:port/index.html)，还是相对于context的根目录(http://server:port/contextpath/index.html)呢？从最大的可移植性方面考虑，这个行为必须被确定下来；在争论了很长时间之后，专家们选择了将其转换化成相对于容器根目录的方案。对于那些坚持相对于context的人，可以使用getContextPath()方法获得相对于context的URL结果。

DTD的修正
最后，Servlet API 2.3增加了对web.xml deployment descriptor行为的一些要求。在使用web.xml文件之前，必须除去文本值两端的空格。(在不需要进行校验的标准XML中，通常情况下保留所有的空格。)这个规定保证了如下的两个条目以相同的方式被进行处理：
API 2.3提供了<auth-constraint>标记规则，特殊值"*"作为<role-name>的通配符表示允许所有的roles访问。如下的xml定义表示当前Web application中所有的用户只要属于Web application中所定义任何一个role，就可以对响应的web资源进行访问：[pre]
<auth-constraint>
    <role-name>*</role-name> <!-- allow all recognized roles -->
</auth-constraint>[/pre]
最后，澄清了在isUserRole()方法中所用到的参数问题，参数可以使用在<security-role>中定义的角色。 例，在web.xml实体中定义的脚本片段：[pre]
<servlet>
    <servlet-name>secret</servlet-name>
    <servlet-class>SalaryViewer</servlet-class>
    <security-role-ref>
        <role-name>mgr<!-- name used by servlet --></role-name>
        <role-link>manager<!-- name used in deployment descriptor --></role-link>
    </security-role-ref>
</servlet>

<!-- ... -->

<security-role>
    <role-name>manager</role-name>
</security-role>[/pre]
无论servlet调用isUserInRole("mgr")还是调用isUserInRole("manager")方法，所获得的结果是一致的。从根本上说，security-role-ref作用是生成一个别名，但并不是必须的。虽然这显得好像本来就应该如此，但是API 2.2规范中叙述到只能够使用那些明确在<security-rike-ref>别名规则中定义的角色。
               Servlet API 2.3的变更
新增加的类
Filter, FilterChain, FilterConfig, ServletContextAttributeEvent, ServletContextAttributesListener, ServletContextEvent, ServletContextListener, ServletRequestWrapper, ServletResponseWrapper, HttpServletRequestWrapper, HttpServletResponseWrapper, HttpSessionActivationListener, HttpSessionAttributesListener, HttpSessionEvent, HttpSessionListener
新增加的方法
getResourcePaths(), getServletContextName(), resetBuffer(), HttpSessionBindingEvent.getValue()
新增加的属性
BASIC_AUTH, DIGEST_AUTH, CLIENT_CERT_AUTH, 和FORM_AUTH
不再被推荐使用的类
HttpUtils

    FDTD方法实际上是以一组有限差分方程来代替麦克斯韦旋度方程，即以差分方程组的解来代替原来电磁场偏微分方程组的解。只有离散后差分方程组的解是收敛和稳定的，这种代替才有意义。所谓收敛性是指当离散间隔趋于零时，差分方程的解在空间任意一点和任意时刻都一致趋于原方程的解。所谓稳定性是指寻求一种离散间隔所满足的条件，在此条件下差分方程的数值解与原方程的严格解之间的差为有界。
    FDTD方法的数值稳定性条件为

 

在各向同性介质中麦克斯韦旋度方程为

    时域有限差分法 (Finite-Difference Time-Domain Method简称FDTD Method)是求解电磁问题的一种数值技术，1966年由K.S.Yee在其论文“Numerical Solutionof Initial Boundary Value Problems Involving Maxwell's Equation in Isotropic Media"中首次提出1"'. FDTD方法直接将有限差分式代替麦克斯韦时域场旋度方程中的微分式，得到关于场分量的有限差分式，用具有相同电参量的空间网格去模拟被研究体，选取合适的场初始值和计算空间的边界条件，就可得到包括时间变量的麦克斯韦方程的四维数值解，通过傅立叶变换还可求得三维空间的频域解。
    近二十多年来 FDTD方法经历了一个蓬勃发展的过程，己经成为一种成熟的时域数值方法[251。从目前水平看，在分析一般散射问题中，数值误差约在1%-3%附近 (RCS的误差略大些)，而在求谐振器本征值问题中，FDTD数值解与理论值误差低于百分之一，某些情况甚至能小于千分之一。可以毫无夸张地说，FDTD方法与其他数值方法从计算精度上讲是可以媲美的，有的则有胜过。加之 FDTD法得到的是时域解，通过傅立叶变换可得到频域解，具有一次时域计算代替频域上逐点计算的潜力，这些均表明FDTD方法与同类数值算法相比具有明显的优势。

尤其近十几年来，随着计算机性能的不断提高和算法的不断完善，FDTD方法更具有吸引力，每年都有大量的相关文章见诸各种刊物1261。今天，它不仅在电磁散射、电磁兼容预测以及生物电磁学中得到卓有成效的应用，而且在天线、微波技术、光电子学等领域也愈益受到人们的重视。

    FDTD方法的基本点如下:

    - Yee元胞。最初由Yee提出的E, H场分量取样节点在空间和时间上采取交替排布，每一个E(或H)场分量周围有四个H(或E)场分量环绕，应用这种离散方式将麦克斯韦旋度方程转化为一组差分方程，并在时间轴上逐步推进求解空间电磁场。由电磁问题的初始值及边界条件就可以逐步求得以后各时刻空间电磁场分布。在计算的过程中将空间的电场(或磁场)与周围修点的磁场(或电场)直接相关联，电磁参数在关联系数中得以体现。由于介质参数己反映在空间每一个元胞的电磁场的计算中，因此这一方法可以处理复杂形状目标和非均匀介质物体的电磁散射问题。

    - FDTD区。在FDTD计算区域中引入总场一散射场连接边界(图1.1所示)，这样使FDTD计算区域划分为总场区和散射场区。其优点在于:(1)将入射波置于该边界上，使任意入射波 (无论是平面波或柱面波，时谐场或瞬态场)的模拟变得简单易行;(2)使只吸收单向行波的吸收边界条件设置得以实现;(3)便于应用散射场数据进行远场的外推计算。但对于辐射问题，激励源直接加到辐射天线上，整个FDTD计算区域为辐射场 〔图1.2所示)，不再区分总场区和散射场区。

 

我希望每天都送花给你
一直到老

一步一步我为你开路
依着你才知道什么叫孤独

谢谢

 
你的眼神在对我倾诉
像阳光静静爱上蜡烛
你好吗

我用微笑慰抚
无言的爱给你
我的手势是一首歌词
风吹过城市

带来了你的天使
我愿意代替你哭泣

我以前没有勇气去认识你
我现在来这儿
是告诉你
我好想你

我很喜欢你