Java EE 6 Java EE 6 Java EE 6 Java EE 6 Java EE 6 Java EE 6

tastelessbeachInternet and Web Development

Nov 12, 2013 (4 years and 7 months ago)


Last month, version 3.1 of the GlassFish application
server was released. With the new GlassFish release, and
Oracle WebLogic Application Server slated for Java EE 6
compliance later this year, it‘s clear Java EE 6 is still a hot
technology – despite all the headline-grabbing rumours
circulating about the new features in Java EE 7 and 8. In
this issue of JAXmag, we take a closer look at some of the
technologies occupying the Java EE 6 space, including
Arquillian and JAX-RS, and get an insight into the nuts
and bolts of what it means to implement the Java EE Web
Profile specification. Let's start with a tour through the
latest release of the specification: a Java EE 6 overview!
Java EE 6 Overview
A Tour Through The Latest Release
JavaEE inside Google App Engine
How to Use CDI in GAE
Taking the Pain out of Integration Tests
A RESTful Approach to the Java EE 6 API
An Introduction to Siwpas
Implementing the Java EE Web Profile Spec
Java, Enterprise Architecture, Agile and Eclipse
Issue March 2011 | presented by
Java EE 6
Java EE 6
Java EE 6
Java EE 6
Java EE 6
Java EE 6

March 2011
This issue of JAXmag is dedicated to the latest industry stan-
dard for enterprise Java computing: Java EE 6. The previ-
ous release, Java EE 5, had set the foundations for reducing
complexity, through its adoption of annotations and POJO
programming, but Java EE 6 continued this streamlining pro-
cess by removing outdated APIs. Java EE 6 also introduced
sub-sets of Java EE APIs, ‘Pro￿ les’, in response to the criticism
that Java EE was too large, especially for developers working
with small to medium Java web applications. Despite some
critics’ complaints that Java EE 6 wasn’t lightweight enough,
Java EE 6 has seen increasing adoption rates since its initial
release. However, this latest version of the Java EE 6 platform
had a controversial (and rather familiar) start, with JSR-316
being at the centre of two years of discussions and debate.
When it was ￿ nally approved in December 2009, some of the
JCP members (IBM, Intel, Red Hat) who voted in favour of
the JSR registered that they were voting for the technology,
and not the technology’s licensing terms.
Java Enterprise Computing
But, after its controversial beginnings, Java EE 6 has been
successfully adopted by a list of application servers. JBoss
Application Server 6.0 of￿ cially supports the Java EE 6 Web
Pro￿ le, and Oracle WebLogic Application Server, IBM Web-
Sphere Application Server v8 and JEUS 7 are currently in de-
velopment for full Java EE 6 certi￿ cation.
In this issue of JAXmag, we introduce readers to the va-
rious technologies that comprise Java EE 6, with the ‘Java
EE 6 Overview’ article by Caucho Technology engineer Reza
Rahman. We’ll examine some of the technologies that occupy
the Java EE 6 space, with articles on JBoss’ Arquillian inte-
gration testing tool, and the Siwpas application server, and
look ahead to the relationship between enterprise Java and
the cloud in Ales Justin’s ‘Java EE inside GAE’ article.
If this issue leaves you hungry for more Java EE-related
knowledge, be sure to check out JAX London’s dedicated
Java EE track, moderated by Oracle’s Arun Gupta. Hope you
enjoy the issue! Jessica Thornsby
Java EE 6 Overview

New Features in Version 6
JavaEE inside Google App Engine

The cloud and enterprise Java
Integration Tests with Arquillian

Alming to Make Testing Easier
The REST Way!

Building Web Services in Java

Simple Web Pro￿ le Application Server
Reza Rahman Ales Justin Markus Eisele S Sangeetha Gurkan Erdogdu
Java EE 6

March 2011 3
by Reza Rahman
Java EE 5 was a remarkable transformation for a mature,
widely deployed, well supported development platform. EJB
3.0 was introduced as the reengineered business component
development model, the aging EJB 2.x Entity Bean model was
replaced by JPA as the persistence paradigm, JSF was intro-
duced as the standard presentation tier framework and JAX-
WS 2.0 replaced JAX-RPC as the SOAP web services API. The
focus of Java EE 5 was squarely on reducing complexity by
embracing the concepts of annotations, POJO programming,
zero-configuration systems, intelligent defaults and freedom
from XML hell. Despite the reservations around Java EE in
some camps, perhaps the best testament to the fact that Java
EE 5 succeeded is the many folks who considered adopting
Java EE for the first time because of these changes. A large
number of these folks also comment on how surprisingly
streamlined and well-put-together the Java EE programming
model felt.
A Bird’s Eye View
Java EE 6 is another important step in the journey towards
the ideal of a simple, streamlined and well-integrated plat-
form. Java EE 6 also includes a rich set of innovations best
reflected in the technologies that comprise the platform in-
cluding brand new APIs like CDI 1.0 and JAX-RS 1.1 or even
relatively mature APIs like Servlet 3.0.
Besides a few relatively minor changes such as standardiz-
ing global JNDI naming (which I won’t cover here), the major
themes for Java EE 6 from a platform standpoint are pruning
and profiles. In some ways, these themes are an essential by-
product of the deep seated changes in the platform. Let’s take
a quick look at these changes.
Pruning the Dead Wood
The first release of Java EE was in 1999. By standards of the
hypercompetitive technology industry, that’s nothing short
of a lifetime. During this span, Java EE has only grown. As
a result, the platform is now weighed down with some dead
wood in the shape of APIs that are outdated, have been su-
perseded, not well supported or not widely deployed. Java EE
6 begins the essential process of carefully pruning these APIs
to make the platform more lightweight and to make room
for healthier growth. Table 1 shows the APIs that are on the
chopping block, along with an explanation of why.
“Pruning” an API essentially means that an application
server vendor need not support these technologies, although
some larger vendors will probably continue supporting the
pruned APIs for a period of time.
Profiles: Different Strokes for Different Folks
One of the major criticisms of Java EE has been that it is
simply too large. Indeed, a majority of small to medium range
Java web applications do not utilize the full Java EE stack.
One can imagine the same to be true of SOA applications that
would use features like messaging, transactions, persistence
and web services but have no need for presentation tier tech-
nologies like JSP or JSF.
Profiles are designed to address this issue. Profiles are essen-
tially sub-sets of Java EE APIs geared towards a particular class
of applications in mind. For example, the Java EE 6 Web Pro-
API Reason for Pruning
JAX-RPC JAX-RPC was an early attempt at modeling SOAP
web services as RPC calls. Web services have since
grown out of simply being an RPC model. The much
more robust, feature-rich and popular JAX-WS API
effectively supercedes JAX-RPC.
EJB 2.x Entity
The complex, heavyweight and overkill model of EJB
2.x Entity Beans has been replaced by the popular,
lightweight, POJO based JPA persistence model in-
troduced as part of EJB 3 in Java EE 5.
JAXR JAXR is one of the few Java APIs for interfacing with
UDDI registries. Unfortunately, since UDDI is not
widely used, JAXR has very limited adoption, deploy-
ment and vendor support.
Java EE
JSR 88 was an attempt at developing deploy-
ment tools that work across application servers.
Unfortunately, this API has never gained much ven-
dor support.
New Features in Version 6
Java EE 6 Overview
Java EE 6 has all the makings of one of the best releases of the enterprise Java standard since its inception in
the late nineties. Java EE 5 was without a doubt a revolutionary release. Java EE 6 straddles the line between
being revolutionary and evolutionary. In the least, it solidifies the changes that began with Java EE 5. This brief
article overviews the changes in Java EE 6, covers some of the API changes at a high level, mentions implemen-
tations currently available or underway and takes a forward look at the changes in Java EE 7 that are just being
Table 1: APIs Pruned in Java EE 6
Java EE 6

March 2011 4
file only includes APIs that are likely to be used in most Java
web applications. As such, the idea of Profiles has been used
successfully in the standards world for a relatively long time.
As you might already know, Java ME supports the idea of Pro-
files geared towards particular device runtime environments.
Likewise, Profiles are used to better organize the increasingly
complex world of web services standards such as the WS-I Ba-
sic Profile, the WS-I Basic Security Profile and the like.
Although Java EE 6 defines the rules for creating new Pro-
files through separate JSRs, only one Profile, the Web Profile
is included in the platform this time. Table 2 lists the APIs
that are included in the Web Profile as opposed to the full
Note that EJB Lite, and not the full version of the EJB speci-
fication is included in the Web Profile. I’ll describe EJB Lite in
greater detail shortly.
A Fast Walk Around the Block
Thus far we’ve covered the work of the JSR 316 expert group,
responsible for determining the overall make-up of the Java
EE platform. While this work is critically important, most
people associate Java EE with the individual APIs that com-
pose the platform. In this section, let’s take a quick look at the
changes in the Java EE 6 APIs. I highly encourage you to dig
further into each of these APIs on your own.
CDI 1.0: CDI is perhaps the most groundbreaking API de-
veloped in the Java EE 6 time-frame. CDI fills a number of
important gaps in Java EE. Although CDI is inspired by Seam,
Guice as well as Spring, it does not directly mirror any of
them. Indeed, CDI adds a number of unique innovations of its
own. Here is the long and short of what CDI offers:
CDI unifies the JSF, JPA and EJB 3 programming models •
to truly feel like a single, well-integrated platform. It does
this by registering EJB 3 beans, JPA entities as well as plain
JavaBeans (“managed beans” in Java EE 6 parlance) as
CDI components and making them accessible via EL as
well as being injectable into each other. In effect, CDI lets
you eliminate JSF backing beans and flatten the traditional
application tiers if you want.
CDI implicitly manages the life-cycle of all registered •
components in appropriate contexts. In addition to the
traditional request, session and application centric compo-
nent scopes, it adds the notion of an implicit “dependent”
scope as well as a “conversation scope”. While the depen-
dent scope essentially “inherits” the invoker’s scope, the
“conversation scope” is based on the idea of application-
demarcated sessions based on stateful workflows. From an
EJB 3.1 perspective, this bridges the gap between client-
agnostic generic component scopes (stateless, stateful,
shared) to Web application centric scopes.
CDI brings a robust set of dependency injection features to •
the platform in a completely type-safe, annotation-driven
and Java-centric way. These features include the ability to
integrate arbitrary Java objects that are not EJBs, Servlets
or otherwise managed objects, inject managed objects into
non-managed objects, inject non-managed objects into
managed objects, use object factories and utilize stere-
otypes to group annotations' metadata together to define
altogether new component types.
CDI enhances the Java EE Interceptor model by adding the •
ability to bind interceptors to annotations instead of hav-
ing to bind interceptors to target object classes themselves.
The annotations bound to the interceptors are then placed
on the target objects. Unlike the Java EE 5 model, this adds
an indirection between interceptors and target objects. CDI
also adds the very interesting concept of “decorators”. In
essence, decorators are interceptors that are aware of target
business objects instead of being business domain agnostic.
As impressive as this list is, it is just the tip of the iceberg. CDI
adds a lot of other very cool features that constitutes the next
generation of integration features for Java EE. For example,
CDI includes a type-safe event bus as well as a well-defined
portable extensions API designed to encourage a rich CDI
plug-in ecosystem to be seeded by projects like Seam 3. For a
closer look at CDI, check out the final draft at
JSF 2.0: Despite the fact that the Java presentation tier
framework market is fiercely competitive, JSF appears to be
holding ground. However, there are a number of valid con-
cerns around the usability and robustness of JSF. JSF 2.0
meets these concerns head-on by focusing on ease-of-use, in-
novation and expanding the feature set:
JSF formally adds Facelets as a view technology. In case •
you are unfamiliar with Facelets, it is an open source view
technology specifically developed with JSF in mind. As
a result, unlike JSP, it fits the JSF component model and
life-cycle a lot better. However, possibly the most powerful
API Web Profile Full Profile
Servlet 3.0
✔ ✔
JSP 2.2
✔ ✔
JSTL 1.2
✔ ✔
EL 1.2
✔ ✔
JSF 2.0
✔ ✔
CDI 1.0
✔ ✔
EJB 3.1 (Lite)
✔ ✔
EJB 3.1 (Full)

JPA 2.0
✔ ✔
JTA 1.1
✔ ✔
JMS 1.1

JavaMail 1.4

JAX-WS 2.2

JAX-RS 1.1

JAXB 2.2

JACC 1.0

JCA 1.6

Table 2: Java EE
6 Web Profile
Java EE 6

March 2011 5
feature Facelets brings to the table is the ability to easily
create custom components and templates without Java
code and with mark-up instead. The complexity in creating
custom components and templates is probably the biggest
complaint against JSF.
JSF 2.0 brings Java EE 5 style annotation-driven configura-•
tion to the table via annotations such as @ManagedBean
and @ManagedProperty. This means a dramatic reduction
in the size of the faces-config.xml file, although things like
navigation rules will still need to be configured in XML.
JSF 2.0 changes the JSF life-cycle to account for AJAX. •
This is done via introducing the concept of partial page
processing to handle AJAX events. This enhancement
makes developing AJAX capable JSF components feel
more natural as opposed to feeling like you were trying to
fit a square peg into a round hole.
An excellent and timely addition in JSF 2.0 is the built-in •
capability to handle resources such as images, JavaScript
files, CSS and the like. This includes the capability to refer
to resources via logical names, grouping resources into
libraries and versioning.
Besides the list above, JSF 2.0 includes a number of other
changes like adding support for events, bookmarking, URL
parameter binding, RAILS_ENV style development stages
and significantly expanding the standard set of components.
You can check these out yourself by reading the JSF 2.0 final
draft at
EJB 3.1: EJB underwent the most dramatic changes in Java
EE 5. As much as it may have seemed impossible, EJB 3.0 was
relatively well-received by the community and the adoption
rate has been growing. It’s probably an oversimplification to
think just the changes in Java EE 5 caused this. For example,
the interest around JBoss Seam and the vigorous development
of GlassFish are probably important contributing factors. The
main goal of EJB 3.1 is to continue down the path of making
EJB as simple as possible while adding meaningful business
component services. Here is a high-level overview of the EJB
3.1 features:
Business interfaces have been made optional even for Ses-•
sion Beans. This is particularly useful for using Session
Beans in JSF with CDI.
EJB 3.1 adds the concept of Singleton Beans. Because they •
are intended for managing shared application state, they
are completely thread-safe by default. However, EJB 3.1
adds declarative concurrency controls for greater flexibility.
A particularly powerful feature in EJB 3.1 is support for •
cron-style scheduling. In addition to the current interval
based timer API, both declarative and programmatic cron-
style scheduling APIs were added.
Another powerful feature added to EJB 3.1 is the capabil-•
ity to invoke Session Bean methods asynchronously via
the @Asynchronous annotation. You can even control the
asynchronous EJB method via a handle to a java.util.con-
current.Future object.
The concept of EJB 3.1 Lite was introduced to add a small-•
er subset of the EJB API geared towards the Web Profile.
While EJB Lite includes features like transactions and
security, it does not include features like messaging, remot-
ing and scheduling.
Besides the features in the list above, EJB 3.1 also adds the
capability to package EJBs directly in WAR files, run an
embedded EJB 3.1 container in Java SE environments such
as JUnit tests (this capability powers CDI/Java EE centric
testing projects like JBoss Arquillian) and utilize standard-
ized global JNDI names for EJB. The EJB 3.1 final draft
covers all these features in detail:
JPA 2.0: As of Java EE 6, JPA has been officially separated
from EJB as a distinct API in its own right. There can be little
doubt that JPA has been a success. It enjoys great adoption
rates and first-class vendor support. That is no meager accom-
plishment for the persistence standard in Java EE considering
the EJB 2.x Entity Beans meltdown. An important factor in
this is probably the unequivocal support from Gavin King as
well as the rest of the JBoss community. JPA 2.0 aims to build
on this success by filing in a few much needed gaps as well as
adding useful innovations:
JPA 2.0 adds a number of much needed ORM mapping en-•
hancements such as the ability to model collections, maps
and lists (that do not represent entity relationships) via the
@ElementCollection annotation and the ability to map
unidirectional one-to-many relationships (JPA 1.0 only al-
lowed bidirectional one-to-many relationships),
Both the • EntityManager and Query APIs have been en-
hanced to support things like retrieving the first result (JPA
1.0 allowed the retrieval of a unique result), specifying
the maximum size of query results, getting access to the
underlying vendor-specific entity manager/query objects
and pessimistic locking (JPA 1.0 only supported optimistic
JPQL has been enhanced with SQL-like • CASE, NULLIF,
COALESCE and like capabilities.
JPA 2.0 adds a Criteria API that many folks have been ask-•
ing for. In case you are unfamiliar with the Criteria API in
Hibernate or TopLink, it is essentially the object-oriented,
type-safe, Java-centric equivalent of JPQL statements. This
is a boon for use cases such as writing complex dynamic
queries and avoiding runtime exceptions thrown while
parsing JPQL.
There are a whole host of other features that JPA 2.0
adds such as standardizing second level caching, standard
JDBC properties, specifying timeouts and the like. Feel free
to take a look at these features detailed in the JPA 2.0 fi-
nal draft available from the JSR site:
Servlet 3.0: Given the maturity of the venerable Servlet API,
it can perhaps be somewhat surprising that it is going through
a major revision. As a matter of fact, the Servlet 3.0 changes
have generated quite a bit of excitement and is likely to be
very well-received by the community. Here is an overview of
the changes:
Java EE 6

March 2011 6
Servlet 3.0 embraces the Java EE 5 model by introducing •
annotations such as @WebServlet, @ServletFilter and

@WebServletContextListener. This significantly reduces
web.xml configuration to the point that it could be elimi-
nated altogether.
Servlet 3.0 also introduces the idea of • web.xml fragments.
This means that the container looks for configuration in
web.xml fragments anywhere in the web application class-
path (such as the WEB-INF/classes directory or jars in the
WEB-INF/lib directory) in addition to the web.xml file in
WEB-INF directory. This is particularly useful for web ap-
plication frameworks like JSF or Struts that need their own
web.xml configuration to be bootstrapped.
Another very cool addition is the ability to programmati-•
cally add Servlets, Filters and Listeners through the Serv-
letContext. Like web.xml fragments, this feature is also
primarily geared towards framework developers that need
to dynamically determine configuration at runtime.
Besides the changes above, Servlet 3.0 also introduces fea-
tures like asynchronous processing support. The Servlet 3.0
final draft is available here for you to take a look at: http://jcp.
JAX-RS 1.1: REST is increasingly gaining traction as an al-
ternative web services development paradigm. The inclusion
of JAX-RS, the REST counterpart of JAX-WS, into Java EE
is a nod to this trend. Much like JAX-WS abstracts away the
low-level details of the SOAP protocol, JAX-RS is designed to
reduce REST development to POJO programming and annota-
tion based configuration. Here is a high level view of JAX-RS:
The • @Path annotation determines the URL that a JAX-RS
resource can be accessed, down to a method in a POJO.
Annotations like • @GET, @POST, @PUT and @DELETE
are used to specify the HTTP method that is used to access
a resource.
Input from sources like URL query parameters, parts •
of the URL, cookie values and HTTP header values are
mapped into variables via annotations like @QueryParam,
@PathParam, @CookieParam and @HeaderParam respec-
The • @Produces annotation tells JAX-RS what the content
type of returned values are such as text/xml, text/json and
the like.
JAX-RS is integrated with Servlets, CDI and EJB.•
JAX-RS has many other powerful features that make REST
development a breeze, much like JAX-WS makes SOAP de-
velopment almost transparent. The final draft of JAX-RS is
downloadable here:
Bean Validation 1.0: Although Bean Validation is not a
component level API per se, it is possibly one of the most
interesting innovations in Java EE 6. The Bean validation API
allows you to enforce application validation rules or con-
straints (such as field not null, numeric value between 10 and
45, valid email, etc) in a declarative fashion only once across
all the application tiers. The idea is that all frameworks that
support Bean Validation would then transparently read and
enforce constraint meta-data that you place on a bean (likely
through annotations). Here is a high level view of the Bean
Validation API:
A simple bootstrap API that any supporting framework •
can use to locate the Bean Validation API and evaluate
constraints as needed. As a Java EE developer, you would
likely not be exposed to this low-level API.
A set of built-in constraint annotations such as • @NotNull,
@Max, @Min, @Size, @Pattern, and so on.
A way to group constraints to be validated at various •
stages of the application.
Bean Validation is integrated with JSF 2 and JPA 2.•
Bean Validation has many powerful features such as the abil-
ity to create custom constraints and validators. The final draft
of the Bean Validation API is downloadable here: http://jcp.
Java EE 6 Implementations
The unique power of Java EE lies in standardization, port-
ability, compatibility and vendor independence. These unique
values can only be realized if there are multiple high quality
compatible Java EE implementations. Fortunately, Java EE 6
has been strongly adopted by a wide range of vendors – some
familiar and some fresh. The table below lists the currently
available implementations as well as the ones in the works
(Table 3).
GlassFish v3 Open source Java EE 6 reference implementation;
Earliest Java EE 6 runtime strongly supported by
Oracle; Offers both a Web Profile as well as Full
Platform implementation.
JBoss AS 6 Most widely used open source Java application serv-
er – recently passed Java EE 6 Web Profile TCK; Java
EE 6 Full Profile implementation on the way.
Resin 4 Focus on a fast, lightweight, reliable open source
Java EE 6 Web Profile server. Resin recently passed
the Java EE 6 Web Profile TCK.
Geronimo 3 Apache licensed open source application server – ba-
sis for IBM WebSphere Community Edition; Geronimo
3 aimed to pass Java EE 6 Web Profile TCK shortly
with a Full Profile implementation to follow.
Korean application server; JEUS 7 one of the earliest
to get Java EE 6 certified; still in beta stage.
WebLogic Next release, WebLogic Server 11g R2, will support
both Java EE 6 Full and Web Profile; planned for cal-
endar year 2011.
WebSphere WebSphere 8 beta previews Java EE 6
JOnAS Open source application server from OW2 consor-
tium; JOnAS 5.2 implementing some Java EE 6 fea-
tures; JOnAS 6 will support Java EE 6
SIwpas Tomcat based open source Java EE 6 Web Profile of-
fering leveraging Apache projects from Turkish com-
pany MechSoft; not certified yet
Table 3: Java EE 6 Implementations
Java EE 6

March 2011 7
As you can see, there are an abundance of options to choose
from despite some industry consolidation such as the Oracle
purchase of Sun and BEA. In fact, Java EE 6 has been imple-
mented more often and faster than any previous Java EE re-
lease. There are other application servers like SAP NetWeaver
that I did not mention above since they have not yet formally
announced their plans around Java EE 6 although they are
very likely to support it in the near future.
A Look Ahead
Even as the Java EE 6 implementations roll in, the work
for the next revision of Java EE is already being initiated.
In the coming months, you should expect to see some of
the first Java EE 7 JSRs. Here are some of the possible
Cloud support is a big part of Java EE 7. While it still isn’t •
clear exactly how Java EE 7 cloud support is going to look,
the changes might include support for modularity, version-
ing, multi-tenancy and greater runtime security.
A brand new API for Java EE concurrency will be added, •
similar to the concurrency utilities in Java SE.
The JCache API will be updated and finally added to Java •
The important concept of a simple managed bean was •
introduced in Java EE 6. In fact, EJBs were redefined to be
managed beans with additional container services. You
should expect this concept to be taken to the next logical
step in allowing EJB services like pooling, transactions,
locking, security, scheduling, asynchronous processing
or even messaging to be available outside of EJB in plain
managed beans (in fact, this is the model that Resin 4 em-
braces today and is supported by the Seam 3 persistence
module as well). In addition, JSF, Servlets, JAX-RS and
JAX-WS should offer greater alignment with managed
EJB 2.x CMP/BMP entity beans and JAX-RPC support in •
EJB should be deprecated.
The next CDI release, CDI 1.1 should be relatively minor •
and include things like an embedded CDI container, en-
hancements to the portable extensions API and more XML
configuration support. The real CDI related work should
be better alignment of EJB, JPA, JSF, Servlet, JMS, JAX-RS
and JAX-WS with CDI.
JSF 2.2 will be a relatively minor enhancement with things •
like better portlet integration, Spring WebFlow/Oracle
ADF style flow management and HTML 5 support.
Servlet 3.1 will be a relatively minor enhancement with •
features like better Servlet async support for the new Java
EE concurrency API and the emerging WebSocket stand-
EL 3.0 will be separated from JSP as a pluggable API and •
include a few enhancements needed for CDI, JSF, etc.
JPA 2.1 will be a minor update to add things like stored •
procedure support, further ORM flexibility, fetching flex-
ibility, immutable attributes, read-only entities, update/
delete criteria queries, dynamic definition of persistence
units and so on.
JAX-RS 2 will include a number of useful features such as •
a client API, better integration with the Bean Validation
API, asynchronous request processing as well as being able
to use JAX-RS resources as MVC controllers (with JSP
pages being views).
JMS will get a long-awaited revamp with JMS 2. JMS •
2 could include more API simplifications, making JMS
plugg able/embeddable as well as better support for emerg-
ing Event-Driven Architecture paradigms.
JTA 2 could be introduced to modernize the dated API as •
well as add better support for local transactions.
Note some of this is from my own personal wish-list; if they
sound right, feel free to support the idea via blogs, etc. Also,
I encourage you to have an active voice in these changes by
participating directly through the JCP:
The changes in Java EE 6 are compelling and have been large-
ly well-received by the community. They include pruning,
profiles, CDI, JSF 2, EJB 3.1, JPA 2, Servlet 3, JAX-RS and
bean validation. If you have not taken a closer look at Java EE
6 yet, you owe it to yourself to do so now. There are a number
of good Java EE 6 implementations available already with
more on the way. In addition to simply being a passive user
or evaluator of Java EE, you also have the opportunity to give
your feedback towards Java EE 7 as the platform continues
to evolve.
[1] Introducing Java EE 6:
[2] Java EE 6 Tutorial:
[3] Java EE 6 Code Examples:
[4] GlassFish:
[5] JBoss:
[6] Resin:
Reza Rahman is an engineer at Caucho Technology focused on Resinís
EJB 3.1 Lite Container. Reza is the author of EJB 3 in Action from Man-
ning Publishing. He is a frequent speaker at Java User Groups and con-
ferences including TheServerSide and JavaOne. Reza is an independent
member of the Java EE 6 and EJB 3.1 expert groups. Reza has over a
decade of experience with technology leadership, enterprise architecture, applica-
tion development and consulting. He has been working with Java EE since its incep-
tion, developing on almost every major application platform ranging from Tomcat to
JBoss, GlassFish, WebSphere and WebLogic. Reza has developed enterprise systems
for companies including Motorola, Comcast, Nokia, Guardian Life, Prudential, Inde-
pendence Blue Cross, Citigroup, Accenture and GMAC using EJB 2, EJB 3, Spring
and Seam.
JAX – The Premier Java,
Architecture & Agile Experience
June 20 – 23, 2011, San Jose CA
Technical presentations and tutorials

In-depth coverage of the latest technologies

Practical implementation techniques

Neutral coverage of the most important Java Ecosystem topics
Register Now!
Media Sponsors:Organized by:
follow us: JAXConf JAXConf
Gold Sponsor:
Just JSF
Webtech & JavaScript
Java EE
Java Core
Java Languages
Agile ALM
Web Architecture
Google App Engine

March 2011 9
by Ales Justin
Companies, as well as developers themselves, have invested
a lot of resources, work and knowledge into mastering their
Java enterprise technologies, whereas cloud computing most-
ly, due to its logical restrictions, works completely differently
from what we’re used to in the heavyweight Java enterprise
world. The potential problem is obvious – do we really have
to forget and throw away a lot of what we have learned and
done in the past few Java enterprise programming years in
order to move into the clouds?
Google, after having to develop cloud infrastructure for its
own needs, and being in an ideal position to offer cloud serv-
ices to the public, was one of the first to provide a free PaaS
service. The service was named GoogleAppEngine (GAE),
and it served Python applications in its initial offering. Due
to the decent success of this initial service, and obviously big
popularity of Java as an open source enterprise-ready lan-
guage, they expanded the GAE service to host Java applica-
tions as well.
With Java the usual practice is to turn good and successful
custom frameworks or projects into a specification. The last
two Java EE specifications are good examples of this with
their JPA, JSF, EJB3 and the latest CDI and BeanValidation.
Meanwhile, the first three mentioned got an upgrade, which
just confirms their vast adoption and good user feedback.
CDI is a fresh enterprise specification, based on the best-of-
breed from popular custom application frameworks such as
Cloud computing is a fast growing field, which is defining a roadmap for future IT infrastructure. If you want to
live on the bleeding edge, you shouldn't just observe it from the sidelines, you should try it! On the other hand,
enterprise Java has been around for quite a while, at the moment already in its sixth stride. Over time various
expert groups evolved the specifications, fixing the mistakes of previous versions, simplifying the usage despite
complexity, and of course adding new interesting technologies.
The cloud and enterprise Java
JavaEE inside GAE
Google App Engine

March 2011 10
JBoss Seam, Google Guice and Spring framework. It allows
simple type-safe configuration, which is extremely useful for
large projects, and is built to play nice with today’s powerful
IDE tools.
Since Google is definitely aware of best-practices, they try
to support existing standards as much as possible. But since
cloud processing has its specific restrictions, not all is that sim-
ple. And this is what is going to be the focus of our article; how
to keep standard technologies present, while still respecting
the cloud restrictions. We’ll look in more detail into how to
introduce CDI, and how to transparently and efficiently in-
tegrate it with JPA, JSF and BeanValidation, while also re-
placing the missing EJB3 functionality. We’ll also touch upon
all of the major GAE restrictions and how to properly tackle
them in Java enterprise environment.
Since today’s solutions need to be fully tested, a new ap-
proach to testing will be presented as well. This new testing
allows transparent environment switching, making tests true
to Java; run once, test everywhere. And this goes for “our”
GAE environment as well.
Introducing CDI
We won’t go too much into details on what is CDI and how
it works. This is a topic for a different article. In this one we’ll
show how to best use it in GAE.
One of the major, if actually not “the” major, GAE restric-
tions is a 30 seconds request/response time limit. Meaning
that if the application doesn’t respond in less than 30 seconds,
GAE itself terminates that thread and throws an appropriate
exception. On the other hand, if the application is not used
for a while, GAE simply shuts down all application instances,
meaning that the next request will suffer an overhead of new
instance booting up. This has lately changed a bit, with the
addition of “Always On” feature, but unfortunately doesn’t
come free of charge.
In order for CDI to work, the CDI runtime needs to inspect
all potential beans upon initialization, thus spending quite some
time determining and validating an application’s beans con-
figuration. Considering that on the first request you might not
just serve the request, but also bootstrap the whole application,
one must think hard to initialize beans as lazy as possible – that
means reducing initialization time processing to the minimum.
Another thing to consider is to filter out all the classes that
are not actually used as beans in your application. In Weld,
the Joss’s CDI and RI implementation, we have a few different
ways to limit a list of potential beans classes. One way is to
define a filtering element in beans.xml, another is to provide an
exact bean-classes.txt file with listed beans’ class names.
As with every framework, CDI needs to have an entry
point into your application. In the web application the easi-
est way to bootstrap custom framework is usually via servlet
listener. CDI, or Weld specifically, is no exception. But, and
an important but, this is only an initial bootstrap, that just
sets up CDI BeanManager, and application’s beans. Since
we’re in a web application, our logic is probably accessed
through servlets and filters. To actually use CDI with those
components an additional integration mechanism must be
For “standard” web containers, such as Tomcat and Jetty,
Weld already provides full out-of-the-box CDI integration.
But since GAE is not pure Jetty, but a Jetty based fork without
all of its features – mostly due to security reasons, we need to
find a different way of integrating with CDI.
This is not as difficult as it might look at a first glance. All
of CDI implementations leave some room for custom exten-
sions, which can easily be used to get a hold of application’s
BeanManager instance. This does make your application a bit
un-portable between different CDI implementations, but that
can easily be abstracted if you actually need it. In our Weld
case, we use the fact that BeanManager is also added as an at-
tribute of a servlet context at boot time. This way we can easi-
ly create a CDI aware delegate of the initial servlet. The way
this works is that non-CDI aware servlet receives the request,
and delegates it to CDI aware servlet-like delegate.
OK, so we now have our super lazy CDI beans up and run-
ning, ready to serve some requests. Let’s have a look how
these beans can actually do something serious, interacting
with your database for example. Onward to JPA!
JPA usage
While GAE has its own low-level persistence API – a simple
detyped DataStore, the JavaEE developers are more used to
JPA API, therefore GAE offers that as well. But to no sur-
prise, there are quite a few reasonable restrictions one must
be aware of.
The actual database is not a relational database as we all
know it, but a highly scalable non-relational BigTable. While
we normally have a single relational database instance, GAE
actually has an unknown number of BigTable instances (or
nodes) which – from a user’s point of view – it randomly
chooses when writing the data. In order to make such writes
ACID, any “related” data needs to be on the same node,
meaning that JPA relationships need to be carefully crafted.
There are already existing OSS frameworks that help
you with this relationship problem as much as possible. In
our case we developed our own simple solution, on top of
standardized JPA, which with the help of proxied entities
hides the workaround’s implementation details. Each entity
instance used is actually a proxy instance that intercepts
calls to potential relationships and turns them into proper
As we already know, a part of JPA is also its 2nd level cach-
ing, which in our case comes in very handy. Instead of doing
expensive query lookups, we can easily cache a lot of previ-
ously looked up data, especially considering that cache comes
“cheap” in GAE. Thanks to this feature, it also makes a lot of
sense to implement an initial JPA EntityManagerFactory ini-
tialization in a very lazy manner. We do not have to actually
instantiate EntityManagerFactory if previously cached data
can be used to handle the lookup.
JSF, BeanValidation and Cache
In order to make use of JSF2, one must properly setup initial
context parameters and unfortunately even use a few hacks.
The parameters need to disable any multi-threaded JSF be-
havior, while that hack we used got us past forbidden class
Google App Engine

March 2011 11
Software & Support Media GmbH
Editorial Offi ce Address
Geleitsstraße 14
60599 Frankfurt am Main
Editor in Chief:

Sebastian Meyen

Jessica Thornsby, Claudia Fröhling

Markus Eisele, Gurkan Erdogdu, Ales Justin, Reza Rahman,
S Sangeetha
Copy Editor:

Nicole Bechtel
Creative Director:

Jens Mainz

Dominique Kalbassi
Sales Clerk:
Mark Hazell
+44 (0)20 7401 4845
Entire contents copyright ©2011 Software & Support Media GmbH. All rights reserved. No
part of this publication may be reproduced, redistributed, posted online, or reused by any
means in any form, including print, electronic, photocopy, internal network, Web or any other
method, without prior written permission of Software & Support Media GmbH
The views expressed are solely those of the authors and do not refl ect the views or po-
sition of their fi rm, any of their clients, or Publisher. Regarding the information, Publisher
disclaims all warranties as to the accuracy, completeness, or adequacy of any informa-
tion, and is not responsible for any errors, omissions, in adequacies, misuse, or the con-
sequences of using any information provided by Pub lisher. Rights of disposal of rewarded
articles belong to Publisher. All mentioned trademarks and service marks are copyrighted
by their respective owners.
Ales Justin was born in Ljubljana, Slovenia and graduated with a degree
in mathematics from the University of Ljubljana. He fell in love with Java
nine years ago and has spent most of his time developing information
systems, ranging from customer service to energy management. He joined
JBoss in 2006 to work full time on the Microcontainer project. He cur-
rently leads Weld project, a JSR-299/CDI RI, while still contributing to Application-
Server, Seam, Arquillian and many other JBoss, projects.
usage; no InitialContext allowed. Another thing to be aware
of is that GAE already comes with EL 1.0 (Unifi ed Expression
Language library) in its classpath, which due to some strange
rule gets used instead of the application shipped EL library
– meaning we’re stuck with EL 1.0 features, needing some
workaround to invoke parameterized bean methods.
The actual implementation usage depends on how many
validation features we want to get out of BeanValidation. In
our case it turned out we actually just needed a simple bean
property validation, making it a lot easier and lightweight
to implement a few BeanValidation SPIs on our own, and
just use that. Since all actual usage is hidden behind proper
BeanValidation API, this makes it trivial to replace with more
complex implementations if needed.
As we already mentioned, caching in GAE is “cheap” and
you have a lot of it. This should encourage you to try and
cache as many things as possible. Of course you should pay
high attention to the cache eviction policy and how to prop-
erly apply it across all layers in order not to leave any stale
data lying around. Another thing to have in mind is that
with application version updates the cached data’s structure
can change, thus breaking serialization contract. Similarly,
the GAE UI admin interface allows admin to change data.
For that reason one should expose clear-all-cache operation
through an application’s admin interface.
Another great thing about GAE is its ease of use even in local
environment. Setting up testing of your application shouldn’t
be too hard. As with other technologies we used, our testing
framework also should be able to support runtime environ-
ment changes. At JBoss we developed two really state-of-
the-art testing frameworks to help you easily achieve this
– Arquillian and ShrinkWrap. The ShrinkWrap project ab-
stracts actual deployment bits, whereas Arquillian abstracts
the actual runtime container aka environment. In order to
test your applications in GAE we just needed to code a proper
Arquillian container implementation which is capable of run-
ning GAE in embedded mode. This way the testing code is en-
vironment agnostic, where actual environment is determined
by the actual single Arquillian container implementation on
the test’s classpath.
We can see that developing applications for GAE doesn’t
mean we need to abandon previously learned JavaEE tech-
nologies. However, we do need to be even more careful when
using these technologies, evaluating every use case against ex-
isting and potential GAE restrictions. We can also see the ben-
efi ts of using standardized APIs and good frameworks which
hide away the environment dependencies.
At the JBoss Weld project we encourage users for any feed-
back they might have on the existing GAE experience, taking
every suggestion, bug fi x, patch or criticism into considera-
tion, while making CDI an enjoyable platform to work with
on GAE.
Agile Day
Java EE
Java Tech & Tools
Systems Integration
Learn about the latest develop-
ments and technologies in the
Java ecosystem
Benefi t from the know-how of in-
ternationally renowned speakers
and industry experts
Network with other delegates,
speakers, vendors and suppliers
Organized by:Sponsored by:
follow us: JAX London JAX London
11 – 13 April 2011 Park Plaza Victoria
Europe´s Number 1 Java Conference Series
Special 20% discount for JAXMag readers!
Enter promo code JAXMAGF1 when registering! Save £140!
The Conference for Java
, Enterprise, Web & Agile
JavaEE and Google AppEngine
Ales Justin, RedHat
2011–04–12 | 10:35 AM – 11:25 AM
What started off as a simple CDI+GAE testing
sandbox project, grew into semi serious pet
project. The presentation will sum up tips and tricks on how
to use top JavaEE specs – CDI, JPA, JSF2 and BeanValida-
tion – inside restrictive GAE env, while still having highly
scalable application.
Testing wise, we'll show ShrinkWrap and Arquillian, the
future of JavaEE testing and how they work with GAE.
Fun with EJB 3.1 and OpenEJB
David Blevins
2011–04–12 | 11:50 AM – 12:40 PM
What's old is new again. That goes for EJB
and OpenEJB. Once a technology for just
app servers, EJB now has several new and exciting features
ranging from plain Java SE usage to simplified packaging
in war files. Get an introduction to EJB 3.1 and see apps
using the full spectrum of the EJB API runnable in a plain
Java SE vm or a full Java EE server. See how these apps can
be quickly developed and tested using new parts of EJB 3.1
like the Embeddable EJB Container API. Then, take your
EJB development to the bleeding edge with techniques not
yet part of the EJB specification such as meta-annotations,
expanded interceptor annotations and more.
Java Persistence API 2.0 with
Doug Clarke, Oracle
2011–04–12 | 02:45 PM – 03:35 PM
JPA 2.0 defines the Java EE standard for
relational persistence with open source EclipseLink provi-
ding the reference implementation along with a number of
advanced features including clustered caching, dynamic
persistence, and JAXB integration. This session will look
at the JPA 2.0 specification and beyond to the advanced
features EclipseLink provides to support building Java EE 6
GlassFish 3.1 -Simplifying
your Java EE 6 development &
Arun Gupta, Oracle
2011–04–12 | 03:45 PM – 04:35 PM
GlassFish 3.1 allows Java EE 6 applications to be deployed
in a multi-instance cluster with session failover capabilities.
It provides several other features like application-scoped
resources, ssh-based remote management and provisi-
oning, extensive support for embedded API, and several
other features. This session will highlight how GlassFish 3.1
simplifies develop/deployment of Java EE 6 apps.
Using CDI Extensions to Make a
Better Java EE
Dan Allen, JBoss
2011–04–12 | 06:00 PM – 06:50 PM
Java EE 6 offers significant and compelling
improvements over previous versions of the platform. But
regardless of how sweeping the change, it's not long before
we want more. In this talk, you'll discover that you don't
have to wait for Java EE 7 to get the features you crave
thanks to the por
table extension integration SPI introduced
into the platform by JSR-299.
Java EE Day at JAX London
Host: Arun Gupta (Oracle)
Java EE 6 was a huge step forward for the platform, allowing rapid testing and putting the fun back in-
to working with EJBs. This day will give attendees the opportunity to produce components of Java EE 6
and answer all the burning topics of today: what are the new standards? What useful new functionali-
ty does it offer for software architectures? What modifications will you need to make to your projects,
in order to reap the full benefits of Java EE? Our experts will answer all these questions - and more! Get up-to-date
on the current state of Java EE technology and make development fun again, with our Java EE Day!
Java EE Testing

March 2011 14
by Markus Eisele
The mission of the JBoss project Arquillian is easy. It’s about
providing a simple test framework. The aim is to remove all
container lifecycle and deployment tasks from the actual test
logic and enable developers to build a broad range of integra-
tion tests for their enterprise Java applications. Integration
tests should be a breeze with Arquillian. Since the early days
of Java EE, testing enterprise applications has been a major
challenge for any project. The isolated testing of technical
components was impossible in some cases, since simple unit
tests were frequently insufficient. One main reason for this,
was the design of the components. They are rarely completely
isolated and often depended on both their runtime and other
In the overall context, these aspects are as important as the
technical work performed by a component. Even with a clean
layer separation, a combination of so-called Mocks (interface
simulation) and unit testing is required to integration test
the interfaces and the implemented logic of the components.
And despite all the potential problems, the actual behaviour
of the target container remains completely untested. Neither
transaction control, dependency injection, or other declara-
tive services can be tested adequately. It is usually one of those
final, open questions whether the right services are bound or
the transferred data is actually in the proper format. Ensuring
Since the early days of Java Enterprise Edition, testing of container components and their interaction has been
a pain-point. Their cooperation with other services has been traditionally difficult to simulate. With the increas-
ing functionality of the container (dependency injection, etc.) cross-links and dependencies have also grown. A
fully automated integration test suite previously consisted of many JUnit tests. Now, Arquillian aims to make this
task easier by offering the first complete and integrated test suite for integration testing.
Aiming to Make Testing Easier
Integration Tests with
Java EE Testing

March 2011 15
this, however, is an essential part of development processes in
companies, and it is known as integration testing. The art of
designing an automated integration test and regularly carry-
ing them out, is something only a few experienced developers
are able to do. This results in many stability problems for
projects. The JBoss project Arquillian tries to eliminate this
deficiency. It allows developers to easily run integration tests
for container components. It does not matter whether these
are deployed on a local (embedded) or remote container. The
idea behind Arquillian is to make integration tests as simple
as unit tests.
General architecture
Arquillian (Figure 1) connects a unit testing framework (JUnit
or TestNG), ShrinkWrap, and one or more supported con-
tainers (Java EE container, servlet container, Java SE CDI
environment, etc.).
In essence it’s a custom test runner for JUnit and TestNG,
which transfers control of the test lifecycle of the respective
test implementation to Arquillian. From there Arquillian de-
le gates to the respective environments for testing within the
container or against the runtime. An Arquillian test case still
looks almost exactly like a normal JUnit or TestNG test case.
The testcases basically cover three different aspects. The test-
case itself, the deployment, which has to be packaged into an
archive and, last but not least, the deployment to the runtime.
Neither the deployment process nor the actual container con-
trol is very magical. The packaging of the testcases into the
right format for the target runtime is done by ShrinkWrap.
This is also the true start of an Arquillian test lifecycle. It
defines the basis of the test case, a suitable archive at runtime
and deploys it on the target container. After that the actual
execution of the test case is initiated and results are collected.
Finally, the archive will be removed from the runtime (unde-
ployed). Up to now, there are only a couple of open-source
containers supported. JBoss (> = 5), GlassFish (> = 3), Jetty (>
= 6.1), Tomcat 6, Weld SE and EE 1.0 or 1.1, 1.0, IronJaca-
mar 1.0, OpenWebBeans Apache 1.0 and Apache OpenEJB
3.1 are among them. According to
the manufacturer future support will
also cover commercial platforms such
as Oracle's WebLogic or IBM's Web-
First steps
If you want to start with Arquillian to-
day, you should be aware that this is
still an alpha release. You can down-
load a complete archive from git or
build it from sources. The following
examples use the Arquillian Examples
project, which is based on Arquillian
1.0.0.Alpha4. If you are trying out this
alpha release you are not an early fol-
lower but a leader. You need the com-
plete stack of brand new technologies.
In addition to Maven 3.0 a current 1.6
Java Development Kit (JDK) is also re-
quired. The best way to install the necessary parts is to install
the complete development environment and extract the ZIP
file with the examples into any directory. The most interest-
ing use case certainly is the testing of Enterprise Java Beans
(EJBs). In conjunction with the GlassFish Embedded Server
3.1 this is already included as a pre-configured example. Find
it in the folder ejb31-gfembedded. All examples run with
Maven. To use the embedded GlassFish as a container, cre-
ate the required profile called "glassfish-embedded-3" in the
projects pom.xml. The example is executed using the “mvn
test-Pglassfish-embedded-3” command. A simple one-liner
responds any runs or errors. If everything runs smoothly you
will see:
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 9828 seconds . If this does not work right away,
you have to check for some potential problems and solve
them. The number one reason for any errors are unknown
or missing Maven repository entries. The Arquillian libraries
are in the Public JBoss Repository (http://repository.jboss.
org/nexus/content/groups/public/). This should be referenced
from your pom.xml or even settings.xml. If you are expe-
riencing any the reason could
be a known bug in Embedded GlassFish. It prevents builds
greater than 3.1 b04 from working offline because it is check-
ing for required xml schema files. The same will happen, if
you sit behind a proxy or firewall. In this case you need to
add some configuration parameters via the Surefire plugin
(SystemProperties, http.proxyHost and http.proxyPort). But
there are other circumstances, that prevent the most recent
Arquillian Alpha from running with the latest GlassFish bits.
During development of GlassFish 3.1 the embedded API
changed. This should be reflected with the next Arquillian re-
lease. So if you are in need of more recent builds, you should
wait a little bit longer for Arquillian to provide an updated
If you experience other errors, you are basically helpless at
first. Arquillian log messages are generally rare. So you need
to dig a little deeper into the configuration. By default, the
root directory of GlassFish stays in the target folder which
Figure 1: General architecture (Source:
Java EE Testing

March 2011 16
was created by Maven. Each test run creates a new directory
there. You can change this behavior by making changes to
the arquillian.xml configuration file. It belongs to the src\test\
resources folder and should look like this:
<?xml version="1.0"?>
Using this configuration, the GlassFish directory used each
time a test is run, is always in the same place. You are now
free to make any additional entries to the embedded Glass-
Fish configuration by changing the domain.xml. But are you
still missing the verbose logging? Then you have to get your
hands on the file. Simply copy it from an
existing GlassFish domain and add it to your development
project (For example src\test\gf). Parse it on as a system prop-
erty (java.util.logging.config.file) to the Surefire plugin. If you
now rerun your tests you can see the container log messages.
Another very helpful artifact would be to have a version of
the packaged archive that Arquillian is deploying. This is sim-
ple, too. Add the following entry to the arquillian.xml.
Besides satisfying your curiosity, this can be especially helpful
in future debugging. Particularly if the generated archive can
be successfully deployed to a standalone glassfish, it ensures
that you are most likely stumbling over some problems that
aren't the project developer's fault.
First simple testcase
When all preparations are complete, it is time to devote time
to the actual test functionality. To test a component in the
container, it must be present. A simple Stateless Session Bean
HelloEJB should be enough as the first example:
public class HelloEJB {
public String sayHelloEJB(String name) {
return "Hello " + name;
The world's best known example EJB is now being reviewed
with a corresponding test case:
public class HelloEJBTest {
private HelloEJB helloEJB;
public static JavaArchive createTestArchive() {
return ShrinkWrap.create(JavaArchive.class, "helloEJB.jar")
public void testHelloEJB() {
String result = helloEJB.sayHelloEJB("JAXMag");
assertEquals("Hello JAXMag", result);
The @ RunWith JUnit annotation ensures that the Arquillian
test runner is used. After that you simply inject the HelloEJB.
The @Deployment annotation declares the method that wraps
the actual EJB archive. The actual test case is initiated by the
annotation @Test in JUnit by known style. The assertEquals
checks the return value against a fixed input string. If the two
strings match, the test is a success. All other cases produce
an error. This simple error doesn’t say much about the error
in general at a first glance. So you have to check the target\
surefire-reports folder for details. Each testcase produces a
result in text and xml files. This isn't very handy, but you
have to blame Surefire for that, not Arquillian. If you change
the EJB call into anything to force an error (e.g. sayHelloEJB
("Markus") you can find the specific error:
org.junit.ComparisonFailure: expected: <Hello [JAXMag]> but was: <Hello [Markus]>
More Container functions
In a similar manner as described above you can test almost
any container functionality with Arquillian, with the State-
less EJBs being the simplest case. It becomes more compli-
cated when the runtime with the appropriate resources (eg
a database or interface) must be supplied or if Context and
Dependency Injection (CDI) is required. But even for such
requirements Arquillian has a solution. The simplest case is
the use of CDI. To enable CDI with your testcase you simply
have to add an empty beans.xml file to the test archive. This
is achieved by:
public static JavaArchive createDeployment() {
return ShrinkWrap
.create(JavaArchive.class, "test.jar")
From now on CDI functions are accessible because test.jar
contains the required beans.xml in the META-INF folder.
Another option is the use of an appropriate beans.xml with
content. For this purpose, it has to be put into the project's
resources directory and referenced accordingly:
Java EE Testing

March 2011 17
Up to now everything we tested was done using the GlassFish
Embedded API. If you are hoping to test your Java Persis-
tence API (JPA) applications you have to switch the container
because these are only supported with the remote GlassFish
container. This requires the entire Arquillian configuration
to be changed. The remote deployment is backed by the JSR-
88 API. If you are looking for
some good examples you can
consult the Arquillian User
Arquillian basically man-
ages to test everything which
could be directly injected or
by facilitating the CDI fea-
tures. In addition to the previous example, you can also use it
to test JMS connections. For this it’s as simple as adding the
appropriate queues, topics and connection factories:
@Resource(mappedName = "/queue/q1")
private Queue dlq;
@Resource(mappedName = "/ConnectionFactory")
private ConnectionFactory factory;
Arquillian as a client
Having tests for the external system representations, is as im-
portant as focusing on application testing from the inside. You
should spend as much time on the interfaces which people
or programs use to interact with your application. Typically
it should be ensured that each application and its execution
path is fully tested. Third parties can interact with the appli-
cation through various interfaces, such as Web Services, EJBs,
or remote via http. If you are taking care of this you have
to consider a lot of things, like object serialization and net-
work connections. In order to test this view onto the environ-
ment Arquillian provides two modes: IN_CONTAINER and
AS_CLIENT. The IN_CONTAINER mode corresponds to
the examples shown above. The AS_CLIENT allows check-
ing the outside view of an application. Running the AS_CLI-
ENT mode is as simple as adding another Annotation to your
In a direct comparison with the fashion IN_CONTAINER the
client tries to fashion as few tasks to perform in the container
and natural to act as a client. The @Deployment method sim-
ply controls the container's lifecycle.
Debugging, and Eclipse Integration
If you don’t like the painful cmd-line maven execution of
your Arquillian tests, you are free to integrate it into your
favorite IDE as long as it is Eclipse or NetBeans or has any
Maven integration at all. Eclipse requires you to use the
m2eclipse plugin. You need to activate the relevant Maven
Markus Eisele is a lead technology consultant working for msg systems
ag in Germany. Markus is a software architect, developer and consultant.
He also writes for German IT magazines. He works daily with customers
and projects dealing with Enterprise Java and other new technologies, on
a variety of platforms using different vendors. His main area of expertise
are Java EE Middleware Servers. You can reach him via or check
his blog at
profile, and you can start using Run As | JUnit Test to run
individual tests from the IDE. NetBeans doesn’t require a
separate plugin. It has Maven support since version 6.8. Here
too, the active Maven Profile needs to be added. The configu-
ration is already done. Debugging basically follows the same
characteristics as with other deployed applications. Test-run-
ner and tests run in a different JVM than the container itself.
Therefore, the debugger has to be attached to the correct
JVM. Details about this can be
found in the container docu-
mentation of your choice.
It’s lots of fun to use Arquil-
lian. There is nothing compar-
able on the market in terms
of seamless container integration. It’s simple enough to use
and not too hard to configure. Simple test cases can be cre-
ated in minutes. Tradeoff is, that it quickly becomes com-
plex. The configuration of the container is only one area. The
more complex your deployments get (e.g. dependent librar-
ies, special classpath configuration) the harder the setup. And
Arquillian is still an Alpha version which is not finished at
the time of writing. Some things simply don’t work at the mo-
ment. If you are running into trouble it could consume your
time very quickly.
To find out where exactly the problem is, you need time
and knowledge. The core of Arquillian doesn’t log too much.
To find a real fault is not easy. But the project is not complete
yet. A couple of features are already announced. In addition
to Method Interceptors the so-called Arquillian Resources
should become available with the next release. That will make
any container-specific objects (such as the initial context) in-
ject able via a generic @ArquillianResource annotation. Sup-
port for other containers is also on the list of things to come.
It will be exciting and worth further observation. The project
is slightly behind schedule and it should come up with the
next development milestone soon.
There is nothing
comparable in terms of seam-
less container integration.

March 2011 18
by S Sangeetha
RESTful Web Services use the methods of HTTP protocol for
the operations they perform. HTTP methods POST, GET,
PUT and DELETE can be mapped to operations like Create,
Read, Update and Delete (CRUD).
RESTful Web Services in Java can be built using JAX-RS
– Java API for RESTful Web Services which is introduced as
part of Java EE 6 Platform and it fully supports REST prin-
JAX-RS – An Introduction
JAX-RS (JSR311) is a Java programming API that is included
as part of the new Java EE 6 Platform. JAX-RS is designed to
make it easy for developing applications in Java using REST
principles / architecture. JAX-RS follows the goals of Java
EE – simplicity and ease of development. JAX-RS API uses
annotations which makes development of web services us-
ing REST architecture simple and easy. Simple POJOs can
be exposed as web resources with the help of annotations,
classes and interfaces provided by JAX-RS API. Since this de-
pends heavily on annotations, JAX-RS requires Java version
5 and above. JAX-RS applications are bundled in a WAR file
similar to any other web application in Java and deployed
on a container that supports Servlet. A Servlet provided by
the vendor is used for routing the requests to the appropriate
web resource. One of the goals of JAX-RS is to make the web
resources deployable across different types of web containers
achieving portability.
Developing RESTful Web Services using JAX-RS
RESTful Web Services in Java can be created with the help
of JAX-RS with any implementation. The classes and inter-
faces used for creating RESTful web services using JAX-RS
are available in the following packages:•••
Resource Class
JAX-RS allows POJOs to expose the functionality as web
services through annotations. According to JAX-RS, a ‘Re-
source’ is a Java class (POJO) which uses JAX-RS annotations
to implement a web resource. Annotation @Path is used on a
Java class to identify that as a Resource class.
public class StockResource {
public String getStockInfo() {
return "This is Stock Information";
This class is packaged as part of a WAR file with an entry
for the Servlet provided by JAX-RS implementation (Jersey
for example). Then the WAR file is deployed in the container
(Glassfish for example) that provides support for JSR 311.
Then the resource is accessed using the normal URI http://
HTTP Method Operation Performed
GET Read a resource
POST Create a resource
PUT Update a resource
DELETE Delete a resource
Building Web Services in Java
The REST Way!
REpresentational State Transfer is an architectural style for accessing information on the web. This is
becoming increasingly popular and an easier way to access services on the web. In the REST architecture style,
information that is available on the server side is considered as resources and these resources can be ac-
cessed in a uniform way using web – Uniform Resource Identifier (URI) and the web protocol, HTTP. Since HTTP
is preferred as the protocol for communication, REST constraints the architecture to client-server architecture
which is stateless in nature. Resources on the web are identified by URIs. Web Services that are created and ac-
cessed using REST principles are called RESTful Web Services.
Table 1: Different
HTTP Methods

March 2011 19
hostname:portnumber/WARfilename/stockquote. This will
result in invocation of this class annotated with @Path an-
notation with a value matching to the corresponding value
of the URI.
Life Cycle of Resource Class
A new instance of the resource class will be created for each
request to that resource. The life cycle of the resource starts
with the creation of object, the constructor is invoked and
then the required dependencies are injected. The appropriate
resource method is invoked and once the response is provi-
ded, the object is made available for garbage collection.
Resource Methods
Resource methods are public methods of a ‘Resource’ class
identified with the request method designator annotation. The
specification provides a clear mapping to the HTTP protocol
and the URI through well defined classes and interfaces. As dis-
cussed earlier, in RESTful web services, the HTTP methods are
mapped to the CRUD (Create, Read, Update and Delete) opera-
tions they perform. Request method designators are annotations
that are used to identify the methods that handle the HTTP re-
quests and JAX-RS defines annotations for HTTP methods like
GET, POST, PUT, DELETE and HEAD. JAX-RS also allows
creating user defined custom request method designators.
The corresponding request method designators are called
depending on the HTTP method request. For example, if the
request is from a HTTP GET request, method annotated with
@GET annotation is automatically invoked and the response
is provided. However for HTTP method requests like HEAD
and OPTIONS, some amount of automation support is pro-
vided. When a HEAD request comes, the method annotated
with @HEAD request method designator is invoked, if there
is no such request method designator, then by default @GET
is invoked without providing any response. However this will
have some impact on the performance. The return value of
the methods with request designator annotations are gene-
rally void, a Java language type or a response object of the
package com.stock;
public class StockResource {
/** Creates a new instance of StockResource */

public StockResource() {
* Retrieves representation of an instance of com.stock.StockResource
* @return an instance of java.lang.String
public String getXml() {
* PUT method for updating or creating an instance of StockResource
* @param content representation for the resource
* @return an HTTP response with content of the updated or created resource.
public void putXml(String content) {
Resource methods can have a set of parameters. Some of these
parameters will have annotations and others will not. The
method parameters can be annotated with one of the follow-
ing annotations:
public String getHtml(@QueryParam("symbol") String stockSymbol) {
StringBuilder str = new StringBuilder(" The price for the Symbol <b>
"+stockSymbol+" </b> is: ");
return str.toString();
When the method is invoked, appropriate parameters are
mapped depending on the semantics of the request. Param-
eters that are not annotated are called as Entity Parameters
whose values are mapped from the request entity body. The
specification does not permit more than one entity parameter
per method.
Annotation Description
@MatrixParam Extracts the value of a URI matrix parameter
@QueryParam Extracts the value of a URI query parameter
@PathParam Extracts the value of a URI template parameter
@CookieParam Extracts the value of a cookie
@HeaderParam Extracts the value of a header
@FormParam Extract the value of a form
@Context Injects an instance of a supported resource
HTTP Method Request Method Designator
Table 2: Dif-
ferent HTTP
Methods Table 3: Annotations

March 2011 20
As discussed earlier, the return value of a resource method
could be void, a response object or any other Java type. For
HTTP requests, to map request entity body to method pa-
rameters MessageBodyReader class provided by JAX-RS API
is used. Similarly, for HTTP response, to map return value
to response entity body, MessageBodyWriter is used. These
classes take care of the conversion between the Java types and
an entity body. Methods that need to return additional type
not part of the standard Java type should return an instance
of Response object. Resource methods can also throw any
checked or unchecked exceptions.
URI Template
As we know, a root resource class is identified using @Path
annotation. The value of the annotation can have a relative
URI path template mentioned between the curly braces {,}
with a reference to the base URI provided by the deployment
context. An URI path template acts as a place holder for rela-
tive path URI. URI path template generally is a String with
zero or more embedded parameters in it. When the values are
applied for the parameters forms a valid URI path.
public class Stock {
In the following example, the Stock resource class is identified
by the relative URI path stock/abc where abc is the value of
the symbol parameter. However ‘{‘ and ‘}’ will not appear in
the URI as it is not valid, it is used just for the sake of specify-
ing the URI template. The value of the symbol parameter can
be retrieved in the method using @PathParam annotation as
the parameter value in part of the URI path. URI template
parameters can optionally have a regular expression.
public class Stock {
public String getStock(@PathParam("symbol") String stockSymbol) {
return " Stock Symbol entered by the user is: <b> "+stockSymbol +" </b> ";
Similarly, the parameter annotation @FormParam will be
helpful to get the information from the form elements in the
public String getStock(@FormParam("symbol") String stockSymbol) {
return "Stock Symbol entered by the user is: <b> "+stockSymbol +" </b> ";
Sub Resources
Apart from the Resource class, methods of a resource class can
also be annotated with @Path annotation. When the methods
are annotated with @Path annotation, the methods are called
as sub resource methods or sub resource locators.
Sub Resource Methods
Methods in a resource class that are annotated with @Path
annotation along with the request method designator an-
notation like @GET, @POST, … are called as Sub Resource
Methods. The sub resource methods will be invoked for a
URI request that is created by concatenating the URI tem-
plate of the method with the URI template of the resource
package com.demo;
public class SayHello {
public SayHello() {
public String hello() {
In the above example, a GET request from the URI /sayHello/
lastname will be handled directly by the hello() sub-resource
method in the SayHello resource class.
Sub Resource Locators
Methods in a resource class that are annotated with @Path
annotation which are used to dynamically identify the object
that will handle the request are called as Sub Resource Loca-
tors. The return value for these methods is generally an object
of resource class that will handle the request. Sub Resource
Locators are similar to normal resource method but cannot
have an entity parameter.
MIME Types supported by JAX-RS for Request and Re-
MIME media types are used to identify the HTTP request
entities and representations. A resource class can produce or
consume any MIME type. Annotations are used to specify
the MIME media type for request and response on a resource
class or a resource method. Annotation @Produces is used
to specify the MIME type for the response (representation
that can be produced by a resource and sent back to the cli-
ent) and @Consumes is used to specify the MIME type for
the request(representation that a resource can accept from

March 2011 21
HTTP request entity or consume the content sent by client).
For specifying simple ‘text/plain’ MIME, @Produces ("text/
plain") and @Consumes ("text/plain") will be used.

public class Hello {
public String sayHello() {
return "Hello, Welcome to the World of REST";
If the MIME type is HTML, then “text/html” is used as the
value for @Produces and @Consumes annotations.

public String getHtml() {
return ("<B><U>Hello, This is demo for REST application");
public void putHtml(String content) {
If the value of the annotation @Produces of a resource method
is not supported by the HTTP request (if it is not part of the
header - Accept in HTTP request), then the resource method
will not be invoked. Similarly if the value of the annotation
@Consumes of a resource method does not match with the
header - Content-Type in HTTP request, the resource method
will not be invoked. If these annotations are not present, then
any of the MIME types (*/*) is supported.
JAX-RS has providers that help in mapping between entities
and associated Java types. These are called as Entity Provid-
ers. The two types of Entity Providers supported by JAX-RS
MessageBodyReader1. is a class that is used to map HTTP
request entity body to method parameters.
MessageBodyWriter2. is a class that is used to map the
return value to the HTTP response entity body.
By default, there are some types automatically supported by
MessageBodyReader and MessageBodyWriter, they are called
as standard types. Following are the standard types:
byte[] – All Media types (*/*)•
java.lang.String – All Media types (*/*)• – All Media types (*/*)• – All Media types (*/*)• – All Media types (*/*)•
javax.activation.DataSource – All Media types (*/*)•
javax.xml.transform.Source – For XML Media types only •
(text/xml, application/xml, application/*+xml)
javax.xml.bind.JAXBElement and application supplied •
JAXB classes – For XML Media types only (text/xml, ap-
plication/xml, application/*+xml)
MultivaluedMap<String, String> - Form Content •
StreamingOutput - All Media types (*/*), only for Mes-•
If the application chooses not to use any of the standard types,
a method can return an object of Response which is built us-
ing ResponseBuilder class.
JAX-RS allows one to write custom mapping from/to rep-
resentation and entity body. Such classes which would pro-
vide custom mapping are annotated with @Provider and
implements the MessageBodyReader or MessageBodyWriter
classes. Entity Provider is also a resource class annotated
with @Provider annotation and implements the JAX-RS API.
@Provider annotation can be used along with @Produces and
@Consumes annotations as demonstrated below:
public void createStock(Stock stock ) {
public class StockProvider implements MessageBodyWriter<Stock> {
public class StProvider implements MessageBodyReader<St> {
The value of the stock parameter will be mapped from the
request entity body using the StProvider class. Similarly when
a mapping has to be done from the representation to the re-
sponse entity body, StockProvider class will be used.
To get a handle to the deployment environment and the indi-
vidual request, JAX-RS provides different types of Context to
resource class as well as providers. Annotation @Context is
used to get the Java types related to request or response. The
different types of Context provided by JAX-RS are:
UriInfo• provides information about the components of a
request URI. Information about both static and dynamic
request URI is provided. However the information pro-

March 2011 22
vided is valid per request only. An instance of UriInfo
is injected to the field of a class or to the parameter of a
method using @Context annotation.

public String getHtml(@Context UriInfo uri) {
MultivaluedMap<String, String> map = uri.getQueryParameters();
Set<String> set = map.keySet();
Iterator<String> iterator = set.iterator();
String content = "";
while (iterator.hasNext()) {
content = content + map.get( + "*******";
return content;
In the above example, Context is used to inject an object •
of type UriInfo as the method parameter whose methods
provide access to request URI information.
Headers• : HttpHeaders provide information about request
header. Generally the information is provided in the form
of a map. An instance of HttpHeader is injected to the field
of a class or to the parameter of a method using @Context
annotation. The methods of HttpHeaders provide access
to request information.
public String getHeaders(@Context HttpHeaders headers) {
Request• : Request interface is provided for content negotia-
tion and evaluating certain preconditions. An instance of
request is injected to the field of a class or to the parameter
of a method using @Context annotation.
Security• : SecurityContext provides information about the
security context of the request. With SecurityContext, in-
formation about the user, group, and roles can be retrieved
from the request and it also helps in identifying the authen-
tication scheme used and whether the request is using https
or not. An instance of SecurityContext is injected to the field
of a class or to the parameter of a method using @Con text
All the above contexts mentioned are available to all con-
tainers where JAX-RS root resource class or a provider is de-
ployed. Apart from these standard ones, @Context annotation
can be used to specify container specific resources too. For
example, in Servlet Container based environment, @Context
can be used to inject dependencies of type HttpServletRequest,
HttpServletResponse, ServletConfig and ServletContext.
Annotation Description
@GET Request method designator annotation. Specifies that the annotated method handles HTTP GET requests.
@POST Request method designator annotation. Specifies that the annotated method handles HTTP POST requests.
@PUT Request method designator annotation. Specifies that the annotated method handles HTTP PUT requests.
@DELETE Request method designator annotation. Specifies that the annotated method handles HTTP DELETE requests.
@HEAD Request method designator annotation. Specifies that the annotated method handles HTTP HEAD requests.
@Path Specifies a relative path for a resource. When used on a class this annotation identifies that class as a root resource.
When used on a method this annotation identifies a sub-resource method or locator.
@Consumes Specifies a list of media types that can be consumed.
@Produces Specifies a list of media types that can be produced.
@PathParam Specifies that the value of a method parameter, class field, or bean property is to be extracted from the request URI
path. The value of the annotation identifies the name of a URI template parameter.
@QueryParam Specifies that the value of a method parameter, class field, or bean property is to be extracted from a URI query pa -
rameter. The value of the annotation identifies the name of a query parameter.
@FormParam Specifies that the value of a method parameter is to be extracted from a form parameter in a request entity body. The
value of the annotation identifies the name of a form parameter.
@MatrixParam Specifies that the value of a method parameter, class field, or bean property is to be extracted from a URI matrix pa -
rameter. The value of the annotation identifies the name of a matrix parameter.
@CookieParam Specifies that the value of a method parameter, class field, or bean property is to be extracted from a HTTP cookie.
The value of the annotation identifies the name of the cookie.
@HeaderParam Specifies that the value of a method parameter, class field, or bean property is to be extracted from a HTTP header.
The value of the annotation identifies the name of a HTTP header.
@DefaultValue Specifies a default value for a field, property or method parameter annotated with @QueryParam, @MatrixParam, @
CookieParam, @FormParam or @HeaderParam. The specified value will be used if the corresponding query or matrix
parameter is not present in the request URI, if the corresponding form parameter is not in the request entity body, or
if the corresponding HTTP header is not included in the request.
@Context Identifies an injection target for one of the context types.
@Provider Specifies that the annotated class implements MessageBodyReader or MessageBodyWriter to provide mapping from/
to representation to request/response entity body.
Table 4:

List of Annotations defined as part of JAX-RS

March 2011 23
Frameworks supporting JAX-RS
There are several open source frameworks supporting JAX-RS
specification. All of them provide good support for standard
server-side JAX-RS APIs and proprietary client APIs. Each
one has its own merits and demerits and are used appropri-
ately. Some of them are discussed here:
Jersey• : JAX-RS applications can be developed in Java us-
ing Jersey – an open source production quality reference
implementation of JAX-RS from Sun/Oracle. Jersey imple-
ments all the APIs and provides annotations for easy and
quick creation of web services in Java using REST style.
Apart from the defined set of annotations and features
defined by JAX-RS, Jersey provides a lot of additional
features with its own APIs like Jersey Client API. Jersey is
available separately for download as well as coming bun-
dled with NetBeans 6.5 along with Glassfish V3 Prelude.
Jersey is built completely using Maven. Jersey provides a
good integration with frameworks like Spring MVC.
RESTEasy• is a JBoss framework for developing RESTful
web services which is fully complaint with the JAX-RS
specification. RESTEasy has been designed to run in any
Servlet Container, but it is preferred with JBoss Applica-
tion Server because of its tight integration. An important
benefit of RESTEasy is apart from providing complete
support for JAX-RS server side APIs; it comes with a pow-
erful RESTEasy JAX-RS Client framework which allows
mapping of HTTP requests to remote servers and interface
proxies. It provides a good integration with other frame-
works like Google Guice, Spring and Spring MVC. It is
highly preferred when there is a need for integration with
Apache CXF• is an open source services framework which
helps in building web services in Java using both JAX-WS
and JAX-RS standards. It supports a variety of protocols
ranging from SOAP, REST HTTP and CORBA to trans-
ports like JMS, JBI etc. Apache CXF provides a good
integration with Spring and JAX-WS services and usage of
Maven makes the integration easier. The benefit of Apache
CXF is that it provides a pluggable architecture which
supports both XML and non XML bindings with any
Apache Wink• is an open source simple yet powerful
framework for building RESTful web services in Java.
This framework has been exclusively designed for REST
support, unlike Apache CXF which supports both SOAP
based and REST based web services. Apache Wink comes
with two modules:
a) Wink Server - is JAX-RS complaint server side API. •
Apart from the standard implementation it provides addi-
tional facilities for RESTful web services
b) Wink Client – is Java based client framework which •
helps in consuming RESTful web services. This is extended
from HttpURLConnection class available in pack-
Restlet• is a leading (most preferred and matured) open
source RESTful web framework for Java which is not
JAX-RS complaint. Its simplicity and scalability helps to
blend server side web applications, web clients and web
services into a uniform web application. There are exten-
sions available to integrate with JAX-RS. The benefit
of Restlet comes from its unique Java API available for
applications built using different platforms like Java SE,
Java EE, Google App Engine, Android and Google Web
JAX-RS provides a good support for building RESTful web
services in Java. It is simple and provides an easy approach
for exposing POJO as a service and supports different types of
representations. JCP has already started working on the next
version of JAX-RS – JAX-RS 2.0 where the focus is going to
be more on the need for a standardized Client API. Discus-
sions are in place to introduce support for hypermedia, inte-
grate matured open source client frameworks from Apache
and introduce architecture – MVC compatible with JAX-RS
programming model – JAX-RS MVC. All these makes JAX-
RS a more promising technology/standard for RESTful Web
services in Java.
The author would like to sincerely thank Mr. Subrahmanya
SV, VP - ECOM Research group for all his encouragements,
support and constant motivation. Special thanks to Mr. Nitin
KL for quickly reviewing this from the technology perspec-
[1] JAX-RS Specification:
[2] JAX-RS Article in
[3] Jersey:
[4] Restlet:
[5] Restlet:
[6] RESTEasy:
[7] Apache CXF:
[8] Apache Wink:
S Sangeetha is a Senior Technical Architect at the E-Commerce Research
Labs at Infosys Technologies. She has over 12 years of experience in ar-
chitecture, design and development of enterprise Java applications. She
is also involved in enhancing the technical skills of Architects at Infosys.
She has co-authored a book on ‘J2EE Architecture’ and also has written
numerous articles on Java for various online Java forums like JavaWorld,, and Her current areas of research are ROA (using Java),
Cloud Computing (using Java) and Android.
Web Profile

March 2011 24
by Gurkan Erdogdu
Java Enterprise Edition (Java EE or formerly known as Java
2 Platform, Enterprise Edition or J2EE) is an enterprise plat-
form for developing highly available, secure, reliable and
scalable business applications. The Java EE platform has un-
dergone several changes from its first release version J2EE 1.2
(December 12, 1999) [1]. The latest version of the specifica-
tion is Java Platform, Enterprise Edition (Java EE) Specifica-
tion, v6 [2]. In this white paper, Java EE and Java Platform,
Enterprise Edition (Java EE) Specification, v6 will be used
The Java EE Specification defines “Java EE Profiles”. A Java
EE profile (simply “a profile”) represents a configuration of
the platform suited to a particular class of applications [2].
“Java EE Web Profile” is a “Java EE Profile” that consists of
several independent specifications related to web application
Siwpas is an open source (LGPL [3] license) application
server based on Apache Software Foundation(ASF) [4] Java
EE projects. The latest version of Siwpas is “CR-5” and the
first commerical quality version is planned to be released at
the end of March.
This white paper has been organized as follows:
Java EE
Web Profile section gives some details about Web Profile.
The next section talks about the ASF and its Java EE based
projects. The MechSoft Siwpas section explains the compo-
nents of Siwpas and its compatibility regarding the Web Pro-
file specification. This white paper ends with Summary and
References sections.
The Java EE 6 Web Profile specification defines the Java EE Web Profile (“Web Profile”), a profile of the Java
Platform, Enterprise Edition specifically targeted at web applications. Siwpas, (Simple Web Profile Application
Server) is an application server aimed at implementing the Java EE Web Profile specification. In this article, the
components of Siwpas, its current state and the level of compatibility regarding the Web Profile Specification will
be discussed.
Simple Web Profile Application Server
Web Profile

March 2011 25
Java EE 6 Web Profile
The Java EE Platform Specification consists of a huge number
of specifications (APIs). For platform provider companies, it
is not easy to develop a fully compliant Java EE Platform that
implements all of the required components of the Java EE
Platform Specification. For application developers, it is not
necessary to use all of the Java EE APIs for developing enter-
prise applications. Because of these observations, the Java EE
Expert Group (EG) has defined Profiles in Java EE v6 and the
first standard profile has been defined, “Java Platform, Enter-
prise Edition 6 (Java EE 6) Web Profile Specification”.
The Web Profile is aimed at developers of modern web appli-
cations. Aiming “modern” web applications then implies offer-
ing a reasonably complete stack, composed of standard APIs,
and out-of-the-box capability to address the needs of a large
class of web applications. Furthermore, this stack should be
easy to grow, so as to address any remaining developer needs
[5]. The Web Profile stack has consisted of several technolo-
gies. Table 1 shows the Web Profile required components.
Java web applications are generally written as 3-tiers. These
tiers are “Web Tier”, “Business Tier ” and “Persistence Tier”.
Each of the Web Profile component sits on these tiers as fol-
Web Tier: • Servlet, Java Server Pages, Debugging Support
for Other Languages, Standard Tag Library for JSP, Java
Server Faces
Business Tier: • Enterprise Java Beans Lite, Persistence Tier,
Java Persistence API
Some of the components are used for general functionality.
These components and their functions are as follows:
Common Annotations for the Java Platform: • This JSR will
develop annotations for common semantic concepts in the
J2SE and J2EE platforms that apply across a variety of
individual technologies [6]
Java Transaction API: • Transaction management and de-
Bean Validation: • Management of business constraints
Managed Beans: • Common lifecycle of managed beans
Interceptors: • Aspect Oriented Programming (AOP) opera-
Context and Dependency Injection for Java EE: • Depend-
ency injection for Java EE
Dependency Injection for Java: • Dependency injection for
standard Java
As we know, the Java EE Web Profile is a subset of the Java
EE Platform specification. Lots of Java EE Platform speci-
fication required components are not contained in the Java
EE Web Profile. For exampe, these are components that not
defined for the Java EE Web Profile specification: JAX-WS,
PIC, JACC, JCA, JavaMail, JSR77, JSR88.
Finally, it is worth remembering that Web Profile products
are allowed to ship with additional technologies, to the re-
quired ones. It is conceivable that products will offer choices
during installation between different configurations, some
richer in extensions, or even allow for complete customiza-
tion beyond the required core (“à la carte” installation) [5].
Apache EE Projects
The Apache Software Foundation provides organizational, le-
gal, and financial support for a broad range of open source
software projects. The Foundation provides an established
framework for intellectual property and financial contributions
that simultaneously limits the contributors' potential legal ex-
posure. Through a collaborative and meritocratic development
process, Apache projects deliver enterprise-grade, freely avail-
able software products that attract large communities of users.
The pragmatic Apache License makes it easy for all users, com-
mercial and individual, to deploy Apache products [4].
In Siwpas, we use ASF Java EE projects for satisfying Java EE
Web Profile required components. These projects and their cor-
respondence to Web Profile components are shown below.
With the exception of the Apache OpenEJB [7] project,
each of the above ASF projects is standalone compatible with
TCK (Technology Compatibility Kit). In other words, Tom-
cat 7 [8], MyFaces 2 [9], OpenWebBeans [10], Bean Valida-
tion [11] and OpenJPA [12] are TCK compliant projects on
their own.
ASF Project Name Web Profile Requirement
Apache Tomcat 7 Servlet, JSP,EL and related components
Apache MyFaces 2 Java Server Faces component
Apache OpenEJB EJB 3.1 Lite and related components
Apache OpenWebBeans Dependency Injection components
Apache Bean Validation Validation component
Apache OpenJPA Persistence API component
Table 2: ASF Java EE Projects
Specification Name Version
Servlet 3.0
Java Server Pages 2.2
Expression Language 2.2
Debugging Support for Other Languages 1.0
Standard Tag Library for JSP 1.2
Java Server Faces 2.0
Common Annotations for the Java Platform 1.0
Enterprise Java Beans Lite 3.1
Java Transaction API 1.1
Java Persistence API 2.0
Bean Validation 1.0
Managed Beans 1.0
Interceptors 1.1
Context and Dependency Injection for Java EE 1.0
Dependency Injection for Java 1.0
Table 1: Web Profile Required Components
Web Profile

March 2011 26
EJB Lite container in Siwpas is a subset of the Apache
OpenEJB project and is called a Siwpas EJB Lite Container.
Currently Siwpas EJB Lite Container has not been tested with
EJB 3 Lite TCK.
Mechsoft Siwpas Application Server
Siwpas [13] (pronounced as Simple Web Profile Application
Server) is a lightweight Java application server platform for
developing enterprise quality Java EE web applications. Si-
wpas integrates above ASF Java EE based projects for pro-
viding a Java EE Web Profile compatible runtime platform
(Figure 1).
Integrating different sets of projects on the same runtime is
not an easy task . MechSoft [14] has been writing an integra-
tion layer component to integrate Apache
Tomcat 7 runtime with Siwpas EJB 3.1
Lite container runtime. Moreover, a cool
web based management console for man-
aging all aspects of Siwpas has been writ-
ten. The Siwpas management console will
be released with the 1.0.0 GA release of
Siwpas and provides the following man-
agement operations.
Overall realtime view of the current •
running system: CPU, Memory, OS,
JVM Heap size
Server configuration•
Applications view and deployment •
JMX, JNDI and ClassLoader views•
Web and EJB Container runtime status•
And more...•
Figure 2 shows a sample snapshot view
from Siwpas console “Applications View” page.
Why Siwpas, why another server?
Before Siwpas was developed, Apache OpenWebBeans (im-
plementation of Context and Dependency Injection for Java
EE Specification) and Apache OpenEJB were used in some
commercial projects, but we wanted to use a lightweight ap-
plication server in a cloud infrastructure. At that time there
was no open source application server for using the Open-
WebBeans and the OpenEJB in a lightweight server runtime.
Therefore it was decided to implement a lightweight server
based on Apache Tomcat 7.
Nowadays, a huge number of application developers and
enterprise companies want to use lightweight application
Figure 2: Siwpas console
Figure 1: Siwpas Runtime View
Web Profile

March 2011 27
servers for deploying and running their web applications.
They do not want to use heavyweight Java EE Servers that
are fully compliant with Java EE Specifications. They want
to manage lightweight, cloud environment friendly servers.
Nonetheless, they also need more technology stack for im-
plementing their web based applications, such as “JPA, JSF,
JTA , EJB etc.” Moreover, most of them deploy their critical
enterprise web applications into the Apache Tomcat in their
production systems.
Siwpas is aimed at providing a lightweight application serv-
er runtime based on Apache Tomcat 7 . It also fills web ap-
plications technology requirements via ASF Java EE projects.
In summary, Siwpas translates Apache Tomcat 7 into a more
powerful enterprise web server.
The benefits of using Siwpas can be listed as follows:
It has a lightweight but powerful runtime environment•
It is based on the very-well known JSP & Servlet Contain-•
er, Apache Tomcat 7
It consists of Web Profile Specification technology stack•
It consists of powerful, commerical quality ASF Java EE •
It is an open source project•
It is supported by MechSoft (7x24 enterprise support)•
It is light and will be always light•
It has a very cool JSF based administration console•
Web Profile Compliance
Currently Siwpas does not claim compliance with Java EE
Web Profile Specification because it has not been tested with
Java EE Web Profile TCK. This does not mean that Siwpas
will never be certified as a Web Profile Compliance applica-
tion server. In order to test Siwpas with Java EE Web Profile
TCK, MechSoft has to be a licensee of Oracle and we are
discussing a reasonable way to obtain this TCK. As men-
tioned in the above paragraphs, with the exception of Apache
Standard Sup-
Products Update √ √
Security Pathes √ √
Hot Fixes - √
Service Hours 5x8 (Business
Number of Incidents 12 per year Unlimited
Number of Contracts 1 3
Web Based Support √ √
Phone Support - √
Max Web Response Time 2 Business Day 1 Business Day
Max Phone Response Time - 2-4 hours
Extra Features
Development Consultancy Per Hours Per Hours
Custom Product Feature - Per Feature
Gurkan Erdogdu is the Chief Technology Officer (CTO) of MechSoft Me-
chanical and Software Solutions. He is the founder and PMC of the Apache
OpenWebBeans Project. He has been working with Java and Java EE tech-
nologies since 1999. He is a member of Apache Software Foundation
and Open Web Foundation. He also runs training sessions on Java and
Java EE technologies. He lives in Ankara/Turkey with his wife. He can be reached at
[1] J2EE 1.2 Home Page:
[2] Java Platform, Enterprise Edition (Java EE) Specification, v6
[3] LGPL License Home Page:
[4] Apache Software Foundation:
[5] Java Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification
[6] Common Annotations:
[7] Apache OpenEJB:
[8] Apache Tomcat 7:
[9] Apache MyFaces:
[10] Apache OpenWebBeans:
[11] Apache Bean Validation:
[12] Apache OpenJPA:
[13] Siwpas Page:
[14] MechSoft Home Page:
Table 2: Different versions of Siwaps
OpenEJB, ASF Java EE projects are TCK compliant with their
respective specificiations.
Siwpas Editions
There are two different editions of Siwpas: Community Edi-
tion and Enterprise Edition. The table below shows differ-
ences between each edition.
The Java EE Web Profile Specification is the first standard
profile specification in the Java EE Profiles that is explained
in the Java EE Platform Specification. Instead of using full
profile compatible Java EE servers, developers are now able
to use more lightweight server runtimes for developing their
Java based web applications. This does not mean that full
profile application servers such as Apache Geronimo will be
useless. Some enterprise applications still need to use other
cool features of the Java EE full profile, such as Remote EJB
Invocation, Asynchronous Message Processing via JMS,
CORBA Integration etc. In an upcoming version of the Java
EE platform, a number of more specific profiles can be seen.
Siwpas is a lightweight web application server based on the
ASF Java EE projects. It provides Java EE Web Profile compo-
nents with a powerful web based administration console. It is
one of the lightweight application servers to implement Java
EE Web Profile Specification.