最近在一个充值平台上使用了HSQL来记录用户的充值记录,本来所有的记录是写到文件里面的,但是由于使用ORACLE的惯性思维导致我浪费了半天的时间.具体情况是这样:
我使用的是HSQL的IN-PROCESS(Standalone)模式,这样在WEB启动的时候,我就会去创建数据库,按照HSQL的文档,如果存在<dbname>.script文件的话,数据库就会将历史数据插入到数据库中,但是在这里我放了一个惯性的错误,我们在ORCALE或是其他的常用数据库中创建表时,一般要先删除就表,让后在创建新的表,这样我就把HSQL的历史记录都删除了,郁闷啊,这可是用户的充值记录啊,以后我怎么对帐啊,:)还好我有备份.
在HSQL更本不需要这样的操作,他自己会去做这样的事情:如果<dbname>.script存在,他就直接执行了这个script,如果没有他才回去创建新的数据库和表结构.

最近将手上的项目(tomcat5.0+spring+struts)的jdk1.4升级到1.5的时候,出现了一堆的问题,经过不懈的努力和网上朋友的提示终于将问题解决了,现在记录如下
1.java.lang.UnsupportedClassVersionError: com/mdcchina/userinfo/logic/UserManager (Unsupported major.minor version 49.0)提示如上的错误,很是郁闷
经过研究和比较在两个不同环境下的编译运行,终于发现这个主要是由于我的机子上安装了两个不同版本的JDK导致的,我想很多的朋友在尝试新的JDK的时候,可能不会删除1.4的版本,但是要注意的是要将JAVA_HOME,CLASS_PATH,PATH等等的环境变量都修改成相关的JDK1.5的目录下面去,因为1.5相对于以前的版本的变化比较大.
2.上面的问题排除后,在运行TOMCAT5.0时候由出现了如下的错误:
2005-11-17 19:38:47 StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
org.apache.jasper.JasperException: Unable to compile class for JSP

Generated servlet error:
C:\application\Tomcat 5.0\work\Catalina\localhost\mlinkweb\org\apache\jsp\layouts\layout_005findex_jsp.java:7: cannot access java.lang.Object

Generated servlet error:
bad class file: C:\application\Java\jdk1.5.0\jre\lib\rt.jar(java/lang/Object.class)
class file has wrong version 49.0, should be 48.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
public final class layout_005findex_jsp extends org.apache.jasper.runtime.HttpJspBase
             ^
1 error

这个问题这是让我郁闷之极啊(^_^)
最后在SUN的JAVA论坛里面找到了答案,只要将JDK1.5的LIB下面的TOOLS.JAR覆盖TOMCAT5.0目录/common/lib下面的tools.jar,然后重启TOMCAT5.0就可以了

http://www.swig.org
这是一个很好的工具,可以再不同的平台和不同语言之间进行协作,JAVA调C,C调JAVA,这样就可以对资源进行重新的整合和利用了,而且还省了不少的事情吼吼...... 以下五步可以让 Struts 1.1 和 Tiles 共同工作：
1. 创建一个 JSP 以表示站点的布局。这是主 JSP，并带有页头、页体和页脚的占位符。分别用 Tiles 标记添加到主 JSP 页面中。
2. 创建一个 Tiles 定义文件并定义每个集成页面的每个占位符中必须包括哪个 JSP 页面。用惟一的名称标识出每一个合成页面定义。
3. 在 struts-config.xml 文件中改变全局和本地转发以使用上一步骤中给出的惟一名称而不是别名。
4. 在启动时用 TilesPlugIn 装载 Tiles 定义文件。将 TilesPlugIn 项加入到 struts-config.xml 文件中。
5. 将 TilesRequestProcessor 项添加到 struts-config.xml 文件中。这是支持 Tiles 的 Struts 应用程序的默认请求处理程序。
 
在现在的一个项目中使用了STRUTS和titles结合的方式来构建VIEW,特别是第5项,让我花了将近2个小时才搞定,正式郁闷,这都是没有好好读文档的结果啊,引以为戒啊,最后还是在Srikanth Shenoy,和Nithin Mallya的文章<<集成 Struts、Tiles 和 JavaServer Faces>>中找到答案. 总于有时间来继续这篇文章的翻译，以后一定要计划好，计划好：），好了，下面进入正题吧：

在对syncml的协议的使用工程进行描述之前我们先来看看同步类型的分类：
syncML协议描述了七种不同的同步类型：
（1）Two-way sync:双向同步是客户端和服务器端交换有关任何修改的数据信息的一种常用的同步类型。
（2）Slow sync:慢同步是双向同步的一种特别的形式。慢同步就是将客户端数据库的数据和服务器端的数据库数据逐个进行比较。如果客户端和服务器端的同步锚不匹配或客户端或是服务器端的修改日志遗失时将会请求一个慢同步。实际上，慢同步就意味着客户端发送所有的数据到服务器端，服务器端对客户端的所有数据进行逐个字段的分析，比较，并将服务段的数据发送到客户端。在同步分析完成后，服务端将所有的修改信息返回客户端。然后，客户端返回所有的数据的映射信息，并添加到服务端。
（3）One-way sync from client only:客户端优先同步，是客户端发送修改信息到服务端，但是服务端的修改信息并不被发送到客户端。
(4)Refresh sync from client only: 从客户端同步刷新，这里客户端为服务端提供所有数据的浏览，服务器根据客户端的修改来更新服务端的数据。
（5）One-way sync from server only:服务端同步优先，这个同步方式是客户端从服务获取所有的修改信息，但是客户端不发送修改信息到服务端。
（6）Refresh sync from server only:从服务端刷新同步，这里假设服务端为客户端提供所有的数据的预览，客户端将更新目标数据库中的数据，更新数据由服务器端发送到客户端。
（7）Server-alerted sync: 服务通告同步，服务器端通知客户端需要发起的同步类型指令给服务端。

好了，同步的几种基本类型我们都描述过了（不过其中有两种4，6我自己也不知道描述被人是否能够看的懂，很难表达，e文还需要加强啊），下面就让我们一起来看看同步的全过程吧。


为了理解基本的同步过程，我们开始讲解一些在客户端和服务端的同步工程的一些细节。由于双向同步是最通常的同步过程，我们就使用这种同步过程作为例子。

一个双向同步的过程可以分为下面几步：
1.同步初始化
2.双向同步
3.数据映射

NOW,让我们一步一的揭开同步的神秘面纱吧：
（1）同步初始化：
任何的同步过程首先都必须进行同步初始化的工作，在一个同步初始化的工程种，服务端和客户端设备通常要叫化一下信息：
a.同步服务器和设备的能力描述
b.请求访问的数据库和同步类型
c.认证信息

同步锚也是在同步初始化中被交换的信息。
下面的过程图介绍了基本的同步初始化过程：



（2）双向同步：

sync4j.framework的基本结构描述:

sync4j.framework.core:这个包的基本功能是描述一个合法的SyncML消息.该模块主要的功能是根据SyncML描述协议构建一个SyncML通讯的XML消息,并对消息的合法性进行检查.
sync4j.framework.protocol:这个包主要是对同步初始化协议规则的描述.
sync4j.framework.config:这个包主要是对sync4j整体结构的描述,包括服务和功能模块的配置说明
sync4j.framework.security:主要处理用户的安全问题
sync4j.framework.logging:主要处理服务端的日志问题(和security模块同属于系统的services层)
sync4j.framework.engine:这个是sync4j的核心模块,他提供了同步引擎的基本接口,容许通过插件的方式实现客户定制同步引擎
sync4j.framework.server:这个包提供了在SYNC4J的同步引擎的基础上开发应用服务的通用的类.

sync4j.server:
 提供了一个SyncML服务的基本架构

SyncML 是一种为了结束终端用户,设备制造厂商,服务提供商(SP)和应用开发者之间的无线数据无法同步的数据同步协议.下面让我们一起来看看无线开发者Chandan Pabla 对SyncML协议(version1.1)的理解和使用客户端/服务器端两边覆盖的同步过程.

1.SyncML的基础:
   SyncML是一种主要的开发式的工业标准,为了使远程数据和个人信息通过不同的网络,平台和设备进行同步而制定的.SyncML使的数据非常的容易在不同的网络和网络设备之间进行传输,因为它支持多种传输协议.
  SyncML的有点可以总结为一下几点:
     (1)可以在不同的网络上工作--包括有限网络和无限网络.
     (2)支持多种传输协议,包括HTTP,WSP(Wireless Session Protocol),OBEX(Bluetooth,IrDA),SMTP,pure TCP/IP.
     (3)支持通用的个人数据格式,如vCard,vCalendar和E-MAIL等.
     (4)对移动设备的存储空间进行了优化.
     (5)建立在internet协议和web技术上,是可执行而且有很好的协作性的.
2.SyncML的协议描述:
   SyncML程序框架是建立在同步描述协议(SyncML Representation protocol)和同步协议(SyncML Synchronization protocol)两个协议的基础上的.同步描述协议定义了同步消息(in XML)的格式描述和在同步框架内工作的细节.同步协议定义了同步客服端和同步服务器端的交互.
   为了建立一个适当的SyncML产品,我们必须要了解这个两个协议的相关要求,下面我们开始看看同步协议的最重要的几个组成部分:
  (1)Change log
  开始一个同步协议的操作时,SyncML协议需要在客户端和服务器端的各自的数据库中维护信息的交换或修改(如替代,增加,删除数据等).SyncML通过一种被称为change log的信息跟踪机制来解决客户端和服务器端的信息交换或修改的问题.SyncML并没有描述change log的格式信息,但是进行同步的每个设备必须能够详细的描述设备上每个数据项从上次同步时的修改的详细情况.

  (2)Map operation(操作的映射)

   同步操作是基于客户端和服务器端的数据库中每个数据元素都有一个唯一标识(IDS)的原则来进行的.客户端ID被称为本地唯一标识(locally unique indentifier LUID),服务器ID被称为全局唯一标识(globally unique identifier GUID).这个ID在服务器和客户端可以相同,也可以不同.如果这个IDS是不同的,那么服务器端就必须保留一个ID的映射,保证服务端和客户端的数据交换的一致性.LUIDS总是由客户端设备来分配的.这就意味者即使是通过服务端添加一个数据项到客户端设备,也是由客户端为这个数据项分配LUID.分配完成后,客户端将通过Map operation把LUID发送到服务端,服务端将更新MAPPING表中数据项的LUID.

  (3)Sync anchors(同步锚)

  当一个同步会话被初始化的时候,总是有两个锚被发送,一个是最后一次同步的锚一个是下一次同步的锚.最后一次的锚描述了发起同步设备发起最后一次同步事件的时间点;下次同步锚描述了发起同步动作设备的当前的同步事件的时间点.通过这种方式,在服务端和客户端交换各自的同步锚.当接收一个NEXT SYNC ANCHOR时,接收设备必须保存它直到下次同步,当下次同步到来的时候,接收设备将比较两次的同步锚并发送最后一次的同步锚,以判断是否在同步时有数据失败.如果最后一次同步锚和下次同步锚匹配,接收设备将认为没有错误并结束同步会话的初始化.如果不匹配,接收设备将从其他设备请求一个适当的动作,比如慢同步.当同步会话成功并结束后,同步锚将被保存.

  (4)Confict resolution(冲突解决方式)

  当同一个数据项在客户端和服务器端同时被修改后,数据的版本冲突就产生了,对同一数据项将产生两个不同版本的数据.同步协议必须有一种策略解决这样的冲突.在SyncML中,冲突策略是同步引擎的一个基本功能,通常是由同步引擎的同步服务器来解决版本冲突问题,也有可能有写客户端设备提供解决这一问题的解决方式.

  在同步描述协议提供了通过通知同步客户端冲突决定和状态码的通用解决方案.如果同步引擎的服务端确定一个冲突,服务端将使用状态码和通知功能通知同步客户端并定义解决方案.下面是一些常用的状态码和冲突解决策略:

     <1>207:数据合并

     <2>208:客户端优先

     <3>209:数据复制

  5.Security(安全性)

  SyncML为了安全的数据同步提供了框架.SyncML本身并没有提供新的安全机制,但是它提供了安全验证框架和在不同的网络层进行安全验证的机制.

  SyncML协议在三个不同的层次定义了用户验证机制,这个三个层分别是:服务器层,数据库层和对象层.SycnML只要求它的安全验证机制在服务器端被支持就可以了.为了使用SycnML协议,同步的客户端和服务器端必须支持基本的MD5验证.在数据库层面和对象层面的安全验证是可以选择的.

  6.Device capabilities(设备性能)

   SyncML协议通过一个初始化设置可以使不同性能的客户端设备和服务器端进行信息的交换.任意一个设备(客户端或服务端)都能请求信息交换,只要客户端设备性能和服务端能协同工作,他们就能让一个同步会话继续下去.

 有两种类型的信息在设备和服务器端进行交换:

    (1)设备信息:包括设备类型,数据模块和制造厂商信息.

    (2)服务器信息:描述了客户端或服务器端支持的数据对象的特性.如果客户端支持vCard version 2.1数据格式和慢同步及双向同步,那么服务器就必须具有这样的能力,否则,同步就不能继续下去.

 同步的客户端必须在第一次同步或者在设备的静态的信息更新后的时候发送设备信息到服务端。同时，当服务器端请求客户端设备信息的时候，客户端应将自身的设备信息发送到服务端。而一个同步服务器应具备接受和处理设备信息的能力，不论它是否接受过客户端的设备信息或是通过自己请求过客户端设备信息。


今天先写道这里，具体的协议使用流程明天给出(备注：这是本人首次翻译相关技术文档，请各路高手指教)