Andy Gibson » Netbeans

Create A New Project With Maven Archetypes

Andy Gibson — Sun, 01 Aug 2010 16:50:12 +0000

Prerequisites

Install Maven

In this tutorial, we will create a new project using the Knappsack Archetypes and compile and deploy it. For this example, we will use the jee6-basic-archetype. Before you begin, you will need to have installed Maven, but you no longer need to manually install the Knappsack Archetypes as they are in the Central Maven Repository now, so you just need to make sure your index is up to date. These instructions will work for any Maven Archetype you have installed and creating new maven projects in general.

Maven archetypes can be thought of as templates that are installed into the Maven environment and can be used to generate new applications from scratch that are pre-configured for certain environments, whether it is Java EE 6, Wicket or Spring. We can create our project using either the command line or an IDE and both Eclipse and Netbeans both have support for Maven. Netbeans has it out of the box while Eclipse requires m2Eclipse to be installed. This tutorial covers all three methods of creating projects from Maven.

New project from the Command Line

Start by opening up a command prompt and navigating to the directory your project will reside in
The easy way to create a project on the command line is to just type
```
mvn archetype:generate
```
We will use the easier version where we don’t have to specify long command lines that include the group and archetype Ids and versions.

You will be greeted with a long list of possible archetypes with a number next to them and a prompt at the bottom to enter the number of the archetype you want to use.

4: local -> jee6-minimal-archetype (Minimal Java EE application with a single page demo of CDI, JSF, JPA and Validation to ...
5: local -> jee6-basic-archetype (Basic Java EE application with just configuration for CDI, JSF, JPA and a sample empty page.)
6: local -> jee6-sandbox-archetype (Sandbox project for Java EE 6 with CDI, JSF, JPA and a sample model and test data to play ....
7: local -> jee6-sandbox-demo-archetype (Complete demo example using CDI, JSF, JPA and validation showcasing a number of ...
8: remote -> docbkx-quickstart-archetype (null)
9: remote -> j2me-simple (Maven 2 Archetype for midlet application using j2me-maven-plugin)
10: remote -> vaadin-archetype-clean (This archetype generates a simple Vaadin application as a Maven project...
...
...
...
...
Choose a number: 65:

Hint : Your locally installed ones should be near the start of the list. The default number (in this case 65) is the quickstart archetype to produce and empty maven project.

Enter the number of the Knappsack archetype you want to use and press enter.

You will then be asked to enter a number of different properties for the project :

Define value for property 'groupId': : com.yourcompany
Define value for property 'artifactId': : yourprojectname
Define value for property 'version': 1.0-SNAPSHOT:
Define value for property 'package': com.yourcompany:
Confirm properties configuration:
groupId: com.yourcompany
artifactId: yourprojectname
version: 1.0-SNAPSHOT
package: com.yourcompany
Y:

Here we assumed the version is the default SNAPSHOT version and that the default package is the same as the groupId value.

Once complete, if you look in the directory you will see a new directory called yourprojectname. Move into this directory and if you have JBOSS_HOME set up you can deploy the project straight away.
```
mvn clean package jboss:hard-deploy
```
Start up JBoss if it isn’t already and go to http://localhost:8080/yourprojectname/home.jsf.
You can now import this project into an IDE such as Eclipse or Netbeans as these IDEs recognize Maven projects

Alternatively, you can use the command line to enter one long command, or as I do, put it in a script or batch file that I can edit in a text editor and run it from there. Here’s an example to get you started which you can copy and paste:

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

Creating a project in an IDE

Creating a Maven project in an IDE is much easier, although sometimes not by much. Typically, you choose to create a new project in the IDE and select maven as the type of project you want to create.

Netbeans

Select File->New Project and in the first list, select Maven and on the right hand side, select Maven Project (not Maven Web Application). Click Next.
Here we will pick our archetype to create our application from. In the list, expand the Archetypes from Local Repository item in the list. If you don’t see the archetypes there, you might need to refresh the index in the IDE. Close the new project window to do this.
1. Select Window->Other->Maven Repository Browser to open the repository browser.
2. In the repository browser window, right click on the repository and select Update Index.
Now you should be able to start the new project from scratch and see the missing archetypes.

Once you have selected the archetype, click finish to setup the project properties.
The project properties are the group and archetype Id for the new project as well as the optional default package name.

You will also configure the project location here and click Finish when done.
Once complete, Netbeans will create your project and open it up. To run it, click Run->Run Main Project and it will prompt you for a Java EE 6 server to use. Select one and click ok. Remember that you need to change the datasource name in persistence.xml so it is not looking for the JBoss default datasource name.

Eclipse

First make sure you have m2Eclipse installed and are running Eclipse under a JDK instead of a JRE. For more details see this Installing and configuring Eclipse tutorial.

In Eclipse, click on File->New->Other.. to bring up the dialog for new projects and start typing “maven” in the search box

Select the maven project item from the list and click Next.
This page lets you determine where the project will reside. Leave the defaults, but make sure the “Create simple project” option is unchecked and click Next.
Here we will pick our archetype which in this case is our Knappsack jee6 minimal archetype. Start typing “knappsack” in the list and you will see the list of available Knappsack archetypes. Again, it is possible that the IDE’s index of the local repository is not up to date and needs a refresh. You will need to cancel the project creation window to do this.
1. Select Window->Show View->Other and in the view selection , start typing “Maven” until you see the window “Maven Repositories”. Select this to open up the view.
2. In the Maven Repositories view, expand the Local Repositories item and right click click on the Local Repository (pathname) item and select Rebuild Index. Confirm that you want to rebuild the index and wait a few moments.
3. Restart the project creation and this time you should see the archetypes you are looking for.
Select the archetype you want to create and click Next.
Now we need to enter the project configuration information, what our project is called, give it a group id, version and default package.

Once the above information is entered you can click Finish and Eclipse will work away at creating your project
To run the project, the easiest way is to install a server in Eclipse (see Tutorial on adding servers in Eclipse) and add the new project to the server. Start the server and navigate to your main page to see it in action.

Getting Started with CDI part 2 – Injection

Andy Gibson — Tue, 22 Dec 2009 13:45:20 +0000

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 Part 1
Read Part 2
Read Part 3

Last Time

Last time we looked at setting up the development environment and creating our EE6 application in Netbeans and deploying it to Glassfish v3. This time, we’ll skip straight to writing code which can be put into either a new Netbeans project using the previous tutorial, or you can use the existing project and just add the new code.

The ‘I’ in CDI

CDI is an API for injecting contexts and dependencies which is the part we’ll turn our attention to now. In Seam and Spring dependencies worked mostly by naming beans and binding them to their injection points by their name. So far we have only referenced a managed bean by name from the JSF page when we defined the name for the bean using the @Named annotation. The primary role of the @Named annotation is to define the bean for the purpose of resolving EL statements within the application, usually through the JSF EL resolvers. Injection could be performed by using names, but this was not how injection in CDI was meant to work since CDI gives us a much richer way to express injection points and the beans to be injected into them.

Let’s look at an example which is somewhat contrived. We have a dao that returns a list of objects that need validating, and for invalid ones, we take a certain action. Here’s the definition for the item.

package eedemo;

public class Item {

    private int value;
    private int limit;

    @Override
    public String toString() {
        return super.toString() + String.format(" [Value=%d, Limit=%d]", value,limit);
    }

    /*
    getters and setters omitted
    */
}

The ItemDao interface defines how we get the list of item objects. In this test application we anticipate using multiple implementations so we will code to interfaces.

public interface ItemDao {

    List fetchItems();

}

The ItemProcessor is our main class that we will inject our beans into and execute the process from. For now, we will start with the Dao and look at how we will inject it into our processor bean.

import java.util.List;
import javax.inject.Named;
import javax.enterprise.context.RequestScoped;

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private ItemDao itemDao;

    public void execute() {
      List  items = itemDao.fetchItems();
      for (Item item : items) {
          System.out.println("Found item "+item);
      }
    }
}

We’ll start with a simple Dao that just creates a list of items and returns a fixed list of items.

public class DefaultItemDao implements ItemDao {

    public List fetchItems() {
        List results = new ArrayList();
        results.add(new Item(34, 7));
        results.add(new Item(4, 37));
        results.add(new Item(24, 19));
        results.add(new Item(89, 32));
        return results;
    }
}

In order to inject the DefaultItemDao into our ItemProcessor we add the javax.inject.Inject annotation to the ItemDao field to indicate that this field is an injection point.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject
    private ItemDao itemDao;

    ...
}

Finally, we need some way to call the execute()ItemProcessor. We can run this in a SE environment, but for now we’ll keep it in a JSF page. We’ll add a new page with a button to call the execute method called process.xhtml.




    
        Item Processor

If you open up the page at http://localhost:8080/ee6demo/faces/process.xhtml you will see just a button that when clicked lists the items from our default Dao implementation in the console.

INFO: Found item eedemo.Item@23cbc6 [Value=34, Limit=7]
INFO: Found item eedemo.Item@a40279 [Value=4, Limit=37]
INFO: Found item eedemo.Item@19e6292 [Value=24, Limit=19]
INFO: Found item eedemo.Item@1597bc4 [Value=89, Limit=32]

We created a class which implements the ItemDao interface and when the application was deployed our managed beans in the module were processed by the CDI implementation (again because of the beans.xml file in the module. Our Inject annotation specifies that we want to inject a managed bean into that field and the only thing we know about the bean to inject is that it must implement ItemDao or some subtype of that interface. In this case, the DefaultItemDao class fits the bill perfectly.

Let’s say we add another Dao class to our application which also implements the ItemDao interface, now the choice isn’t so clear as to which bean we want to inject.

public class AnotherItemDao implements ItemDao {

    public List fetchItems() {
        List results = new ArrayList();
        results.add(new Item(99, 9));
        return results;
    }

}

We now have two classes the implement this interface and predictably, Weld gives us an ambiguous dependency error meaning that it cannot determine what bean to use for that injection point. Most, if not all of the errors that can occur with regards to CDI injection in Weld are reported at deployment time, even down to whether beans are missing a Serializable implementation.

Caused by: org.jboss.weld.DeploymentException: Injection point has ambiguous dependencies.
Injection point: field eedemo.ItemProcessor.itemDao; Qualifiers: [@javax.enterprise.inject.Default()]; 

Possible dependencies: [eedemo.AnotherItemDao, eedemo.DefaultItemDao]

We could make our itemDao field in the item processor a type that matches one of the implementation types (AnotherItemDao or DefaultItemDao) since it would then match one and only one class type. However, then we would lose the benefits of coding to an interface and find it harder to change implementations without changing the field type. A better solution is to instead look at CDI Qualifiers.

Qualifiers

A CDI qualifier is an annotation that can be applied at the class level to indicate the kind of bean the class is, and also at the field level (among other places) to indicate what kind of bean needs to be injected at that point.

When CDI inspects an injection point to find a suitable bean to inject it takes not only the class type into account, but also any qualifiers. Without knowing it, we have already used one qualifier which is the default qualifier called @Any. Let’s create a @Demo qualifier which we can apply to our DefaultItemDao implementation and also to the injection point.

package eedemo.qualifier;

import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.METHOD;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.inject.Qualifier;

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

}

First, we’ll add this qualifier to our default dao implementation at the class level.

@Demo
public class DefaultItemDao implements SomeDao {

    public List fetchItems() {
..
..

If you save and deploy this file now, you may notice that we don’t have any errors, and if you go to the web page and click the execute button, you can see that in the console, it displays the list of items from the AnotherItemDao dao (remember we annotated the DefaultItemDao implementation but not the injection point). By adding the Demo qualifier to the default dao implementation, we made the other implementation a more suitable match for the injection point as it matched on type and on qualifiers and the DefaultItemDao has a qualifier that is not on the injection point making it less suitable.

If we add the Demo annotation to the injection point and deploy it, when we click our button we use the default implementation again. This is because we are matching based on type and qualifiers and the DefaultItemDao is the only bean with both the correct type and the Demo annotation.

Alternative Injection Methods

There are multiple ways to define an injection point on the injected class. So far we have annotated the fields that will reference the injected object. You do not need to provide getters and setters for field injection. If we wish to create immutable managed beans with final fields, we can use injection in the constructor by annotating the constructor with the Inject annotation. We can then apply any annotations to constructor parameters to qualify beans for injection (of course, each parameter has a type that can assist in qualifying beans for injection). A bean may only have one constructor with injection points defined, but it may implement more than one constructor.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private final ItemDao itemDao;

    @Inject
    public ItemProcessor(@Demo ItemDao itemDao) {
        this.itemDao = itemDao;
    }
}

We can also call an inialization method which can be passed the beans to be injected.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private ItemDao itemDao;

    @Inject
    public void setItemDao(@Demo ItemDao itemDao) {
        this.itemDao = itemDao;
    }
}

While in the above case we used the setter method for initialization we can create any method and use it for initialization with as many beans as we want in the method call. We can also have multiple initialization methods in a bean.

    @Inject
    public void initBeans(@Demo ItemDao itemDao,@SomeQualifier SomeType someBean) {
        this.itemDao = itemDao;
        this.bean = someBean;
    }

The same rules apply to bean matching regardless of how the injection point is defined, it will try and find the best match based on type and qualifiers and will fail on deployment if there are multiple matching beans or no matching beans for an injection point.

Let’s look at the other aspects of our application, we get a list of items, iterate through them and test each one and if it fails that test, we pass it on to an error handler. We’ll create an ItemValidator interface to determines whether an item is valid or not.

public interface ItemValidator {
    boolean isValid(Item item);
}

We’ll expand our ItemProcessor class to incorporate the new feature.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject @Demo
    private ItemDao itemDao;

    @Inject
    private ItemValidator itemValidator;

    public void execute() {
      List  items = itemDao.fetchItems();
      for (Item item : items) {
          System.out.println("Item = "+item+" valid = "+itemValidator.isValid(item));
      }
    }
}

Our first implementation will be DefaultItemValidator which will simply test the limit against the value.

public class DefaultItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < item.getLimit();
    }
}

If we save our changes, go to our web page and click our button, in the console you will see that our items are being validated and the only valid item is where the value is less than the limit.

INFO: Item = eedemo.Item@25dd89 [Value=34, Limit=7] valid = false
INFO: Item = eedemo.Item@1f37ca2 [Value=4, Limit=37] valid = true
INFO: Item = eedemo.Item@7b8d67 [Value=24, Limit=19] valid = false
INFO: Item = eedemo.Item@18075da [Value=89, Limit=32] valid = false

Now lets consider the scenario where we have a deployment to a different site that is more relaxed and considers an item invalid only if the value is more than twice the limit. We may want to have another bean that implements the validator interface for that logic.

public class RelaxedItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < (item.getLimit() * 2);
    }
}

Now we have an ambiguous dependency problem since we have two classes implementing the same interface. The only difference is based on deployment so for most deployments, we want to use the default, but for one deployment, we want to use the relaxed implementation. CDI offers the use of the Alternative annotation which lets you package multiple beans that match an injection point without ambiguity errors, and the bean to use is defined in the beans.xml. This means you can deploy both implementations in the same module with the only difference being the beans.xml definition which can change over different deployments.


@Alternative
public class DefaultItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < item.getLimit();
    }
}

and

@Alternative
public class RelaxedItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < (item.getLimit() * 2);
    }
}

If we deploy our application now, we will get an unsatisfied dependency error since we defined the two matching beans as alternative but we didn’t enable either of them in the beans.xml file.



    
        eedemo.RelaxedItemValidator

This tells CDI that for this deployment we want to use the RelaxedItemValidator. You can think of the alternative annotation as effectively disabling the bean making it unavailable for injection, but allowing the implementation to be packaged with the other beans. Adding it as an alternative in the beans.xml file effectively enables the bean making it available for injection. By moving this type of metadata to the beans.xml file, we can bundle different versions of the file with different deployments.

Handling Invalid Items

Continuing the example, invalid items are sent to the ItemErrorHandler as they are discovered.

public interface ItemErrorHandler {
    void handleItem(Item item);
}

Let’s start by implementing a fake handler that saves the item details to a file. We want to open the file before we start handling items, leave it open for the duration of the process as we add content to the file, and then close the file when we are done with our processing. We could manually add initProcess() and finishProcess() methods to the error reporter bean, but then we couldn’t code to the interface since the caller would need to know about those class specific methods. We could add those same methods to the ItemErrorReporter interface but then we would have to unnecessarily implement those methods in every class that implements that interface. Instead, we can use some of the lifecycle annotations from the Managed Bean spec to call methods on the bean at certain points in the bean lifecycle. A PostConstruct annotated method is called when the bean has been constructed and any dependencies the bean has have been injected. Likewise, a PreDestroy annotated method is called just before the bean is disposed of by the container.

public class FileErrorReporter implements ItemErrorHandler {

    @PostConstruct
    public void init() {
        System.out.println("Creating file error reporter");
    }

 @PreDestroy
    public void release() {
        System.out.println("Closing file error reporter");
    }

    public void handleItem(Item item) {
        System.out.println("Saving "+item+" to file");
    }
}

Our final change is to add the item error handling into our ItemProcessor bean.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject @Demo
    private ItemDao itemDao;

    @Inject
    private ItemValidator itemValidator;

    @Inject
    private ItemErrorHandler itemErrorHandler;

    public void execute() {
      List  items = itemDao.fetchItems();
      for (Item item : items) {
          if (!itemValidator.isValid(item)) {
              itemErrorHandler.handleItem(item);
          }
      }
    }
}

When we run this from our browser we see the following in the console ;

INFO: Creating file error reporter
INFO: Saving eedemo.Item@d8b01e [Value=34, Limit=7] to file
INFO: Saving eedemo.Item@12a5e8 [Value=89, Limit=32] to file
INFO: Closing file error reporter

Next Time

Different application deployments might use different rules for handling invalid items. such as rejecting the item, to sending notifications to individuals or just flagging them or listing them in an output file. In addition, we may want to do a combination of these (reject an order, send email to the sales rep, and list it in a file).
One great way to handle this kind of multi-faceted problem is using events which we’ll look at next time.

Click to view getting started with jsf 2.0 and CDI part 3

Getting Started with JSF 2.0 and CDI in JEE 6 part 1

Andy Gibson — Wed, 16 Dec 2009 14:20:03 +0000

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 Part 1
Read Part 2
Read Part 3

Getting Netbeans and JEE6

First download the latest version of Netbeans (at the time of writing 6.8 has just been released). Make sure the download version you choose includes Glassfish V3 and java web and EE. Once downloaded, install it and get it up and running and we can start writing the application.

Starting the Project

Once Netbeans is up and running, start a new web project by clicking New Project and select the Java Web category and select a Web Application project and click next.

Give the new project a name (I called mine ee6demo) and a directory and click next. On the server settings, Glassfish v3 should already be selected so select next. In this tab, make sure Java Server Faces is selected and stick with the defaults in the lower panel that appears when you select it.

You can now click finish and Netbeans will create the project and open it up for you in the IDE. On the left you can see the project explorer and in the main tab you can see a file called index.html. Without doing anything, open the Run menu in the main menu and select “Run Main Project”. After a moment of activity and console logging a web browser window should open up with the message “Hello From Facelets” which is exactly what we can see in the index.xhtml file. So far, we haven’t done anything and we already have a working web application shell.

Just take a moment and look at the tabs on the left hand side, you should see Project,Files, and Services. Click on the services tab and expand the Servers node and you should see the Glassfish server we are using with a little green arrow on it indicating that the server is running. For now, we don’t need this because we aren’t actually going to deploy to the server again, no restarts and no manual deployments, so go back to the projects tab on the left.

Adding some code

In the projects tab, expand the “Source Packages” node and right click and select New->Java Class. Give the class the name MessageServerBean and a package name (I used eedemo). We annotate the class with the javax.inject.Named annotation and a single method to return a string.

package eedemo;

import javax.inject.Named;

@Named
public class MessageServerBean {

    public String getMessage() {
        return "Hello World!";
    }
}

This a managed bean as defined by CDI which in Glassfish v3 is implemented using Weld from JBoss. One thing we need to do now is tell the server that this project is a module containing CDI beans. We add a file called beans.xml to the project in the WEB-INF folder. Right click on the WEB-INF folder in the project manager in the ee6Demo/Web Pages/folder and select New->XML Document. In the file name editor, just call it beans, not beans.xml as the IDE will add the xml extension for you and if you add the xml extension, the file will be called beans.xml.xml (I’ve often tripped myself up with that one!). Open the beans.xml file in the editor, and select all the text and delete it so it is an empty file. You could alternatively just put . (Note This file can be used to specify bean related information in xml so you aren’t limited to annotations)

The last change is to edit the index.xhtml and replace the “Hello From Facelets” with our own text.

        Message is : #{messageServerBean.message}

        Message Server Bean is : #{messageServerBean}

Save it and go to your browser and refresh the page (http://localhost:8080/ee6demo/).

Message is : Hello World!
Message Server Bean is : eedemo.MessageServerBean@xxxxxxx

You should now see the message from the bean displayed on the page. Now go back into your message bean and change the message to something else (I used Hello From Weld!), save the file and then refresh the browser. Your new message appears automatically since your application code has been hot deployed automatically by Netbeans . If you don’t see your changes just give it a second and refresh again.

From the second line in our page you can see that the class name is eedemo.MessageServerBean and the bean is just a pojo. Even though this is JEE, there is no complex class hierarchy wrapped in layers of transactions, interceptors and all that ‘Heavy’ stuff you keep hearing about.

What’s going on?

When the application is deployed, the presence of a beans.xml file signals that this module contains CDI managed beans so the classes on the path are scanned for CDI annotations. Our bean was annotated with the @Named annotation and so this class was registered with Weld (under that name) (edit in a CDI module, all beans are registered with Weld, the named annotation is just used to match beans to injection points). When our JSF page was rendered, JSF tried to resolve the value of messageServerBean in the page using the registered expression resolvers in JSF. One of these is the Weld EL Resolver which has the MessageServerBean class registered under the name messageServerBean. We could have specified a name with the annotation, but since we didn’t it was registered under the default name of the class name with a lower case first name. The Weld resolver returns an instance of this bean in response to the request from JSF. Bean naming is only needed when using EL expressions and should not be used as the default mechanism for injection. CDI provides type safe injection by class type and stereotypes or qualifiers as we’ll see later.

Upgrading to an EJB

As we are using a JEE stack, we can easily deploy our bean as an EJB with some small changes thanks to EJB 3.1. Just open up the MessageServerBean and add the javax.ejb.Stateless annotation at the class level. Again, just save the file and go to your browser and refresh (no manual deploying, just save the file), and you should see something like :

Message is : Hello From Weld!
Message Server Bean is : eedemo.__EJB31_Generated__MessageServerBean__Intf____Bean__@xxxxxxx

Amazingly, we turned our pojo bean into a fully featured EJB with just one annotation, we saved it, and refreshed our page and our changes appeared, we don’t have to create any weird project configurations, local interfaces or arcane deployment descriptors.

Different EJB types

You can also try using the @Stateful annotation (don’t forget to implement the java.io.Serializable interface in the bean as it needs to be able to passivate (edit This isn’t necessary for it to be an EJB, but it is necessary if you want it to be session or conversation scoped)). Alternatively, you could try the new @Singleton annotation for singleton instances. If you do, you may notice that there is a javax.ejb.Singleton and javax.inject.Singleton. Why two Singleton annotations? A single annotation in CDI lets you define a singleton instance outside of EJB in case you are using CDI in a non-EJB environment. An EJB singleton will have all the features of an EJB such as transaction management so you have the choice depending on your needs and whether the environment is EJB or not.

In this first part, we have created a new JSF 2.0 application, made it CDI enabled and added a managed bean which we then referenced from the web page. In part 2, we’ll start looking at creating more complex beans and injecting them into and with other beans.

Click to view Part 2

Java EE 6 Is Here

Andy Gibson — Fri, 11 Dec 2009 00:13:19 +0000

Like Christmas come early, Sun announced the release of JEE 6. This release sees continued improvement in the JEE stack with the inclusion of JSR 299, Java Contexts and Dependency Injection (CDI), and EJB 3.1 as well as JSF 2.0, and JPA 2.0. JSF especially has seen changes as a result of practical user feedback and community add-ons such as Seam and JSF Ajax frameworks which have contributed back to the JCP.

Glassfish v3 which implements the full JEE 6 stack has also been released, with JBoss’ Weld as the CDI implementation. Netbeans 6.8 has also been released with full JEE 6 project support including maven support for enterprise applications. Also of note is the hot deploy function of Glassfish which can deploy your app while maintaining session information.

Personally, I’m pleased. JEE 6 has really improved things for the java standards, and CDI has filled some gaps that previously required different additional pieces to completely fill. The ghosts of EJB 2.1 should now be permanently laid to rest, but should serve as a stark reminder. Having good frameworks to build standards based solutions is always good for the community.

I’ll try and get some tutorials on developing with CDI and JSF 2.0 with Netbeans and Glassfish out soon.

Glassfish, Netbeans and JSF 2.0 Test Drive

Andy Gibson — Tue, 03 Nov 2009 04:32:44 +0000

I’ve spent some time in the last couple of weeks playing around with Glassfish, Netbeans 6.8 Beta (and milestone 2 before it) and JSF 2.0, and I have to say that this is turning out to be a really good set of development libraries and tools.

(note This post relates to both the milestone 2 and beta versions of Netbeans 6.8 which I have been tinkering with over the duration of this article being written.)

The download for Netbeans 6.8 comes with Glassfish v3 which implements JEE 6 including JSF 2.0 and JPA 2.0.

Glassfish now has really fast hot deployment so you can change a line of code, save it, and it re-deploys instantly which in my opinion, this is a huge productivity booster. This isn’t limited to Netbeans, the eclipse plugins also provide this feature, and it works with pretty much any framework. I tried it with Wicket and Spring MVC and it was fantastic to get a wicket error where I had forgotten to add a component, so I go back to the java page code, add the component, refresh my browser and it works. Glassfish now has support for JEE 6 so you can make a pojo a local EJB just by adding the @stateless annotation to it. You can also deploy EJBs in war files as well without needing the whole EAR setup. One problem I did see was that when you used the EAR project setup with an EJB and War project, the hot deploy didn’t appear to work as well. Changes to the war file didn’t appear to redeploy, maybe because it is the EAR file that is deployed and not the war. However, still fantastic stuff.

Netbeans 6.8 beta was released in the last week or so. Feature-wise it is a great product with better tooling for JSF, including JSF 2.0, facelets support, and auto-completion for JSF backing beans in the JSF page. It also includes support for JEE 6, EJB 3.1, JPA 2.0 and development with Glassfish v3. It also improves upon the existing Maven support by providing for mavenized Ear projects.

While the features are impressive, Netbeans still seems hindered by performance issues and some minor bugs (although it is a milestone/beta release). Personally, I found this release no more sluggish that other releases although some people in the forums have had worse experiences. Netbeans strength has always been that it offers one standard solution without the plugin nightmares that eclipse has. While Netbeans has plugins they are more like installable features, they have a higher granularity than Eclipse plugins which is more like DLL hell. That said, I use Eclipse at work and it is always hard to shift from one keyboard mapping to another, and Eclipse does seem faster without the intermittent pauses. However, right now, Netbeans is a superior product in terms of features, especially for a JSF developer. I’d keep an eye out for the 6.8 final release to see how it comes out, and give 6.8 milestone 2 a go just to enjoy the experience if you are interested in using a standards based stack because thats obviously where the Netbeans folks are focused.

One big issue I have with Netbeans is the oddness of some of the key mappings. I think in nearly every application I use I press Alt+F and then C to close the currently edited document. Whether is it in MS Office, Borland Delphi, Eclipse, Firefox, while in the file menu, the C key always closes the currently open document you are editing. In Netbeans, it closes the currently edited project which means suddenly my project disappears when I want to close an edited file. Another is the use of Ctrl+Space for invoking auto completion which in Netbeans sends focus to the project manager or something like that. Sure, I can change the keymappings, such as to the Eclipse profile, but then I’m using some arbitrary weird key mapping which isn’t Netbeans and it isn’t completely the same as Eclipse. It is probably this way for legacy reasons, but some of these key presses are de facto standards.

Lastly, we come to JSF 2.0 which was forged from JSF 1.2 and the litany of complaints about it. The JSR group looked at the solutions out in the wild that already work around those problems (many of which were written by people in that very group) and incorporates those fixes in a standard JSF API type of way. Primarily we have the dropping of JSP as the default view in exchange for the Facelets / JSF templating solution. This also lent itself very well to easier component creation including no-code components. There is now zero configuration required except for the servlet in web.xml and managed beans can now be defined using annotations. Navigation which also used to be in the faces-config.xml is also more convention of configuration. Another big request was the inclusion of AJAX awareness in the JSF lifecycle . It provides the bare minimum features that 3rd party developers can build upon using the standard API instead of their own AJAX solutions. There is better support for GET requests and page parameters as well as invoking actions on page requests which is a feature often used in Seam.
There is also some performance boosts with regards to re-working state saving and the resource access mechanisms have been improved a great deal.

Also noteworthy is the inclusion of Weld CR 1 which is the reference implementation of JSR 299 – Java Contexts and Dependency Injection from JBoss. Admittedly, I haven’t really gotten round to taking a look at it, but from what I have seen and read so far, it looks like it fills some gaps in the JEE 6 platform and is up to par with the new found simplicity and strength that JEE 6 is promoting right now.

Overall, this is a pretty exciting set of tools and framworks and well worth a look if you are interested in adopting a standards based stack.