tryOnIt

Thursday, November 02, 2006

Birthday

Today i turned 29! Recall the my last 6 years:
2000: failed in examing for master, and then i began my first online game;
2001 : graduated from college and hunter my first job;
2002 ~ 2004: work harder, harder;
2005: too tired to continue, then i left job 6 month and played online game again;
2006: return to work and fall in love.

BTW eclipse is turning 5!

Happy Birthday!!!

Tuesday, October 31, 2006

Specify custom isolation levels with the Spring framework

Many Java Enterprise Edition (EE) applications access more than one resource when executing a user's request. For instance, an application might need to place a message on a message-oriented middleware queue and update a database row under the same transactional context. You can accomplish this by using the Java Transaction API (JTA) transaction manager your application server provides and XA-compliant drivers to connect to the data resources. But your application's requirements might call for a custom isolation level in a global transaction during the execution of a use case -- and JTA transaction managers don't support custom isolation levels. If you're using the Spring framework, an exception will be thrown if you specify a custom isolation level for a global transaction in your Spring configuration file, for this reason.

This article shows you a way you can use Spring to specify custom isolation levels in global transactions. The approach works if you're deploying your application on any application server that uses the data source definition as the location for specifying the isolation level value for database access. To benefit from the article, you should be familiar with the Spring framework and understand how to define transactional proxies and aspect-oriented advice in Spring configuration files. Familiarity with your application server, Java EE design patterns, and the concept of global/distributed transactions is also assumed.

Source: Specify custom isolation levels with the Spring framework

Javolution

Javolution real-time goals are simple: To make your application faster and more time predictable!
That being accomplished through:

Source: Javolution

Friday, October 27, 2006

Getting Real: What is Getting Real? (by 37signals)

  • Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
  • Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).
  • Getting Real is staying small and being agile.
  • Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
  • Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
  • Getting Real delivers just what customers need and eliminates anything they don't.
  • Source: Getting Real: What is Getting Real? (by 37signals)

    Thursday, October 26, 2006

    InfoQ: Migrating Struts Apps to Struts 2

    The processing of a request can be broken into these 6 steps:

    1. A request is made and processed by the framework - the framework matches the request to a configuration so that the interceptors, action class and results to use are known.
    2. The request passes through a series of interceptors - interceptors, and interceptor stacks, can be configured at a number of different levels for the request. They provide pre-processing for the request as well as cross-cutting application features. This is similar to the Struts RequestProcessor class which uses the Jakarta Commons Chain component.
    3. The Action is invoked - a new instance of the action class is created and the method that is providing the logic for this request is invoked. We will discuss this in more detail in the second part of this series; however, in Struts2 the configuration of the action can specify the method of the action class to be invoked for this request.
    4. The Result is invoked - the result class that matches the return from processing the actions' method is obtained, a new instance created and invoked. One possible outcome of the result being processed is rendering of a UI template (but not the only one) to produce HTML. If this is the case, then Struts2 tags in the template can reach back into the action to obtain values to be rendered.
    5. The request returns through the Interceptors - the request passes back through the interceptors in reverse order, allowing any clean-up or additional processing to be performed.
    6. The response is returned to the user - the last step is to return control back to the servlet engine. The most common outcome is that HTML is rendered to the user, but it may also be that specific HTTP headers are returned or a HTTP redirect is invoked.

    Source I: InfoQ: Migrating Struts Apps to Struts 2 -- PART I

    Source II: InfoQ:Migrating Struts Apps to Struts 2 -- PART II

    Tuesday, October 24, 2006

    SOA meets Web 2.0 - Where the Java EE standards fall short

    Fundamentally, a service-oriented architecture facilitates the creation of dynamic data services within the enterprise and enables the enterprise developer to create composite applications that leverage any number of these services. Web 2.0 promises a rich Web experience where users can collaborate in effective and, hopefully, rewarding ways. If we combine these two phenomena we can begin to realize significant new efficiencies in the way members of an enterprise community interact amongst themselves and with corporate data that is constantly changing around them. Collaborative enterprise mashups and other next-generation Web applications are on the horizon, but speculation in the development community is that there are fundamental gaps between the technologies needed to realize the apparent benefits. We will examine the state of Java presentation technologies in an effort to understand where the standards must go to facilitate the marriage of SOA and Web 2.0 concepts.

    Source: SOA meets Web 2.0 - Where the Java EE standards fall short

    Monday, October 23, 2006

    MaintainJ inc.

    MaintainJ uses AspectJ to capture the sequence of method calls for a use case. This call trace is used to generate the diagrams. MaintainJ works as a plug-in to Eclipse. Developers write simple aspects that capture the call trace and save the trace files with extension 'ser'. These *.ser files can directly be opened in Eclipse to show class and sequence diagrams.

    Link to MaintainJ inc.

    Monday, September 04, 2006

    Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0

    This article compared Spring and EJB3.0 at persistence, transcation management, statefulness.

    After reading, i got the idea, Spring is more flexible whereas EJB3.0 is more scalable and extensible.

    There will be the part 2 in this series (coming soon), it will examine additional characteristics including messaging, remoting, scheduling, dependency, and intermediation. Also it will illustrate how to make the decision between Spring and EJB3.0 and the strategies for integrating both into one.

    I expect it!

    Link to Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0

    Think About Java-Joe!

    This is the discussion about if we need closures . What is the closures?

    Link to Think About Java-Joe!

    Technology Reading

    Developing applications with Facelets, JSF, and JSP

    XFire 1.2 Release Notes

    Davisor Publishor -- DOC to PDF and HTML with Java

    The Linux desktop: Browser and distro security tips

    Technology Reading

    Qt Jambi

    6 Tips for Sane User Interfaces

    JUnit V TestNG: Managing external dependencies