Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately
the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork
well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?
Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.
| Memory Analysis in Eclipse |
| Enterprise AJAX - Transcend the Hype |
Every modern commercial Web application employs a technology that lets the Web server assemble content dynamically upon the client's request. The reason is obvious: With business data changing so rapidly, simply not enough hands exist on Earth to manually update the content on the Web and corporate intranets. Thus, numerous servlets, CGI scripts, JSPs (JavaServer Pages), and ASPs (Active Server Pages) continuously process client requests to generate responses on the fly. This is called dynamic content publishing, a well-known concept with well-known pros and cons:
Pros:
At the same time, whenever possible, the same commercial Web applications serve static content. Documents like articles, photos, corporate reports, disclaimers, and so on represent static data, and therefore, don't need to be generated when the client requests them. This data exists in file form and is generally created only once. This is called static content publishing and has been around since the Internet's inception. Its strong and weak points contrast with those of dynamic content publishing:
Pros:
For some time, I pondered how to combine the strengths of these two approaches while avoiding their weaknesses. I wondered: Is there such a thing as semistatic or semidynamic content publishing? And then I discovered ...
My event-driven content publishing solution is simple, and I'll explain it with a familiar example.
Most developers are familiar with the idea of personal homepage-style Web applications that serve static content. Once a notable event occurs in the author's life, she simply opens her favorite Web-authoring tool, modifies or adds the content, and FTPs it to the Web server.
Please note that she actually modifies the content upon an event taking place. In between events, the content is static; hence, the term event-driven. Remove the weak human factor from the above example and you get a powerful publishing concept. Its core lies in the assumption that in between data modification (or state change) events, the data is static. Therefore, you can present the data in static Web content. Upon the data modification event, this static content automatically repopulates with new data and serves as such until the next event. In comparison, traditional dynamic content publishing appears request-driven.
Let's examine the event-driven content publishing concept:
Pros:
As wonderful as it looks, the approach is no silver bullet. Its applicability heavily depends on the ratio between the frequency of data modification events and the Web client's requests. For example, if the events occur more frequently than the client's requests, this approach creates even more overhead on the server than request-driven publishing. Imagine a rarely visited Webpage that displays current server time with millisecond precision. Use the event-driven approach to publish such a page and your server will die long before the first curious client can enjoy the fruits of your labor.