Travel of Software Developer: 01.2012

You want to reuse action and view-management code.
You want to improve request-handling extensibility, such as adding use case functionality to an application incrementally.
You want to improve code modularity and maintainability, making it easier to extend the application and easier to test discrete parts of your request-handling code independent of a web container.

Pro Spring Patterns

Remove action and view management functionality from the front controller.
Deploy pluggable action and view handlers to provide support for different types of page controllers and views
Improve the reusability, cohesion, and modularity of the application code.
The front controller should be generic and as lightweight as possible.
Promote test-driven devleopment by making it possible to run unit tests outside the web container.

My understanding

To put it simple, Front Controller is a very first step of creating a good web application by centralize the controller into one access point, so that we can standardize the web application process flow, create access points to inject reusable components/filters.

However, Front Controller is too simple to most web applications. We need to do more. So we need to think about how to generalize the other part of the system, to make it "better".

Thanks to Front Controller, we can now have a more general MVC model. We can make sure that the centralized Front Controller, such as Spring Dispatcher Servlet, decouple the web request and many web specific technologies out of the scope of the design, so that we can think in a more generic way, an application way.

After Front Controller, it is not difficult to put the rest of process into two pars: Action Handling and View Handling. The application works through the request and does everything according to the request on the server side, such update database, create session information, update some distributed services, etc. This is the action part. After that, the application needs to response the client with appropriate data with appropriate format. Usually it would be HTML page, but sometimes, it could be something else.

When considering the action part, it could be very complex. But most of the cases could be defined as a chain of execution. Then we can see that the HandlerMapping interface of Spring makes sense:

It uses some request properties to locate an execution chain.

Even though it won't cover all cases, but at least, it would help most of the case. This design is good enough.

Front Controller

Core J2EE Patterns - Front Controller
Design Patterns: Front Controller
Core J2EE Patterns
Front Controller pattern - Wikipedia, the free encyclopedia
P of EAA: Front Controller
Front Controller
Front Controller [Web Application Component Toolkit]

Front Controller pattern - Wikipedia, the free encyclopedia

The Front Controller Pattern is a software design pattern listed in several pattern catalogs.
The pattern related to the design of web application.
It "provides a centralized entry point for handling requests."

My understanding

The most straightforward to implement a web application feature:

Create a start point page, or use a result of another request.
Have the client to fill in some data if necessary.
Have the client to submit the data to send out a request.
Process the request and response with some new information/page.

To fulfill this logic, you just need a form and point out to a response JSP page which is subject to process the request and response with with information.

Centralized dispatcher mechanism:

As a software system, web applications have a log of reusable items, including:

Authentication management.
Consistent page styles.
Shared business logic/component.
Auditing.
etc.

To apply for re-usability, you need to make all the request/response processes working in a similar way and make some places for the reusable components to fit in.

Luckily, we have Spring DispatcherServlet or other framework to help us with this requirements. There are no reasons that we should not stick to it.

Basically, this is a first step to develop a good web application.

What's in the book:

Use Spring Dispatcher Servlet as the standard access point of most of the web request, instead of having a JSP to handle form requests.
Use servlet mapping to map URL patterns to Dispatcher Servlet:

Decouple Spring framework.
Make the system extensible (You can add as many urls as you want into the system)

Use Spring bean container to define the mapping between URL path with a Controller implementation.

A controller is a pure Java class with the knowledge to handling internal process of the requests and the view for the responses.
This controller handle the business logic in a single purpose class.

Design theories:

Decouple the underlying support system. Here is Web server.

Comparing to CGI, or bad JSP implementation

Make the implementation extensible

URL pattern mapping to automatically map things into the dispatcher.
You just need to add a new URL with a certain patterns into your system, without changing the dispatcher's configuration. (Many extensible framework haves this theory, such as OSGi.

Dispatcher View

Core J2EE Patterns - Dispatcher View
Core J2EE Patterns
Dispatcher - Wikipedia, the free encyclopedia
Pro JavaTM EE Spring Patterns: Best ... - Dhrubojyoti Kayal - Google Books
DispatcherServlet (Spring Framework)

Problem domain:

Core J2EE Patterns

Problem:

You want a view to handle a request and generate a response, while managing limited amounts of business processing.

Forces:

You have static views
You have views generated from an existing presentation model.
You have views which are independent of any business service response.
You have limited business processing.

Pro Java EE Spring Patterns

Basically the same.

Solution:

Pro Spring Patterns

What are the differences?

Logically they are the same.
Simple business processes will be configured into the controller using IoC/AOP container, so that business process will be out of the scope of the main process flow. This is the power of declarable service injection and decoupling.
By decoupling business processes, the whole process flow is a simple mapping url dispatching flow

Find the corresponding URL
Create the view
Render it.

Pre-assumption

The business processes should be simple enough to inject into the the controller

Simple input/output parameter
Simple work flow

Overcomplex Concerns

Be careful if:

This is a complex solution to a simple task.

Overcomplex solution:

Dispatching to a static or semistatic view is a simple task. But still there is dependency on layering and various framework-specific components to maintain a consistent application architecture. This is a complex solution to a simple task.

(From Pro Java EE Spring Patterns)

State: You're Doing It Wrong - Alternative Concurrency Paradigms Fo...

JIT编译后的本地代码执行时的内存结构是怎么样的？

弱问：JIT编译后的本地代码执行时的内存结构是怎么样的？

发信人: kyxkcoach (coach), 信区: Java
标  题: 弱问：JIT编译后的本地代码执行时的内存结构是怎么样的？
发信站: 水木社区 (Sat Sep 24 14:03:15 2011), 站内

这时用的堆和栈仍是JVM里面的那个吗，还是直接用操作系统的内存？
这时候动态连接、GC等怎么办？　

发信人: IcyFenix ().println("helloworld"), 信区: Java
标  题: Re: 弱问：JIT编译后的本地代码执行时的内存结构是怎么样的？
发信站: 水木社区 (Sat Sep 24 14:42:12 2011), 站内

在java heap的内容：代码是否被jit过，对在java heap里面的内容没有任何影响。
java heap的memory layout只由虚拟机寻址架构（32/64bit）和class文件中定义
的内容所决定。具体见这篇文章的内存布局部分：
http://icyfenix.iteye.com/blog/1145044
在java vm stack的内容：还是那个jvm栈，但是对于同一段代码在jit前后所形成的
栈帧是不一样的。
在method area的内容：填充了native code cache，但原来类加载时bytecode在
method area所产生的数据不能被简单代替掉，因为hotspot中有激进优化以及持续优
化，前者在优化条件不成立时，需要逆优化退回解释状态执行，后者在执行条件变化
时，要重新进行jit，典型的就是osr编译转标准编译，这都需要原有的类数据做支
持。
上面这几块内存区域，都是实现在os的堆上。“动态连接、GC等怎么办？”，这个等问
题具体一些再讨论。以上内容限于hotspot。

发信人: kyxkcoach (coach), 信区: Java
标  题: Re: 弱问：JIT编译后的本地代码执行时的内存结构是怎么样的？
发信站: 水木社区 (Sat Sep 24 14:52:54 2011), 站内




也就是说PC指令从JVM指令变成了本地CPU的指令，但内存分配仍在JVM的Runtime Data
Area里面？　

那CPU寻址时懂得去找JVM的内存空间？或者说JVM内存空间和OS内存之间有简单直接的映
射？

发信人: IcyFenix ().println("helloworld"), 信区: Java
标  题: Re: 弱问：JIT编译后的本地代码执行时的内存结构是怎么样的？
发信站: 水木社区 (Sat Sep 24 16:39:56 2011), 站内

不需要做映射，jvm的内存就是OS内存的一部分，能直接访问的。具体我们来做一个小
实验吧。看下面简单的代码：

public class Bar {
     int a = 1;
     static int b = 2;

     public int sum(int c) {
         return a + b + c;
     }

     public static void main(String[] args) {
         new Bar().sum(3);
     }
}

上面代码很简单，但也能说明问题了：a是实例变量，来自java heap，b是类变量，来
自method area，c是参数，来自vm stack（这几句是概念模型的，jit后，实际jvm
运作是怎样见后面结论的说明，这里提示一下，避免有同学看了开头没看结尾产生误
解），来看看jit之后，他们是怎么访问的。

执行环境是7u02 fastdebug with hsdis：
>java -version
java version "1.7.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b127)
Java HotSpot(TM) Client VM (build 20.0-b06-fastdebug, mixed mode)

执行命令：
>java -XX:+PrintAssembly -Xcomp -
XX:CompileCommand=dontinline,*Bar,sum -
XX:CompileCommand=compileonly,*Bar.sum test.Bar
上面-Xcomp是让虚拟机尽量编译模式，这样代码偷懒不用jit预热。两个
CompileCommand意思是不要内联sum并且只编译sum，PrintAssembly就是输出反汇
编内容。
all right，一切顺利的话，屏幕上出现类似下面的内容：

[Disassembling for mach='i386']
[Entry Point]
[Constants]
   # {method} 'sum' '(I)I' in 'test/Bar'
   # this:     ecx       = 'test/Bar'
   # parm0:    edx       = int
   #           [sp+0x20]  (sp of caller)
   ……
   0x01cac407: cmp    0x4(%ecx),%eax
   0x01cac40a: jne    0x01c6b050         ;   {runtime_call}
[Verified Entry Point]
   0x01cac410: mov    %eax,-0x8000(%esp)
   0x01cac417: push   %ebp
   0x01cac418: sub    $0x18,%esp         ;*aload_0
                                         ; - test.Bar::sum@0 (line
8)
   ;;  block B0 [0, 10]

   0x01cac41b: mov    0x8(%ecx),%eax     ;*getfield a
                                         ; - test.Bar::sum@1 (line
8)
   0x01cac41e: mov    $0x3d2fad8,%esi    ;   {oop(a
'java/lang/Class' = 'test/Bar')}
   0x01cac423: mov    0x68(%esi),%esi    ;*getstatic b
                                         ; - test.Bar::sum@4 (line
8)
   0x01cac426: add    %esi,%eax
   0x01cac428: add    %edx,%eax
   0x01cac42a: add    $0x18,%esp
   0x01cac42d: pop    %ebp
   0x01cac42e: test   %eax,0x2b0100      ;   {poll_return}
   0x01cac434: ret

代码很简单，一句一句来看：
检查栈溢（mov %eax,-0x8000(%esp)）
保存上一栈帧（push %ebp）
建立新帧（sub $0x18,%esp）
取实例变量a（0x8(%ecx),%eax），这里0x8(%ecx)就是ecx+0x8的意思，前面
[Constants]中提示了，“this:ecx = 'test/Bar'”，那么偏移0x8越过对象头之
后，就是实例变量a的位置。这里没有“映射”，相对地址直接访问。
取test.Bar在方法区的指针（$0x3d2fad8,%esi），看，这里0x3d2fad8直接就访问
了，也没有“影射”，如我前面说的，jvm内存也是os内存的一部分，绝对地址也是直接
访问。
取类变量b（mov 0x68(%esi),%esi）
做2次加法，求a+b+c（add %esi,%eax 、add %edx,%eax），c呢？在
[Constants]中提示了，“parm0:edx = int”，在edx中。
撤销栈帧（add $0x18,%esp）
恢复上一栈帧（pop %ebp）
轮询方法返回处的safepoint（test %eax,0x2b0100）
方法返回（ret）

结论：
前一贴提到，java heap、method area、vm stack都在操作系统的堆内存中，在
jit之后，native code面向的是操作系统的堆，说变量a还在java heap中，应当理
解为a的位置还在原来的内存位置上，但是native code是不理会java heap之类的概
念的，因为不是同一个层次的东西。那得出的结论是JVM Spec上的模型与实际运作，
尤其是JIT后实际的内存模型是两码事。

Travel of Software Developer

31.1.12

30.1.12

22.1.12

android - How do I get the web page contents from a WebView? - Stack Overflow

Android - Handle "Enter" in an EditText - Stack Overflow

19.1.12

15.1.12

Ramblings on pretty much anything technical.: Observations on ActiveMQs temp storage.

14.1.12

XPath

12.1.12

How to use ExecutorService of java concurrent programming? - Stack Overflow

Java Monitoring

9.1.12

1.1.12

Servlet and JSP development with Eclipse WTP

Application Controller

Front Controller

Dispatcher View

Overcomplex Concerns

JIT编译后的本地代码执行时的内存结构是怎么样的？