上上签's Blog - Windows Live

RJ's profile上上签PhotosBlogListsMore

Tools

Help

<< First < Previous Next > Last >>

April 03

migration form jdk1.2 to jdk 1.3

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.

11:05 AM | Add a comment | Permalink | Blog it

March 30

Talking about 射频/仿真工具

Quote

射频/仿真工具

ADS2004A  ADS2003C  HFSS9.2  Ansoft Designer Zeland IE3D9.2  XFDTD6.0  Serenade  CST

        微波系统的设计越来越复杂,对电路的指标要求越来越高,电路的功能越来越多,电路的尺寸要求越做越小,而设计周期却越来越短。传统的设计方法已经不能满足微波电路设计的需要,使用微波EDA 软件工具进行微波元器件与微波系统的设计已经成为微波电路设计的必然趋势。EDA即Electronic Design Automation, 电子设计自动化；目前,国外各种商业化的微波EDA 软件工具不断涌现，微波射频领域主要的EDA 工具首推Agilent 公司的ADS 软件和Ansoft 公司的HFSS、Designer 软件，其次是比较小型的有Microwave Office, Ansoft Serenade, CST, Zeland, XFDTD, Sonnet 等电路设计软件。下面将会将会简要地介绍一下各个微波EDA 软件的功能特点和使用范围，以期大家有个总体的了解。

        微波EDA 仿真软件与电磁场的数值算法密切相关，在介绍微波EDA 软件之前先简要的介绍一下微波电磁场理论的数值算法。所有的数值算法都是建立在Maxwell方程组之上的，了解Maxwell方程是学习电磁场数值算法的基础；在频域，数值算法有：有限元法 ( FEM -- Finite Element Method）、矩量法( MoM -- Method of Moments），差分法( FDM -- Finite Difference Methods），边界元法( BEM -- ），和传输线法( TLM -- Transmission-Line-matrix Method），在时域，数值算法有：时域有限差分法( FDTD – Finite Difference Time Domain ），和有限积分法( FIT – Finite Integration Technology ）。如果想进一步了解各种数值算法的具体实现，可以参阅以下几本书籍：

① Microwave Circuit Modeling Using Electromagnetic Field Simulation,

② Numerical Techniques in Electromagnetics,

③ Electromagmetic Simunation Using the FDTD Method，④ Complex eletromagnetic problems and numerical Simulation Approaches。

        其中，使用矩量法( MoM ）的微波EDA软件有ADS，Ansoft Designer，Microwave Office, Zeland IE3D，Ansoft Esemble，Super NEC和FEKO；使用有限元法 ( FEM ）的微波EDA软件有HFSS和ANSYS；使用时域有限差分法( FDTD ）的微波EDA软件有 EMPIRE和XFDTD，使用有限积分法( FIT ）的微波EDA软件有CST Microwave Studio和CST Mafia。

        下面来介绍较流行几种的微波EDA软件的功能和应用。

        ADS – Advanced Design System，是Agilent公司推出的微波电路和通信系统仿真软件，是国内各大学和研究所使用最多的软件之一。其功能非常强大，仿真手段丰富多样，可实现包括时域和频域、数字与模拟、线性与非线性、噪声等多种仿真分析手段，并可对设计结果进行成品率分析与优化，从而大大提高了复杂电路的设计效率，是非常优秀的微波电路、系统信号链路的设计工具。主要应用于：射频和微波电路的设计，通信系统的设计，DSP设计和向量仿真。现在最新的版本是ADS2004A。

        Ansoft Designer，是Ansoft公司推出的微波电路和通信系统仿真软件；它采用了最新的视窗技术，是第一个将高频电路系统,版图和电磁场仿真工具无缝地集成到同一个环境的设计工具，这种集成不是简单和界面集成,其关键是Ansoft Designer独有的"按需求解"的技术,它使你能够根据需要选择求解器,从而实现对设计过程的完全控制。Ansoft Designer实现了“所见即所得”的自动化版图功能，版图与原理图自动同步，大大提高了版图设计效率。同时,Ansoft还能方便地与其他设计软件集成到一起，并可以和测试仪器连接，完成各种设计任务，如频率合成器，锁相环，通信系统，雷达系统以及放大器，混频器，滤波器，移相器，功率分配器，合成器和微带天线等。主要应用于：射频和微波电路的设计，通信系统的设计，电路板和模块设计，部件设计。现在最新的版本是Ansoft Designer 2.1。

        Ansoft HFSS，是Ansoft公司推出的三维电磁仿真软件；是世界上第一个商业化的三维结构电磁场仿真软件，业界公认的三维电磁场设计和分析的电子设计工业标准。HFSS提供了一简洁直观的用户设计界面、精确自适应的场解器、拥有空前电性能分析能力的功能强大后处理器，能计算任意形状三维无源结构的S参数和全波电磁场。HFSS软件拥有强大的天线设计功能，它可以计算天线参量，如增益、方向性、远场方向图剖面、远场3D图和3dB带宽；绘制极化特性，包括球形场分量、圆极化场分量、Ludwig第三定义场分量和轴比。使用HFSS，可以计算：① 基本电磁场数值解和开边界问题，近远场辐射问题；② 端口特征阻抗和传输常数；③ S参数和相应端口阻抗的归一化S参数；④ 结构的本征模或谐振解。而且，由Ansoft HFSS和Ansoft Designer构成的Ansoft高频解决方案，是目前唯一以物理原型为基础的高频设计解决方案，提供了从系统到电路直至部件级的快速而精确的设计手段，覆盖了高频设计的所有环节。现在最新的版本是Ansoft HFSS 9.2。

        Microwave Office，是AWR公司推出的微波EDA软件，为微波平面电路设计提供了最完整, 最快速和最精确的解答。它是通过两个模拟器来对微波平面电路进行模拟和仿真的。对于由集总元件构成的电路，用电路的方法来处理较为简便；该软件设有"VoltaireXL"的模拟器来处理集总元件构成的微波平面电路问题。而对于由具体的微带几何图形构成的分布参数微波平面电路则采用场的方法较为有效；该软件采用的是"EMSight"的模拟器来处理任何多层平面结构的三维电磁场的问题。"VoltaireXL" 模拟器内设一个元件库，在建立电路模型时，可以调出微波电路所用的元件，其中无源器件有电感、电阻、电容、谐振电路、微带线、带状线、同轴线等等，非线性器件有双极晶体管，场效应晶体管，二极管等等。"EMSight"模拟器是一个三维电磁场模拟程序包，可用于平面高频电路和天线结构的分析。特点是把修正谱域矩量法与直观的视窗图形用户界面(GUI）技术结合起来，使得计算速度加快许多。MWO可以分析射频集成电路 (RFIC）、微波单片集成电路(MMIC）、微带贴片天线和高速印制电路(PCB）等电路的电气特性。

        XFDTD，是Remcom公司推出的基于时域有限差分法(FDTD）的三维全波电磁场仿真软件。XFDTD用户界面友好、计算准确；但XFDTD本身没有优化功能，须通过第三方软件Engineous完成优化。该软件最早用于仿真蜂窝电话，长于手机天线和SAR计算。现在广泛用于无线、微波电路、雷达散射计算，化学、光学、陆基警戒雷达和生物组织仿真。软件最新版本为 XFDTD 6.0

        Zeland IE3D，IE3D是一个基于矩量法的电磁场仿真工具，可以解决多层介质环境下的三维金属结构的电流分布问题。IE3D可分为MGRID、MODUA和PATTERNVIEW三部分；MGRID为IE3D的前处理套件，功能有建立电路结构、设定基板与金属材料的参数和设定模拟仿真参数；MOODUA是IE3D的核心执行套件，可执行电磁场的模拟仿真计算、性能参数（Smith园图，S参数等）计算和执行参数优化计算；PATTERNVIEW是IE3D的后处理套件，可以将仿真计算结果，电磁场的分布以等高线或向量场的形式显示出来。IE3D仿真结果包括S、Y、Z参数，VWSR，RLC等效电路，电流分布，近场分布和辐射方向图，方向性，效率和RCS等；应用范围主要是在微波射频电路、多层印刷电路板、平面微带天线设计的分析与设计。软件最新版本为Zeland IE3D10.0。

        CST MICROWAVE STUDIO，是德国CST（Computer Simulation Technology）公司推出的高频三维电磁场仿真软件。广泛应用于移动通信、无线通信（蓝牙系统）、信号集成和电磁兼容等领域。微波工作室使用简洁，能为用户的高频设计提供直观的电磁特性。微波工作室除了主要的时域求解器模块外，还为某些特殊应用提供本征模及频域求解器模块。CAD文件的导入功能及SPICE参量的提取增强了设计的可能性并缩短了设计时间。另外，由于CST设计工作室的开放性体系结构能为其它仿真软件提供链接，使微波工作室与其它设计环境相集成。

        Sonnet，是一种基于矩量法的电磁仿真软件，提供面向3D平面高频电路设计系统以及在微波、毫米波领域和电磁兼容/电磁干扰设计的EDA工具。SonnetTM应用于平面高频电磁场分析，频率从1MHz 到几千GHz。主要的应用有：微带匹配网络、微带电路、微带滤波器、带状线电路、带状线滤波器、过孔（层的连接或接地）、偶合线分析、PCB板电路分析、PCB 板干扰分析、桥式螺线电感器、平面高温超导电路分析、毫米波集成电路（MMIC）设计和分析、混合匹配的电路分析、HDI 和LTCC 转换、单层或多层传输线的精确分析、多层的平面的电路分析、单层或多层的平面天线分析、平面天线阵分析、平面偶合孔的分析等。

        其他的微波射频相关的EDA软件还有Ansoft公司的Serenade 8.71、Esemble 8.0、SIwave 2.0、Ansoft Links 3.0、Optimatrics，CST公司的CST Mafia 4.1、CST Design Studio、CST EM Studio 2.0，Zeland公司的Fidelity，Ansys公司的Ansys、FEKO，Eagleware-Elanix公司的Eagleware Genesys，和Super NEC等。这里限于时间篇幅就不一一介绍了。如果大家想认真学习微波EDA相关软件,推荐去微波EDA网( http://www.mweda.com ）看看，那里有很多微波软件和和经典的学习使用教程。

9:43 AM | Add a comment | Permalink | Blog it

FDTD编程

（1）在FDTD中时间步长Δt必须很小，尽管增大时间步长会减小精度，但实际编程中为满足稳定性要求，时间步长不会很大。另外在编程过程中，如果时间步长和空间步长的比例选取不适当，可能在伪彩图中没有激励的波形，一般来说，时间步长与空间步长之比应小于10倍的光速大小。之所以小于10倍光速大小，主要是由于波在空气中一般以小于光速传播，而在进行采样分析时，在一个波长范围内至少要采10个点才能保证波不至于失真

（2）为了保证FDTD解的稳定性和收敛性，离散网格边长δ应满足条件δ≤λ／12

（3）总场边界与散射体间的距离应大于5δ，总场边界与散射场数据存储边界间的距离应大于2δ，散射场数据存储边界与截断边界间的距离应大于8δ。

•产生原因

–FDTD网格中，会导致数字波模在网格中发生改变，这种改变是由于计算网格本身引起的，而非物理因素，所以必须考虑

•适当选取时间步长，空间步长，传播方向，可以得到理想情况（我们实验只需考虑这种特殊情况）

–3-D方形网格：取波沿对角线传播
(数值稳定的极限状态),可得理想色散关系。

–2-D方形网格:也是沿对角线传播，
（也是数值稳定的极限状态）

–1-D网格 (数值稳定的极限状态)

9:35 AM | Add a comment | Read comments (1) | Permalink | Blog it

Mur吸收边界条件

1Mur吸收边界条件
　　其具体推导过程可参考文献［2］,递推公式如下：
　　
　　

9:09 AM | Add a comment | Permalink | Blog it

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">

9:04 AM | Add a comment | Permalink | Blog it

March 28

Servlet 2.3：新特征

改变：
· 需要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的执行过程进行记录的一个简单的日志过滤器的例子代码如下：

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class LogFilter implements Filter {
FilterConfig config;
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws ServletException, IOException {
ServletContext context =config.getServletContext();
long bef = System.currentTimeMillis();
chain.doFilter(req, res); // no chain parameter needed here
long aft = System.currentTimeMillis();
context.log("Request to " + ((HttpServletRequest)req).getRequestURI() + ": " + (aft-bef));
}
public void init (FilterConfig config) throws ServletException{
this.config = config;
}
public void destroy () {
this.config = null;
}
}

当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中，所以不需要改变任何代码就可以添加新的监听器。监听器的例子如下:

public class MyConnectionManager implements ServletContextListener {
public void contextInitialized(ServletContextEvent e) {
Connection con = // create connection
e.getServletContext().setAttribute("con", con);
}
public void contextDestroyed(ServletContextEvent e) {
Connection con = (Connection) e.getServletContext().getAttribute("con");
try { con.close(); } catch (SQLException ignored) { } // close connection
}
}

监听器保证每新生成一个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能够自定义错误页面，例:

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ErrorDisplay extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
String code = null, message = null, type = null;
Object codeObj, messageObj, typeObj;
// Retrieve the three possible error attributes, some may be null
codeObj = req.getAttribute("javax.servlet.error.status_code");
messageObj = req.getAttribute("javax.servlet.error.message");
typeObj = req.getAttribute("javax.servlet.error.exception_type");
// Convert the attributes to string values
// We do things this way because some old servers return String
// types while new servers return Integer, String, and Class types.
// This works for all.
if (codeObj != null) code = codeObj.toString();
if (messageObj != null) message = messageObj.toString();
if (typeObj != null) type = typeObj.toString();
// The error reason is either the status code or exception type
String reason = (code != null ? code : type);
out.println("<HTML>");
out.println("<HEAD><TITLE>" + reason + ": " + message + "</TITLE></HEAD>");
out.println("<BODY>");
out.println("<H1>" + reason + "</H1>");
out.println("<H2>" + message + "</H2>");
out.println("<HR>");
out.println("<I>Error accessing " + req.getRequestURI() + "</I>");
out.println("</BODY></HTML>");
}
}

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

这些属性能够让错误页面包含异常的堆栈信息和产生问题的资源的URI。下面的servlet例子使用了新属性。

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ErrorDisplay extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
String code = null, message = null, type = null, uri = null;
Object codeObj, messageObj, typeObj;
Throwable throwable;
// Retrieve the three possible error attributes, some may be null
codeObj = req.getAttribute("javax.servlet.error.status_code");
messageObj = req.getAttribute("javax.servlet.error.message");
typeObj = req.getAttribute("javax.servlet.error.exception_type");
throwable = (Throwable) req.getAttribute
("javax.servlet.error.exception");
uri = (String) req.getAttribute("javax.servlet.error.request_uri");
if (uri == null) {
uri = req.getRequestURI(); // in case there’s no URI given
}
// Convert the attributes to string values
if (codeObj != null) code = codeObj.toString();
if (messageObj != null) message = messageObj.toString();
if (typeObj != null) type = typeObj.toString();
// The error reason is either the status code or exception type
String reason = (code != null ? code : type);
out.println("<HTML>");
out.println("<HEAD><TITLE>" + reason + ": " + message
+ "</TITLE></HEAD>");
out.println("<BODY>");
out.println("<H1>" + reason + "</H1>");
out.println("<H2>" + message + "</H2>");
out.println("<PRE>");
if (throwable != null) {
throwable.printStackTrace(out);
}
out.println("</PRE>");
out.println("<HR>");
out.println("<I>Error accessing " + uri + "</I>");
out.println("</BODY></HTML>");
}
}

新的安全属性
Servlet API 2.3增加了两个新的request属性，有助于一个使用HTTPS连接的servlet获得有关的某些信息。对于使用HTTPS加密的servlet，server支持下面列出的新加的request属性：
· javax.servlet.request.cipher_suite：HTTPS所使用的密码组
· javax.servlet.request.key_size：加密算法所使用的密钥长度

servlet可以在程序中使用这些属性决定是否一个网络连接拥有足够的安全强度。应用程序可以拒绝加密位数不够长或使用不信任算法的那些连接。例如，下面的方法判断连接是否使用了不低于128位长度的密钥进行加密。

public boolean isAbove128(HttpServletRequest req) {
Integer size = (Integer) req.getAttribute("javax.servlet.request.key_size");
if (size == null || size.intValue() < 128) {
return false;
}
else {
return true;
}
}

细微的调整
在API 2.3中还存在一些细微的调整之处。首先，在HttpServletReques类中定义了新的四个静态的不可变的字符串型的常量：BASIC_AUTH，DIGEST_AUTH，CLIENT_CERT_AUTH，和FORM_AUTH。与之对应的是用来获得客户端使用哪一种认证方式的getAuthType()方法的代码可以如下书写：

if (req.getAuthType() == req.BASIC_AUTH) {
// handle basic authentication
}

与API 2.2兼容，原有的判断方式同样能够使用，但是不符合代码的规范性。注意将"BASIC"放在equals()之前能够避免在getAuthType()方法返回null的时候产生空指针异常：

if ("BASIC".equals(req.getAuthType())) {
// handle basic authentication
}

另一个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中，通常情况下保留所有的空格。)这个规定保证了如下的两个条目以相同的方式被进行处理：

<servlet-name>hello<servlet-name>
和
<servlet-name>
hello
</servlet-name>

API 2.3提供了<auth-constraint>标记规则，特殊值"*"作为<role-name>的通配符表示允许所有的roles访问。如下的xml定义表示当前Web application中所有的用户只要属于Web application中所定义任何一个role，就可以对响应的web资源进行访问：[pre]
<auth-constraint>
    <role-name>*</role-name> 
</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</role-name>
        <role-link>manager</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

3:27 PM | Add a comment | Permalink | Blog it

March 25

FDTD数值稳定性和收敛性

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

其中D为维数。
此外，用差分方法对麦克斯韦方程进行数值计算将引起波的色散，即在FDTD网格中波的传播速度将随频率而改变。这种色散将导致非物理原因引起的脉冲波形畸变。另外差分离散后，FDTI〕计算中波的传播速度与传播方向有关，从而引起人为的各向异性问题。必须在算法中考虑色散问题。FDTD方法中的数值色散关系为

即可使数值色散和各向异性减小到所要求的精度。
以上讨论是波动方程最简单的解，即将平面波带入差分方程得到的解，所引起的稳定性、色散以及各向异性方面的问题，这些问题并非介质的物理特性所引起得的，而是数值计算中的差分近似所致。在FDTD的数值计算中，上述稳定性、色散、各向异性将影响到数值计算的精度。遵循平面波情况导出的选择判据会减小计算中的误差。

5:02 PM | Add a comment | Permalink | Blog it

FDTD公式和基本原理

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

在直角坐标系中，令f (x,Y,z, t )代表E场或H场的某一分量，在时间和空间域中的离散用以一下符号表示

f(x,Y,Z,t)=f (iAx, jAY, kAz, nAt)=f"(i,j,k) (1-2)

对f(x,Y,z,t)关于时间和空间的一阶偏导数取中心差分近似，即

电场和磁场在空间中各节点的排布如图1.3所示。这就是所谓的Yee网格，每一个磁场分量由四个电场分量环绕，同样，每一个电场分量由四个磁场分量环绕。这种电磁场分量的空间抽样方式不仅符合法拉第感应定律和安培环路定律的自然结构，而且这种电磁场各分量的空间相对位置也适合于麦克斯韦方程的差分计算，能够恰当地描述电磁场的传播特性。以Ex分量为例.其差分公式为

对其它场分量，处理方式完全一致。由各场分量的差分公式可以看出，每一个网格上的电(磁)场分量新的迭代值仅依赖于该节点前一时间步的值及其四周邻近节点的磁(电)场分量前半个时间步的值。这一关系构成了FDTD方法的基本迭代步骤。

4:45 PM | Add a comment | Permalink | Blog it

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所示)，不再区分总场区和散射场区。

— 吸收边界条件。为了用有限的计算区域模拟无限空间中的电磁问题，必须在计算区域的边界上设置吸收边界条件，将计算区域截断。吸收边界从开始简单的插值边界[371，到后来广泛采用的Mu:吸收边界[38]，以至近几年发展起来的完
全匹配层((PML吸收边界[[39]，其吸收效果越来越好。

— 近一远场变换。FDTD的模拟只能限于有限空间，为了获得计算域以外的散射场(或辐射场)，必须借助等效原理，应用计算区域内的近场散射数据实现计算区域外的远区场的外推。对于时谐场和瞬态场分别采用不同的外推方法。

4:14 PM | Add a comment | Permalink | Blog it

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

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

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

谢谢

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

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

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

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

我很喜欢你

2:32 PM | Add a comment | Permalink | Blog it | 音乐