In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.
If you’ve seen my posts or my site before, you’ll no doubt be aware that I have written at great length about Java EE 6, JSF, CDI , EJB and so on. What I haven’t written about is the many frustrations I’ve come up against in dealing with these frameworks on their own and especially when combined, or how their usefulness is often constrained to the application server container.
Java EE in some ways is an archipelago of frameworks that lacks the cohesiveness and all in one wide screen vision that software developers need. Java EE is about the enterprise, in reality its about the web, or even more specifically about Java EE containers. There’s a whole slew of uses for a good type safe and flexible dependency injection and AOP framework and such as CDI outside of Java EE containers but there is very little information and code to make it actually work.
Our goal is to make CDI useful and usable on its own without Java EE 6, and to give developers the tools and information to do so. To let them write vendor neutral and portable code, and apply agile and best practices. Developers know how to write good software and don’t want to sacrifice that for the sake of using a framework to make things easier. To that end we aim to provide code and information that will help facilitate those practices.
There will be some learning for ourselves along the way and we will have to change some of our previously held concepts. I know over the last few weeks having been getting CDI working and useful outside of the web container it has really altered my perspective on how I think about the dependencies and structure in CDI applications. My perspective has changed even more than when I wrote A Little Less Conversation.
As much as I hate to say it, we did come up with a mission statement, although we found it fairly easy and enjoyable to clearly defined the goals and attitudes of the project.
Our mission is to :
- Promote and facilitate the use of the Java Context and Dependency Injection (CDI) framework in relation to as many aspects of application development as possible.
- Enable developers to take advantage of CDI independently of Java EE.
- Provide lightweight, lean and agile access to the underlying CDI container as a core principle in our efforts.
- Make testing easy without requiring a complex set of tools or complex deployment scenarios.
- Enhance both Java EE development as well as the use of CDI in non Java EE application where possible.
- Promote and enable the use of CDI in a vendor neutral environment and maximize the portability of application code across CDI implementations.
- Not reject the ideas of Java EE but expand the usability of CDI outside the borders of Java EE application servers with frameworks that are not a part of the specification.
- Not reject other CDI efforts but to provide another venue to promote those efforts. This is an addition. This is another voice in support of CDI.
We are pretty excited that so far we have been able to live up to the intent of our mission statement with everything we’ve done so far. Over the next few days and weeks you will see articles and tutorials come out of Rick, Rob and I as we write about the CDISource project and we start to showcase some of the code we have written and start giving you an idea of where we are heading.
Right now we have vendor neutral support for starting up CDI outside of the web container and also for testing CDI beans with minimal configuration and intrusion on your test cases. We also have a few other pieces that are nearly ready, as well as dozens of ideas to get started on.
You can start by looking at Ricks brand new introduction of CDI over on JavaLobby.
Adam Bien wrote about the Troubled with the crippled Java EE 6 APIs in Maven and a solution for them. Another solution has presented itself now that JBoss has finalized the Java EE 6 spec pom and added it to their public repositories as of early January 2011.
You can include the spec in your own project by adding the following to your
You may also need to add the JBoss repository to your
pom.xml which is defined as :
I’ll be adding this pom to the Knappsack archetypes to resolve some of the issues people have been facing with the broken spec dependency.
It looks like JBoss 6.0 milestone 5 has just been released. Not that anyone would know it since they haven’t announced it anywhere, I just saw Aslak Knutsen tweet it. Dan Allen also posted slides from his JavaOne presentation on Weld and the future of Seam.
I have finally got around to putting the Mavan Java EE 6 Archetypes into the Maven Central Repository. This means you no longer have to manually download and install the Archetypes, they should be available for you to use out of the box. In some cases, depending on how you are creating your projects, you may need to refresh or update your Repository indexes in the IDE before they are visible.
In Eclipse (with m2Eclipse installed), you open the Maven Repositories view, locate the Central Repository in the global repositories, and right click and select update index to make the archetypes available.
To create a new project from the command line, you can copy the following command into a script or batch file and edit it to setup your own group and archetype values.
mvn archetype:generate -DarchetypeGroupId=org.fluttercode.knappsack -DarchetypeArtifactId=jee6-sandbox-demo-archetype -DinteractiveMode=false -DarchetypeVersion=1.0.4 -DgroupId=org.application -DartifactId=sandboxdemo -Dpackage=org.application
The new version includes the archetypes for creating Java EE 6 applications in servlet containers which lets you play around with CDI, JSF, JPA, validation and other JEE 6 technologies using an embedded servlet container from the command line.
(updated : This post refers to Glassfish installations prior to version 3.0.1 which was recently released and includes Weld version 3.0.1. Given the new version, this manual update is not necessary and should not be performed if you have an updated installation of Glassfish 3.0.1+)
Even some of the recent versions of Glassfish include a version of Weld, the reference implementation for CDI (JSR 299), that has some major issues. Since Glassfish uses OSGI, upgrading isn’t as easy as just replacing the jar with a new one. This tutorial shows you how to upgrade Glassfish to Weld 1.0.1.Final as well as including a pre-built distribution of the two files that need re-deploying.
One of the ways to get around the faulty version of Weld currently in Glassfish is to moving up to Glassfish 3.0.1 nightly builds (update : 3.0.1 has been released and should be used) . A less bleeding edge solution would be to upgrade the version of Weld that is deployed on your current version of Glassfish by updating the
weld-osgi-bundle jar files. However, one must be careful of the integration jar version as one of the major interfaces changed after the initial release of Weld introducing incompatibilities.
Updating the OSGI bundle is easy since it can be built from the Weld source code. Just download and compile it and locate the osgi-bundle.jar file.
We also need to grab a new version of the
weld-integration.jar file. There are all sorts of versions of this file, but the one I found working for Weld 1.0.1.final was version 3.0.1-b11/.
I’ve already built the osgi-bundle and grabbed the integration jar and verified that they work so I’ve renamed and zipped them so you can just download and unzip them into the
modules directory of your Glassfish v3 installation.
This is also a necessary step to get the Knappsack Java EE 6 demo project working under Glassfish. You can find more details on the server compatability page
Note : Spigot has been renamed to DataValve.
(Edit : I renamed this post so it doesn’t seem like Spigot is just for Seam, Spigot can be used with different frameworks or without any at all. However, I wrote this post since Spigot is so familiar to the Seam EntityQuery that it should be easy for Seam users to get the idea)
Seam developers should become familiar with Spigot concepts fairly quickly since they are very similar to those found in the Seam
EntityQuery which was one of the main inspirations for the framework. If you imagine taking the entity query class and splitting it in two, one part to keep hold of state and the other to actually fetch the data. The stateful part is the
Paginator that keeps track of what the current ordering of the data is, what is the current page and how big the pages are. The stateless part takes the Ejbql and the pagination information and returns a subset of the data. Now imaging that the data provider has the JPA pieces taken out and replaced with an abstract
fetchResults method. This method is implemented in subclasses for specific data providers for text files, sql queries, jpa queries, native jpa queries, xml files, comma delimited or just an in memory dataset.
Read More »
Note : Spigot has been renamed to DataValve and is hosted over on FlutterCode.com.
It’s been a while since I’ve posted anything new as I’ve been busy with a new Open Source software project called Spigot. It’s a java library that sits between your application code and your data sources (Hibernate, JPA, JDBC or any arbitrary source of data) and helps with things like pagination and sorting using a common interface so you can switch out data providers and use alternatives.
For query language data providers, Spigot also facilitates excluding restrictions from WHERE clauses when parameters are resolved to null. Parameters are handled using parameter resolvers so there is more than one way to parameterize the query including EL expressions, reflection or a value map on the data provider.
Spigot also provides a few other add-ins like converting any dataset into an in-memory dataset that can itself be paginated and sorted and shared across an application (such as commonly used data in a web application). The
IndexedDataProviderCache can give you random access into a dataset with caching and look ahead loading. This lets you hook a dataset with thousands of rows up to a Swing JTable with an instant response and a very small memory footprint since it doesn’t need to load all the objects at once as the provider will load the records as needed and cache the results. This is demonstrated in the Swing Demo in the download. There are also demos for Wicket and CDI with JSF.
You can ready about why I created Spigot in the documentation
Spigot is currently hosted on Project Kenai, where you can download the release, view documentation online or read about 10 ways Spigot helps developers.
Last time we looked more in depth at CDI and how we can define beans and inject them into other beans. This time we are going to look at how we can use events to decouple the handling of actions in the system.
Read More »
In part 1, we looked at creating a JEE 6 application with Netbeans using JSF and CDI running on Glassfish. Now we’ll take a closer look at using CDI for managing dependencies in a Java EE 6 environment.
Read More »
Here’s a quick tutorial on how easy it is to get started with JSF 2.0 and JSR 299, Java Contexts and Dependency Inject (CDI) using the latest release of Netbeans 6.8.
Read More »