软件项目管理

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1231828

posted @ 2007-03-19 22:12 junhong 阅读(326) | 评论 (0) | 编辑 收藏

WSDL Info

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

Services are defined using six major elements:

• types, which provides data type definitions used to describe the messages exchanged.
• message, which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.
• portType, which is a set of abstract operations. Each operation refers to an input message and output messages.
• binding, which specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType.
• port, which specifies an address for a binding, thus defining a single communication endpoint.
• service, which is used to aggregate a set of related ports.

If the values being passed are part1=1, part2=2, part3=3, the request format would be as follows for each port:

port1: GET, URL="http://example.com/o1/A1B2/3"
port2: GET, URL="http://example.com/o1?p1=1&p2=2&p3=3
port3: POST, URL="http://example.com/o1", PAYLOAD="p1=1&p2=2&p3=3"

For each port, the response is either a GIF or a JPEG image.

Example 6. GET and FORM POST returning GIF or JPG

<definitions .... >
    <message name="m1">
        <part name="part1" type="xsd:string"/>
        <part name="part2" type="xsd:int"/>
        <part name="part3" type="xsd:string"/>
    </message>

    <message name="m2">
        <part name="image" type="xsd:binary"/>
    </message>

    <portType name="pt1">
        <operation name="o1">
           <input message="tns:m1"/>
           <output message="tns:m2"/>
        </operation>
    </portType>

    <service name="service1">
        <port name="port1" binding="tns:b1">
           <http:address location="http://example.com/"/>
        </port>
        <port name="port2" binding="tns:b2">
           <http:address location="http://example.com/"/>
        </port>
        <port name="port3" binding="tns:b3">
             <http:address location="http://example.com/"/>
        </port>
    </service>

    <binding name="b1" type="pt1">
        <http:binding verb="GET"/>
        <operation name="o1">
           <http:operation location="o1/A(part1)B(part2)/(part3)"/>
           <input>
               <http:urlReplacement/>
           </input>
           <output>
               <mime:content type="image/gif"/>
               <mime:content type="image/jpeg"/>
           </output>
        </operation>
    </binding>

    <binding name="b2" type="pt1">
        <http:binding verb="GET"/>
        <operation name="o1">
           <http:operation location="o1"/>
           <input>
               <http:urlEncoded/>
           </input>
           <output>
               <mime:content type="image/gif"/>
               <mime:content type="image/jpeg"/>
           </output>
        </operation>
    </binding>

    <binding name="b3" type="pt1">
        <http:binding verb="POST"/>
        <operation name="o1">
           <http:operation location="o1"/>
           <input>
               <mime:content type="application/x-www-form-urlencoded"/>
           </input>
           <output>
               <mime:content type="image/gif"/>
               <mime:content type="image/jpeg"/>
           </output>
        </operation>
    </binding>
</definitions>

4.2 How the HTTP GET/POST Binding Extends WSDL

The HTTP GET/POST Binding extends WSDL with the following extension elements:

<definitions .... >
    <binding .... >
        <http:binding verb="nmtoken"/>
        <operation .... >
           <http:operation location="uri"/>
           <input .... >
               <-- mime elements -->
           </input>
           <output .... >
               <-- mime elements -->
           </output>
        </operation>
    </binding>

    <port .... >
        <http:address location="uri"/>
    </port>
</definitions>

These elements are covered in the subsequent sections.

4.3 http:address

The location attribute specifies the base URI for the port. The value of the attribute is combined with the values of the location attribute of the http:operation binding element. See section 4.5 for more details.

4.4 http:binding

The http:binding element indicates that this binding uses the HTTP protocol.

<definitions .... >
    <binding .... >
        <http:binding verb="nmtoken"/>
    </binding>
</definitions>

The value of the required verb attribute indicates the HTTP verb. Common values are GET or POST, but others may be used. Note that HTTP verbs are case sensitive.

posted @ 2007-01-28 16:24 junhong 阅读(336) | 评论 (0) | 编辑 收藏

SAX2.0

/*
自从XML真正形成以来(我认为是Org.W3C组织发布XML标准时开始),XML得到了很快的发展,
 很多厂商都有推出了自己的XML解析器,如Apache的xalan,IBM的xerces,sun的JDOM等,不过这些都是在
 基于JAXP(java API for XML processing)的,从JDK 1.4.0开始的后续j2sdk里都附加了JAXP,这给开发人员
 带来了很大的方便,这使得我们在处理一般的XML功能上的问题时不再需要去用第三方的XML处理器了.
 随着XML的迅速发展,SAX也从1.0到了现在的2.0了(还是能够和1.0兼容),结构上有了一些较大的变化.

 DOM(document object model)每次读取XML节点时都要把它load到内存里 来,在文档很大时,就显得很慢了,SAX(simple API for XML),是一个XML解析器的接口,它比DOM更低级一些,它是一种基于事件和回调模式的XML处理方式, 因此在解析速度上DOM是没法比 的(当要解析的XML文档很大的时更是如此).那么在SAX中事件响应(event)是什么呢 ? 我个人认为这一点和Swing,AWT中的事件义有点相似的,都有是指在触发某些特定的行为时所做的处理,如:mouse 的click事件等到. 这里则是指碰到特定的XML节点的所做的处理,如文档开始(startDocument),文档结束 (endDocument),元素开始(startElement)等很多,大家看一下SAX的API中的方法名字就知道有哪些事件了,基本上可以做到见 文知义的.在只想分析XML内容(只读),要求高性能,灵活性 能够定位错误信息(SAX能够定位错误的行列位置)时,最好用SAX来做. 一般情况下SAX是按下面的原理去使用的:
  <1>设置事件处理器(SAX 1.0是使用一个通过继承HandlerBase类的实例来设置的,SAX 2.0则是继承DefaultHandler的,还有用XMLReader方式的,在原理上没有很大的区别)
  <2>载入要解析的内容
  <3>在需要解析的事件方法里(具体参见SAX API文档)加入自己的控制逻辑.
  <4>重复<3>直到解析完为止.                 
 
 在这里我自己写了一个描述电影海报信息的XML文件(file.xml),用SAX2.0写了一个很简单的XML内容阅读器来解析它, 和大家交流一下自己的心得.程序在我的机器上经过了测试的(OS: win2k Advanced Server(English version),
 Intel pentium CPU, 256M RAM)
*/

import org.w3c.dom.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
import javax.xml.parsers.*;

class MyXMLReader extends DefaultHandler
{  
 //Fields
 private int index;
 private Locator locator;

 //Constructor
 public MyXMLReader(){
  super(); //it must be done !
 }

 //nain method
 public static void main(String[] args){
  try{   
      SAXParserFactory sf  = SAXParserFactory.newInstance();
      SAXParser sp = sf.newSAXParser();
      MyXMLReader reader = new MyXMLReader();
      sp.parse(new InputSource("film.xml"),reader);
  }
  catch(Exception e){
   e.printStackTrace();
  }
 } 

 //Response the startDocument event
 public void startDocument() {
  System.out.println("\n********************************* (: 元旦电影海报 :) ***********************************\n");
 }  

//Response the startElement event
 public void startElement(String uri, String localName, String qName, Attributes attrs){  
  if( qName.equalsIgnoreCase("film") ){   
   index ++;   
   int attrCount = attrs.getLength();
   for( int i = 0; i < attrCount; i ++ ){
    String attrName = attrs.getQName(i);
    if( attrName.equalsIgnoreCase("name") ){
     System.out.println("\t第" + index + "场,片名:<<" +  attrs.getValue(i) + ">>");
    }
    if( attrName.equalsIgnoreCase("price") ){
     System.out.println("\t票价:" + attrs.getValue(i) );     
    }
    if( attrName.equalsIgnoreCase("station") ){
     System.out.println("\t放映地点:" + attrs.getValue(i) );     
    }
    if( attrName.equalsIgnoreCase("time") ){
     System.out.println("\t放映时间:" + attrs.getValue(i) );
    }
    if( attrName.equalsIgnoreCase("describtion") ){
     System.out.println("\t影片简介:" + attrs.getValue(i) );
    }
    System.out.println();
  }
 }

 //Response the endDocument event
 public void endDocument(){
  System.out.println("\t\t\t\t\t\t\t------ 共有" + index + "场电影要放映");  
 }

 //Response the endElement event
 public void endElement(String uri, String localName, String qName){
     //add your codes if neccessary ...
 }

 //Print the fata error information
 public void fatalError(SAXParseException e){
  System.out.println("\nFatal error information -->");
  System.out.println("\t" + e.getMessage());
  System.out.println("\tAt line " + locator.getLineNumber() +
                  ",column " + locator.getColumnNumber());
 }
 
 //Print the usual error information
 public void error(SAXParseException e){
  System.out.println("\nUsual error information -->");  
  System.out.println("\t" + e.getMessage());
  System.out.println("\tAt line " + locator.getLineNumber() +
                  ",column " + locator.getColumnNumber());
 }
 
 //Print the warning information
 public void warning(SAXParseException e){
  System.out.println("\nWarning information -->");    
  System.out.println("\t" + e.getMessage());  
  System.out.println("\tAt line " + locator.getLineNumber() +
                  ",column " + locator.getColumnNumber());
 }

 //Store the error locator object
 public void setDocumentLocator(Locator lct){
  locator = lct;
 }

}//End class MyXMLReader

附 : film.xml完全的内容:

<?xml version="1.0" encoding="GB2312"?>
   <!-- 2003年元月1号长沙市各大影院落放映列表 -->
   <common city="ChangSha China" date="01/01/2003">
     <film name="英雄" price="30" station="田汉大剧场" time="19:00"
        describtion="国产最新大片,张艺谋导演,梁朝伟,张曼玉,李连杰等众多大明星主演">
  </film>
  <film name="无间道" price="20" station="长沙市演艺中心" time="15:00"
        describtion="韩国大片">
  </film>
  <film name="武士" price="20" station="湖南省电影院" time="17:00"
        describtion="韩国大片,有点像英雄">
  </film>  
  <film name="长排山之战" price="15" station="长沙市电影超市A1厅" time="19:00"
        describtion="反映对越自卫反击战时期中国军人的故事片">
      </film>
  <film name="高山下的花环" price="15" station="长沙市电影超市A2厅" time="19:00"
        describtion="反映对越自卫反击战时期中国军人的故事片">
  </film>  
    <film name="这里的黎明静悄悄" price="15" station="长沙市电影超市A3厅" time="19:00"
        describtion="反映对越自卫反击战时期中国军人的故事片">
  </film>
  <film name="子夜" price="15" station="长沙市电影超市B1厅" time="19:00"
        describtion="反映对越自卫反击战时期中国军人的故事片">
  </film>
  </common>

posted @ 2006-11-24 10:21 junhong 阅读(637) | 评论 (0) | 编辑 收藏

Thinking in java review 2

posted @ 2006-06-28 17:46 junhong 阅读(1767) | 评论 (0) | 编辑 收藏

Thinking in java review

1、  Java  中所有的 member function 都是动态绑定

2、  Java 中所有的对象都是通过 new 来动态产生

3、  所有的容器 (collection) 和 Object array( 对象数组 e.g String []str=new String[10]) 内都包含都是对象的 reference

4、  在 java 中， java 编译器有责任产生“将 stack 指针前后移动“的程序代码，所以 它必须能够完全掌握它所编译的的程序中“存在 stack 里头的所有数据的实际大小和存活时间“， 如此一来便会限制程序的弹性。 由于这个限制，尽管我们可以将对象的 reference 存储与 stack 内，但却不能将一般的 java 对象放在 stack 中
特例：（ primitive types ）
基本型别会经常被使用，如果使用 new 来产生此类极小，极简单的变量，会因“ new 将对象置于 heap 之上“ 而效率不好。因此对于此类变量 java 采取 c/c++ 的方式，也就是不用 new 分配器空间，而是产生一种所谓的 ”automatic “变量，存于 static 中

5、  当你产生某个存储对象的数组，真正产生的是个存储 reference 的数组。此数组建立之后，其中的每一个 reference 都会被自动设为某个特殊的值 null,

6、  { String s=new String(“ddd”);} s 这个 reference 会在生存空间之外消失无踪，但是， s 先前所指的那个 String 对象仍然会继续占用内存

7、  Class 内的基本型别变量都有初值，但是在函数内的 local variable 是没有初值的

8、  Java 中，所有传递的对象的场合，传递的都是对象的 reference.

9、  Return ； 说明这个函数运行结束，返回到其调用函数。 Return 2 ：返回一个数 2 给调用者，同时结束本函数的运行。

10、              Class 内的 non-static data(state) 和 method , 都是和特定的对象绑定的，一般情况下，你的产生某个对象，再通过该对象取用其数据和函数。所以 non-static 数据 / 函数必须知道他们隶属于哪一个对象，才有办法运行 .static 函数内不能使用 non-static 数据和函数

11、              (object1= = object2 ) 两个对象的 reference 的 = = 比较得是两个对象的内存的地址。所以我们不能使用 = = 来测试两个对象的内容是否相等。如果想测试对象的内容是否相等，应该使用 equal(), 任何一个对象都拥有这个函数。不过你自己的 class 需要 override 这个函数，否则默认的 equal() 函数是还是比较的两个对象的内存地址。
Java 标准程序库中的大多数 class 都 override 了 equal(), 所以他们都会比较对象的内容是否相等。

12、              位运算符都是作用于基本正数类型。该运算符主要是针对硬件编程使用（我们用得不多，）

待续

posted @ 2006-06-27 17:40 junhong 阅读(1793) | 评论 (0) | 编辑 收藏

关于输入框中显示双引号和单引号

posted @ 2006-04-19 23:39 junhong 阅读(632) | 评论 (0) | 编辑 收藏

how to use ant to deply your web application

First of all, if you develop your application by Eclipse, it means you have had the ant tool and you need not to download the internet.

Projects

A project has three attributes:

Optionally, a description for the project can be provided as a top-level <description> element (see the description type).

Each project defines one or more targets. A target is a set of tasks you want to be executed. When starting Ant, you can select which target(s) you want to have executed. When no target is given, the project's default is used.

Targets

A target can depend on other targets. You might have a target for compiling, for example, and a target for creating a distributable. You can only build a distributable when you have compiled first, so the distribute target depends on the compile target. Ant resolves these dependencies.

It should be noted, however, that Ant's depends attribute only specifies the order in which targets should be executed - it does not affect whether the target that specifies the dependency(s) gets executed if the dependent target(s) did not (need to) run.

Ant tries to execute the targets in the depends attribute in the order they appear (from left to right). Keep in mind that it is possible that a target can get executed earlier when an earlier target depends on it:

						
								<target name="A"/>
<target name="B" depends="A"/>
<target name="C" depends="B"/>
<target name="D" depends="C,B,A"/>
						
				

Suppose we want to execute target D. From its depends attribute, you might think that first target C, then B and then A is executed. Wrong! C depends on B, and B depends on A, so first A is executed, then B, then C, and finally D.

In a chain of dependencies stretching back from a given target such as D above, each target gets executed only once, even when more than one target depends on it. Thus, executing the D target will first result in C being called, which in turn will first call B, which in turn will first call A. After A, then B, then C have executed, execution returns to the dependency list of D, which will not call B and A, since they were already called in process of dependency resolution for C and B respectively as dependencies of D. Had no such dependencies been discovered in processing C and B, B and A would have been executed after C in processing D's dependency list.

A target also has the ability to perform its execution if (or unless) a property has been set. This allows, for example, better control on the building process depending on the state of the system (java version, OS, command-line property defines, etc.). To make a target sense this property, you should add the if (or unless) attribute with the name of the property that the target should react to. Note: Ant will only check whether the property has been set, the value doesn't matter. A property set to the empty string is still an existing property. For example:

						
								<target name="build-module-A" if="module-A-present"/>
						
				

						
								<target name="build-own-fake-module-A" unless="module-A-present"/>
						
				

In the first example, if the module-A-present property is set (to any value), the target will be run. In the second example, if the module-A-present property is set (again, to any value), the target will not be run.

If no if and no unless attribute is present, the target will always be executed.

Important: the if and unless attributes only enable or disable the target to which they are attached. They do not control whether or not targets that a conditional target depends upon get executed. In fact, they do not even get evaluated until the target is about to be executed, and all its predecessors have already run.

The optional description attribute can be used to provide a one-line description of this target, which is printed by the -projecthelp command-line option. Targets without such a description are deemed internal and will not be listed, unless either the -verbose or -debug option is used.

It is a good practice to place your tstamp tasks in a so-called initialization target, on which all other targets depend. Make sure that target is always the first one in the depends list of the other targets. In this manual, most initialization targets have the name "init".

If the depends attribute and the if/unless attribute are set, the depends attribute is executed first.

A target has the following attributes:

A target name can be any alphanumeric string valid in the encoding of the XML file. The empty string "" is in this set, as is comma "," and space " ". Please avoid using these, as they will not be supported in future Ant versions because of all the confusion they cause. IDE support of unusual target names, or any target name containing spaces, varies with the IDE.

Targets beginning with a hyphen such as "-restart" are valid, and can be used to name targets that should not be called directly from the command line.

Tasks

A task is a piece of code that can be executed.

A task can have multiple attributes (or arguments, if you prefer). The value of an attribute might contain references to a property. These references will be resolved before the task is executed.

Tasks have a common structure:

						
								<nameattribute1="value1" attribute2="value2" ... />
						
				

where name is the name of the task, attributeN is the attribute name, and valueN is the value for this attribute.

There is a set of built-in tasks , along with a number of optional tasks , but it is also very easy to write your own .

All tasks share a task name attribute. The value of this attribute will be used in the logging messages generated by Ant.

Tasks can be assigned an id attribute:

						
								<taskname id="taskID" ... />
						
				

where taskname is the name of the task, and taskID is a unique identifier for this task. You can refer to the corresponding task object in scripts or other tasks via this name. For example, in scripts you could do:

						
								<script ... >
  task1.setFoo("bar");
</script>

						
				

to set the foo attribute of this particular task instance. In another task (written in Java), you can access the instance via project.getReference("task1").

Note¹: If "task1" has not been run yet, then it has not been configured (ie., no attributes have been set), and if it is going to be configured later, anything you've done to the instance may be overwritten.

Note²: Future versions of Ant will most likely not be backward-compatible with this behaviour, since there will likely be no task instances at all, only proxies.

Properties

A project can have a set of properties. These might be set in the buildfile by the property task, or might be set outside Ant. A property has a name and a value; the name is case-sensitive. Properties may be used in the value of task attributes. This is done by placing the property name between "${" and "}" in the attribute value. For example, if there is a "builddir" property with the value "build", then this could be used in an attribute like this: ${builddir}/classes. This is resolved at run-time as build/classes.

Built-in Properties

Ant provides access to all system properties as if they had been defined using a <property> task. For example, ${os.name} expands to the name of the operating system.

For a list of system properties see the Javadoc of System.getProperties .

In addition, Ant has some built-in properties:

				
						basedir             the absolute path of the project's basedir (as set
                    with the basedir attribute of <project>).
ant.file            the absolute path of the buildfile.
ant.version         the version of Ant
ant.project.name    the name of the project that is currently executing;
                    it is set in the name attribute of <project>.
ant.java.version    the JVM version Ant detected; currently it can hold
                    the values "1.1", "1.2", "1.3", "1.4"  and "1.5".

				
		

				
						<project name="MyProject" default="dist" basedir=".">
    <description>
        simple example build file
    </description>
  <!-- set global properties for this build -->
  <property name="src" location="src"/>
  <property name="build" location="build"/>
  <property name="dist"  location="dist"/>

  <target name="init">
    <!-- Create the time stamp -->
    <tstamp/>
    <!-- Create the build directory structure used by compile -->
    <mkdir dir="${build}"/>
  </target>

  <target name="compile" depends="init"
        description="compile the source " >
    <!-- Compile the java code from ${src} into ${build} -->
    <javac srcdir="${src}" destdir="${build}"/>
  </target>

  <target name="dist" depends="compile"
        description="generate the distribution" >
    <!-- Create the distribution directory -->
    <mkdir dir="${dist}/lib"/>

    <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
  </target>

  <target name="clean"
        description="clean up" >
    <!-- Delete the ${build} and ${dist} directory trees -->
    <delete dir="${build}"/>
    <delete dir="${dist}"/>
  </target>
</project>

				
		

Notice that we are declaring properties outside any target. As of Ant 1.6 all tasks can be declared outside targets (earlier version only allowed <property>,<typedef> and <taskdef>). When you do this they are evaluated before any targets are executed. Some tasks will generate build failures if they are used outside of targets as they may cause infinite loops otherwise (<antcall> for example).

We have given some targets descriptions; this causes the projecthelp invocation option to list them as public targets with the descriptions; the other target is internal and not listed.

Finally, for this target to work the source in the src subdirectory should be stored in a directory tree which matches the package names. Check the <javac> task for details.

Token Filters

A project can have a set of tokens that might be automatically expanded if found when a file is copied, when the filtering-copy behavior is selected in the tasks that support this. These might be set in the buildfile by the filter task.

Since this can potentially be a very harmful behavior, the tokens in the files must be of the form @token@, where token is the token name that is set in the <filter> task. This token syntax matches the syntax of other build systems that perform such filtering and remains sufficiently orthogonal to most programming and scripting languages, as well as with documentation systems.

Note: If a token with the format @token@ is found in a file, but no filter is associated with that token, no changes take place; therefore, no escaping method is available - but as long as you choose appropriate names for your tokens, this should not cause problems.

Warning: If you copy binary files with filtering turned on, you can corrupt the files. This feature should be used with text files only.

Path-like Structures

You can specify PATH- and CLASSPATH-type references using both ":" and ";" as separator characters. Ant will convert the separator to the correct character of the current operating system.

Wherever path-like values need to be specified, a nested element can be used. This takes the general form of:

				
						    <classpath>
      <pathelement path="${classpath}"/>
      <pathelement location="lib/helper.jar"/>
    </classpath>

				
		

The location attribute specifies a single file or directory relative to the project's base directory (or an absolute filename), while the path attribute accepts colon- or semicolon-separated lists of locations. The path attribute is intended to be used with predefined paths - in any other case, multiple elements with location attributes should be preferred.

As a shortcut, the <classpath> tag supports path and location attributes of its own, so:

				
						    <classpath>
      <pathelement path="${classpath}"/>
    </classpath>

				
		

can be abbreviated to:

				
						    <classpath path="${classpath}"/>

				
		

In addition, DirSet s, FileSet s, and FileList s can be specified via nested <dirset>, <fileset>, and <filelist> elements, respectively. Note: The order in which the files building up a FileSet are added to the path-like structure is not defined.

				
						    <classpath>
      <pathelement path="${classpath}"/>
      <fileset dir="lib">
        <include name="**/*.jar"/>
      </fileset>
      <pathelement location="classes"/>
      <dirset dir="${build.dir}">
        <include name="apps/**/classes"/>
        <exclude name="apps/**/*Test*"/>
      </dirset>
      <filelist refid="third-party_jars"/>
    </classpath>

				
		

This builds a path that holds the value of ${classpath}, followed by all jar files in the lib directory, the classes directory, all directories named classes under the apps subdirectory of ${build.dir}, except those that have the text Test in their name, and the files specified in the referenced FileList.

If you want to use the same path-like structure for several tasks, you can define them with a <path> element at the same level as targets, and reference them via their id attribute - see References for an example.

A path-like structure can include a reference to another path-like structure via nested <path> elements:

				
						    <path id="base.path">
      <pathelement path="${classpath}"/>
      <fileset dir="lib">
        <include name="**/*.jar"/>
      </fileset>
      <pathelement location="classes"/>
    </path>

    <path id="tests.path">
      <path refid="base.path"/>
      <pathelement location="testclasses"/>
    </path>
				
		

The shortcuts previously mentioned for <classpath> are also valid for <path>.For example:

				
						
								
								 <path id="base.path">
      <pathelement path="${classpath}"/>
    </path>

				
		

can be written as:

				
						 <path id="base.path" path="${classpath}"/>
				
		

				
						generally, you need not to write your builder.xml file started from scratch. you can just modify the following

						
								
								part to meet your demand.
				
		

				
						<project name="javastep" default="deploy" basedir=".">
				
		

				
						<!-- ===================== Property Definitions =========================== -->
				
		

				
						    <!--
         All properties should be defined in this section.
         Any host-specific properties should be defined
         in the build.properties file.
				
		

				
						  In this app, the following properties are defined in build.properties:
				
		

				
						   o  tomcat.home     - the home directory of your Tomcat installation
        o  webapps.home    - the place to copy the war file to deploy it
    -->
				
		

				
						  <property file="build.properties" />
 
				
		

				
						  <property name="app.home"          value="." />
  <property name="app.name"          value="javastep" />
  <property name="javadoc.pkg.top"   value="hello" />
				
		

				
						  <property name="src.home"          value="${app.home}/src"/>
  <property name="lib.home"          value="${app.home}/WebRoot/WEB-INF/lib"/>
  
  <property name="classes.home"       value="${app.home}/WebRoot/WEB-INF/classes/"/>
  <property name="deploy.home"       value="${app.home}/deploy"/>
  <property name="doc.home"          value="${app.home}/doc"/>
  <property name="web.home"          value="${app.home}/WebRoot"/>
				
		

				
						  <property name="build.home"        value="${app.home}/build"/>
  <property name="build.classes"     value="${build.home}/WEB-INF/classes"/>
  <property name="build.lib"         value="${build.home}/WEB-INF/lib"/>
				
		

				
						<!-- ==================== Compilation Classpath =========================== -->
				
		

				
						    <!--
         This section creates the classpath for compilation.
    -->
				
		

				
						  <path id="compile.classpath">
				
		

				
						    <!-- The object files for this application -->
    <pathelement location="${classes.home}"/>
				
		

				
						    <!-- The lib files for this application -->
    <fileset dir="${lib.home}">
      <include name="*.jar"/>
      <include name="*.zip"/>
    </fileset>
				
		

				
						    <!-- All files/jars that Tomcat makes available -->
				
		

				
						
								
  </path>
				
		

				
						
								
<!-- ==================== Build Targets below here========================= -->
				
		

				
						
								
<!-- ==================== "help" Target =================================== -->
				
		

				
						    <!--
         This is the default ant target executed if no target is specified.
         This helps avoid users just typing 'ant' and running a
         default target that may not do what they are anticipating...
    -->
				
		

				
						 <target name="help" >
   <echo message="Please specify a target! [usage: ant &lt;targetname&gt;]" />
   <echo message="Here is a list of possible targets: "/>
   <echo message="  clean-all.....Delete build dir, all .class and war files"/>
   <echo message="  prepare.......Creates directories if required" />
   <echo message="  compile.......Compiles source files" />
   <echo message="  build.........Build war file from .class and other files"/>
   <echo message="  deploy........Copy war file to the webapps directory" />
   <echo message="  javadoc.......Generates javadoc for this application" />
 </target>
				
		

				
						<!-- ==================== "clean-all" Target ============================== -->
				
		

				
						   <!--
          This target should clean up any traces of the application
          so that if you run a new build directly after cleaning, all
          files will be replaced with what's current in source control
   -->
				
		

				
						 <target name="clean-all" >
    <delete dir="${build.home}"/>
    <delete dir="${classes.home}"/>
    <delete dir="${deploy.home}"/>
				
		

				
						    <!-- can't delete directory if Tomcat is running -->
    <delete dir="${webapps.home}/${app.name}" failonerror="false"/>
				
		

				
						    <!-- deleting the deployed .war file is fine even if Tomcat is running -->
    <delete dir="${webapps.home}/${app.name}.war" />
				
		

				
						    <!-- delete the javadoc -->
    <delete dir="${doc.home}"/>
				
		

				
						 </target>
				
		

				
						<!-- ==================== "prepare" Target ================================ -->
				
		

				
						    <!--
          This target is executed prior to any of the later targets
          to make sure the directories exist. It only creates them
          if they need to be created....
          Other, similar, preparation steps can be placed here.
    -->
				
		

				
						  <target name="prepare">
				
		

				
						    <echo message="Tomcat Home = ${tomcat.home}" />
    <echo message="webapps Home = ${webapps.home}" />
				
		

				
						    <mkdir dir="${classes.home}"/>
    <mkdir dir="${deploy.home}"/>
				
		

				
						    <mkdir dir="${doc.home}"/>
    <mkdir dir="${doc.home}/api"/>
				
		

				
						    <mkdir dir="${build.home}"/>
    <mkdir dir="${build.home}/WEB-INF" />
    <mkdir dir="${build.home}/WEB-INF/classes" />
    <mkdir dir="${build.home}/WEB-INF/lib" />
				
		

				
						  </target>
				
		

				
						<!-- ==================== "compile" Target ================================ -->
				
		

				
						    <!--
          This only compiles java files that are newer
          than their corresponding .class files.
     -->
				
		

				
						  <target name="compile" depends="prepare" >
    <javac srcdir="${src.home}" destdir="${classes.home}" debug="yes" >
        <classpath refid="compile.classpath"/>
    </javac>
  </target>
				
		

				
						<!-- ==================== "build" Target ================================== -->
				
		

				
						    <!--
          This target builds the war file for the application
          by first building the directory structure of the
          application in ${build.home} and then creating the
          war file using the ant <war> task
     -->
				
		

				
						  <target name="build" >
				
		

				
						    <!-- Copy all the webapp content (jsp's, html, tld's, xml, etc. -->
    <!-- Note that this also copies the META-INF directory -->
    <copy    todir="${build.home}">
      <fileset dir="${web.home}"/>
    </copy>
				
		

				
						    <!-- Now, copy all the Java class files -->
    <copy    todir="${build.home}/WEB-INF/classes">
      <fileset dir="${classes.home}"/>
    </copy>
				
		

				
						    <!-- Now, copy all the properties files, etc that go on the classpath -->
    <copy    todir="${build.home}/WEB-INF/classes">
      <fileset dir="${src.home}">
         <include name="**/*.properties" />
         <include name="**/*.prop" />
      </fileset>
    </copy>
				
		

				
						    <!-- Now, copy all the jar files we need -->
    <copy    todir="${build.home}/WEB-INF/lib">
      <fileset dir="${lib.home}" />
    </copy>
				
		

				
						    <!-- Create the <war> file -->
    <jar jarfile="${deploy.home}/${app.name}.war"
         basedir="${build.home}"/>
				
		

				
						  </target>
				
		

				
						<!-- ==================== "deploy" Target ================================= -->
				
		

				
						    <!--
         This target simply copies the war file from the deploy
         directory into the Tomcat webapp directory.
     -->
				
		

				
						  <target name="deploy" depends="build" >
				
		

				
						    <!-- Copy the contents of the build directory -->
    <copy todir="${webapps.home}"  file="${deploy.home}/${app.name}.war" />
				
		

				
						  </target>
				
		

				
						<!-- ==================== "doc" Target ==================================== -->
				
		

				
						    <!--
         This task creates javadoc. It is dependent upon only the
         'compile' target so it is not executed in a normal build.
         As a result, the target needs to be run on its own.
    -->
				
		

				
						  <target name="javadoc" depends="compile">
      <javadoc sourcepath = "${src.home}"
                  destdir = "${doc.home}/api"
             packagenames = "${javadoc.pkg.top}.*"/>
  </target>
  
<!-- ==================== "test" Target ================================== -->
				
		

				
						    <!--
        This task runs all test cases. It invokes each test case individually.
        The "test-all" target is tied back to the "struts-test" target which
        actually runs the tests. This allows other test targets to be created
        in this section while maintaining the ability to run each test target
        individually. All individual test targets should be added to the
        "depends" attribute of the "test-all" target to provide a single
        target that runs all tests.
-->
				
		

				
						  <target name="test-all" depends="struts-tests" />
				
		

				
						  <target name="struts-tests" depends="build" >
				
		

				
						      <junit printsummary="yes" >
				
		

				
						          <classpath >
              <pathelement location="${classes.home}"/>
              <pathelement location="${build.home}"/>
              <pathelement location="${build.home}/WEB-INF/classes"/>
              <path refid="compile.classpath"/>
          </classpath>
				
		

				
						          <formatter type="plain" />
          <test name="hello.mocktest.TestHelloAction" />
          <test name="hello.mocktest.TestHelloActionMultiple" />
      </junit>
    
  </target>
</project>

				
		

posted @ 2006-04-19 21:41 junhong 阅读(384) | 评论 (0) | 编辑 收藏

how to deal with the Frame when using sitemesh

1. install the sitemesh described in the above article.

2. To be able to specify which mappers will be applied to a request, create the file [web-app]/WEB-INF/sitemesh.xml that contains the following:

   <sitemesh>
       <property name="decorators-file" value="/WEB-INF/decorators.xml" />
       <excludes file="${decorators-file}" />
   
       <page-parsers>
           <parser content-type="text/html"
               class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
           <parser content-type="text/html;charset=ISO-8859-1"
               class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
       </page-parsers>
   
       <decorator-mappers>
           <mapper class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper">
               <param name="config" value="${decorators-file}" />
           </mapper>
       </decorator-mappers>
   </sitemesh>
   

   in this example, the only mapper that will be applied is the ConfigDecoratorMapper, and that will only be applied to responses of type text/html or text/html;charset=ISO-8859-1. Responses of any other content type (eg image/gif) will be ignored by Sitemesh. Additionally, any files that match a pattern specified in the excludes file (in this case '/WEB-INF/decorators.xml') will not be touched by Sitemesh.

3. The excludes file points to an XML file that contains an <excludes /> block similar to the following: add the following code in your decorators.xml

   <decorators defaultdir="/decorators">
    <excludes>
     <pattern>/plainPage.jsp</pattern>
     <pattern>/ewebeditor/*.*</pattern>
    </excludes>
    <decorator name="main" page="main.jsp">
     <pattern>/*</pattern>
    </decorator>
   </decorators>
   

posted @ 2006-04-13 23:46 junhong 阅读(1075) | 评论 (0) | 编辑 收藏

how to use sitemesh

<sitemesh>
    <property name="decorators-file" value="/WEB-INF/decorators.xml" />
    <excludes file="${decorators-file}" />

    <page-parsers>
        <parser content-type="text/html"
            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"
            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
    </page-parsers>

    <decorator-mappers>
        <mapper class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper">
            <param name="config" value="${decorators-file}" />
        </mapper>
    </decorator-mappers>
</sitemesh>

<filter>
    <filter-name>sitemesh</filter-name>
    <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<decorators defaultdir="/decorators">
    <decorator name="main" page="main.jsp">
          <pattern>/*</pattern>
    </decorator>
</decorators>

<sitemesh>
    <property name="decorators-file" value="/WEB-INF/decorators.xml" />
    <excludes file="${decorators-file}" />

    <page-parsers>
        <parser content-type="text/html"
            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"
            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
    </page-parsers>

    <decorator-mappers>
        <mapper class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper">
            <param name="config" value="${decorators-file}" />
        </mapper>
    </decorator-mappers>
</sitemesh>

<decorators>
    <excludes>
        <pattern>/plainPage.jsp</pattern>
        <pattern>/plain/*.jsp</pattern>
    </excludes>
</decorators>

posted @ 2006-04-13 23:41 junhong 阅读(2838) | 评论 (0) | 编辑 收藏

Design pattern with java (part four)

1. Flyweight: too many objects
   it is very simple, you externalize some of the data in an object, so that you can pretend that you have more objects than you really do. However, this adds complexity to the interface for using such objects, because you must pass in additional information to method calls in order to tell the method how to find the externalized information.
2. Decorator: too many classes
   The use of layered objects to dynamically and transparently add responsibilities to individual objects is referred to as the decorator pattern.
   Used when subclassing creates too many (& inflexible) classes
   All decorators that wrap around the original object must have the same basic interface
   Dynamic proxy/surrogate?
   This accounts for the odd inheritance structure
   Tradeoff: coding is more complicated when using decorators
   Basic decorator structure

Connecting different types

1.Adapter

Adapter takes one type and produces an interface to some other type. When you’ve got this,
and you need that, Adapter solves the problem. The only requirement is to produce a that,
and there are a number of ways you can accomplish this adaptation.
//: adapter:SimpleAdapter.java
// "Object Adapter" from GoF diagram
package adapter;
import junit.framework.*;
class Target {
public void request() {}
}
class Adaptee {
public void specificRequest() {
System.out.println("Adaptee: SpecificRequest");
}
}
class Adapter extends Target {
private Adaptee adaptee;
public Adapter(Adaptee a) {
adaptee = a;
}
public void request() {
adaptee.specificRequest();
}
}public class SimpleAdapter extends TestCase {
Adaptee a = new Adaptee();
Target t = new Adapter(a);
public void test() {
t.request();
}
public static void main(String args[]) {
junit.textui.TestRunner.run(SimpleAdapter.class);
}
} ///:~
2. Bridge
but the goal of Bridge is to allow you to structure your code so that you can easily add new kinds of front-end objects which are implemented with functionality in new kinds of back-end objects. Thus, both front-end and back-end can vary independently of each other.

The front-end classes can have completely different interfaces from each other, and typically do. What they have in common is that they can implement their functionality using facilities from any number of different back-end objects. The back-end objects also don’t have the same interface. The only thing the back-end objects must have in common is that they implement the same kind of functionality – for example, a group of different ways to implement a graphics library or a set of different data-storage solutions.

Bridge is really a code-organization tool that allows you to add in any number of new frontend services that implement their operations by delegating to any number of back-end options. Using Bridge, you can accomplish this without the normal combinatorial explosion of possibilities that would otherwise occur. But keep in mind that the vector of change with Bridge is typically happening at coding time: it keeps your code organized when you are dealing with an increasing number of options for implementing functionality.

posted @ 2006-04-12 16:07 junhong 阅读(241) | 评论 (0) | 编辑 收藏