At various points throughout the show, there have been numerous dead bodies and with it, a strong urge to bury the dead. Consider even when Rousseau and Karl were shot by Mercenaries, they took the time to bury the bodies, and it’s not like their arrival was going to be a secret for long. in LaFleur, when Sawyer and Juliet killed the others attacking Amy, they had to bury the bodies in accordance with The Truce. Now this might be a way to hide the killings, but it also may mean that any dead bodies must be buried. After The Purge, the bodies were put in a shallow grave, but not covered.

Christian Shepherd’s body, like John Lockes body was on its way to be buried, we have no confirmation that Alex was buried. Yemi’s body wasn’t buried when the plane crashed although Eko burned the plane but Yemi’s body was mysteriously missing. Sayid technically did die and was not buried. Claire, if she did die wasn’t buried either.

So far it seems all of these bodies have been taken over or manipulated by the Smoke Monster/the Man In Black. My thinking is that when bodies are not buried, they are available for claiming by the Man In Black / Smokey, hence the need to ensure that any dead bodies are not left above ground to provide a shell for the MIB to manipulate. Yemi, Locke, Christian (probably) and maybe Claire have been affected by Smokey / MIB to some degree. Incidentally, this could also be a theory for Adam and Eve. One dark, one light, one for the Mib and one for Jacob for the next iteration. I also seem to recall that someone made the comment that the dead on the island tend not to stay dead or some similar phrase.

Numbers Up

Throughout the show, the numbers have been one of the most intriguing mysteries of all. The writers have said a couple of times that there might never be an explanation for the numbers.
at a certain point, explaining something mystical demystifies it. To try and have a character come and say, “Here is what the numbers mean,” actually makes every usage of the numbers up to that point less interesting. – Damon Lindelhof

Within the show, the numbers have been a consistent factor all along and while I am willing to concede absolutely that many occurrences of them is just pure coincidence (like the soccer shirts at the airport and hotel rooms), I think there absolutely is some need to explain their meaning. I think it goes beyond coincidence that the same numbers that were imprinted on the hatch end up being broadcast from the island for decades and were entered into the computer for so long. Why not just have the swan operator press the enter key every 108 minutes, why enter anything at all? Why even bother imprinting the numbers on the hatch if there is no relevance? It’s like writing the show so that every character is called Mike. It’s either relevant to the purpose they are there or just bloody stupid if you put it down to coincidence. With the last couple of weeks we have seen an introduction of the numbers again assigned to people and even angles on the lighthouse mirror so hopefully we will get the complete answer to the numbers.

The Loophole

So, it seems that Jacob and the Man In Black have been playing the same game over and over and this time the MIB finally found a way to kill Jacob. He asks Jacob if he has any idea what he had to go through which raises the interesting question of how long has MIB been manipulating the game? It seems smokey may have been on to John when they first encountered each other in Walkabout which was the fourth episode. John saw something beautiful, perhaps it was his own spiritual reflection, or perhaps it was smokey showing Locke what he needed to see (a common theme in Lost). One quality MIB needed was Locke’s desire to stay on the Island if he was to go off Island, die and bring everyone back. I’m sure there were other rules regarding who who could kill Jacob and how and why. Obviously, MIB couldn’t just kill Ben and then impersonate him as the leader of the others, get an audience with Jacob and then kill him especially since Ben had never had an audience with Jacob so how could he? The MIB had to promote John Locke up to the level of leader in such a way that he would be allowed to see Jacob, along with the requirement that Locke be that special someone who was the right kind of person to lead the Others and be so in tune with the Island that he would get to see Jacob. If this is the case, then it allows one to re-watch Lost with fresh eyes, spotting the places where Locke, and the Others were manipulated along, where Locke was encouraged forwards to the point where he would find his own destiny on the Island, but then meet the needs of returning to the Island dead so the MIB could then assume his identity and role and then manipulate Ben into wanting to kill Jacob. Perhaps MIB has been masquerading as Jacob for the purpose of ignoring Ben to prime the pump so to speak since we know someone else was using Jacobs cabin and he only showed himself to Locke to set the ball rolling.
I think we need to learn a little more about the rules in order to start drawing up what the MIB needed to do in order to create the loophole and how he did it. What would be mind blowing is if along with MIB manipulating the whole show we found out that Jacob had been manipulating the whole show so he could defeat the MIBs plans. After all, in the lighthouse, Jack was outraged that Jacob had been watching him and setting this up his whole life. Perhaps they both have been manipulating the viewers for the whole show. Perhaps Jack is Jacobs hope the same way Locke was MIBs hope, after all Jack versus Locke has been another common thread.

Random Mysteries

Here’s some random mysteries that I keep thinking about and will hopefully get answered.

• Why broadcast the numbers/enter them into the computer, whats the relevance?
• What’s with the psychic who advised Claire
• Why were all those tubes from the Dharma observation station being dumped in the middle of nowhere
• Why can’t women get pregnant?
• What happened to Anne? (Darlton claimed she and the volcano were important)
• What was the deal with Jin taking that watch to LA?
• I’m sure there’s more to Cindy than we know
• Will we see a Libby backstory?

Even as we start to draw down the show in the final season, we still keep getting fresh mysteries, such as who is Jacks ex-wife in the alternative timeline?

Back to the Beginning

Interestingly, we seem to be redoing the first season again. Many of the issues are cropping back up, Shannon’s inhaler, the caves, Adam and Eve, treks into the jungle with Jack and Hurley. Also, the central character for the episode that we see flash sideways for mirrors the season 1 order with Kate, Locke and Jack and Sun is next in both Season 6 and Season 1. It should be interesting the week after since that was a Charlie centric episode. One of the biggest earliest questions was “What is the smoke monster?”, after all it was introduced in the first episode. Darlton commented that we wouldn’t find out till the very last episode. I thought, like many others, he was joking but it seems that this is indeed the case since the MIB (along with Jacob) seems to be final mystery that encapsulates all others and probably will only be answered in the finale.

The parallels with Season 1 casts fuel on to the fire that the whole thing will end with a reset and start at the beginning, but that would seem a rather cruel and clumsy way to end it. Perhaps we see the start of the next iteration with the next group of Losties arriving at the Island. It would certainly open the door to another season or two or more likely, a spin off without having requiring the original actors or writers.

public class Person {

  private Long id;
  private String firstName;
  private String lastName;
}

public class User extends Person {

  private String userName;
  private String password;

}

public class Customer extends Person {

  private int creditLimit;

}

public class Employee extends Person {

  private Date beginDate;
  private Date endDate;

}

The classic problems here are that a customer may not always be a person, and a person may be both a customer and a vendor and possibly even be an employee and user. It also ignites the age old debate of whether a user must be an employee or all employees are also users. Using inheritance severely restricts us by taking away our one chance to inherit from a single class and limits our future plans since we are claiming some hard rules such as “every user is a person”.

Also, how do we handle a person that leaves the company and comes back? Do we have two different instances of this person in the system? For that matter, most Person instances will be duplicated if a person is a customer and a user and employee. This also leads to problems with things like name changes where one version gets updated but the other doesn’t.

Role your own

One common solution to this problem is to let the Person entity have a collection of roles that they perform so they can be either a user,an employee, a customer or vendor at the same time. This does solve the problems of not having to worry about inheritance hierarchies and whether a user is an employee or vice versa and also lets a person play all those roles at once. However, it only works where you know that every user, customer, vendor or employee will be a person.
It’s also not very clear how we should reference these entities. If I have an order and need to reference a customer, do I reference the person or the persons customer role?

Compose Yourself

Alternatively you can use composition to model the relationship instead of inheritance. We can define a Person class which models just a person and we model Customers and Employees as separate classes that encapsulate the information specific to that role and has a reference to the person associated with it.The benefit here is that the different classes do not have to be subclassed from the Person class which lets us inherit from whatever we want.

public class User {

  private Long id;
  private String userName;
  private String password;
  private Person person;
}

and

public class Customer {

  private Long id;
  private Person person;
  private int creditLimit;
}

public class Employee {

  private Long id;
  private Person person;
  private Date beginDate;
  private Date endDate;
}

We don’t have to worry about whether Employee should inherit from a User or vice versa since they are entirely different entities but they reference the same person instance. We still have the ability to check for things like users that are employees by finding users and employees that have a matching person reference. Modeling for each of the entities is kept specific to what the entity represents. A customer contains customer information and an employee contains employee information with only a single reference to the person it is representing.

This solves our original problems, but also gives us far more in return. It is a far more flexible design because we can expand the definitions of the classes beyond the hard restriction that every customer must be a person. Let’s consider a situation where the developers have been asked to allow businesses to also be defined as customers in the system. With the Customer subclassing from Person design it would be a nightmare to change the code to accommodate this. On the other hand, if we designed Customer to use composition, we can easily resolve the problem.

public abstract class AbstractCustomer {

  private Long id;
  private int creditLimit;
  public abstract String getName();
}

We can create a person based customer by subclassing it and adding a reference to the person.

public class PersonCustomer extends AbstractCustomer {

  private Person person;

  public abstract String getName() {
    return person.getName();
  }
}

For a company based customer, we can again subclass it, this time adding a Company reference.

public class CompanyCustomer extends AbstractCustomer {

  private Company company;

  public abstract String getName() {
    return company.getName();
  }
}

Notice that in the abstract base class, we define the getName() method to return the name of the customer. This is made abstract and must be implemented in subclasses specific to the type of customer we are implementing. As a general rule, like any inheritance, common attributes that apply to all types of the entity should go in the base class because then you will be able to call those methods on references to the entity as the base class type instead of having to use a more specific subclass type. For example

  String msg = "Hi There "+customer.getName();

is much cleaner than

  String msg = "Hi There ";

  if (customer instanceof PersonCustomer) {
    msg = msg+((PersonCustomer)customer).getPerson.getPersonName();
  }

  if (customer instanceof CompanyCustomer) {
    msg = msg+((CompanyCustomer)customer).getCompany.getCompanyName();
  }

Another nice effect of this is modularity since you can add new customer types and the old queries will work the same way. For example, if you start with PersonCustomer you might have a query which lists the customers with a certain credit limit.

select c from Customer c where c.creditLimit > 500

If you suddenly add the CompanyCustomer class to the application, the query will still work and will now include company based customers in the list. Remember, the more attributes defined on the base class, the more attributes you will be able access or query on when obtaining instances as the base class. However, note that code driven attributes such as the getName() example above cannot be used for querying in JPA since the attribute does not resolve to a database field. To query by person name you would have to drop down to using the actual class name to query the name fields in the person reference.

Unique People, non-unique references

If an employee leaves the company and comes back, we can deal with this much easier because we can set the end date for the existing Employee instance when they leave and when they come back, we can create a new employee instance that references the same Person entity. We still only have one Person instance that is referenced by both Employee instances and thus there is no duplication. This kind of modeling is not only more accurate in that one person was an employee on two different occasions, but it also provides a form of auditing trail for that person. If you store the Employee reference, you can still use either the person or the employee id to search for data. If you wanted to see what orders this specific employee had filled in, you can search using either the employee id which would get the orders for this version of the employee only, or you could match based on the person id and see what orders that person had ever filled in as either employee instance. This also reflects the real world better since there is only ever one person, but they could have multiple periods as an employee.

Modeling with JPA

It is fairly easy to model the basic composition in JPA by adding a @ManyToOne annotation to the entity reference (in this case the person).

If you plan on creating subclasses that are backed by different entities (i.e. PersonCustomer and CompanyCustomer) then you have to choose between different inheritance strategies. If there only a few differences between subclasses, you can probably just use a single table. If there are bigger differences between the subclasses, you might want to use a joined table inheritance strategy while keeping the core attributes of the parent class in the main table.

For legacy databases, you could be faced with the problem that the referenced entity id, such as the company or person id in the customer subclass, is stored in the same field in the database record. You can use the same field name for the reference in the subclasses and JPA will work with it.

public class PersonCustomer extends AbstractCustomer {

  @ManyToOne
  @JoinColumn(name="REF_ID")
  private Person person;

}

public class CompanyCustomer extends AbstractCustomer {

  @ManyToOne
  @JoinColumn(name="REF_ID")
  private Company company;

}

Obviously, this method eliminates the opportunity to use foreign keys since a foreign key cannot reference two different tables. New designs should not use this method for this reason even though JPA allows it. If you let JPA drop and create the tables for you, with Hibernate at least, you will end up with a foreign key on the REF_ID field to either the person or company table that will be incorrect when you assign the other subclass type to it. Through luck, it may not raise an error the first time around (if you happen to have an instance of one entity that has the same Id as the other entity type) but it will at some point.

If you really need this design, then you can just build the tables yourself without the foreign key, but you should use a separate field even though it means that each record will have blank field in it. With a separate or join table inheritance strategy, you have no choice but to use separate fields for the references.

A technique with many uses

This technique has many applications, but I haven’t really seen it discussed that much. Obviously, most published application examples (i.e. Pet store or my own Issue Tracker) are trivial or incomplete so they don’t really require this level of attention to modeling detail. However you start to find all sorts of places this technique can be used for larger domain models either to provide functionality needed now or a flexible design to meet future requirements. Obviously, we don’t want to use this for everything in case we want to extend any object in our model, but refactoring models once you have gone live can be problematic as it not only involves code refactoring, but database refactoring as well. Adopting this technique early (i.e. pre production) in places it is likely to be needed can save a lot of headaches later on.

As another example, let’s say you wanted to define a Location which is basically an address and a few other attributes. These locations can be used for all sorts of things in various places in the application. We already have an Address class used throughout our code and we can embed it in our Location.

public class Location {

  @Embedded
  private Address address;

  private Date createdOn;
  private String description;

}

Half way through your project you find that since this location class is used everywhere, the needs have changed somewhat and in some places need to have a dynamic address that belongs to a person and needs to be updated when the persons address changes, and some places need a static fixed address that never changes (i.e. delivery address an order was sent to which never changes).

We can easily implement this by creating a Location class that is subclassed into the different implementations that source the address from different places.

public abstract class Location {

  public Address getAddress();
  private String description;
  private Date createdOn;

}

public class FixedLocation extends Location {
  @Embedded
  private Address address;

  public Address getAddress() {
    return address;
  }
}

public class PersonLocation extends Location {

  @ManyToOne
  private Person person;

  public Address getAddress() {
    return person.getPrimaryAddress();
  }

}

Not only have we provided a solution for our fixed and dynamic address problem, since FixedLocation will store the address internally while the others will dynamically obtain the latest address from the Person, but we have provided a structure that will allow us to turn any entity into an address provider for our Location class. In some ways, we are using it as more of an adapter pattern since the address sources no longer have a common type. We are using an adapter pattern to make the different implementation sources fit with our Location interface.

I have found a number of uses for such compositions/adapters in places where inheritance would have severely limited my options or provided some difficult challenges, and by implementing this concept I’ve been able to make my models far more flexible and be able to accommodate new needs quickly.

Also in the comments of the announcement, Max Anderson notes that the nightly builds of JBoss Tools 3.1 now supports CDI auto completion and JSF 2.0. I had a very quick look at it yesterday and it looks promising. I also tried it out with the latest JBoss 6 snapshot and am very pleased to say that the redeployment times on JBoss 6 are much faster and more in line with the performance on Glassfish which is something I have raved about.

I’ll be looking at it some more and probably write up a couple of tutorial posts.

I don’t plan on doing blow by blow recaps since there are plenty around the web and I don’t have time so consider this some general thoughts over the last two episodes, LA X parts 1 and 2 and What Kate Does. I have some concerns over this whole alternate timeline/sideways flash. Incidentally, note how when transitioning between the main and alternate timeline we have a sucking jet engine sound as opposed to the sucking whoosh sound we had with the flashbacks for the first few seasons. The alternate time, and I’m not sure that is what it is, but let’s stick with that for now, has the losties landing in LAX and the island underwater. To me, that says that the bomb never went off and as a result, ‘the incident’ was the unhindered drilling at the swan hatch that probably ended up causing the Island to sink. In the main timeline, the losties on flight 815 crashed, fought the others, went back in time and blew up the swan hatch before the incident. Miles commented in “The Incident” whether anyone had thought that setting the bomb off caused the events of their future (the swan being built and their plane crashing). This solution not only makes sense, but is paradox free, and yet the writers in their pod cast last week said that the island sinking was because the bomb went off which is quite annoying.

So far, we have seen in the alternative timeline how things are similar, but different in small and subtle ways. I’m a proponent of Whatever Happened, Happened as opposed to the idea that the losties can change their future (and therefore their past). Once you open the door for alternate timelines you open the door for multiple timelines. Furthermore, the additional timeline would have always existed regardless of the actions of the losties on the Island so it really doesn’t make sense as to why we are seeing this particular timeline. There are probably timelines where 815 crashed on take off and Jack is a drug addicted rock star, Locke is a marathon runner and Charlie became a priest. Why show us this timeline? I think the answer lies in the fact that our losties in this timeline have some kind of link of conciousness to the main timeline as we see them have bouts of recognition and familiarity with the main time line. In LA X, I thought the writers were just messing with us in the initial scenes were we see Jack on 815 looking disoriented. However, What Kate Does, they make those links stronger. The name Aaron just pops into Claires head, Kate and Jack have a moment of recognition as she drives off in the taxi, and the friendship of Claire and Kate probably made it that much easier for Kate to be more sympathetic to Claire to go and help her. I therefore think that the writers will somehow pull these two timelines together somehow and the introduction of the new timeline is not accidental and arbitrary.

It is also worth noting that there might only be a single timeline and the start of LA X is where the ‘main’ timeline is leading to. If you ignore the ‘main’ timeline on the island, we are seeing the end of lost, i.e. what happens to the 815′ers if they never crash. It could be that the final episodes show us how the main timeline leads up to the start of the LA X ‘alternate’ timeline. This is possible if you consider that the island moves through time, although it mostly seems to move back in time which I think is relevant. If the losties start moving back in time as soon as they crash on the Island, the Island isolates them from the rest of the world as they pass back in time, therefore there won’t be two Jacks in the timeline because alternate Jack is travelling on a plane on October 22nd 2004 while main timeline Jack is shifting slowly back in time on an Island which will never cross paths with main timeline Jack. Perhaps that is how the island avoids detection, it moves through time and only stays in places where it knows there is nobody looking if you go for the idea of being able to see all time at once.

Anyway, I give the writers a 50/50 chance of pulling this all together in a sensible way. The fact that they already introduced a paradox regarding the bomb going off and sinking the island and the cherry picking of alternative universes is a bad sign though. Of course, we could be mis-interpreting this completely and the alternative story is very relevant to the main story and will merge seamlessly.

For a while there, I forgot it was a Kate centric story which usually means it blows, it’s not actually the Kate centric story that blows, it’s just that more screen time reminds us of how Kate is like the flame that Sawyer and Jack both fly close to. After 6 seasons, I’m sure there is going to be some allegory to how Kate is the axle that keeps the Jack and Sawyer wheels on the same track without which they would both fly off in different directions. However, after 6 seasons it’s hard to imagine that either of them would be interested in someone who changes her mind more often than her underwear (it’s an island people, there isn’t a lot of underwear).

WKD also introduced a few new mysteries, what did Kate do? She tells the garage mechanic she was wanted for murder, then tells Claire she’s innocent, which I might actually believe. It seems that so far, people in this timeline are much nicer. The interaction between Locke and Boone, and Locke and Jack was enjoyable to watch, even hinting there there is a mutual respect of each others beliefs in science and faith and even that they both have a healthy dose of each. Kate might even be innocent of all charges, Hugo thinks he’s lucky, and while Sawyer may not be squeaky clean, I think he’s in a much better place morally. I think Sawyer gave Hugo a genuine warning as opposed to the warning that was the opening moves of a con like he did in “Every Man For Himself”. Charlie is the only one who it seems is not better off, even to the point that in the alternate timeline, he is still destined for death by suffocation. The motto for Season 6 is Destiny Found, is this their destiny? Is all this about getting them to the point where the can continue onwards?

I was also very surprised that there actually was a family that Claire was supposed to meet. I suspected that the psychic knew the flight would go down and Claire would have no choice but to raise the baby instead of it being raised by another. Why else would he be so specific about the flight? Of course, this is the alternative timeline and he may have actually arranged someone to adopt Aaron since the plane wouldn’t be crashing. Unfortunately, I think “It’s an alternative timeline” is going to be the new scapegoat for any weird changes or unanswered questions. We still have to address the issue of ‘fake’ psychic Richard Malkin and his daughter Charlotte coming back to life screaming about John Locke.

Here’s a thought, the idea is that around October 22nd 2004, the timelines split or separated which introduced changes in the timelines. Let’s go back to the old mystery of the changing photographs and their frames in Mrs Gardner’s house when Miles comes to do his ghostbusting bit. That took place around the time the wreckage was supposedly found which could put it around a month after the crash. Perhaps these changes are a result of the same event that caused the splitting timelines on 22nd October 2004, we just didn’t realize it at the time.

It seems Locke gets back in on the action next week, and he might be up for manipulating Sawyer. I’m hoping that the story arc doesn’t have Sawyer end up the way he came onto the island. Prior to the crash, Sawyer had been manipulated into killing Frank Duckett by Hibbs who took advantage of the tragedy in his life. I’m hoping fake Locke doesn’t use the same mechanims to manipulate Sawyer into doing something stupid.

Still lots of mysteries to go, with new ones being added, and in true Lost fashion, most answered mysteries result in the addition of new ones.

It comes on a lightly toasted bun, on which they put a drop of tangy A1 sauce and a creamy mayonnaise type dressing and plenty of fried onion straws. Now, if they’ve done it properly the burger should have some pink to it but still be warm throughout and that is when you get a good juiciness to the burger. They’ve been a little bit inconsistent recently and not asked how I want the burger and sometimes I get it well done and other times I get it nice and pink-ish. Since they can’t decide on a default, just tell them you want it pink and warm throughout (medium as opposed to medium well).

When this thing arrives, you start by biting into the soft bun and then you plough through the onion straws which have a mildly crunchy fried texture and a slight sweetness from the onions. You then hit the soft mild (swiss?) cheese and the burger which is a patty of tender juicy beefiness with just the right crumbly texture to the burger and a juiciness that drips. In there somewhere is the tangyness of A1 which punctuates the other flavors now and again. These things are awesome and they are on the 2 for $20 menu (2 meals plus an appetizer for $20). I think they are grinding their meat fresh, and gently forming the patty so the meat doesn’t form into a tight beef puck which just gets tough.

Next time I plan on broadening my horizons and trying one of their other burgers (cowboy or cheese burger) to see if it is as good. The A1 burger doesn’t have bacon on it which normally should be an instant penalization, but regardless this burger is still so tasty. I used to have the cowboy burger (well done) but the toppings (onion rings, bacon and BBQ sauce) were tastier than the burger. I plan on trying it with the new improved burgers since perfect burger plus fantastic toppings could lead to an epic event!

(Update – 8th Feb 2010 – After taking my brother and Sister in law there, we found that a) They are thoroughly inconsistent, with the better burgers being the exception not the rule. b) Their service was crappy as they delivered appetizers, salad and the burgers in the space of 2 minutes after letting us wait for 10 minutes (Their problem, we planned on having a long meal and working our way through the cocktail menu). Also, they just got usurped by Michael Symon).

As a refresher, in our last part, we had an application that obtained a list of items, validated them and took a specific action when an invalid item was found. Lets say in the future we want to expand our system to handle all sorts of things happening when we find an invalid item. This could range from an email being sent, changes made to other data (i.e. an order canceled) or storing a list of rejections in a file or database table. To completely decouple the implementation we can use events. Events are raised by the event producer and subscribed to by event observers. Like most of CDI, event production and subscription is type safe and allows qualifiers to determine which events observers will observe.

Luckily we don’t have to change our application much to implement this, we just provide an implementation of the ItemErrorHandler that raises the event when it handles the item. We will inject an instance of the Item error handler called EventErrorHandler and create a @Notify qualifier to select it for injection.

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

@Notify
public class EventItemHandler implements ItemErrorHandler {

    @Inject
    private Event<Item> itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

In this item handler, we inject an instance of an Event where the event payload will be an Item. The event payload is the state data passed from the event producer to the event observer which in this case passes the rejected Item. When the invalid item is handled, we fire the event and pass in the invalid item we received. This event based item handler is injected the same as any other item handler would be so we can swap it in and out whenever we need to and also can substitute it during testing. We created a @Notify qualifier annotation to identify this error handler for injection and can use it in our item processor by adding it to the injection point.

    @Inject
    @Notify
    private ItemErrorHandler itemErrorHandler;

If we deploy this now, we will see that when the item processor hits invalid items, the event based item error handler fires the event. Currently though we don’t have anything observing the event. We can fix this by creating an observer method which is the only thing needed to observe an event. We can still re-use our existing item processors by adding an event observer method to the implementations which just calls the error handler method. For example, to make our FileErrorReporter respond to the event, we add the following observer event.

public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes Item item) {
        handleItem(item);
    }
    ....
    ....

If you run the application now, you will see that the events are fired on the invalid objects, and the item information is being saved when this event is fired. You will also note that the lifecycle events are being observed.

Note that the file error reporter bean is created each time the event is raised which may or may not be what we want. In this case, we don’t want to create the bean new each time since we don’t want to open and close the file for each item. We still want to open the file at the start of the process, and then close it once the process it completed. In this case, we need to consider the scope of the FileErrorReporter bean which doesn’t have a scope defined. When no scope is defined, CDI defaults it to the default pseudo dependent scope. What this means in practice is that the bean is created and destroyed over a very short space of time, typically over a method call. In our case here, the bean is created and destroyed for the duration of the event being fired. To fix this, we need to lengthen the scope of the bean by manually adding a scope annotation. We will make this bean @RequestScoped so once the bean is created the first time the event is fired, it will remain created for the duration of the request. Also, for any injection points that this bean is qualified to be injected to, the same bean instance will be injected. Here is the log when we make our scope change to the bean. Note that the bean is still only created when the event is fired.

Let’s take the events example a little further. Right now we are observing any event for an item but chances are, there may be different types of events in the system for the items. We want to be specific in which observers subscribe to which events. Luckily CDI provides for this in a similar manner to how we determine suitable beans for injection points by using typing and qualifiers.

First, lets create a problem for ourselves by firing events off for each item we validate by adding the following code to the item processor.

    @Inject
    private Event processorEvent;

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

This will fire an event for each item we process, but we don’t want the invalid item handler to subscribe to each of those events. If we do, we will see output like the following :

For each item, the file item handler observer is being called for each item because we aren’t distinguishing the kind of events fired when the item is processed and the kind of event fired when an invalid item is found. To differentiate between them we will create an @Invalidate qualifier to qualify the event for invalid items. This annotation will be placed on the event injection point and also on the observation point method.

@Notify
@RequestScoped
public class EventItemHandler implements ItemErrorHandler {

    @Inject @Invalidated
    private Event itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

@Save
@RequestScoped
public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes @Invalidated Item item) {
        handleItem(item);
    }

    ....

}

If you run the code now, you will see that we no longer call the file save handler for each item, even though we are firing the event for each item.

You can add an event observer to the item processor just to see the events are still being raised and can be observed.

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

    ....

    public void observeItemEvent(@Observes Item item) {
        System.out.println("Item event observed for item "+item);
    }
}

This will print a message whenever an event is fired so you can see that there is a difference between the two event subscribers and also that the more general version of the observer sees all events related to the item.

Events are a great way to decouple parts of the system in a modular fashion as you can add pieces that will subscribe to events with the event producer unaware of the observer as opposed to the even producer having to call the observer manually when events are not used. For example, if someone updates an order status, you could add events to email the sales rep, or notify an account manager if a tech support issue is open for more than a week. These kinds of rules can be implemented without events, but events make it easier to decouple the business logic. Additionally, there is no compile or build time dependency and you can just add modules to your application and they will automatically start observing and producing events. Additionally, observers and producers know nothing about each other, nor do they require any configuration for them to do so.

Scheduling the Processing

One last tidbit before we move on to creating CDI driven JSF apps is that for now we are running our code from a button in a JSF page but typically this is something that would get fired off on a regular basis. With the power of the EJB 3.1 scheduler we can do just that in a new class with few lines of code. We’ll create a new stateless EJB into which we’ll inject our ItemProcessor and add a method to call the execute() method which will be called at a scheduled time.

@Stateless
public class ScheduledProcessor {

    @Inject
    private ItemProcessor itemProcessor;

    @Schedule(hour="07",minute = "00")
    public void execute() {
        System.out.println("executing scheduled job!");
        itemProcessor.execute();
    }
}

This makes use of the new EJB 3.1 @Schedule annotation and will schedule this method to be called every morning at 7am. You could make it on the hour every hour, or you could use the EJB timer service to implement your own timeout. We inject the same ItemProcessor implementation we have been using all along and call the execute() method. That is a pretty powerful transformation letting us re-use our existing code and easily incorporating EJB services with POJO managed beans into an EJB needing only a few lines of code.

Note : If you actually implement this and run it, it won’t work because of a Weld 1.0 bug whereby the request scope isn’t active during calls to EJB timeouts (see here for details) so you’ll have to wait until Weld 1.01 which should be out fairly soon.

In summary, nested conversations do for regular conversations what conversations do for session scope. With session scope, you cannot have mutliple instances of a named variable, you have to put each variable instance in its own conversation where it will be unique. However, if you want to have multiple instances of a named variable within the conversation, again, you cannot and you have the same problem you have with the session scope, that variables must be unique. Therefore you have to have each variable in its own nested conversation under the main conversation the same way we had the top level conversation under the session scope.

In some weird web app which lets you pick a person and then put costumes on them, you might have a main page where you select the person, and then in separate browser windows you can pick different outfits for that person. You put the selected person value in a different conversation so the value of #{selectedPerson} is local to the conversation allowing multiple selected people in different browser windows. This overcomes the limitations of the session which allows only one value for #{selectedPerson}

However, if you had that conversation open in multiple windows or tabs so you can compare different costumes on that person, there would only be one value of #{selectedCostume} for the conversation shared between all windows. As you select a costume in one window, it would affect all the other windows as they share the variable in that conversation. Using nested conversations would allow the conversation to have different values for the selected costume under the same parent conversation with the same selected person.

Taking it further you could select the person in the top level conversation, select the costume in the nested conversation, and then you could have multiple windows open with further nested conversation letting you pick different shoes to go with that costume. Also, if you change the person in the top level conversation, it will change the selected person for all windows using that conversation or any of its nested conversations.

I’m not sure there is a great need for nested conversations, I’ve never really used them or found the need and I don’t think users open that many browser windows or tabs to create different logic paths within a conversation. I think it is acceptable to limit the data isolation to a single conversation level.

Also, I have a couple of food posts almost completed as Christmas was full of good food and recipes that inspired me to blog about it (Must have been watching Julie & Julia in the New Year that did it).

Happy New Year all!

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<Item> 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<Item>  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<Item> fetchItems() {
        List<Item> results = new ArrayList<Item>();
        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.

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.

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<Item> fetchItems() {
        List<Item> results = new ArrayList<Item>();
        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.

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<Item> 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<Item>  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.

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 ;

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.

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 <beans></beans>. (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