GlassFish v3, CDI, Maven, Eclipse

I am disaffected with NetBeans. It looks fancy, but I still can't get back the love I had using the 3.x version :) Seems as if I am converted to an Eclipse lover.
This was the point where I started to try getting CDI examples to work with GlassFish v3, CDI/Weld, Maven and Eclipse.
For those of you, haven't made it. Here is the how-to (I am using versions with the numbers in brackets):

1) Get:
- Maven (2.2.1)
- Eclipse (3.6M2)
- GlassFish (v3 build 74.2)

2) Create a maven project using:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=cditests -DarchetypeArtifactId=maven-archetype-webapp


3) Add a my-webapp\src\main\java folder to it
4) Add the following dependencies to the my-webapp\pom.xml

<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<scope>provided</scope>
<version>1</version>
</dependency>

<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<scope>provided</scope>
<version>1.0</version>
</dependency>

<dependency>
<groupId>javax.annotation</groupId>
<artifactId>jsr250-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>


5) Add an empty file named beans.xml to my-webapp\src\main\webapp\WEB-INF
6) run mvn eclipse:eclipse for making this an eclipse based project
7) add your code
8) run mvn clean install (compile / package)
9) deploy it to your GlassFish domain
10) think about enhancing this with JSF 2.0 ;)

JSR-299 CDI portable extensions

One of my fav features of the new CDI spec is the ability to integrate custom extensions. The portable extensions spi is the place to start over with it.
You can find some examples of portable extensions in gavins blog. The latest weld reference documentation (weld-reference.pdf, 867 KiB, application/pdf) contains a chapter (16) with more details about the extension spi.

CDI is intended to be a foundation for frameworks, extensions and integration with other technologies. Therefore,
CDI exposes a set of SPIs for the use of developers of portable extensions to CDI.

Getting started is straight forward. (I was using NetBeans 6.8 with this example)
Add a webproject and a separate java library project. Push whatever is needed to your webproject and don't forget to put an empty beans.xml in your WEB-INF/ folder.
Now, start writing your extension.

1) Create a java class
that implements the marker interface javax.enterprise.inject.spi.Extension


public class MyExtension implements Extension {
//...
}

2) Register your extension
as a provider by creating a folder named META-INF/services/ in your java library project and putt a file named javax.enterprise.inject.spi.Extension in it. This file has to contain the full qualified name of your extension class (in my case net.eisele.cdi.extensions.MyExtension))

3) Implement the extension logic.
Basically extensions listen to events fired by the CDI container and are able to modify the containers metamodel. The events fired are one or all of the following:
javax.enterprise.inject.spi.BeforeBeanDiscovery
javax.enterprise.inject.spi.ProcessAnnotatedType
javax.enterprise.inject.spi.ProcessInjectionTarget and ProcessProducer
javax.enterprise.inject.spi.ProcessBean and ProcessObserverMethod
javax.enterprise.inject.spi.AfterBeanDiscovery
javax.enterprise.inject.spi.AfterDeploymentValidation

You have to add your business methods and declare an @Observes for every event you are willing to catch. Example:

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bbd) {
log.info("Begin the scanning process");
}


4) You can have a BeanManager
injected to your methods, too.

public void getBeanManager(@Observes BeanManager bm)

The nerve center for extending CDI is the BeanManager object. The BeanManager interface let you obtain beans, interceptors, decorators, observers and contexts programmatically.

5) You can inject your new extension
even it is not really a bean.

@Inject
MyExtension ext;

or

@Inject
MyBean(MyExtension myExtension) {
myExtension.doSomething();
}


If you deploy your app to GlassFish v3 you see something like this in your logfile:

INFO: Begin the scanning process

That was it. You got your first CDI extension up and running.

JSR-299 CDI Interceptors

Playing around with Java EE 6 these days, I came across some new features, I will blog about. Today I just want to give a short introduction to the enhancements made to javax.interceptor by the CDI.

Interceptor functionality is allready defined by the Java Interceptors specification. CDI enhances this with a more sophisticated, annotation-based approach for binding interceptors to beans. Only four stepts to get to your new CDI interceptor.

1) Write the interceptor binding:

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


2) Write the interceptor:

@LogTime
@Interceptor
public class LoggingInterceptor {

@AroundInvoke
public Object logExecutionTime(InvocationContext ic) throws Exception {
long start = System.currentTimeMillis();
try {
return ic.proceed();
} catch (Exception e) {
throw e;
} finally {
long time = System.currentTimeMillis() - start;
String method = ic.getClass().getName();
Logger.getLogger(
LoggingInterceptor.class.getName())
.log(Level.INFO, "*** Invocation of "
+ method + " took " + time + "ms");
}
}
}

3) Declare the interceptor in beans.xml:
<interceptors>
<class>cdi.LoggingInterceptor</class>
</interceptors>

4) Use the interceptor in your code:

//...
@LogTime
public String getText() {
//..
}


That is all. Have fun.

Java EE 6 Specification summary - Zoom Text

Having the final Java EE 6 in place it is time for a nice presentation of all included technologies. Here you are. This is done with a little help of the "ZoomText Tool" provided by Timo Elliott. Navigate and have fun. Java EE 6 includes 38 JSRs.

Breaking news: Java EE 6 is done!

As posted 30 minutes ago by Roberto, the JEE 6 spec is finaly done!

Breaking news: Java EE 6 is done! The final approval ballot closed 9 minutes ago.
http://jcp.org/en/jsr/results?id=5025
(source: http://twitter.com/robc2/status/6229390753)

Intel and SAP abstained from the vote. SpringSource did not vote at all.
The Apache Software Foundation voted with no. All others voted yes. Therefore the Executive Committee for SE/EE has approved the final approval ballot.

As usual, there are many complaints about the licensing model (missing "full license terms") . This is also the base for the ASF vote.

On 2009-11-30 Apache Software Foundation voted No with the following comment:
The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to lead other JSRs until the above matter is resolved.

This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted "yes".

IBM complained about the newest JSRs included very late into the umbrella specification.

With the exception of the JSR 330 and JSR 299 injection support defined by the EE 6 platform, we believe that this new specification brings value to the industry. We remain concerned that the injection support defined by the platform will create unnecessary difficulties for the community. IBM will continue to support both expert groups in the development of a single integrated and extensible injection programming model.

JEE complexity, documentation, pruning - some analyses and thoughts

J2EE applications can be rapidly deployed and easily enhanced as the enterprise responds to competitive pressures.
(Source: Sun Microsystems Inc.: J2EE Specification)

I am working with JEE6 these days. Try to design some new tech-workshops, sessions and lessons to bring others up to speed with this. During my research I cam across an old slide which talks about total complexity (in number of specification pages). Up to today it only covered J2EE 1.0 until J2EE1.4. But I needed to know more about the actual specifications JEE5 and JEE6. Ok. It was time to browser the jcp website and look out for the details.
The result was unexpected. After having seen so many people complaining about the complexity/size of the J2EE if was finally heard by the Specification Leads and the JEE5 was launched with a slightly different goal than the J2EE specifications before:

The focus of Java EE 5 is ease of development. To simplify the development process for programmers just starting with Java EE, or developing small to medium applications, we’ve made extensive use of Java language annotations that were introduced by J2SE 5.0.
(Source: Sun Microsystems Inc.: JEE5 Specification)

But as you can see, compared to the other versions it is the most complex one regarding to the total number of specification pages. Seems as if the fundamental work for simplyfing the platform itself comes to fruition with JEE6 finally.



The graph itself is reduced to the core and well known APIs. This is a little more than half of the complete platform documentation for JEE6. The complete documentation consists of about 6300 pages (some release notes are not considered with this number).

What else is to mention:
- You see the JSF specification comming in with JEE5. About 450 pages of specification, that were added. Slightly reduced to 400 with JEE6.
- The size of the umbrella specifications was reduced. JEE5 (JSR-244) has about 80 pages of specification more than JEE6 (JSR-316).
- Both JSP versions does not include the Expression Language parts. This would add another 122 pages of specification. JSTL (272 pages) is also not part of this number.

One of the major goals of industry standards is the backward compability. This could be seen in the chart, too. As more and more specifications come in, the old ones still are not beeing dropped even if they are considered as not beeing state of the art anymore. A good examples of this is CMP. Removing the dead parts of APIs, outdated features and not well supported parts is something that will have more attention in the future. The JEE6 already introduced a concept for getting rid of this ballast, called prunning. Based on the community votings, some APIs will disappear from JEE7.

Mike Lehmann on #Weblogic, #JEE6 and Open Standards - #OOW09 Followup

One of my personal highlights at Oracle OpenWorld 2009 was the OTN techcast series. Livestreaming from the OTN lounge Justin brought up some very interesting guests to talk to. I got the chance to ask some questsions during the session with Mike Lehmann. Mike is the Senior Director of Product Management, Fusion Middleware Oracle Weblogic Server and Java Plattform.
See the complete techcast here. I am asking some live questions during the last five minutes.



The whole session only last a quarter of an hour. Therefore some questions still were unanswered. I asked Mike to kindly answer them by email afterwards. That is, what he did. A big "Thank you for doing that!" goes out to Mike!

AppSrvs have become some kind of comodity these days. What do you believe are the true differentiators for weblogic server?

One of the key benefits of adopting a standard like Java EE is it levels the playing field but there continues even in the core Java server space to be quite a large number of unique differentiators just for the core application server. I will outline examples of these below. We also have seen that the architectural styles and approaches that our community is using to build applications has changed over the years and we have adopted our server infrastructure offering to address these challenges our customers are facing with a new model we call the Application Grid which we think ups the ante on perceived commoditization and potentially redefines what customers expect in an application infrastructure.

On the Java EE side, once one gets beyond the API conformance, you typically see application servers like WebLogic differentating in a number of areas. Ones that are key to WebLogic Server include capabilities like - I have chosen a few representative ones rather than an end to end list:

Development Model

Capabilities like FastSwap which enables customers to replace Java classes (add methods, fields etc) without having to go through a redeployment or bounce of the server. It is an example of a server side capability above and beyond what the JDK proper offers in this space.

- Capabilities like Shared Libraries and Filtering Classloader support that enable developers to include multiple versions of common jars within the infrastructure without impacting the runtime (e.g. xml parsers v1 and v2 or different versions of logging infrastructure or different versions of popular frameworks)

Operations Model

WebLogic Diagnostics Framework - most application servers have some sort of ability to see stack traces or see baseline metrics when executing but the ability to formally set SLA's on the infrastructure and when they are breached dump out sophisticated diagnostics images is not common at all. Certainly it is unknown or limited in open source.

Consistent and deep scripting infrastructure - WLST in WLS - This seems like such a simple requirement but ironically as you probably well know is not a capability that exists in open source or typically in very primitive fashion. WLS's scripting and automation infrastructure is extremely rich and key to what customers achieve remarkably low operational costs on WebLogic compared to writing and invent equivalents on other platforms.

Runtime Model
Capabilities like side by side deployment - the ability to deploy a new version of an application without impacting existing users on a single JVM. Not requiring complex cluster dances to enable customers to transition to the new version of the application.

Thread management with Workload Manager - most other appliccation servers are very primitive here and it is an art versus a more deterministic well understood exercise as it is within WebLogic Server.

Messaging infrastruture - here beyond the basic JMS you see in most servers, WebLogic takes messaging out of the box within a Java EE server to another level not requiring customers to buy separate JMS infrastructure because of the richness we have here. We are remarkably succcessful in the JMS side and frankly it is not only highly differentiated for our standalone messaging customers where we compete against pure play messaging vendors but also to our huge SOA install base who depend on it for capabilities such as the Oracle Service Bus and our BPM solution.

High Availability

Capabilities like Whole Server Migration and Service migration - capabilities that many other servers leave to the imagination of the adminstrator.

These are some very simple examples but represent that even in so called commodity infrastructure there is in fact a long list of features that do result in significant value add to customers choosing application servers and frankly we believe significant operational, development and administrative cost savings that simply can not be achieved by competitive solutions.

Now we have also worked on adapting to how we see our customers deploying our infrastructure. In particular with this concept called the Application Grid. We define the Application Grid as: "The application grid approach to middleware infrastructure allows a set of applications to easily react to peaks and valleys in demand and adjusts capacity to improve overall performance by optimizing shared resources. It also allows for rapid application deployment and automated adjustments—enabling greater efficiency, competitiveness, and simplification in your IT environment.' Product wise in the Java space, the Application Grid consists of three major runtime products - Oracle WebLogic Server for mission critical Java EE applications, Oracle Coherence as an in memory data grid and JRockit for high performance low latency JVM infrastructure and in the management space Oracle Enterprise Manager.

The simple way of thinking about the Application Grid is very much like RAC in the Oracle Database. RAC is all about better quality of service on commodity hardware - improving scalability, reliability and availability on large clusters of commodity hardware. This has clearly been a sensibility in the middle tier for many years but frankly most application server vendors have done little to tackle it square on to make it an out of the box feature. We have done this in several areas within the Application Grid. Two examples that are top of mind are around state management and operational management. In the area of state management as you saw from OpenWorld we talk alot about scaling infrastructure using Coherence but it is not enough simply add Coherence to your infrastructure, it has to be seamlessly integrated with your applications - in our world frequently running on WebLogic Server. In Fusion Middleware 11g we did exactly this - we introduced seamless integration for statement management via Coherence integration with WebLogic Server. We have seen results that frankly extremely compelling and validate our vision of the Application Grid such as customers achieve several fold increase in capacity off of existing hardware and others being able to scale out dramatically further than they were prior to the introduction of Coherence into their infrastructure.

On the management side our investment in Enterprise Manager as an overall strategic management platform for WebLogic and Fusion Middleware has been a great win fairly significantly differentiating us from other vendors. Our ability to not just manage single instances of WebLogic Server, not just single domains of WebLogic Server but manage across multiple datacenters we think plays to where many of our customers are going where issues like Active Passive and Active Active topologies across data centers are actively being used and evaluated by our customers. A management solution that covers that breadth is extremely important to achieve success in these topologies and is a key value proposition that underlies our vision of the Application Grid.

So a long answer to a simple question - yes, there remain a long and compelling list of differentiators for WebLogic Server proper. The evolution of what most customers are now facing in the infrastructure frankly changes the game to not just an application server versus application server but a larger scale application infrastructure problem domain where we think architectural approaches like the Application Grid redefine expectations of customers entirely.

Looking out to GF v3, comming out with a first JEE6 release in the beginning of december. What do you advice erly adopting JEE6 customers to do? Switch? Wait? For how long?

We will have to of course wait to see when Java EE 6 officially released and as you know GlassFish is the reference implementation of it. Currently the public schedules indicate that it will be released before the end of this year and we are optimistic that Sun and the JCP can achieve these goals and thus enable the rest of the industry to also update their products to be Java EE 6 compatible.

As you may know Oracle already has made big strides in WebLogic Server 10g R3 and the recent WebLogic Server 11g to areas that Java EE 6 formalizes - the lighter weight Web profile. In WebLogic Server 10g R3 we introduced the ability to install a lighter weight core WebLogic Server as an option- as low as ~170M - and the ability to turn off containers like JMS and EJB through a single command line option. You may also be aware that Oracle itself is the provider of the JPA reference implementation EclipseLink which we ship in our commercial offering fully supported. Both of these are big areas of Java EE 6 that customers of WebLogic can use today in production environments well ahead of Java EE 6 being available to achieve some of the productivity benefits that many expect to see with Java EE 6.

Of course this approach does not mean WebLogic Server is already Java EE 6 compatible. We are both active participants in the standards community closing down Java EE 6 and actively working on our next major release where we hope to achieve Java EE 6 compatibility assuming the standard comes through the standards process in a time fashion. So what do I recommend to people today? Get involved by looking what is in Java EE 6 and for an understanding of where the experience will be, take a look at what you already get with production products like WebLogic Server 11g today that are remarkably close to some of the key characteristics customers are expecting in Java EE 6.

I saw a GlassFish presentation at Oracle Develop and was impressed by the startup times. What about further reducing development round trip time for WLS developers? Do you plan to optimize this further with the next releases?

We are always very actively engaged in increasing all the performance metrics of WebLogic Server and have strict release criteria that gate our release cycles. We actively engage in both public benchmarks like the SPECjAppServer2004 benchmark - where recently at OpenWorld we once again announced a world record result on single node infrastructure - but also on key metrics like startup time, deployment time, console access time, runtime performance metrics and many more. Already our effort on a lighter weight footprint WebLogic Server does provide significant improvements for developers and our ultimate compatibility with the Java EE 6 Web profile will further improve this. We will continue to heavily invest in as a quick startup time, quick deployment time and overall development cycle is hugely important for us to continue to be credible and adopted within the developer community.

Oracle has ever been an active member of the JCP. What do you expect other companies (e.g. IBM) to do, expecting that the sun deal closes? Will they further contribute to Java or does the whole setup needs to be changed?

Oracle has a long and actively engaged relationship with the Java Community Process and plans to continue this active involvement and participation in the community. It is not possible for me to comment beyond this due to the position we are in with the acquisition of Sun.

The WLS development team is about four times bigger than the Sun GlassFish team is. From a developers point of view I do not understand, why the adoption of new specifications take that long. What about doing more technical previews with weblogic server?

It is difficult for me to comment on development team size as neither company publicly states development numbers on the core application server so this would be speculation. Clearly the Fusion Middleware development team is tackling a broader set of middleware than Sun and thus is sized to deal with that problem domain but that is much different than solving the Java EE problem domain. And correspondingly the Sun middleware team has investments beyond GlassFish proper and would have an equally difficult time with such a comparison.

I can comment on the technical previews. Oracle has historically been very active in providing technical previews probably the most notable in the recent past was with the Oracle Application Server where we actively released ahead of production and every competitor on the market support of JPA and EJB 3.0 in J2EE 1.4 conforming to the final specification. Correspondingly BEA prior to the acquisition was also aggressive in this space being one of the first commercial vendors to come to market with a preview of Java EE 5.0 support. We would like to continue this going forward and our investment in developing EclipseLink in open source where daily snapshots of the software are available by the very nature of the development process are a great example of this. Bottom line: both Oracle pre-BEA and BEA pre-Oracle actively engaged the developer community with technical previews, we hope to continue that going forward.

How do you see the future of WLS within Fusion Middleware? Will it continue to be the fondation, but still be available as a solid standalone product? Or will the integration into the stack finally lead to a highly optimized Oracle Applicationserver (again)? And what would be your wish about the future?

We see WebLogic Server as both a compelling standalone product as it is today and also as the foundation of Fusion Middleware as it is today with Fusion Middleware 11g. Generally we see the roadmap of WebLogic Server in three dimensions:

1. Just Enough Application Server - this is aimed at the light weight, agile Java EE profile nature we see developers evolving to today and is represented nicely by the Java EE 6 Web profile and Oracle long investment in OSGi as a key modularization technology for application servers. Areas here include not only the runtime but deep integration into build, test, and continuous integration and qa environments - aimed at the full development lifecycle not just the core server infrastructure. This has applicability for the general standalone WebLogic Server market as well as customers adopting Fusion Middleware who want fast, lightweight development and deployment environments.

2. Large Scale Shared Services Infrastructure - this is aimed at customers who are deploying WebLogic Server in large deployments both large clusters and across multiple datacenters with an cost of operations that is significantly less than any other competitor on the market. A different mind set around extremely efficient and automated administration, operations and management has to be built into the product than that of working in smaller clusters like other more simply API compliant servers. Again this has huge applicability to our general standalone WebLogic Server market where this is a hard requirement but also our customers who are adopting Fusion Middleware across their enterprise.

3. Fusion Middleware and Fusion Applications - Clearly as you note, we have a clear business incentive to make WebLogic Server the best application server for Fusion Middleware and Fusion Applications. Ironically while some folks think this could be seen as a bad thing for standalone WebLogic Server customers, I tend to look at it as the opposite: Fusion Middleware and Fusion Applications represent some of the most challenging and functionally rich software infrastructure on the planet and an application server that is capable of running these sets of applications and infrastructure has unique and differentiated capabilities for our customers who also need a rock solid, proven infrastructure for their equivalently challenging and feature rich application infrastructures.

I think this is a challenging mission so when you ask for my wish for the future, it is to deliver on this mission. Oracle WebLogic combined with the Oracle organization that continues to have a world class engineering team that is uniquely positioned to change the industry's view of what application server infrastructure by executing against this set of goals.

Some customers complain about "vendor lock in" things and sometimes they switch to open source appservers. What would you tell those customers? why should they further invest into Weblogic?

Oracle has long had the mantra that there is a difference between open source and open standard. Open standards are one that are developed in conjunction with participants from the entire industry - commercial and open source vendors/participants. Java EE is a great example of this. Open source is a different approach - effectively making the source code available and in a number of cases, like with commercial offerings, can and do step up to being compatible with open standards.

WebLogic Server is a Java EE compatible server and as such applications developed on it that are conformant to Java EE standards have the optional choice and risk reduction strategy of being able to deploy on other Java EE compatible application servers. If customer decides to develop on an open source server and adopt a non-open standards framework (e.g. not Java EE) then they are taking on a risk that they may be locked into that server and unable to migrate unless they re-write their application. Some customers take this risk and face the challenge of those vendors - as you have seen in the open source market - being acquired and the resulting lack of certainty over the future of these non-open standard approaches. With Oracle because of corporate wide mandate and commitment to open standards as long as customers are building to standards like Java EE they have a strong certainty that they can mitigate any risk of vendor lockin by looking to alternative application servers.

Oracle also understands the attraction of open source - particularly since some areas of open source evolve faster due to lack of overhead associated with reaching a consensus across all major industry players and that can be sometimes advantageous to bring to market some technologies. This was particularly apparent in the web framework space with Apache Struts many years ago and Spring more recently. This is why in conjunction with a strong adherence to open standards you have seen Oracle actively participate and support open source projects be it contributions such as Apache Trinidad, EclipseLink (both standards and open source - ) or Spring (our contribution of WebLogic transaction integration to the project and Spring Pitchfork) or finally our Ecliplse Plug ins for Java EE (Oracle Enterprise Eclipse Pack [OEPE]). Our contributions in open source are actually fairly unique and are exemplified by EclipseLink. You will see that EclipseLink is not a fork from our commercial offering - it is one and the same. This is the same with OEPE where we develop in open source and ship it/support it as the commercial offering within our software packaging.

Bottom line: We believe we have the best open standards server implementation on the planet and agressively are standards compliant. We are also strong believers in open source and actively participate in numerous communities supporting open source development. Our efforts are backed by a development organization, support organization and sales organization who strongly believe in this mission, so we believe investing further in WebLogic Server is frankly in customers best interest and gives them the benefit of world class, standards based infrastructure with maximum risk mitigation while leveraging the best open source has to offer.

What would be your personal favorite feature of Weblogic 11g if you could make a wish?

I have been quite fond, as you have heard me speak at OpenWorld, of a feature we call ActiveCache which is the direct integration of Oracle WebLogic Server and Oracle Coherence to manage state in a separate tier from WebLogic Server. We see this giving pretty substantial benefits to our customers - reported benefits of doubling capacity on the same hardware as an example - for a remarkable simple and declarative change to ones application infrastructure. Coherence seriously changes how one can write applications when one takes the leap that you have a completely reliable and redundant in memory data grid available to your applications like you do with ActiveCache. We have seen customers using WebLogic and Coherence go from using it for basic state management to simple caching to using it for architectures where data is lazily written to back end databases to enable even more capacity into processor bound backend infrastructures and finally to complex computational risk analysis on that same in memory data. A truly exciting an unique technology that I think we are just seeing a small taste of what we will be able to do with it in coming releases.

What does the OTN Community mean to you? And how do you try to integrate or take advantage of their feedback?

OTN is of huge value to my team as product managers planning releases of WebLogic Server and our engineering team as they work on individual features. There are literally millions of developers who participate in OTN in numerous ways - forums, contributing articles, wikis, contributing code samples and directly feeding back to product teams. We as the product teams use it constantly as vehicle to developers with podcasts, blogs and participation in forums. We frankly have a lot of difficulty keeping up because it has grown so large - I think because of the quality of material and the quality of the community - but fortunately we have not only ourselves within Oracle to scale it we also have programs such Oracle ACE Directors where our top users also become very active and well known within the community and contribute and guide discussions.

Proposed Final Draft (PFD) of the Java EE 6 Platform available

The Proposed Final Draft (PFD) of the Java EE 6 Platform specification and of the two other specs being defined by the JSR-316 expert group, the Java EE 6 Web Profile specification and the Managed Beans specification, is now available from the JCP web site.

Book review: Real World Java EE Patterns - Rethinking Best Practices by Adam Bien

I got the chance to look at the digital edition of Adams newest book. All "Bien works" promise real world knowledge and code you need to develop lean and maintainable Java EE 5 / 6 applications. Therefore I was quite excited to see his new book.

Real World Java EE Patterns - Rethinking Best Practices guides you to efficient code and best practices in a structured way, with real world examples.

The first two chapter sum up, what you should already know. Basic JEE principles (EJB, JPA, JMS, JCA, JTA, Dependency Injection, Convention Over Configuration, Interceptors, REST), Transactions, Isolation Levels, Core J2EE patterns. In short, this is more like a "history of the internet section".

Chapters three to five realy deal with patterns. Starting with business layer patterns for domain driven and service oriented architectures, over to patterns for integration of asynchronous, legacy, or incompatible resources and finaly infrastructural patterns for eager-starting of services, thread tracking and more.

Chapter six finaly is about pragmatic Java EE Architectures. With a discussion of superfluous patterns and outdated best practices. Things like DAOs, Business Delegates, Data Transfer Objects extensive layering, indirections and more. Beside this, the introduces lean and pragmatic service and domain driven architectures, based on the discussed patterns.

As a conclusion: A good book to start over again with patterns in JEE6. If you skip the first two parts and focus on the "pattern" itself, it can be a very usefull ressource for you. As always, Adam's books are fun to read and easy to understand even for non native speakers :)

The online PDF version is available from Lulu.com.
(If you use the the promo code: "README" you will save 10% off)

Have a look at http://press.adam-bien.com/, too.

J2EE to JEE5 or JEE6 Migration

More and more mature projects think about migrating these days. After a couple
of years of successfull development it is time to decide weather to
switch to updated enterprise java versions or to keep the old ones.
Looking out for the JEE6 release, which is getting closer each day, I will have
a look at some things to keep in mind if you are thinking about updating your J2EE
projects.

Migrate to JEE5 or JEE6?
Even if the final version of the JEE6 specificatione is getting closer, there are
only few pre-release versions of JEE6 appservers available already. And with the
late integration of JSR-299 and JSR-330 there are still some major pending changes.
In a business sense, this puts unneeded risk to your projects. If you have some
more time for migrating (target time mid of 2010) it would be worth waiting. Otherwise it will be best to update to JEE5.

Migrate to JEE5 or keep J2EE?
Basically these are your choices. Keep it or migrate. The main decision driver are
the business requirements. Do you have to update your application server version but
keep all the code and no need for making changes? Go ahead and rely on the JEE5 backward
compatibility. You have bigger changes to do? Possible performance problems? Expensive
refactorings planned? Give JEE5 a chance and migrate. Third option is to mix both strategies.
Only change parts of the implementation that needs to be touched and leave the rest J2EE style.

Effort estimation
The migration effort highly depends on the implementation quality and complexity of your application.
Starting with plain webapplications up to full blown CMP1.x/2.x projects your technical complexity
grows and the migration efforts will do so, too. The worser your code quality and arcitectures are,
the bigger are your migration efforts. Following this, the worst kind of migration project would be
a CMP 1.x enterprise applications with hardly any architectural concepts, bad documentation and
really poor code quality.


Risks and Problems
Most risky is the migration not only from one specification version to another but from one
appserver to another verdor's version. In this case you probably would have to cope with
vendor specific solutions (proprietary classes and/or features, deployment descriptors, specific behaviour).
Another problem could arise from special frameworks (e.g. Weblogic Diagnostics). If you depend heavily on
such features, you should probably try to no change the application server vendor in a first step.

Requirements for migration
Your project should meet some requirements before you think about migration.
You should have:
- ... some testcases at hand. Especially if you are going to migrate the persistence layer!
- ... a testdatasource available.
- ... two test environments (old and new)
- ... code that compiles with JDK 1.5 (check for incompatibilities/deprecations)
- ... thought about moving your development project settings to a JEE5 project.

Enterprise Java - a firmer grasp of the fundamentals

This blog is about Enterprise Java. The word "Enterprise" mainly refers to the fact, that it need some more that just plain
Java to run applications that fulfill enterprise requirements. Beside the fact, that most of them were tried to be adressed
by the Java standard with a nearly equal name (JSR 316) there is still lot to learn about this topic beside the basics.
Here are some hints and best practices for beginners wanting to gain a firmer grasp of the fundamentals.
These tips assume, that you already knwo about OOP and Java in general.

1) Read, read, read, read and understand
The Enterprise Java Specification is incredibly thorough and has truly helpful comments following each included standard.
Before asking questions or trying to figure out an issue on your own, save some time and just head straight to the
documentation. Another good place to look for answers and get a deeper understanding about the collaboration of the
standards is the Duke's Bank Sample application. Also known as the JEE Tutorial. Besid this, it is always a good idea
to have a look at the documentation of the application server of your choice.

- JSR 313 Documentation
- Duke's Bank Tutoral
- Certified Java Application Servers

2) Get used to exceptions and learn to read them
You’ll find bugs in your code that you might not have spotted earlier, as not all bugs keep the application from working.
There are different levels of strictness in the reporting that you can use. Depending on the framework, application server
or JDK you are using, you have to configure error reporting the right way.

- JDK Logging
- Commons Logging
- Log4j

3) Use an enterprise IDE
IDE’s (Integrated Development Environments) are helpful tools for any developer.
While they’re not for everyone, an IDE definitely has its place. IDE’s provide tools like

* syntax highlighting
* code completion
* error and deprocation warnings
* refactoring (reworking)
* appserver integration.

And many other features. There are plenty of great IDEs out there that support Enterprise Java. Have a look and take
your choice:

- Eclipse IDE
- Netbeans
- IntelliJ
- OEPE

4) Try some frameworks
Starting with JEE 5 the specification got much easier to use. Anyway, there are still some concepts that feel to
overengineered. Some frameworks try to fight this and reach the goal of providing enterprise grade applications on
a different track. Beeing a skilled developer, you should have seen some of them. Take your time and experiment with them.

- Springframework
- JBoss Seam

5) Try different O/R Mappers
JEE 5 introduced the Java persistence API (JPA). Beside the reference implementation, that ships with the specification
there are plenty other, very good and stable O/R mappers available out there. Most of them have a moving history and
come with advantages or disadvantages depending on your needs. To use the right O/R mapper, it is worth seeing some.

- Hibernate
- EclipseLink
- OpenJPA

6) Don’t Repeat Yourself (DRY)
DRY stands for Don’t Repeat Yourself, and it’s a valuable programming concept, no matter what the language.
DRY programming, as the name implies, is ensuring that you don’t write redundant code.

7) Think about readable code
If you don’t use indentations and white space in your code, the result looks may look like a painting.
Ensure that your code is readable and easy to search because you’ll most definitely be making changes in the future.
IDEs and advanced text editors can add indentation automatically. Take your time to adjust the default settings to
meet your needs. Have a look at available code-templates and best practices out in the web or other projects.

8) Think in tiers
Maintenability is one of the trickiest parts in JEE development. There are plenty of options for architecting your
software. The first paradigma is about tiers. Separete the client from the logic and the database access. spend some
time reading about tiers and how to decouple them.

9) Be aware of dependencies
Even if your follow tip 7, you still have to think about dependencies. You can have a couple of dependencies not only
inside your code and tiers but also with your libraries and infrastructure components. Make shure, you are using the
right and only the needed dependendencies wherever they may appear. Handle them on different levels (Architecture,
Development, Build and Depolyment)

10) Stick to naming conventions
Naming this isn’t just for your own good. There’s nothing worse than trying to find your way through some other
programmer’s nonsensical naming conventions. Help yourself and others by using names that make sense for your
classes, variables and declarations. It's worth taking a look at the basic Sun naming conventions. There are plenty
of different project or customer sets out there, too. Respect them and don't think of them as unneeded. One aspect
of JEE programming is about teams. Most likely you will not be the only one working on a project. Sticking to naming
conventions makes live much easier for all involved team members.

11) Comment your code
Aside from plain formatting, you’ll also want to use inline comments and JavaDoc to
annotate your code. You’ll thank yourself later when you’re needing to go back and find something in the code,
or if you just can’t remember what a certain function did. It’s also useful for anyone else who needs to look
over your code. Remember, that your most likely will not be the only one writing code in an enterprise grade project.

12) Decide on the right plattform to start learning with
There are some application servers out there for free. Well known are Sun's Glassfish, Apache's Geronimo or even Redhat's
JBoss. Beside this, you could always decide to start over with a free for development edition of one of the major commercial
vendors, like Oracle's Weblogic, IBM's Websphere or SAP's AS Java. No matter, which version you start over.
This will always be your home to come back to. Therefore it could be
worth thinking about your future needs. What plattform is your company using? Which area of interest drives my developments?

13) Never, Ever Trust Users
If your application has places for user input, you should always assume that they’re going to try to input naughty code.
I am not implying that users are bad people. It’s just a good mindset. A great way to keep your application
hacker-free is to always initialize your variables and validate input on any way to safeguard your site from attacks
(e.g. XSS, SQL Injection).


14) Ask for Help
It’s only human nature to want to hide the fact that we don’t know much about a certain topic.
Nobody likes being a rooky! But how are we going to learn without asking? Feel free to use forums, StackOverflow or
event the vendors support base to ask more seasoned JEE developers questions.


Have any ideas and tips of your own? I’m sure you do! Comments welcome!

Java EE 6 will be around November

As announced today on The Aquarium from pelegri the new JEE6 specification will include both JSR 330 and JSR 299. A blog entry from Roberto Chinnici explains the details about:

I'm happy to announce that, thanks to the work of many individuals, we've come to a positive resolution on this issue. Here are the key points:

* JSR-299 will be updated to use the JSR-330 annotations
* The initial draft of JSR-330 has evolved to take into account requirements coming from JSR-299
* Both JSRs will be part of the Java EE 6 Platform

This very late addition of a new JSR changes the release date of the platform to sometime in November:

Overall, we expect these changes to add four-six weeks to the schedule for Java EE 6. That would put the final release some time in November.

A Sampling of EJB 3.1

Ken Saks posted some interesting examples and impressions about EJB 3.1 at the Sun enterprise blog. He is the Specification Lead for EJB 3.1 and a Senior Staff Engineer in the Java EE team at Sun. Read his blog.

Hot topics:

• Ease of Development


• No-interface View


• Simplified Packaging


• New EJB 3.1 Features

JCP Approves the Java EE 6 Public Review (JSR-316)

The Executive Committee for EE/SE has approved the Public Review for JSR 316, the Java EE 6 Specification.

The vote was 12 YES, 1 NO, 1 ABSTAIN, and 2 NO-VOTED; see Ballot Results. You can download the PRD draft, and, as always, your feedback to the Executive Committee and to the JSR316 Expert Group are very welcome.

Most interesting comments from the ballot results are the comments from SAP and Springsource.

SAP AG voted Yes with the following comment:
SAP votes YES but would like to content that more work is required for the integration of JSR 299 into the platform to be useful and successful. We also would like the Spec Lead to consider putting more emphasis on architectural rigor regarding a single consolidated and extensible component model to be used across the platform - right now there are three (EJB, JSF and JSR 299).

SAP also has different component models in place already. And none of them is truely widespread in the java corner of SAP at the moment. If you want to get more information on this, look the "getting started with application development" guide on the SAP community network.
I am a big fan of SAP's JavaAS >=7. But I am not shure, if JEE is all about one common component model. Even if we have three ore more in place. The only thing that should be forced is the seamless interaction between them.

SpringSource voted Abstain with the following comment:
The introduction of profiles is a step in the right direction. However, we are disappointed not to see a minimal web profile, especially as this has become the choice of most enterprise Java users.

As with previous releases, the inclusion of unproven technology is a risk, especially in JSR 299 and EJB concurrency annotations. The number of substantial changes late in the process also gives us concern about the maturity of the result--especially, the impact of the scope creep of JSR 299 on other specifications.

Experience has shown that tying dependency injection features to a server environment does not match user requirements, as injection is common to all application types. We would have preferred to see a dependency injection model for SE, as we proposed in 2007.

Finally, we are not convinced that the end result matches the goals of Java EE 6 as defined in the original specification request, which we strongly supported.

Ok. This is a more serious comment. I am worried about the missing profiles, too. As I have seen the "Webprofile" for the first time I was wondering about what someone could call "web" :-) The requested "minimal webprofile" could be something similar to the JEE5 Webcontainer. Anyway: It is missing and I do expect that we get in bigger trouble with this doing our first projects on JEE6. Beside that I would love to see some more specialized profiles (e.g. portal, sip, etc).

Not beeing a member of the EG, I am not shure about the "inclusion of unproven technology" and the "number of substantial changes late in the process". But I am shure that both can result in problems. Looking at the different EG members with all their different interests it's like a miracle to me, seeing a new consolidated version of the JEE Spec "nearly" in time ;) What seems to be clear is, that if the inventors of Spring (aka the non JEE component guys :-)) have reservations on the impact of the JSR-299 it's worth looking at.

JEE6 - Public Review Draft

The public review period of the JEE6 specification (JSR-316) started on january 23. It will be open for comments up to the 23 of february.
Java EE 6 is the Enterprise Edition of version 6 of the Java platform, and thus will be built on Java SE 6.

The main focus of this new release will be to include existing JSRs and frameworks to the JEE landscape and to further continue in simplyfing the whole platform. The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, the JSR-316 introduces the concept of Java EE platform Profiles. The public review draft already contains the initial Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification.

At the moment the required components of the Web Profile are defined as follows:
The following technologies are required components of the Web Profile:

• Servlet 3.0


• JavaServer Pages (JSP) 2.2


• Expression Language (EL) 2.2


• Debugging Support for Other Languages (JSR-45) 1.0


• Standard Tag Library for JavaServer Pages (JSTL) 1.2


• JavaServer Faces (JSF) 2.0


• Common Annotations for Java Platform (JSR-250) 1.1


• Enterprise JavaBeans (EJB) 3.1 Lite


• Java Transaction API (JTA) 1.1


• Java Persistence API (JPA) 2.0

The specification team is looking for comments onto including Web Beans (JSR-299) into the profile or not. The profile definition itself is quite simple. Beside the Web Beans I am missing the possibility to deploy libraries to the container.

Let's see, what other Profiles will be available with the final version and what happens to the application server out there. I personaly expect non of them to provide separate profiles. They all will deliver complete JEE6 functionality.
Changes will come to separate webcontainers, like tomcat.

Btw: did you wonder about (EJB) 3.1 Lite? I did!
Chapter 2.11 from the EJB 3.1 (JSR-318) Specification states:

The EJB API is comprised of a large feature set with support for implementing business logic in a wide variety of enterprise applications. However, the full range of API contracts is not always crucial for all runtime environments. In addition, the breadth of the full API can present challenges for developers just getting started with Enterprise JavaBeans technology.
For these reasons this specification defines a minimal subset of the EJB API known as EJB Lite. EJB Lite is a proper subset of the full EJB 3.1 API. It contains a small, powerful selection of EJB features suitable for writing portable transactional business logic. The vastly reduced size of the feature set makes it suitable for inclusion in a wider range of Enterprise Java products, many of which have much smaller installation and runtime footprints than a typical full Java EE implementation.
An EJB Lite application is merely an EJB application whose EJB API usage falls within the EJB Lite subset. There are no special APIs defined only for EJB Lite. Therefore, any EJB Lite application can be deployed on any Java EE product that implements Enterprise JavaBeans technology, whether that product
supports EJB Lite or the full EJB API.
The EJB Lite API is composed of the following subset of the EJB API :

• Stateless, Stateful, and Singleton Session Bean components


• Local and no-interface view only


• Synchronous method invocations only


• Container-managed transactions / Bean-managed transactions


• Declarative and programmatic Security


• Interceptors


• Deployment Descriptor support (ejb-jar.xml)

An EJB Lite implementation is also required to support Java Persistence 2.0.

There you are. It's a quite minimalistic approach. But after all it's nothing. No full blown EJB and no minimalistic POJOs. What do you think?

JSR 316 oder auch JEE6

Irgendwie ist es ein wenig an mir vorbei gegangen.
Am 17.07. wurde die Expert-Group für die neue JEE6 Spezifkation
zusammengestellt.

http://jcp.org/en/jsr/detail?id=316

Einige spannende Dinge tun sich da. Zu allererst bleibt die Einführung von "Profiles" zu bemerken. Ein recht kritischer Artikel von Douglas Dooley beschreibt recht gut, zu welchem ersten Eindruck man kommen mag.

Ebenfalls spannend sind die deferred Teile. Nicht mehr dabei:

• JSR-168 Portlet Specification


• JSR-170 Content Repository for Java technology API


• JSR-207 Process Definition for Java


• JSR-208 Java Business Integration (JBI)


• JSR-225 XQuery API for Java (XQJ)


• JSR-235 Service Data Objects


• JSR-286 Portlet Specification 2.0


• JSR-289 SIP Servlet v1.1


• JSR-301 Portlet Bridge Specification for JavaServer Faces

Als Trost bleibt: Vielleicht kommen die mit JEE7 und dem JSR-277 Java Module System wieder.