REVERT TO CONSOLE » Priyatam

Understanding OpenJPA InvalidStateException: Detected reentrant flush

Priyatam — Wed, 01 Jun 2011 18:37:22 +0000

Ran into this issue today:

 org.apache.openjpa.persistence.InvalidStateException: Detected reentrant flush.  Make sure your flush-time instance callback methods or event listeners do not invoke any operations that require the in-progress flush to complete.
	at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1923)
	at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1698)
	at org.apache.openjpa.kernel.QueryImpl.isInMemory(QueryImpl.java:956)
	at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:838)
	at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:779)
	at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)

This is a tricky exception since the verbose description does not clarify the intent.

The problem:
I had to write my own Auditing since we weren’t using Hibernate (and so no Envers) but openjpa 1.2.2. Don’t ask me why. It’s a big financial company and they like Websphere 7 (which “ships” openjpa 1.2).

A sample “Profile” entity

@Entity
@EntityListeners({ProfileAuditListener.class})
public class Profile implements Serializable {
 ...
}

The standard JPA Entity Listener:

@Named
public class ProfileAuditListener implements ApplicationContextAware {
        private ProfileAuditDao auditDao;

	@PostUpdate
	@Transactional
	public void postUpdate(Profile newProfile) {
	    ProfileAudit audit = new ProfileAudit();
	    ...
    	    ...
   	    Profile oldProfile = profileDao.read(newProfile.getEmail());
            // InvalidStateException thrown above
            ...
            // Compare field by field for editable fields
	    ...	

	    auditDao.audit(audit);
	}
}

A simple Dao

@Repository("profileDao")
public class JPAProfileDao implements ProfileDao {

	@Transactional(readOnly = true)
	public Profile read(String email) {
		List profiles = em.createNamedQuery("findByEmail").setParameter("email", email);
		if (profiles.size() != 0) {
			return profiles.get(0);
		}
		return null;
	}
}

As you can see, nothing fancy here. An Audit interceptor trying to see the difference in ‘Profile’ properties just after updated the entity in db. However an exception is thrown where I execute a read-only Transactional query.

Explanation:
The exception indicates that the event listener might be executing a flush accidentally from another operation and OpenJPA doesnt allow a flush to occur during a flush. Wait, a flush? But I’m not flushing anywhere, in fact — I think it’s all default flushing.

That’s the catch. The default querying in openjpa is FlushModeType.AUTO and that causes a flush to occur even if it’s a @Transactional(readOnly=true)

Solution:
set the flush mode to FlushModeType.COMMIT on that particular query.

You can also set a system wide property like setting false flushBeforeQueries = true in persistence.xml but I wouldn’t recommend that unless you want this behavior explicitly. For instance, my unit tests needed the auto flush to work since I persist and read in the same transaction (Spring Transactional tests).

In general, your use case might be different from mine but the underlying concept is same. Look for the accidental flushes from openjpa. If in doubt, always tune up the DEBUG logging.

Mock Unit Testing Services and Daos with Mockito and Spring 3

Priyatam — Mon, 09 May 2011 14:46:02 +0000

If you haven’t been mocking yet, check this out. There are other tools in Groovy using DSLs but if you want to stick to Java, Mockito is by far the best BDD-style mock unit testing tool.

Traditional examples provide a List mocking example or foo/bar example which I find it mostly annoying since it doesn’t teach you how to solve real problems. And the documentation is verbose and crams with unnecessary features confusing us further. In this tutorial, I’ll dive straight into a relevant example of mock testing Daos in Service layer. I’m not a big fan of Daos anymore (after the advent of JPA), however for the purposes of this tutorial, it’ll be easier to explain.

Consider a Profile entity (like facebook user profile) with daos/services: ProfileDao/JPAProfileDao, ProfileService/ProfileServiceImpl. To complicate things further, say you are using DTOs since it’s a client server app with a GWT front end. You might need a simple mapper class. Let’s call it ProfileMapper/ProfileMapperImpl.

@Service("profileService")
public class ProfileServiceImpl implements ProfileService {
	private final ProfileDao profileDao;
	private final ProfileMapper profileMapper;

	@Inject
	public ProfileServiceImpl(final ProfileDao profileDao, final ProfileMapper profileMapper) {
		this.profileDao = profileDao;
		this.profileMapper = profileMapper;
	}

	@Transactional
	public void create(ProfileDto profile) throws DuplicateProfileException {
		if (profile == null) {
			throw new IllegalArgumentException("profile cannot be null.");
		}

		Profile profile = profileMapper.toEntity(profile);
		// set default state as active
		profile .setIsActive(true);

		try {
			profileDao.save(profile);
		}
		catch (DuplicateKeyException e) {
			logger.warn("Unable to save profile with userId: " + profile.getUserId() + " already exists.");
			throw new DuplicateProfileException();
		}
		logger.debug("Profile saved successfully.");
	}

	@Transactional(readOnly = true)
	public ProfileDto read(String userId) throws InvalidProfileException {
		validateProfileInfo(userId);

		ProfileDto profileDto = null;
		Profile profile = profileDao.read(userId);
		if (profile != null) {
			profileDto = profileMapper.fromEntity(profile);
			logger.debug("Profile retrieved successfully.");
		}
		else {
			logger.debug("...");
		}
		return profileDto;
	}

	...
}

Now, in order to test ProfileService, you need to mock out ProfileMapper and ProfileDao, right? Let’s see how we do this in a simple JUnit 4.4+ test.

import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class ProfileServiceTest {

	@Mock
	ProfileDao profileDao;

	@Mock
	ProfileMapper profileMapper;

	// Can't use @InjectMocks because Mockito doesn't support constructor injection
	// As a workaround use @Before below to initialize service with stubs
	ProfileService profileService;

	@Before
	public void init() {
		profileService = new ProfileServiceImpl(profileDao, profileMapper);
	}

	@Test
	public void testRead() throws InvalidProfileException {
		// Simulate InvalidProfileException
		try {
			profileService.read("");
			fail(); // should never execute
		}
		catch (InvalidProfileException e) {
			e.getMessage(); // expected
		}

		// Given
		Profile profile = TestData.createTestProfile("userid"); // test utility to create a test Profile
		when(profileDao.read("userid")).thenReturn(profile);
		when(profileMapper.fromEntity(profile )).thenReturn(TestData.createTestProfileDto("userid"));

		// When
		ProfileDto dto = profileService.read("userid");

		// Then
		assertEquals(dto.getUserId(), "userid");
	}
}

Explanation:
1) Wrapping your test with @RunWith(MockitoJUnitRunner.class) helps create the mock initialization through annotation scanning (@Mock, @InjectMocks)
2) Add @Mock annotations for the components to mock. In this case profileDao, profileMapper
3) As of 1.8.5, Mockito doesn’t provide @InjectMock with construction injection. @Before test initializer is a workaround to inject ProfileService with mocks. Note that this will not be required if ProfileService has setter/getter injection of dependencies. However, I prefer JSR330 construction injection which is a best practice .
4) The actual @Test class with mockito stubs. Let’s dig deep into this.

As a template, it’s a good practice to view tests like a BDD style test.

// Given 

// When

// Then

The above template forces you to think on the explicit conditions during which we run our unit test.

Next, we need to figure out a way to stub our mock component’s methods,

when(operation).thenReturn(object)

In our example we want to mock profileDao.read(userId). So that translates to

when(profileDao.read("userid")).thenReturn(profile);

Note that we’re letting the mocked dao return a profile object that we just created in the previous step. This will be 50% of most of your mocking use cases.

The next common used use case is to simulate exceptions from the mocked classes. Consider a test for create(…) that simulates the DuplicateProfileException.

@Test
	public void testCreateDuplicate() {
		// Given
		ProfileDto dto = TestData.createTestProfileDto("userid");
		Profile profile = TestData.createTestProfile("userid");
		when(profileMapper.toEntity(dto)).thenReturn(profile);
		doThrow(new DuplicateKeyException("duplicate profile")).when(profileDao).save(profile);

		// When
		try {
			profileService.create(dto);
			assertEquals(1, 2); // should never execute
		}
		// Then
		catch (DuplicateProfileException e) {
			e.getMessage();
		}
	}

Notice the line

doThrow(new DuplicateKeyException("duplicate profile")).when(profileDao).save(profile);

Quite simple, isn’t it?

If you’ve read so far, you can succuessfully write mock unit tests for 80% of your use cases. There are other advanced features like finding redundant invocations, spying on objects to simulate partial mocking, most of which I don’t see implementing for majority of my use cases.

Database Surrogate keys Vs Natural keys

Priyatam — Tue, 12 Apr 2011 18:06:07 +0000

Ran into this issue at my client recently and it was hard to convince the db admin why surrogate keys was an advantage for a developer working in an ORM solution

Natural key
- business requirements changes, then you have to change the natural key
- not easy to index an alphanumeric or String value
- can’t expose the natural key to end users who can then guess the business key and use for querying undesireable data
- you can’t rename the type without changing everything
- If using strings, joins are a bit slower as compared to the int data-type joins, storage is more as well. Since storage is more, less data-values get stored per index page. Also, reading strings is a two step process in some RDBMS: one to get the actual length of the string and second to actually perform the read operation to get the value.
- Locking contentions can arise if using application driven generation mechanism for the key.
- Can’t enter a record until value is known since the value has some meaning.

Surrogate key
- A surrogate key is immune to changes in business. In addition, the key depends on only one field, so it’s compact. The auto-incrementing field provides a unique, stable, and compact primary key.
- Business Logic is not in the keys.
- Small 4-byte key (the surrogate key will most likely be an integer and SQL Server for example requires only 4 bytes to store it, if a bigint, then 8 bytes).
- Joins are very fast.
- No locking contentions because of unique constraint (this refers to the waits that get developed when two sessions are trying to insert the same unique business key) as the surrogates get generated by the DB and are cached. Very scalable.

Not to mention, for surrogate keys, a Java developer could assume and code several reusable strategies:
- Have a common BaseIdEntity with an @Id attribute with a common generation strategy or named sequence generators
- Have Base generic services or daos (FooServiceImpl extends BaseServiceImpl)
- Generic finder methods with named queries
- And many other referential lookups that can be streamlined once a common id is used

References:
The great primary key debate

Understanding Spring Transaction Management

Priyatam — Sun, 06 Mar 2011 16:17:24 +0000

This is a little wiki file I had for a long time while understanding how spring transactions worked. Time to put it in a blog. (Note: data is unprocessed)

- Two types of transactions: Global and Local Transactions
- PlatformTransactionManager is main interface in Spring
- PROPAGATION_REQUIRED, PROPAGATION_SUPPORTS, PROPAGATION_MANDATORY, PROPAGATION_REQUIRES_NEW, PROPAGATION_NOT_SUPPORTED, PROPAGATION_NEVER, PROPAGATION_NESTED
- ISOLATION_DEFAULT, ISOLATION_READ_UNCOMMITTED, ISOLATION_READ_COMMITTED, ISOLATION_REPEATABLE_READ, ISOLATION_SERIALIZABLE
- Spring’s Declarative Transaction management. Can customize transactional behavior using AOP. Like custom behavior in case
of transaction rollback declaritvely.
- How @Transactional works. The combination of AOP with transactional metadata yields an AOP proxy that uses a TransactionInterceptor in conjunction with an appropriate PlatformTransactionManager implementation to drive transactions around method invocations

- Steps when a method is invoked with @Transactional
— Spring AOP kicks in, create proxy of the target. If nothing is configured JDDK dynamic proxy is created, but if aspectj is configured,
aspectJ proxy is created
— TransactionInterceptor kicks in the configured TransactionAdvice
— TransactionAdvice calls the underlying PlatformTransactionManager to acquire a new db connection
— Datasource is kicked in. If a connection pool is present, a conection is returned from the pool
— Method is invoked
— If no exceptions, great
— If exceptions are returned, apply rules to determine whether transaction should be rolled back. If yes, TransactionInterceptor will roll back
transaction
— Based on exceptions, PlatformTransactionManager either commits or rollsback transaction
— Release connection JDBC after transaction
— Return conenction to pool
— Return the method call

- Annotate @Transactional on classes and not interfaces because Java annotations are not inherited from interfaces means that if you are using class-based proxies or the weaving-based aspect then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy.

- When using proxies, you should apply the @Transactional annotation only to methods with public visibility.

- Spring AOP uses either JDK dynamic proxies or CGLIB to create the proxy for a given target object. If the target object to be proxied implements at least one interface then a JDK dynamic proxy will be used. If the target object does not implement any interfaces then a CGLIB proxy will be created.

- Using ‘proxy-target-class=”true”‘ on , or elements will force the use of CGLIB proxies for all three of them.

- multiple transaction managers can be used and referred as @Transactional (“account”)

...

- Programmatic transaction can be done by TransactionTemplate (callBack approach) or PlatformTransactionManager directly

JPA
—

References:
Spring Transaction Propogation
Stack Overflow “transactions”
Transactional Pitfalls

Maven settings.xml for corporate proxy with custom user-Agent

Priyatam — Sun, 27 Feb 2011 20:06:05 +0000

In some corporate enviroments, it’s just not enough to add a simple proxy setting in maven settings.xml. For instance, some prozy servers reject any HTTP request that’s coming from a non IE browser. Foruntately, Maven has a way to fake a user-agent and this might be a way to circumvent your corporate server settings Of course, make sure you ask your IT if that’s ok! More often it’s easy for them to approve rather than ask them to change their proxy policies for Maven (Maven, what is that?)

Here’s an example settings.xml file along with standard reposities from JBoss, Spring, Codehause, Ibiblio. I have set it to a proxy named myproxy.com along with a Firefox user-agent. Note that you need to a config for each repo that you need to configure for a custom user-agent proxy.



	
	
	
	
	
		
			ibiblio
			
				true
				6000
				
					
						User-Agent
						
							Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
						
					
				
			
		
		
			spring-repo
			
				true
				6000
				
					
						User-Agent
						
							Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
						
					
				
			
		
		
			jboss-repo
			
				true
				6000
				
					
						User-Agent
						
							Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
						
					
				
			
		
		
			atlassian-repo
			
				true
				6000
				
					
						User-Agent
						
							Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
						
					
				
			
		
		
			codehaus-repo
			
				true
				6000
				
					
						User-Agent
						
							Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
						
					
				
			
		
	
	
		
			ibiblio
			http://mirrors.ibiblio.org/pub/mirrors/maven2/
			external:*
		
		
			spring-repo
			http://ebr.springsource.com/repository/
			external:*
		
		
			jboss-repo
			http://repository.jboss.org/maven2/
			external:*
		
		
			atlassian-repo
			https://maven.atlassian.com/repository/public/
			external:*
		
		
			codehaus-repo
			http://repository.codehaus.org/
			external:*
		
	

	
		
			true
			http
			yourproxy.com
			8080
			
			
			
		
		
			true
			https
			yourproxy.com
			8080

Understanding Events in JEE6 with examples

Priyatam — Mon, 07 Feb 2011 19:00:57 +0000

JEE 6 implements Event Delagation model and Observer (Publish-Subscribe) pattern out of the box much more elegantly than other api.

A Publisher fires events along with a type that needs to be passed. An Observer (can have multiple observers) simply observes for the Event “type” and receives the object sent by the publisher along with any other injectable objects. Note that there is no restriction on what objects needs to be sent when the event is fired. As long as the publisher and subscriber are sending and receiving same object types, the event is handled.

Note that since the event handler executes in a separate thread, it cannot alter the original event generator and an exception thrown here will not affect the event generator. For such cases of fine grain control of business execution, use a Decorator.

Event Qualifier (annotation definition)

import javax.inject.Qualifier;
import java.lang.annotation.*;
import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, PARAMETER, FIELD})
public @interface RegistrationEvent {
}

Event Listener

import javax.enterprise.event.Observes;
import javax.inject.Inject;
import org.jboss.logging.Logger;

public class RegisteredEventListener {
    @Inject
    private Logger log;

    public void onRegistration(@Observes @RegistrationEvent User user) {
    	log.info("Registration Event received for user: " + user);
    }
}

Event Firing (Actual Service where event is fired)


import javax.enterprise.event.Event;
import javax.inject.Inject;

@Stateless
public class UserRegistrationImpl
	implements UserRegistration, Serializable {

	@Inject
	@RegistrationEvent
	private Event< User> event; // Note: this event fires "User" objects

	public String register() {
		em.persist( member );
		event.fire( member ); // Fires the event
		return "users
	}
}

Understanding JSR299, Contexts and Dependency Injection explained

Priyatam — Sat, 05 Feb 2011 17:34:07 +0000

Forget Session, Application, Request, and Coversation Scope. All these scopes, though useful, still have to be managed by hand. ie.,
– a reference must be created in a session or request (the context)
– a utility method must be written to manage this context (& cleanup eventually)
– the component needs to have access to this utlity method or the context (session, request) to retrive the reference

Most importantly, the “client” component and original “context holder” have direct coupling of the refereced object. With JSR299, it’s like this:

a reference to any object can be injected into any object without actually referring to the object

Really? That’s crazy.

Exactly.

JSR299 container manages thereferences for you in a context (session, requestm, conversation, etc.,) and provides a type-safe way of retrieving these references by a quaifier annotation. For ex, let’s say a PersonSearch Service needs to know the currently logged in user. Normally, you would use a utility function that will return the user. In Spring that would be SecurityContextHolder.getContext().getAuthentication().getPrincipal(). In Seam, it would be something simpler. But what if you don’t want to deal with a service that takes no method parameters and all that you want is a typed object in return?

Think. No parameters.

Would it be easier if you had somethinkg like this?

@LoggedIn
Principal principal;

in your service bean?

By injecting this annotated field, any component in the application can get the “reference to loggedIn user object.” The container holds this reference for any component that asks for it, and it holds it in the scope that the original reference was created. In this case, maye an Authenticator bean created it to keep it in SessionScope. In other words, any “managed” bean (ie., managed by the container, so Stateless, SessionScoped, ApplicatinScoped, etc.,) can get the reference to the logged in user by simply injecting a User object with a qualifier @LoggedInUser. Forget about static methods and manual context management!

But how do you create a @LoggedIn user? Simple, actually.

@Produces @LoggedIn @Named
public User getCurrentUser() {
    return currentUser;
}

In this case, a sessionScoped Authenticator component has a method that returns an instance variable, currentUser.

The advantage of this is loose coupling and at the same time, strong typing. Further, by providing multiple qualifier like @Produces and overriding scopes, the injectable object can be custom defined both at the injectable context and the point of creation (Producer).

Another fine example. Let’s say in the above person search, you want to return the list of persons and tie it to the request scope so that any other component in the same underlying request cycle can retrieve it (JSF page).

@Produces @Named @RequestScoped
public List& getPersons() {
    return em.createQuery( "select p from Person p" ).getResultList();
}

Even better, you’d like to have a static lookup across the session.

@Produces @Named @SessionScoped public List getPersons() {
    return em.createQuery( "select p from Person p" ).getResultList();
}

But how do you then update the search list in the session if a new person was added in the same session? Welcome to JEE 6 build in Event Model.

public void onPersonListChanged(
    @Observes( notifyObserver = Reception.IF_EXISTS )
     final Person person ) {
	getPersons();
}

See here to understand what @Reception means.

Understanding the uses of JEE6 @Decorator vs @Interceptor with an example

Priyatam — Tue, 01 Feb 2011 18:30:44 +0000

Let’s look at an Interceptor first.

Interceptor definition: AuditTime — wraps a simple debug around a method invocation with time stamps.

import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.*;
import java.lang.annotation.*;
import javax.interceptor.*;

@Inherited
@InterceptorBinding
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface AuditTime {
}

Interceptor implementation.

import javax.inject.*;
import javax.interceptor.*;
import org.jboss.logging.*;

@AuditTime
@Interceptor
public class AuditTimeInterceptor implements Serializable {

	private static final long serialVersionUID = 8205679619877467367L;

	@Inject
	Logger log;

	@AroundInvoke
	public Object computeTimestamp(InvocationContext ctx ) throws Exception {

		log.trace( String.format(
			"Starting %s.%s",
			ctx.getMethod().getDeclaringClass().getSimpleName(),
			ctx.getMethod().getName() ) );

		long start = System.currentTimeMillis();

		Object object = ctx.proceed();

		long stop = System.currentTimeMillis();

		log.trace( String.format(
			"Invocation time for %s.%s is %s",
			ctx.getMethod().getDeclaringClass().getSimpleName(),
			ctx.getMethod().getName(),
			String.valueOf( stop - start ) ) );

		return object;
	}
}

Example Usage.

@AuditTime
public void foo(String bar) {
 // do something
}

The above is pretty straight forward. Adding an @AuditTime to any method will provide timestamps. An interceptor as you know adds cross-cutting concerns across methods, across code infratructure, maybe design. But it may not directly influence business decision.

A Decorator on the other hand, is a fine grained interceptor if you want to put it that way. Lets jump straight into an example.

An example User Registration Service

public interface UserRegistrationService {
	String register();
	String update();
	Member getUser();
	public String selectUser(String id );
}

Now, let’s say we want to filter all registrations that has a user email ending with “.ru.”

import javax.decorator.*;
import javax.inject.Inject;
import javax.persistence.*;
import org.jboss.logging.Logger;

import xxx.Service.UserRegistrationService;

@Decorator
public abstract class RegistrationEmailDecorator implements UserRegistration, Serializable {

	private static final long serialVersionUID = 7780160635139112007L;

	@Inject
	private Logger log;

	@PersistenceContext
	EntityManager em;

        // Note: A Decorator is exactly like the decorator pattern. It "is" and "has a" UserRegistration. In JEE6, the "has a" relationship, ie., composition, is explicitly qualified as @Delegate
	@Inject
	@Delegate
	UserRegistrationService service;

	public String register() {
		User u = service.getUser();

		if ( u.getEmail().endsWith( ".ru" ) ) {
			log.info( "Someone with russian domain has registered. Probably a spam, not registering." );

			// do not proceed original call
			return "users";
		}
                          // else, proceed the call.
		return service.register();
	}
}

This is obviously a dumb example but you get the picture. A decorator is different from an interceptor because an interceptor just intercepts any method call (before/after) but doesn’t know the behaviour inside the call. Since a Decorator (Decorator Pattern) implements the decorating class interface and composes it, it can modify the behavior based on business rules.

Thus, decorators provide business rule concerns (sort of “fine grained” interceptors) whereas an interceptor provides system wide, cross-cutting concerns (not related to business). Using both smartly in your JEE6 project can improve readability, and code maintenance.

Of course, don’t go crazy with Decortors or Interceptors making the actual Service calls useless . Nothing should override the most important design concern — OO.

Ivy file for a JEE6 / Seam 3-beta / Primefaces project

Priyatam — Fri, 28 Jan 2011 20:23:25 +0000

Most examples online use Maven for build files. I’m sure some of you are still on ant or Ivy. Here’s an ivy file for a starter JEE6 project with Seam-3-beta (at this time of writing), Primefaces, Prettyfaces and other misc jars (testng) that you might need.

And the ivy resolvers in settings file would be something like this:

Example of RESTful Webservices in JEE6 with Exception mapper to route HTTP status codes

Priyatam — Tue, 25 Jan 2011 18:12:12 +0000

JEE6 provides a specification for Webservices (SOAP AND REST) and JAX-RS is the default Reference implementation. A lot of cookie-cutter code is eliminated for implementing webservices. Unlike Restlet which doesn’t provide much functionality for integrating restful webservices into a web application (exception mapping and custom annotations to process http params, or DI), JEE6 webservices combine the power of JSR299 along with several utlity methods. For example, an exception mapping provider maps an exception to a Response. If this exception is thrown, the JAX-RS implementation will catch it and invoke the corresponding exception mapping provider. An exception mapping provider is an implementation of ExceptionMapper, annotated with @Provider.

In this example code, let’s walk through a simple usecase where we need to retrieve a list of users via GET using the path: /users/{email}

First, you need to add a JAXRs Activator class. A class extending {@link Application} and annotated with @ApplicationPath is the Java EE 6 “no XML” approach to activating JAX RS.

@ApplicationPath( "/rest" )
public class JaxRsActivator
	extends Application {
	/* class body intentionally left blank */
}

Then, add a RESTful Service class with the correct Path

@Path( "/users" )
@Produces( { "application/xml", "application/json" } )
@RequestScoped
public class UserRESTService {

	@PersistenceContext
	private EntityManager em;

	@Context
	private UriInfo uriInfo;

	@GET
	public List< User> listAllUser() {
	    return em.createNamedQuery( "UserfindAll", User.class ).getResultList();
	}

	@GET
	@Path( "/{email}" )
	public UserlookupUserByEmail(@PathParam( "email" ) String email ) {
		// Note that if NoResultException is thrown by below, NoResultMapper automactically translates to a 404
		Member member = null;
		return em.createNamedQuery( "User.findByEmail", User.class ).setParameter( "email", email ).getSingleResult();			}
}

Finally, write an Exception Translator(s)

@Provider
public class NoResultMapper implements ExceptionMapper< NoResultException > {
    public Response toResponse( NoResultException ex ) {
	return Response.status( 404 ).entity( ex.getMessage() ).type( MediaType.TEXT_PLAIN ).build();
    }
}

As you can see, there are no xml configurations. No surprises. It just works in any standard JEE6 container. Note that webservices are not a part of Web Profile, so you would need a fully certified JEE6 container (glassfish or JBoss).

For other features like mapping http params to method params, DI or other exception handling, watch out for Seam 3 Rest support (currently in beta) which have custom bean validation integrated into http requests, seam-catch exception handling, and other cdi extensions.