xmatthew - BlogJava

摘要: 本人早期整理的Java工具类学习笔记阅读全文

posted @ 2008-10-25 20:21 x.matthew 阅读(4079) | 评论 (7) | 编辑收藏

JSR 311(JAX-RS: Java API for RESTful Web Services) 规范正式发布

期待了好久了，终于等到了规范的正式的发布。下面官方发布信息,记录了JSR 311规范从筹备到发布的历程。


Status: Final
Stage		Start	Finish
Final Release	Download page	10 Oct, 2008
Final Approval Ballot	View results	09 Sep, 2008	22 Sep, 2008
Proposed Final Draft	Download page	15 Aug, 2008
Public Review Ballot	View results	27 May, 2008	02 Jun, 2008
Public Review	Download page	02 May, 2008	02 Jun, 2008
Early Draft Review	Download page	24 Oct, 2007	23 Nov, 2007
Expert Group Formation		27 Feb, 2007	15 Aug, 2007
JSR Review Ballot	View results	13 Feb, 2007	26 Feb, 2007
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Please direct comments on this JSR to: jsr-311-comments@jcp.org

与其它规范发布一样，伴随此次发布，Sun同步发布该规范的参考实现项目jersey。最新版本为1.0。为了让大家能快速体验Rest带给我们全新的架构风格，可以直接从本地下载程序。bookstore-1.0.war 源代码 bookmark-1.0-project.zip.

下面展示了一个代码片断，让大家直观感受一下。

1 @Path("/bank")
2 public class Bank {
3
4     @POST
5     @Path("/account/{name}")
6     public Account createAccount(@PathParam("name") String name,
7             @QueryParam("balance")BigDecimal balance) {
8         //

9         return new Account(name, balance);
10     }
11
12     @GET
13     @Path("/account/{name}")
14     public Account getAccount(@PathParam("name") String name) {
15         //

16         return Account.getByName(name);
17     }
18
19 }
20

上面的代码，就会发布两个资源服务:

POST /bank/account/newAccount
GET /bank/account/newAccount

大家看到，用Rest发布资源服务非常方便。当然上面例子只是一个非常简单的示例，用于展示Rest的应用，也希望大家提出好的建议和意见。

Good Luck!
Yours Matthew!

posted @ 2008-10-21 21:29 x.matthew 阅读(5876) | 评论 (3) | 编辑收藏

Hibernate配置文件中几种实现数据库连接方式的配置方法

  参读了Hibernate的源代码后，整理了一下Hibernate配置文件中几种实现数据库连接方式的配置方法。(共四个方式)
   1. 程序内部启动 c3p0 连接池。
   配置方式如下:连接池的支持(注：需要c3p0的类库支持)

   注： Hibernate根据 hibernate.c3p0.max_size 这个配置来识别是支持c3p0连接池

   2. 引用外部连接池    (通过JNDI查找 DataSource资料)
   需要配置方式如下:

   3. 通过 org.hibernate.connection.ProxoolConnectionProvider 创建
    由
       hibernate.proxool.xml
       hibernate.proxool.properties
       hibernate.proxool.existing_pool 三个配置一起来确定

   4. DriverManager 创建直接连接方式

注： Hibernate根据 hibernate.connection.url这个来识别,由于在识别时，c3p0的优先级会高于DriverManger所以，与c3p0的配置不会冲突

Good Luck!
Yours Matthew!

posted @ 2008-10-19 21:19 x.matthew 阅读(3281) | 评论 (0) | 编辑收藏

源代码解读Spring+Hibernate(JPA)的LazyLoadException异常

好久的笔记了，趁刚好休息整理文档，翻出这一部分，稍加整理后，就发上来给大家共享一下，希望对各位有所帮助。

关于LazyLoadException异常，使用过Hibernate O/R Mapping工具的人应该都遇到过，网上也是有很多解决的方案，其中Spring提供的一个方案就是在web.xml增加一个filter,示例代码如下:

<filter>
    <filter-name>entityManager</filter-name>
    <filter-class>org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>entityManagerFilter</filter-name>
    <url-pattern>*.action</url-pattern>
</filter-mapping>

解决办法有了，接下来应该会有人好奇：这个配置filter后它是如何工作的？
下面来分析一下这个功能实现的源代码, 不过之前，比较重要的是了解，为何会出现lazyload exception的异常发生。

下面我模拟写了一段代码，这段代码就会发生该异常
注：只是为了说明，相关的代码就省略了。

@Entity
public class Room {

@Id
@Column(length=32)
private String id;

@Column(length=20)
private code;

@OneToMany(mappedBy="room") //default is use lazy load strategy
private Set desks;
}

@Entity
public class Desk {

     @Id
     @Column(length=32)
     private String id;

     @Column(length=20)
     private code;

     @ManyToOne
     private Room root;

}

public class RoomSerivce {

    @Transactional(readOnly=true)
    public Room getRoomById(String roomId) {
      Assert.notBlank(roomId, "room'id is null);
        return getDao().findById(roomId);

    }

}

1 public class RoomServiceTest {
2
3     public static void main(String[] args[]) {
4
5         //get service from spring beanfactory
6         RoomService service = SpringContext.getSerivce("roomService");
7         Assert.notNull(service, " roomService bean not exsit");
8
9       Room room = service.getRoomById("1");
10       //here lazy exception throw out
11       Set Desks = room.getDesks();
12       CollectionsUtils.toString(Desks);
13     }
14 }

   分析这段代码，我们不难发现，在RoomServiceTest这个测试的例子中，因为使用了基于Annotation的声明性事务，所以在RoomSerivce.getRoomById方法运行结束后，事务就已经提交了。但示例中Room实体与Desk实例的关系使用的是lazy fetch的策略，此时Room对象中的desks集合还是为空。
当执行到下面两句时(这才真正使用到desks集合时)
Set Desks = room.getDesks();
CollectionsUtils.toString(Desks);
Hibernate就会根据原来lazy设定的方式，取EntityManager，根据它从数据库查询 Desk实现的数据，这时上面我们已经提到，事务已经随getRoomById方法的运行结束提交. EntityManager对象也已经关闭。此时再调用 EntityManager操作，就会报EntityManager has been closed 异常(lazy load exception)

   ok, 清楚这块，大家有时可能也猜想到了Spring这个解决方案是怎么处理的了。
   Spring的TransactionInterceptor 其就是通过AOP负责拦截着所有针对事务TransactionManager的操作.
   这样Spring就可以针对lazy异常进行拦截了。

   清楚上面的后，下面的代码是非常好理解了，来看一下OpenEntityManagerInViewFilter的代码:
我加了些注释，大家很容易明白:

1     protected void doFilterInternal(
2             HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
3             throws ServletException, IOException {
4
5       //通过WebApplicationContext,从Web服务中取得context实例后，根据EntityManagerFactory.class类型
6       //取得EntityManagerFacotry实例
7         EntityManagerFactory emf = lookupEntityManagerFactory(request);
8         boolean participate = false;
9
10         //如果静态方法hasResource已经有EntityManagerFactory实例了，就不用再通过
11         //EntityManagerFactory创建一个新EntityManger了
12         if (TransactionSynchronizationManager.hasResource(emf)) {
13             // Do not modify the EntityManager: just set the participate flag.
14             participate = true;
15         }
16         else {
17             logger.debug("Opening JPA EntityManager in OpenEntityManagerInViewFilter");
18             try {
19             //通过EntityManagerFactory创建一个新EntityManger,并通过bindResource方法
20             //保存到TransactionSynchronizationManager中
21             //这样，通TransactionSynchronizationManager的getResource方法取得EntityMangerHolder
22                 EntityManager em = createEntityManager(emf);
23                 TransactionSynchronizationManager.bindResource(emf, new EntityManagerHolder(em));
24             }
25             catch (PersistenceException ex) {
26                 throw new DataAccessResourceFailureException("Could not create JPA EntityManager", ex);
27             }
28         }
29
30         try {
31             filterChain.doFilter(request, response);
32         }
33
34         finally {
35             if (!participate) {
36             //每次请求结束后，就把EntityManager关闭
37                 EntityManagerHolder emHolder = (EntityManagerHolder)
38                         TransactionSynchronizationManager.unbindResource(emf);
39                 logger.debug("Closing JPA EntityManager in OpenEntityManagerInViewFilter");
40                 EntityManagerFactoryUtils.closeEntityManager(emHolder.getEntityManager());
41             }
42         }
43     }
44

    上面的代码就不用多解释了，到现在已经很清楚知道Spring针对 Hibernate的Lazy问题是怎么解决的。
    当然我们可以扩展到除Web服务以外，来实现解决lazy的问题。(我们自己来管理TransactionSynchronizationManager就可以了)

    当然Spring针对 Hibernate(非JPA的实现)原理也是一样，只是它针对的SessionFactory,也是由TransactionSynchronizationManager来统一管理。

    最后如果大家如还有不清楚的，欢迎一起讨论。

Good Luck!
Yours Matthew!

posted @ 2008-10-11 18:01 x.matthew 阅读(3084) | 评论 (3) | 编辑收藏

找工作一定要先了解公司的团队文化

    盼了好久的国庆节终于到了，整理一下手边的工作，工作进度的追踪，code review和工作管理报告都已经完成。终于松了口气，长假可以尽情休整一下(虽然回来工作会更忙碌)，但这段时间可以有很多的自由时间分配，打算给自己好好的冲冲电。

    闲话少说，进入正题。之所以本人要提出"找工作一定要先了解公司的团队文化"这个建议，是因为最近一项工作中的一些事情让我感触颇深，所以写下来，也且当发发牢骚。
    由于最近公司与一个专业的软件公司X公司(不方便直注该公司名称)签订开发了一套比较大的系统,现在到了开发合同到期, 按双方领导协商，开始系统的交接工作。本人被任命参与到这项任务，担任移交过程中所有的技术支持工作。

    交接工作其实就是对方公司提交约定要求设计文档，最新的源代码，接口文档，我这边负责审阅这些文档和代码，再重新按公司文档要求重新整理，备案，当然前题我必须完全整理这些文档的内容和代码的每个方法的功能。
    就在移交过程中，发生一些事情，让我头疼了好一阵，才引发了我对大家找工作的这条建议。
    事情的全部经过大概是这样，因为系统比较庞大(其实共有五个独立的子系统组成),所以一个子系统的进行交接，每个子系统交接安排在两周至三周时间。首先交接的就是文档，当我接到文档后，着实让我吃惊不少。文档基本上看不太明白，不仅内容不全，而且基于上与系统对应不上。所谓的设计文档，只有界面设计(而且没有几个与现系统能完全对应上的)与数据表设计外，其它的什么都没有。没有办法，所以让领导干涉，但多次沟通无果后(跨公司合作很难), 最终只要放弃对文档部分的要求，公司这边也是希望我这边通过掌握他们的代码，这样文档部分就可以由我们边来整理了。

   当然读代码并不是件易事，尤其是读别人写的代码。所以我也整理了一套方案，希望对方公司能提供下面一些简单文档以帮助我顺利开展代码的阅读工作。
    1. 程序清单--包括程序名称(功能)对应的源代码文件,对应的数据表名 (因为用C#开发，基本上一个源文件，一个窗体文件)
    2. 接口文档(主要对其它子系统的接口部分，因为他们的实现是通过共享表实现数据交互，所以这块接口说明就更加重要)接口文档希望他们能整理出接口的功能说明，接口所在的源代码，接口数据表字段说明，触发的动作，触发的频率。

    这次对方公司很合作，三天就把文档写完发给了我们，但质量呢？，除了程序清单还算可以看外，接口文档就丢了几张数据表过来，而且还有三分之一的表名没有列到文档中，其它就什么都没有的。（这是接口说明文档，当然觉得不行了，这个根本没有办法整理), 所以提议想与他们的技术人员沟通一下，猜想可能对方是没有太明白我们接口文档的要求吧，所以沟通后，与他们的一个项目经理协商(到里觉很，安排得很好，这样的任务与技术领导沟通问题应该马上就能解决了，我刻意先打听一下这位经理的一些情况，听说是有很高的学历和资历)，准备好说词后，就与这个经理进行了交流，但结果让我有点意外，他强调这个文档没有问题，所以我按原准备好的说词，与他说明接口的重要性，接口文档应该怎么编写。而他的这次回答，就让感觉太意外了。他解释到，接口不是一个东西(头一次听说),在他们的设计中，所有的代码设计都是个人边想边写的，而且他们的系统是一个整体，没有接口(那几个子系统交互的数据说明没有，那还不乱了)，所以他解析根本没有"(你们说的)接口"这个东西，是因为我们提了要"(这个他认为不存在的)接口", 所以弄了几张表给你们。还说以前他们给别人做系统，别人从没有这么要过。同时故意询问一下他手下几个做开发的人员，"你们知道接口吗？能按他们要求整理出来吗？"结果他手下很会意的回复到，怎么会有这东西,现在能整理得出数据表已经不错了，我写代码现在早记不清楚，给你们弄表名已经够花时间的了。（真是无话可说),接下来他还要"教导"我，说我对接口是一个错误的理解，要帮我纠正过来。听他们这样的回复，真是无奈的很，但毕竟工作没完成，无法向领导交差，还是坚持的一点希望他们能按要求交出接口文档，但足足说了20分钟，都无果(可能有人会问，怎么会花这么多时间，我只能说大家都看过大话西游的唐僧吧)。

   最后终于放弃(无奈啊)，无功而返。回去后，虽然头疼，但必竟是自己的任务没有完后，只好自己花时间读代码，希望把接口这部分的文档整理出来。结果一看代码，简直让我哭笑不得，到处都是不知明的变量a1,ttt，text1,不知明的方法button1Onclick, button5Onclick。方法没有参数，都是通过全局变量来传递，还有更严重的就是数据库操作竟然没有事务(后来与他们一个开发人员交流后，才得知他根据就不知道什么是事务，也不知道事务有什么用途)，与他们经理沟通，结果他很“聪明"来一个拖延战术，没办法，系统问题太多，不交接对方公司就不提供源代码，也就无法解决问题(最终他的战术成功).

   到现在为止交接过程就在这种状况进行近一半了，交接了有二个系统。也陆续见过一些他们的开发人员，都是毕业二三年的年青程序员，实话说看他们的代码，真是件非常痛苦的事情(怎么会有这样的程序员)，但反思过来，替他们一想，想必他们刚从大学出来，应该也是雄心壮志，也想做一个优秀的程序员(应该是误入了这个这么糟的团队所致吧)。其实我心里一直想问他们一个问题，"你们真不担心自己的前途和发展吗？"(并非我忋人忧天，像他们虽年轻，但时间一晃就过，照他们现在没有目标规划，只是与现在的团队熬下去的话，到了三十岁以后，那就比较难补救了。)

说了这么多，的确啰嗦了。最后还是强调一下我们观点，找工作，一定要多去了解面试的那个团队的文化氛围。本人认为好的团队，才能带领员工成长和发展的。

祝国庆快乐！

Good Luck!
Yours Matthew!

posted @ 2008-09-29 00:48 x.matthew 阅读(651) | 评论 (1) | 编辑收藏

Tomcat5 类装载器分析

    Tomcat5.5 类装载器的实现都是通过继承于JDK中的 java.lang.ClassLoader类。
    包括Bootstrap，System，Common, Catalina, Shared和Webapp这六种类加载器来实现不同目录的类文件装载。

    Bootstrap
          |
       System
          |
       Common
      /      \
Catalina   Shared
             /   \
        Webapp1 Webapp2 ...

Bootstrap 类装载器:
    它用于加载最基本的JVM运行环境类，装载JDK目录下类文件($JAVA_HOME/jre/lib/ext)
    使用它的目的是以防一些JVM提供商实现时，可能考虑某些原因会把部分的类文件通过不同的多个类加载加器加载，同时会
    屏蔽一些类加载让应用层的类加载器访问到。
    System 类装载器:
        该类装载器根据JVM的CLASSPATH参数设置装载类文件，该类装载器对于Tomcat内部的程序和应用层的程序都是可见的。
        注：目前tomcat5的启动脚本($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat)，会把全局环境变量CLASSPATH忽略。
        而且通过下面的几个类库来实现装载设置:
        * $CATALINA_HOME/bin/bootstrap.jar 包含一个main()方法来初始化tomcat5服务，并实例类装器所依赖的类文件。
        * $CATALINA_HOME/bin/tomcat-juli.jar 初始Jakarta commons logging API和 java.util.logging LogManager.
        * $CATALINA_HOME/bin/commons-logging-api-x.y.z.jar - Jakarta commons logging API.
        * $CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon API.
        * jmx.jar - The JMX 1.2 implementation.
    Common 类装载器:
        该类装载器对于Tomcat内部的程序和应用层的程序都是可见的.
        当然不太建议把应用层的类库放到这里来加载。
        所有$CATALINA_HOME/lib目录下未压缩的类文件，资源和压缩后Jar/zip文件都会补该类装载器加载。

        Tomcat5.5默认该目录的类文件有:
        * commons-el.jar - Jakarta commons el, implementing the expression language used by Jasper.
        * jasper-compiler.jar - The JSP 2.0 compiler.
        * jasper-compiler-jdt.jar - The Eclipse JDT Java compiler.
        * jasper-runtime.jar - The JSP 2.0 runtime.
        * jsp-api.jar - The JSP 2.0 API.
        * naming-common.jar - The JNDI implementation used by Tomcat 5 to represent in-memory naming contexts.
        * naming-factory.jar - The JNDI implementation used by Tomcat 5 to resolve references to enterprise resources (EJB, connection pools).
        * naming-factory-dbcp.jar - Jakarta commons DBCP, providing a JDBC connection pool to web applications. The classes have been moved out of their default org.apache.commons package.
        * naming-java.jar - Handler for the java: namespace.
        * naming-resources.jar - The specialized JNDI naming context implementation used to represent the static resources of a web application. This is not related to the support of the J2EE ENC, and cannot be removed.
        * servlet-api.jar - The Servlet 2.4 API.
        * tomcat-i18n-**.jar - Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.

    Catalina 类装载器:
         该类装载器用都装载tomcat5.5本身所需要的类文件和资源。应用层的类装载器不能访问到它。
        所有$CATALINA_HOME/server/classes目录下未压缩的类文件，资源文件都会补该类装载器加载。
        所有$CATALINA_HOME/server/lib目录下压缩后Jar/zip文件都会补该类装载器加载。
         Tomcat5.5默认该目录的类文件有:
        * catalina.jar - Implementation of the Catalina servlet container portion of Tomcat 5.
        * catalina-ant.jar - Some Ant tasks which can be used to manage Tomcat using the manager web application.
        * catalina-optional.jar - Some optional components of Catalina.
        * commons-modeler.jar - A model MBeans implementation used by Tomcat to expose its internal objects through JMX.
        * servlets-xxxxx.jar - The classes associated with each internal servlet that provides part of Tomcat's functionality. These are separated so that they can be completely removed if the corresponding service is not required, or they can be subject to specialized security manager permissions.
        * tomcat-coyote.jar - Coyote API.
        * tomcat-http.jar - Standalone Java HTTP/1.1 connector.
        * tomcat-ajp.jar - Classes for the Java portion of the AJP web server connector, which allows Tomcat to run behind web servers such as Apache and iPlanet iAS and iWS.
        * tomcat-util.jar - Utility classes required by some Tomcat connectors.

    Shared 类装载器:
        该类装载器可化被所有的应用程序类装载器共享(除了tomcat本身内部类加载外)
            所有$CATALINA_BASE/shared/classes目录下未压缩的类文件，资源文件都会补该类装载器加载。
        所有$CATALINA_BASE/shared/lib目录下压缩后Jar/zip文件都会补该类装载器加载。
        注：如果有该类库使用$CATALINA_BASE环境变量启动了多个实例，则该类装载器类库的引使用会$CATALINA_BASE变量而不是$CATALINA_HOME

    Webapp 类装载器:
        应用层的类装载器，每个应用程序都会创建一个单独的类装载器。该类装载器只能本应用程序中可见。
        所有/WEB-INF/classes目录下未压缩的类文件，资源文件都会补该类装载器加载。
        所有/WEB-INF/lib目录下压缩后Jar/zip文件都会补该类装载器加载。


    把各个类装载器的定义整理出来后，Tomcat5.5服务器类装载器执行的顺序如下:
    * Bootstrap classes of your JVM
    * System class loader classses (described above)
    * /WEB-INF/classes of your web application
    * /WEB-INF/lib/*.jar of your web application
    * $CATALINA_HOME/common/classes
    * $CATALINA_HOME/common/endorsed/*.jar
    * $CATALINA_HOME/common/i18n/*.jar
    * $CATALINA_HOME/common/lib/*.jar
    * $CATALINA_BASE/shared/classes
    * $CATALINA_BASE/shared/lib/*.jar

Good Luck!
Yours Matthew!

posted @ 2008-09-27 19:28 x.matthew 阅读(2110) | 评论 (1) | 编辑收藏

Tomcat6 类装载器分析

    Tomcat6 类装载器的实现都是通过继承于JDK中的 java.lang.ClassLoader类。
    包括Bootstrap，System，Common和Webapp这四种类加载器来实现不同目录的类文件装载。
    示例结构如下：
      Bootstrap
          |
       System
          |
       Common
       /     \
Webapp1   Webapp2 ...

Bootstrap 类装载器:
    它用于加载最基本的JVM运行环境类，装载JDK目录下类文件($JAVA_HOME/jre/lib/ext)
    使用它的目的是以防一些JVM提供商实现时，可能考虑某些原因会把部分的类文件通过不同的多个类加载加器加载，同时会
    屏蔽一些类加载让应用层的类加载器访问到。
    System 类装载器:
        该类装载器根据JVM的CLASSPATH参数设置装载类文件，该类装载器对于Tomcat内部的程序和应用层的程序都是可见的。
        注：目前tomcat5的启动脚本($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat)，会把全局环境变量CLASSPATH忽略。
            而且通过下面的两个类库来实现装载设置:
            * $CATALINA_HOME/bin/bootstrap.jar 包含一个main()方法来初始化tomcat6服务，并实例类装器所依赖的类文件。
            * $CATALINA_HOME/bin/tomcat-juli.jar 初始Jakarta commons logging API和 java.util.logging LogManager.
    Common 类装载器:
        该类装载器对于Tomcat内部的程序和应用层的程序都是可见的.
        当然不太建议把应用层的类库放到这里来加载。
        所有$CATALINA_HOME/lib目录下未压缩的类文件，资源和压缩后Jar/zip文件都会补该类装载器加载。

        Tomcat6默认该目录的类文件有:
        * annotations-api.jar - JEE annotations classes.
        * catalina.jar - Implementation of the Catalina servlet container portion of Tomcat6.
        * catalina-ant.jar - Tomcat Catalina Ant tasks.
        * catalina-ha.jar - High availability package.
        * catalina-tribes.jar - Group communication package.
        * el-api.jar - EL 2.1 API.
        * jasper.jar - Jasper 2 Compiler and Runtime.
        * jasper-el.jar - Jasper 2 EL implementation.
        * jasper-jdt.jar - Eclipse JDT 3.2 Java compiler.
        * jsp-api.jar - JSP 2.1 API.
        * servlet-api.jar - Servlet 2.5 API.
        * tomcat-coyote.jar - Tomcat connectors and utility classes.
        * tomcat-dbcp.jar - package renamed database connection pool based on Commons DBCP.
        * tomcat-i18n-**.jar - Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.

    Webapp 类装载器:
      应用层的类装载器，每个应用程序都会创建一个单独的类装载器。该类装载器只能本应用程序中可见。
    所有/WEB-INF/classes目录下未压缩的类文件，资源文件都会补该类装载器加载。
    所有/WEB-INF/lib目录下压缩后Jar/zip文件都会补该类装载器加载。

    把各个类装载器的定义整理出来后，Tomcat6服务器类装载器执行的顺序如下:

    * Bootstrap classes of your JVM
    * System class loader classses (described above)
    * /WEB-INF/classes of your web application
    * /WEB-INF/lib/*.jar of your web application
    * $CATALINA_HOME/lib
    * $CATALINA_HOME/lib/*.jar

Good Luck!
Yours Matthew!

posted @ 2008-09-27 19:24 x.matthew 阅读(2847) | 评论 (2) | 编辑收藏

Spring3.0新特征-Restful support MVC

最近在Spring官网上发现，Spring 2.5发布不久，Spring3.0项目已经是开始进行了。

包括很多新功能，如标题中提到的Restful的支持，还有Servlet3.0的支持等。
大概总结了一下，Spring3.0中会包括以下一些新特性:

1. Full scale REST support by means of additions to the Spring MVC API - already pretty detailed, and apparently going to be included in the first milestone release

2. Support for Unified EL (as seen in Spring Web Flow) - very likely part of 3.0, but no details given

3. Annotation support for declaring factory methods - as above
4 .Support for Portlet 2.0 (JSR 286), including resource requests (ResourceServingPortlet) - as above
5. "Preparations" for Servlet 3.0 specification - sounded a lot like architectural preparations not visible to the "consumer"
6. Something to fill the gap between Spring Web Flow and Spring MVC - that sounded very vague
7. Inclusion (probably generalisation) of the repeat, retry and resume semantics provided by Spring Batch - was only hinted at, no details given
8. Inclusion of the OXM support provided by Spring WS - sounded pretty definitive, but no details given
9. Some kind of site definition language for the web stack - no idea whether this is more than a rumour
10. Model-based validation for use both in server and client - as above

下面我们具体介绍一下Restful该特性.
刚才我也提到了，Spring3.0是基于其目前提供的Spring MVC框架上引入对Rest的支持，这样使其可以很好的融合到Spring中。
下面有一段代码，大家看了会更有体会。
先看一下如何发布Rest风格的服务接口

1 @RequestMapping(value = "/gadgets/{id}",
2       method = RequestMethod.GET)
3 public View getGadget(@PathParam String id) {
4   // 功能是根据 id 查询 Gadget对象
5   // 返回View对象
6 }
7

   看到使用Annotation方式，代码非常简洁。@RequestMapping是对访求的资源进行服务的绑定， value指定服务的资源路径, method是指Rest风格中的CRUD的方法。
   @PathParam是对资源路么参数的解析,它会自动根据提交的数据格式，解析参数值。

   下面来看一下RestTemplate，对Rest服务接口的调用.

1 // 使用getForObject执行查询操作
2 // (指定参数提交方式)
3 RestTemplate template = new RestTemplate();
4 Gadget gadget = template.getForObject(
5     "http://www.springify.com/gadgets/{id}",
6     Gadget.class, 1);
7
8 // 使用postForLocation 执行新增操作
9 // (指定参数提交方式,使用Map对象)
10 Map<String, String> params =
11     new HashMap<String, String>();
12 params.put("id", 42);
13 URI uri = template.postForLocation(
14     "http://www.springify.com/gadgets/{id}/features",
15     new Feature("Glows in the dark."), params);
16
17 // 删除操作的演示
18 template.delete(
19     "http://www.springify.com/gadgets/{id}", someId);
20
21
29

总结：可以看到使用Rest风格的服务发布，可以对服务资源进行统一的管理，使用发布的接口更清晰。

当然在Spring 3.0 发布之前，上述的API，annotation可能会有变动，我们也期待Spring能与我们早日见面。

最后，由于本人对Rest技术了解还不是太深入，也希望大家能多提些意见和建议。

Good Luck!
Yours Matthew!

posted @ 2008-09-02 19:32 x.matthew 阅读(4782) | 评论 (4) | 编辑收藏

hibernate-memcached--在Hibernate中使用Memcached作为一个二级分布式缓存

摘要: 今天在网上看到一个用Memcached作为Hibernate二级分布式缓存，感觉挺有兴趣，就是尝试用了，感觉还不错，就推荐给大家看一下。阅读全文

posted @ 2008-08-20 16:43 x.matthew 阅读(14906) | 评论 (11) | 编辑收藏

VB6实现基于HTTP Web调用解决方案

摘要: 引子: VB6是一种比较早的高级语言,但可以说在它那个时代非常流行，本人就遇到不少项目用该语言进行开发，但随着Java, .net等其它新语言的发展，VB6已经渐渐淡出了，但不少其开发的项目却被保留了下来。目前遇到的一个困扰就是这样的系统如何解决与新语言开发的系统的数据交互问题。本文就先抛一个话题，VB6实现基于HTTP Web调用来解决与基于B/S架构的应用程序间的调用(示例使用Java开发)。阅读全文

posted @ 2008-08-19 08:50 x.matthew 阅读(5602) | 评论 (1) | 编辑收藏

仅列出标题

常用链接

留言簿(45)

随笔分类(145)

随笔档案(110)

文章档案(1)

友情链接

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜