News aggregator

The author discusses how the use of generic programming in C++ can lead to conflicts with object-oriented design principles. He demonstrates how a technique known as type erasure can often be used to resolve these conflicts. An in-depth example is presented: any_iterator, a type-safe, heterogeneous C++ iterator.

C++ is a language for writing efficient high-performance programs, and bit manipulations are bread and butter of many such programs. This article presents a solution to the problem of constraining bit operations to allow only safe and legitimate ones, and turn all invalid bit manipulations into compile-time errors.

Have your cake and eat it, too, with STL extensions. In this chapter extract from his latest book, Matthew Wilson shows you how to take full advantage of the STL Iterator abstraction, without sacrificing block-transfer efficiency of Scatter/Gather I/O memory.

Object factories provide a useful abstraction for object construction. A special problem with object factories must be considered, however, when subscribing template classes with object factories. This article presents an overview of the "subscription problem" along with several solutions.

I'm using <s:convertEntity /> and when I submit the form I get an error message on the page Value is not a valid option — what am I doing wrong?

This commonly asked question on the Seam forum refuses to go away — so lets run through the problem, look at the workarounds and what changes would be needed to JSF to make it go away.

The Background

JSF allows you to specify a converter for any editable value; the converter converts from an Object to a String when rendering the page, and from a String to an Object when submitting a form. JSF comes with some built in converters (e.g. for Date, enums...) or allows you to create a custom converter.

Inside your custom converter you implement getAsString, returning a String, which, when passed to getAsObject on submitting the form, you use to get hold of the Object and return it.

Seam provides <s:convertEntity />, a generic converter which does the job of converting any JPA entity (mapped with annotations or XML, with a simple or composite key). It takes the primary key of the entity, stores it, returns a reference to the location in the key store; when the page is submitted, the key is fetched from the store and used to load the entity.

The Problem

The JSF 1.2 Specification (sections 4.1.15.3 and 4.1.16.3) specify that

...must provide a specialized validate() method which ensures that any decoded value is a valid option (from the nested UISelectItem and UISelectItems children).

In other words, the submitted item must be in the list displayed on the page. As the entity converter loads the selected object from the persistence context when the page is submitted, the submitted object is not in the displayed list.

The Workarounds

1. Display the list and submit the form inside the same long running conversation (so that the persistence context returns the same object both times). This makes caching the list of selectable items hard.
2. Overriding equals() on the entity (which isn't a a great idea).

The Solution

For JSF 2 this validation should be optional/overrideable (as it is everywhere else in JSF). In this case the converter is doing all necessary validation.

Pete Muir 2007-10-30T15:25:10Z

Find out what makes the JavaBeans Activation Framework a perfect vehicle for RESTful data transmission, then put JAF to work in a sample Web application that tracks requests and responses through a Java Servlet-based system.

Some say Apple's Leopard and Sun's Mustang were meant to run neck and neck -- but so far Java SE 6 is out of the race.

This post summarizes a complaint about JSF that I hear from time to time:

... traditional page design workflow isn't as straight-forward with JSF. With action-based web frameworks, it was rather easy for a HTML designer with some technical acumen to directly edit JSPs to implement a look and feel. Not so with JSF -- you're farther away from the final HTML. Its the components you include on the page that generate DIV tags and so forth. Having accrued 10+ years experience working with HTML, I find this the most frustrating aspect of JSF. We've been given a series of HTML Mockups from a design firm, and integrating has proved to be very challenging. I wonder if JSF merely shifts work efforts from HTML editing to Component customization.

Well, it may be frustrating at first, but on balance I would argue that it is a good thing that your web designer is not editing HTML directly.

The reason is that you should not be implementing look and feel by directly editing HTML. If you're doing that, then you're working around the whole architecture of HTML. What you should be doing instead is adding CSS selectors to your semantic HTML content, and applying your layout, look and feel using CSS. The architecturally correct separation of responsibilities is:

• Developers produce semantic content
• Designers produce stylesheets

Now, most JSF component libraries (and most Ajax libraries in general) kinda muddy the water here by providing widgets that look pretty out of the box, and can be skinned according to some built-in theme facility. Well, this is an important marketing feature for something like RichFaces - users have an expectation that widgets will look pretty without customization - but for serious development I think it tends to lead people down the wrong path. That's why one of my first feature requests for RichFaces was a plain theme that looks intentionally ugly, and is easy to style using CSS.

In my opinion, there is third, under-appreciated, attribute of the HTML architecture:

• Both content and style are expressed declaratively

And, in my view, this is essential for understandability of the code.

Let's consider good 'ol <h:dataTable>:

<h:dataTable value="#{products}" var="prod"> <h:column> <f:facet name="header">SKU</f:facet> #{prod.sku} </h:column> ... </h:dataTable>

This code fits the semantic content description perfectly. It's a highly declarative specification that:

1. there is a table, where each row is a product
2. with a column that has a header and some content in each cell

I can't really imagine a nicer way to express this. Consider the traditional JSP/JSTL type approach:

<table> <tr> <th>SKU</th> ... </tr> <c:forEach items="${products}" var="prod"> <tr> <td> <c:out value="${prod.sku}"/> </td> ... </tr> </c:forEach> </table>

This is a significantly more complex implementation:

• there are 5 levels of nesting, compared to 3
• it's difficult to correlate the column header name with the content, except by counting <th>s and <td>s

Even worse, it features an iterator, thus mixing two completely different language paradigms (declarative vs. procedural) in a totally unsatisfying way.

On the other hand, it doesn't hide the bare HTML tags from us. If we wanted to edit the JSP template to add presentational concerns, it's easy enough. Unfortunately, once we start adding presentation concerns to our HTML, the HTML code becomes much less reusable. What we should be doing instead is adding CSS selectors.

And, of course, all well-written JSF components make this super-easy:

<h:dataTable value="#{products}" var="prod" rowClasses="oddrow,evenrow" headerClass="header" syleClass="table products"> <h:column> <f:facet name="header">SKU</f:facet> #{prod.sku} </h:column> ... </h:dataTable>

Now our designer can concentrate upon developing declarative CSS stylesheets to target the selectors we have provided, and we will be free to make all kinds of changes to the semantic HTML without affecting the design (for example, we could use some fancy table control such as <rich:table> that provides lazy fetching of data from the server when the scrollbar is dragged, along with sortable, resizable columns and row selection. All without a line of JavaScript.

The declarative, semantic style of user interface development really starts to show its potential when we consider databinding. In a traditional UI library, tree views are a pain. We need to write messy Java code to adapt our application's model to something that the tree widget can comprehend. In RichFaces, we simply declare how the tree structure maps to the structure of our object model. No Java code required:

<rich:tree> <rich:recursiveTreeNodesAdaptor roots="#{root}" nodes="#{dir.children}" var="dir"> <rich:treeNode>#{dir.name}/</rich:treeNode> <rich:treeNodesAdaptor nodes="#{dir.files}" var="file"> <rich:treeNode>#{file.name}</rich:treeNode> </rich:treeNodesAdaptor> </rich:recursiveTreeNodesAdaptor> </rich:tree>

Now just try to do that in some other Web framework! :-)

Probably, you can now guess why I'm going against the grain by sticking up for JSF when some folks are jumping on bandwagons like GWT or Wicket. These technologies attempt to specify a naturally hierarchical artefact using sequential code. Personally, I just don't get that. I'm deeply interested in technologies like Hibernate, JPA, Seam, Web Beans, EJB3, jBPM which reformulate what used to be programmatic concerns in a declarative mode. That there should be a movement away from declarative programming in the one field where it is most natural (user interface) is counter-intuitive to me.

Actually, the pure-declarative nature of JSF templates is a pretty unique feature of JSF. Facelets is the first templating language I've ever seen that doesn't need iterators and conditionals. JSP, Velocity, FreeMarker, RHTML, etc, all encourage the mixing of logic and content. Facelets/JSF let you express dynamic content every bit as declaratively as HTML or DocBook express static content. (Jacob Hookom is one of the smartest guys in Java, in case you missed it.)

Gavin King 2007-10-27T20:39:18Z

The theme of Web Beans is:

• Loose coupling with strong typing!

Loose coupling comes in a variety of guises:

• deployment time polymorphism
• runtime polymorphism
• lifecyle independence
• decoupling of technical concerns
• decoupling of event producers from event consumers

Loose coupling makes a system more dynamic. The system can respond to change in a well-defined manner. In the past, frameworks that attempted to provide the facilities listed above invariably did it by sacrificing type safety. For example, many frameworks use XML deployment descriptors, or string-based identifiers to wire components together and define their lifecycle. Other frameworks use some kind of string-based expression language to bind interceptors to components (the most disgusting example of this is the use of regexes in AOP pointcut expressions).

Web Beans lets components interact in a loosley coupled way without ever resorting to XML or String-based identifiers. The only time component names are used is for binding Web Beans components to a non-typesafe language such as Unified EL.

1. deployment time polymorphism is provided via typesafe binding annotations and component types
2. runtime polymorphism is provided via typesafe binding annotations on producer methods
3. lifecycle independence is a feature of the contextual component model
4. technical concerns are decoupled by interceptors bound via typesafe interceptor binding annotations
5. event producers and event consumers are decoupled via a typesafe event object and event binding annotations

You don't see string-based identifiers in Web Beans code, not because the framwork is hiding them from you using clever defaulting rules (configuration by convention, as the Ruby folks say, or configuration by exception, as we used to say in the EJB3 expert group), but because there are simply no strings there to begin with!

This provides obvious benefits in that any IDE can provide autocompletion, validation and refactoring without the need for special tooling. But it also provides a the less-immediately-obvious benefit. It turns out that when you start thinking of identifying components, events or interceptors via annotations instead of names, you have an opportunity to lift the semantic level of your code.

Web Beans encourages you develop reusable annotations that model concepts, for example,

• @Asynchronous,
• @Mock,
• @Secure,
• @Action or
• @Updated,

instead of non-reusable compound names like

• asyncPaymentProcessor,
• mockPaymentProcessor,
• SecurityInterceptor,
• LoginAction or
• DocumentUpdatedEvent.

When I look at Java code today, and I see these kind of compound names, it reminds me of old-fashioned naming conventions for variables in dynamic languages, which embed the type of the variable in the variable name, for example str_username. These naming conventions were a clear workaround for the fact that the language had no primitives for expressing typing information.

Compare the following observer methods:

void onDocumentUpdate(@Observes DocumentUpdatedEvent event) { ... } void onDocumentUpdate(@Observes @Updated Document doc) { ... }

Both are correct, but the second approach is more Web-Beansy. The @Updated binding annotation models a reusable notion. We can use it for other events:

void onDocumentUpdate(@Observes @Updated Order order) { ... }

And notice how much more literate this code is.

Or compare the following implementations of Login:

public @SessionScoped @Component @Interceptors(SecurityInterceptor.class) class Login { ... } public @SessionScoped @Secure @Component class Login { ... }

The second form is more Web-Beansy - the code is more decoupled and more literate.

The nirvana of this kind of literate programming is a new feature of Web Beans called stereotypes. A stereotype lets you encapsulate scope, interceptor bindings, component type, etc, into a single package that models a role in the application architecture. For example, instead of defining:

public @RequestScoped @Named @Secure @Transactional @Component class LoginAction extends BaseAction { ... }

We could create a stereotype:

@RequestScoped @Named @Secure @Transactional @Component @Stereotype(requiredTypes=BaseAction.class) @Target(TYPE) @Retention(RUNTIME) public @interface Action {}

And reuse it for all our actions:

public @Action class LoginAction extends BaseAction { ... } public @Action class UpdateDocumentAction extends BaseAction { ... }

Another example is a stereotype for singletons. Of course, we could write:

public @ApplicationScoped @Component class ReferenceData { ... } public @ApplicationScoped @Mock class DummyReferenceData extends ReferenceData { ... }

But I would prefer:

@ApplicationScoped @Component @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Singleton {} public @Singleton class ReferenceData { ... } public @Mock @Singleton class DummyReferenceData extends ReferenceData { ... }

Well, this stereotype did not save much typing. But on the other hand, it tells us more about the ReferenceData class. The code is more literate and understandable. Even better, it's much easier for me to find all singletons in my code, or to add an interceptor to singletons. It also makes it easier to ensure that certain patterns are followed consistently in a large project.

Gavin King 2007-10-26T18:21:45Z

I'm happy to announce that we've just released Seam 2.0.0.CR3. (download it) As you can see from the release notes, we've been rather busy the last few weeks. Most of the changes since CR2 are documentation and test related, but we've also been busy fixing bugs, upgrading dependencies and making sure that JBossTools and Seam 2.0 work together.

We expect the GA release to come in the next few days, so stay tuned!

Norman Richards 2007-10-25T16:25:47Z

Mark Newton presents JBoss application server 5.0 What's New at the JUG Switzerland.

History of JBoss AS

119 days average release cycle, 9 releases of JBoss 3.2.x, J2EE 1.3 certification, JDK 1.3.

126 days average release cycle, 6 releases of JBoss 4.0.x, J2EE 1.4 certification, JDK 1.4.

55 days average release cycle, 3 releases of JBoss 4.2.x, JEE 5.0 compatible implementation, not certification, does 95% of it and requires JDK 5.0.

For JBoss AS 5.0.x new standalone implementations:

• JBoss Messaging (replaces old JBoss MQ)
• JBoss Security
• JBoss Federated SSO

New kernel is JBoss Microcontainer 2.0 and a profile service which is responsible for managing the POJOs that now bind the services together. Aiming for a Q1 2008 final release date and a CR in 2007.

JBoss Messaging 1.4

The new JMS 1.1 compatible messaging implementation supports distributed queues and topics as well as transparent failover and load distribution - internally it uses JGroups as transport.

Clustering

New major revision of JBoss Cache (2.1) with a much simpler API and a greater emphasis on usage outside of JBoss AS.

JBoss AOP 2.0

Integrated with the microcontainer: If you add behavior to a POJO using AOP, and you deploy it, you get dependency management - you can't call a POJO without the aspect, it won't be deployed before the aspect is available. And vice versa, aspects are not deployed if the POJOs they depend on are not deployed so far. Aspects can be bound to POJO lifecycle, e.g an aspect that binds a proxy into JNDI when the POJO enters the deployed state. It also has some new plain AOP features: Before, Afer, Throwing, Finally flows for interception.

What does the kernel do?

A microkernel needs to support dynamic loading and unloading of services. For that we need:

• a way to deploy new services
• a bus so that the client does not communicate with a service directly, clients are decoupled from services

How was this done in JBoss 3.x and 4.x? We used an MBeanServer to provide the bus and deployers that load services into the kernel together with a simple dependency injection mechanism. MBeans were used to implement services and configured with XML descriptors which injected attribute values into the MBeans at deployment. XMBean are special MBeans that allow you to add method interception to an MBean. Calls pass through the bus and interceptors with a level of indirection through a generic invoke(method, arguments, argumentTypes) operation.

For performance reasons the bus wasn't actually used much: A reference to a services would be looked up directly in the registry. So the interceptors were not used.

What was bad about the JBoss JMX microkernel:

• JMX is restrictive, lifecycle and classloading were a problem
• You can't run JMX on Java ME
• You actually need to know how to implement MBeans
• If you access services directly through a reference, interceptors are not applied

Design objectives for JBoss AS 5.x

Services should be POJOs and behavior should be added through AOP - effectively reproducing all the features of the JMX microkernel. Much improved dependency injection and classloading. Layered and easily extensible design (no references to JBoss classes), should be usable without JBoss AS.

The new name for this kernel is Microcontainer.

The core of the microcontainer is Container, Kernel, Dependency. Behavior is added with JBoss AOP.

Kernel: Provides the bus and registry, and an event manager.

Container: Wrapper for POJOs, AOP jointpoints and reflection on the actual service implementation POJO.

Dependency: Basically an abstract state machine that manages service dependencies.

Some optional packages on top of the core: OSGI integration, Guice integration.

Creating a service

Define the POJO with <bean> and <property> declarations in jboss-beans.xml (replaces the old jboss-service.xml). Beans have a name and a class, properties support injection with references to (other) bean names.

Add behavior using the <aop:aspect> namespace and elements and pointcut expressions. You can also extract the aspect/pointcut to a separate file.

Profile service

Management system for POJOs instead of the old JMX based administration which was based on editing XML files. People would manage configurations by keeping these files in CVS. The web console only supported changing the runtime values in memory, didn't write back into the files.

What we want:

• Centralized maintenance as profiles, e.g. all, minimal, default, ...
• Persistence of changes made to a profile across server restarts
• Propagation of profile changes across a cluster
• Versioning of profiles

Implementation similar to JDK 6 Open MBeans specification: A deployment has a collection of ManagedObjects, you define them with annotations in your service, e.g. @ManagedOperation(description="A setting you can change")

Summary

• JBoss AS 5.0 has a completely new architecture based on the microcontainer with POJOs and AOP

• Management improved with the addition of profile service

• Clustering and security is much enhanced

• It will be fully Java EE 5.0 compliant

Christian Bauer 2007-10-25T15:41:22Z

The JCP folks seem to have resolved their technical problems, and the Web Beans EDR is now available at jcp.org. We've had some great feedback on the comments alias already. Please keep it coming!

Gavin King 2007-10-23T21:00:58Z

Peter Hilton and Nicolas Leroux will present their experience of implementing an application using Seam, and Bruno Georges will talk about Open Source SOA.

Second JBoss Benelux User Group Meeting

The programme will begin with a presentation on Open Source SOA by Bruno Georges, Technical Development Manager, Enterprise Frameworks at JBoss. This will include an ESB Presentation and a demo based on jBPM for process flow orchestration.

In the second presentation, Peter Hilton and Nicolas Leroux, will describe Lunatech's practical experience with JBoss Seam. We will talk about strengths and limitations of JBoss Seam 1.2.1.

• Date: Friday, 2nd November 2007
• Time: Arrive 1700-1800, presentations start 1800, finish 2000-2100.
• Location: Lunatech Research, Heemraadssingel 70, 3021 DD Rotterdam, The Netherlands (http://www.lunatech-research.com/contact/)
• Please reply by e-mail to nicolas(AT)lunatech.com

Pete Muir 2007-10-23T10:56:23Z

One of the most common forum questions is How do I make Seam call an action method at startup?.

The easiest way is to observe the org.jboss.seam.postInitialize event (which occurs right after Seam finishes initializing):

@Name("observeInitialization") public class ObserveInitialization { @In EntityManager entityManager; @Observer("org.jboss.seam.postInitialize") public void observe() { // Do your initialization here } }

However, as this event occurs before JSF finishes initializing, if you want to use Seam Mail at startup, you should schedule it to happen a short time after initialization:

@Name("asynchronousMailProcessor") public class AsynchronousMailProcessor { @Asynchronous public void sendMail(@Duration long duration) { Renderer.instance().render("/mail.xhtml"); } } @Name("observeInitialization") public class ObserveInitialization { @In AsynchronousMailProcessor asynchronousMailProcessor; @Observer("org.jboss.seam.postInitialize") public void observe() { // Schedule a send for 30s time, by which time JSF will be initialized asynchronousMailProcessor.send(30 * 1000l); } } Pete Muir 2007-10-23T10:33:03Z

The Only Load Balancer In The World That ...

Advertisement

Is Designed For ultra-low power consumption, L4-7 functionality, H/W SSL Accel, HA option, $2,490

Get a primer on the Data Transfer Object design pattern and learn how using XML-based DTOs with a simple tool can speed up the development of Java mobile client-server applications.

Ales Justin and Mark Newton are going to present the new JBoss application server core and kernel on Thursday this week, at a meeting of the JBoss special interest group. See you there.

Christian Bauer 2007-10-22T15:09:47Z

Last nights build of JBoss Tools now has Seam 2 support in its project creation wizards and the artifact wizards (New Seam Action, Form, etc.)

The generated test project still needs some work, but it is showing a green light when you run it and we still need to work on enabling our validator and parts of the Seam component view to properly pick up Seam 2 components. Until that is fixed there will be more noise in the list of validations.

But it is otherwise fully functional and usable and I must say with (almost) omnipresent EL navigation and code completion, the improved visual JSF editor and all the hotdeployment you could wish for, doing Seam development in Eclipse is becoming a breeze.

Max Andersen 2007-10-22T07:44:50Z

Vendors step up to address the technology triangle of governance, quality, and management essential to SOA.

The first [Attachment] is now available! Please send comments to jsr-299-comments(AT)jcp.org. We really do pay attention to community feedback, so if you take the time, it won't be wasted!

(The JCP site is currently experiencing technical difficulties, so we're making the spec available for download here, temporarily.)

I would like to give a huge thanks to everyone on the expert group who helped get us this far. I know it's inelegant to single out individuals, but since it is rare to see people (especially individual JCP members) recognized for their contributions to spec groups, I'm going to do it anyway. Extra special thanks to:

• Bob Lee
• Linda DeMichiel
• Jacob Hookom
• Adam Winer
• Michael Youngstrom
• Richard Kennard
• Conny Lundgren
• Roger Kitain
• Chris Maki

Let us know what you think!

Gavin King 2007-10-19T04:41:14Z