Seam Framework: Available in Paperback

February 19, 2009

I just got my hands on a hard copy of my book, Seam Framework: Experience the Evolution of Java EE. For those who have been awaiting the paperback release, you can order your copy today from Amazon or Barnes and Noble. The book is the second edition of the best-selling JBoss Seam covering the latest and greatest features of Seam 2.1 and Web Beans (JSR-299). Check it out!

Posted in JBoss Seam, JBoss Seam 2E News 4 Comments »

5 Steps to Improve your Development Process

February 4, 2009

Improving your development process takes time and effort, but always pays off in code quality and professionalism. When consulting for an organization I always recommend the following 5 steps that I feel are essential to any development process. You may already be using these recommendations in practice as they are all well-known techniques and tools so I certainly applaud anyone who can check off each step. Note that each step requires learning, practice, and discipline, so if you are introducing something new, take it a step at a time. Process improvement doesn’t happen over night.

1. Write tests for your code, then write more tests

I won’t get into the religious battles generally surrounding Test Driven Development (TDD), but regardless of what you believe you should be writing tests for your code. Professional software developers write tests and run the test suite after making logic changes. As Robert C. Martin put it in Clean Code, “Code is never clean unless it has tests.” Enough said.

What it requires:

• A unit testing tool such as JUnit or TestNG. I also recommend a code coverage analysis tool for measuring how well you’re doing with your testing such as Cobertura or Emma.
• Learning to write testable code (e.g. small methods that generally have a single responsibility).

2. Don’t let your code changes become stale, commit regularly

Don’t hang onto your changes locally for an extended period of time. For continous integration to flush out issues early, you must integrate your code with other developers often. If you follow the technique of continuous commits, it will re-enforce itself on other members of your development team over time.

Merging is a pain to say the least. In a continuous commit environment, the longer you hold onto changes, the more likely you will have to merge. Other developers will soon realize that if they do not follow this approach, you are going to make their life miserable.

What it requires:

• Breaking your work into smaller chunks that can be completed in reasonable time periods.
• Developing the habit of committing as you finish a logical chunk of code.

3. Setup a Continuous Integration (CI) server

Continuous integration (CI) is nothing new, but I’m always surprised at how many environments I encounter that are still not using this vital development technique. Setting up a CI server is easier than ever thanks to some outstanding open-source projects.

What it requires:

• A build that is autonomous, i.e. doesn’t rely on external input such as compiling the source files in Eclipse, to achieve the goal of building the project artifact(s).
• A CI server implementation and a build machine to install the server on. Popular implementation choices include Hudson and CruiseControl (the original).

4. Automate scheduled releases to a production environment clone

Aka: Release Early, Release Often. The CI server can deploy releases to a production environment clone based on the current stable code in the VCS. If possible, this deployment should be fully automated and should generally occur at a specific time.

To avoid downtime for user testing it is not recommended that this occur on each commit. As the size of the team grows this can become quite a hindrance with continuous commits. Deploying a release somewhere between nightly and weekly at a time when usage is low is generally reasonable.

What it requires:

• A way to deploy the application from the CI server to the production environment clone. With the hot deployment features of JBoss, I generally use SFTP and Hudson provides a great plugin for this.

5. Add a project artifact repository

This is probably the most controversial of the steps outlined here. The concept of an artifact repository is probably familiar to most people given the broadened use of Maven, but may still be unfamiliar to some. Maven repositories allow you to store project artifacts including POMs, jars, wars, ears, etc. in a structured format that incorporates naming conventions and versioning. This allows you to archive versions of your software products over time while automating dependency management as dependencies and versions change.

What it requires:

• A server to install the artifact repository with the disk space necessary to store archives over time. Popular server choices include Artifactory and Nexus.
• Integration of dependency management into your build. If you are using Ant, the Ant Tasks for Maven are useful or you can use Maven itself. Ivy is also a popular choice.

So what would you recommend? What processes and tools do you feel are essential to all development teams?

Posted in Agile 5 Comments »

Seam Framework: All Chapters Now Available

November 30, 2008

All early access chapters for Seam Framework: Experience the Evolution of Java EE have now been released through Safari Rough Cuts. The only book specifically covering Seam 2.1 now includes new chapters on Seam 2.1 security, an introduction to Web Beans (JSR-299), multi-layer caching, using Maven with Seam, and much more! You can download the source code or learn more here.

These chapters are still undergoing copy-editing so if you would like to pre-order the final print edition, you can order from amazon today. The final edition is scheduled for print release in February. Check it out!

Posted in JBoss Seam, JBoss Seam 2E News No Comments »

Core Seam 2.1 Refcard Released

November 24, 2008

Have you been searching for a quick reference for setting up and configuring your Seam applications? Well search no more! The Core Seam Refcard has now been released through the DZone Refcardz site and includes:

• Component annotations
• Seam-gen commands and configuration
• Conversation management
• Common components.xml configuration
• Seam security
• The Seam application framework
• Hot tips and more…

So download the Core Seam Refcard here and please send your comments and feedback to refcardz@dzone.com. For in-depth coverage of Seam 2.1, you can also purchase the upcoming Seam Framework: Experience the Evolution of Java EE. Enjoy!

Posted in JBoss Seam, JBoss Seam 2E News 3 Comments »

Seam and Web Beans: Not just evolutionary, revolutionary

September 29, 2008

Just a quick note to let you know that I will be speaking next week on October 8 at the Java MUG in Dallas. I will be talking about how Seam has simplified JEE web development and influenced the revolutionary Web Beans specification (JSR-299). Hope to see you there!

[Presentation Slides]

Posted in JBoss Seam, Web Beans 6 Comments »

OSGi: What modularity can do for you (part 1)

August 27, 2008

It’s been a bit since I blogged last, but I wanted to discuss something I’ve been busy with lately. Inspired by a recent presentation by a friend of mine, Craig Walls, and the announcement by Ales Justin to support OSGi in JBoss 5, I decided to see what all the fuss is about. Perhaps you’ve heard all the hype lately surrounding OSGi, but I wanted to let readers know what they are in for should they decide to trek the OSGi path.

Part 1 will really just be an introduction to OSGi, so for those who have been watching OSGi for awhile now (the OSGi Alliance was founded in 1999!) feel free to jump in on the next entry. But, for those who are OSGi newbies, this will help to get the ball rolling.

So what is modularity all about?

Modularity is the basis of the OSGi world and each bundle is considered a distinct module. Essentially bundles are just standard jars which happen to register with the OSGi container on deployment.

• They inform the OSGi container of what services they expose and what services they consume.
• They run in the same VM and all invocations of the module are in-process calls (no remote invocations).
• Modules are restricted in their interaction with one another as the OSGi container defines restricted class-loading policies (only allowing classes from a module to be exposed if they are explicitly exposed).

Bundles are not a fit for all cases and not all jars are required to be OSGi bundles. In fact using tools like the Apache Felix Maven OSGi Plugin we can choose to selectively embed dependencies directly into our bundles. But, in this case always consider the scope of the classes contained in those embedded dependencies as there are specific rules related to class-loading in the OSGi container.

When modularity counts

Modularity is important in cases where we want to limit what our clients can and cannot use. For example, looking at the Seam Booking Example, let’s say we add a payment service. We can define the payment service through an API, aptly named: PaymentService. There is likely a fairly extensive implementation behind the PaymentService necessary to validate forms of payment, authorize charges, etc, but the Booking application is really only concerned with authorizing payment (not the messy details).

public interface PaymentService {
  public boolean authorizePayment(Payment payment);
}

The details of the implementation should be hidden from the Booking application. Unfortunately, if the payment-service.jar is loaded into our classpath, we suddenly have access to not only the interface, but all the implementation classes as well. So there is nothing to stop developer A from directly instantiating and invoking PaymentServiceImpl. And when developer B changes the name of this class and its implementation months down the line suddenly we have a break.

OSGi solves this by only providing visibility to the services which are exposed by a bundle. This makes things simple in the following package structure:

payment-service
- src/main/java
    - com.solutionsfit.payment
         PaymentService
    - com.solutionsfit.payment.internal
         PaymentServiceImpl
         ... ...

Notice the package structure above. The PaymentService interface is separated from the implementation which is in general good practice, but externalizing one package or the other has never been enforced. So how can it be done with OSGi?

Remember that crazy MANIFEST.MF file that perhaps you looked at one time to see what was in there. Or maybe you just noticed it sitting there and never bothered to look at it (Maven generates it for us anyway right!?). OSGi introduces some specific entries into the MANIFEST file that defines exactly what packages are imported and exported. So for our example above our manifest may look something like:

Manifest-Version: 1.0
Bundle-SymbolicName: com.solutionsfit.payment-service
Bundle-Name: Payment Service
Bundle-Version: 1.0.0
Bundle-Description: Payment Service
Import-Package: org.apache.commons.lang
Export-Package: com.solutionsfit.payment
Build-Jdk: 1.5.0_15
Bundle-ManifestVersion: 2

These entries simply let the container know what they require from other modules to execute:

Import-Package: org.apache.commons.lang

And what they make available to other modules:

Export-Package: com.solutionsfit.payment

Notice that we haven’t specified anything earth-shattering here. All we’ve done is said that we require commons-lang to be provided to us and we are making the com.solutionsfit.payment package available to others. Note that I don’t state where the dependencies come from! This means that in the above case any registered bundle could export the package that I use. You can also specify a version to be more specific:

Import-Package: org.apache.commons.lang;version=”2.4.0″

This allows multiple bundles to export the same package but we only use the version we are interested in. This becomes very useful in addressing dependency version issues between jars. Here bundle A can depend on 2.3.1 while bundle B depends on 2.4.0 and the OSGi container enforces this restriction for us. In the example above by not specifying a version, the latest version registered by a bundle will be chosen.

Note in our diagram above that the PaymentService is the only class available to the org.jboss.seam.example.booking bundle. This is because we explicitly specified that its package should be exported meaning that the OSGi container makes it visible to other bundles.

This all looks very Maven-ish to me…

Your right! The naming conventions and versioning are very similar to Maven and they fit well together. In general, the BundleSymbolic-Name is determined by appending the group-id and artifact-id of your Maven POM. The version is just stripped directly from the POM, so it all fits. In fact, if you want to make your jar a bundle, simply create a /src/resources/META-INF/MANIFEST.MF file by swapping in your project details in the entry above and add the following lines to your POM:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifestFile>
              src/main/resources/META-INF/MANIFEST.MF
            </manifestFile>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>

The next packaging of your project will be a OSGi bundle. Of course, the Apache Felix plugin mentioned previously provides a much more automated approach, but if you are into manual entry (sometimes the best way to learn), this approach will certainly work.

So besides visibility, what does this buy me?

Imagine the Booking application is running in production and your customers are happily booking trips to their favorite vacation destinations. You have realized that there is a critical bug in the production payment service that could result in substantial losses for your company. Do you bring down the application for temporary maintenance and perhaps lose those customers? No way!

With OSGi there is very loose coupling between the bundles. While OSGi will simply provide back a direct reference to the object registered by the bundle, this allows helpers like Spring-DM to proxy the PaymentService that will force the org.jboss.seam.example.booking to wait should the service go down.

If we simply replace the bundle with a bundle that includes the fix, the container will unregister the old bundle and register the new bundle. The proxy can then handle the reference shuffling and resume the service invocation.  This interaction will be almost instantaneous. Your customers will be completely oblivious to what has happened and you just saved your company a substantial amount of money (do I hear bonus?).

The diagram above obviously omits quite a bit of the magic of OSGi and hides some implementation details, but demonstrates the general idea.

Alright, alright, so all this stuff is very basic, where are the integration points! Don’t worry, in upcoming posts I’ll further discuss how the Booking application can use OSGi to simplify development.

Stay tuned…

Posted in JBoss Seam, OSGi 9 Comments »

Managing Environment Specific Configuration with Seam

June 17, 2008

Swapping configuration between development and production (and often other environments) is usually a custom solution but often follows a general pattern. Personally, I usually leave this up to properties files. For instance, let’s say we have a specific URL for an adding service and let’s say the URL changes between the development and production environments. Obviously we would want to automate this.It is quite simple to define a component to invoke the service using Seam:

package com.solutionsfit.example.service;

@Scope(ScopeType.STATELESS)
public class AddingServiceFacade {
  private location;
  private port;

  public int add(int num1, int num2) {
    // invoke service at location and port
    // ... ...
  }

  // getters and setters
  // ... ...
}

Once defined, we can simply create a namespace for this component (as shown in this previous posting) and our configuration in components.xml becomes simple:

<components xmlns="http://jboss.com/products/seam/components"
    xmlns:service="http://solutionsfit.com/example/service"
  ... ...
  <service:adding-service-facade name="addingService"
    location="@addingServiceIpAddress@" port="@addingServicePort@" />
  ... ...

The wildcard attributes above are replaced by our components.properties definition:

addingServiceIpAddress=192.168.0.1
addingServicePort=9999

The properties are set into our component at create time and invocation is now as simple as injecting the component:

@Name("addingAction")
public class AddingAction {
  @In
  private AddingServiceFacade addingService;

  // ... ...

  public void addNumbers() {
    result = addingService.addNumbers(num1, num2);
  }
}

Since this definition changes between development and production we simply maintain properties files specific to each environment aptly named: components-dev.properties and components-prod.properties. A simple ant target (or Maven profile) resolves the appropriate properties file based on environment when creating the archive that is being deployed.

This becomes even more useful when creating integration tests. An additional properties file can be defined that specifically defines the integration testing properties for your automated tests (e.g. components-test.properties). The integration test target can then use this properties file for running automated tests, avoiding any additional setup in the tests, and allowing a full integration test to be run.

So my question, how are you managing your environment-specific configuration with Seam?

UPDATE: This approach will be supported in Seam 2.1 as a feature of seam-gen’d projects as part the profiling functionality. See JBSEAM-3157 to patch your existing seam-gen’d project.

Posted in JBoss Seam 8 Comments »

Seam Framework: Experience the Evolution of Java EE

June 6, 2008

After a highly anticipated wait, Michael and I are pleased to announce that the Rough Cut of JBoss Seam 2E is available with a new title: Seam Framework: Experience the Evolution of Java EE. The new edition is a major update to the original including:

• New chapters on Groovy, JBoss Rules (Drools), Events, Quartz, Multi-layer Caching, Maven, and Seam 2.1 Security
• Introduction to Web Beans (JSR-299)
• Major updates to Seam conversation model, transaction management, and many other features
• Updates to all examples and the overall structure of the book

The new title boasts the power of Seam and the impact it has had on the Java EE environment with the upcoming Web Beans JSR. Whether you are a developer in the heat of a baptism by fire Seam project, a seasoned Seam developer looking to deepen your understanding of the framework, or a developer interested in learning this exciting new technology; this is the book for you.

The book takes a pragmatic approach by walking you through detailed examples illustrating how to use the features of Seam and providing the particulars necessary to get up-and-running quickly. In addition, the book provides in-depth discussions of these features ensuring your understanding of the powerful new concepts Seam has introduced to the Java EE environment.

Be aware that the Rough Cut has not been through the rigorous editing process the final version of the book will receive. Your comments and feedback are welcome and encouraged. If you want to reserve your copy of the final print version today, you can pre-order now at Amazon!

The examples covered throughout the book can be downloaded here. You can deploy the examples by first editing the included build.properties file to include the following settings:

• jboss.home – the location of your local JBoss instance (the examples have been tested against JBoss AS 4.2.3.GA)
• seam.home – the location of the latest Seam distribution (the examples have been tested against JBoss Seam 2.1.0.SP1)

Once you have made these changes simply execute ant main deploy. This will build the example and deploy it to the configured JBoss instance. If you have any questions or run into any difficulties, please let us know!

Posted in JBoss Seam, JBoss Seam 2E News 22 Comments »

Getting Groovy with Seam after TSSJS

April 1, 2008

TSSJS was a great conference this year. Neal Ford, well-known author and ThoughtWorker, initiated the conference by delivering an inspiring keynote address discussing dynamic languages, DSLs (Domain-specific languages), and their role in the evolution of software development. Matt Raible blogged about the presentation and you can find a brief summary here. Polyglot programming became a theme of the conference with Ted Neward delivering yet another inspiring keynote encouraging developers to create their own language.

Building on this inspiration, Scott Davis discussed taking the Groovy Red Pill. Well, you would be happy to know I have taken the Red Pill, but of course with a Seam twist. I have been working on a time-tracking application (for my company’s internal use) utilizing Seam and Groovy that I will release as a freely available example. Groovy and Seam integration will be discussed in-depth in JBoss Seam 2E, but let’s look at the Groovy way to initialize a Timesheet:

@Entity
class GroovyTimesheet
{
  @Id @GeneratedValue
  Long id;

  @OneToMany
  @JoinColumn(name="TIMESHEET_ID")
  List<GroovyTimeEntry> entries = new ArrayList<GroovyTimeEntry>();

  GroovyTimesheet(PayPeriod payPeriod, int month, int year)
  {
    (payPeriod.getStartDate(month, year)..
      payPeriod.getEndDate(month, year)).each
    {
      entries << new GroovyTimeEntry(hours:0, date:it);
    }
  }

  // ... ...
}

So what is going on here? Essentially we define a range of dates that are iterated over. The PayPeriod is a fairly simple enum that determines the start and end dates of a pay period. By specifying (startDate..endDate) we define a range. Groovy understands the meaning of a range of dates allowing us to express this in a very concise manner (try expressing this in Java and you’ll get the picture). In addition, we use the each operation on this range. The each operation allows us to define a closure that executes as Groovy loops through our range of dates a day at a time. This allows us to initialize each GroovyTimeEntry instance for the pay period.

You will also note use of the << operator (or the leftShift operator). This operator is defined for a List allowing us to add elements to the list through this syntactic sugar. The GroovyTimeEntry instance is initialized using the default construction approach. By default, named constructor parameters can be specified in any order to initialize an object instance. If you define a constructor this is no longer provided by default. Finally, you will notice the use of the keyword it in the closure we defined for the each operation. The keyword it provides the value of the current element in the iteration. So in our instance, as we loop through the date range, each date will be provided iteratively in the range.

@Entity
class GroovyTimeEntry {
  @Id @GeneratedValue
  Long id;

  BigDecimal hours;
  Date date;
}

Wow, is that all the code? Looks pretty nice doesn’t it. As mentioned, the default constructor allows us to specify named parameters. In addition, getters and setters are automatically provided for each of our attributes.

You’ve probably noticed the use of JPA annotations here. This is perfectly legal and your groovy class will be a JPA entity. The same is true for Seam components annotated with @Name. So how does this work? Groovy classes are compiled to Java bytecode under the covers so JEE and Seam features are fully available to your Groovy classes at runtime. Simply use the groovyc compiler that can be accessed here or include the groovyc Ant task into your build. This will be covered in-depth in JBoss Seam 2E.

So what if we want to add GroovyTimeEntry instances to the GroovyTimesheet instance programmatically? The following code implements this:

@Entity
class GroovyTimesheet
{
  // ... ...

  void leftShift(GroovyTimeEntry entry)
  {
    entries << entry;
  }

  // ... ...
}

As mentioned, the leftShift operator is provided by Groovy and can be overloaded within your custom implementations. By defining a custom leftShift implementation we are now able to add a GroovyTimeEntry instance through the following:

// ... ...
timesheet << new GroovyTimeEntry(new Date());
// ... ...

Operator overloading isn’t limited to the leftShift operation. We can also overload other operators such as +:

// ... ...
BigDecimal plus(GroovyTimeEntry entry)
{
  this.hours + entry.hours;
}
// ... ...

This allows us to add the hours of two GroovyTimeEntry instances using the simple + operator. Notice that a return is not specified. This is optional as the last line is assumed to be a return statement.

As mentioned, a complete time-tracking application will be provided that not only demonstrates Groovy entities but also Groovy Seam components. In addition, the time-tracking application will make use of the ExpandoMetaClass to extend final Java classes at run-time! The code for the application is in development and will be made available through Google code. Also, stay tuned for JBoss Seam 2E which will provide the intimate details of Groovy and Seam integration. So take the Red Pill and use the meta-programming features of Groovy in your own Seam applications!

Posted in JBoss Seam, JPA, groovy 9 Comments »

JBoss Seam 2E Preview Chapters Released

February 13, 2008

The first cut preview chapters for JBoss Seam, Second Edition, 2/E have been released. You can access the preview chapters at the Safari Rough Cut site and can retrieve the code examples discussed throughout the chapters from this previous posting.

The full versions of these chapters are available through Safari by subscription as well as a number of other chapters. Coming soon, you can expect more coverage of core Seam as well as using Seam with Groovy, Rules-based Security, JBoss Cache, Quartz integration, and much, much more. If you are planning to attend TSSJS, I look forward to seeing you there! Michael will be presenting so be sure to attend his presentation.

Stay tuned for more updates!

Posted in JBoss Seam, JBoss Seam 2E News 12 Comments »