In a move either personal or political, The Middleware Company, parent of TheServerSide.com has terminated their relationship with JBoss.

This decision is, in many ways, symbolic of the damaged relationship between JBoss and the Java community. Many users or potential users of JBoss will take a step back and reconsider that decision, not questioning the merits of the application server, but questioning the integrity of the company. Marc Fleury has always been a colorful character, but with more of a reputation of keeping things interesting.

Now, the JBoss name is tarnished rather than textured. Before, it was a curiosity. Now, it is a pariah. Do you want a business relationship with a company that will not apologize, not even admit wrongdoing, but just say that they won’t do it in the future (not that they necessarily did it in the past). With their current hiring push, how many talented developers and staff will shy away, fearing that the JBoss name could hurt their future job prospects or harm their reputation? I’m not suggesting that all, or even most will… but it’s enough to matter.

At the foundation, JBoss has been a novel piece of software, and one that has succeeded both through colorful PR and through word of mouth. The latter depends on the community, and this blunder may have just sucked the energy out of their raving fans. $10 million in investment cash is nice, but happenings like this will certainly erode the value of the IPO they have their eye on, and it certainly isn’t enough to try and replace that flattened community buzz they had with marketing efforts to take IBM and BEA head on. Can they recover? Quite probably. But any bump they got from astroturfing can’t possibly make up for the credibility gap they’ve earned.

Credit goes to Dion for bringing this (witty) alternate abbreviation to my attention. The TSS posting about BEA pushing Service Oriented Architecture brought to my attention how SOA is a magic marketing term that pretends to somehow wrap SOAP/Web Services in a way that precludes bad design. (My full comments here.)

Just more bait for PHBs to think they need to spend money on something they can already do today. In fact, SOA may itself be bad design if applications are unnecessarily decoupled in this way (which seems a likely result, given the way it’s being pushed).

IBM has posted a flamebait article detailing “best practices for J2EE application development”. Lists such as this can be helpful, but they’ve forgotten the simple complexity of the number of layers and complexity matching the complexity of the app. Many of the practices are good starting points, but by no means should they be rules.

The best practices

   1. Always use MVC.
   2. Apply automated unit tests and test harnesses at every layer.
   3. Develop to the specifications, not the application server.
   4. Plan for using J2EE security from Day One.
   5. Build what you know.
   6. Always use Session Facades whenever you use EJB components.
   7. Use stateless session beans instead of stateful session beans.
   8. Use container-managed transactions.
   9. Prefer JSPs as your first choice of presentation technology.
  10. When using HttpSessions, store only as much state as you need
      for the current business transaction and no more.
  11. In WebSphere, turn on dynamic caching and use the WebSphere servlet
      caching mechanism.
  12. Prefer CMP Entity beans as a first-pass solution for O/R mapping
      due to the programmer productivity benefits.

1. Always? What if I’m writing a one page app? What if all I want is a page that displays the time? There are such things as apps too simple for MVC.

2. Units tests at every layer? I’ve challenged for some time the degree to which some people suggest that you test your data access layer. Suppose you want to test a simple DAO class that retrieves an object by its id from a database using Hibernate. If that method simply calls Session.load(Class c, Object id), what are you really testing there? Hibernate? Your configuration? What database do you test against, and which values do you compare to determine success? The value/effort ratio is pretty low here.

3. The point is not to get into app server specific configuration and coding. The problem is that they use the example of J2EE security. What’s the issue? Well, in order to use J2EE security, you have to configure JAAS in a way that is app server proprietary. A good general principle, but it can’t be strictly followed.

4. A topic near and dear to my heart, security. Turn it on always? What if your app doesn’t need security? What if you need 2 factor authentication, which isn’t supported by J2EE security? Favor the use of J2EE security, yes. Always turn it on? No way.

5. Build what you know – an okay philosophy, I suppose. Basically, build your app a layer at a time instead of building it all at once. I’d say to at least fire a tracer bullet first.

6. ALWAYS use session facades with EJB components? Even if your app only has two stateless session beans? Overengineered. Refactor the session facade in later when complexity justifies it.

7. Avoid stateful session beans when possible. Fair enough – they’ve given some wiggle room here, which makes it reasonable.

8. Use container managed transactions. Fine.

9. Prefer JSPs. I actually generally agree with this. This step actually suggests that developers fight the urge to get fancy with XML/XSL when the requirements don’t justify it. Tapestry users get a pass here – though I personally find Tapestry to be a bit cumbersome, it can’t be equated with the whole XSLT to generate HTML crowd.

10. Use the HttpSession only for what you immediately need for this business transaction. The goal is noble – keep the session small so you can persist sessions and improve performance. Saying to only put info for the current transaction is a bit limiting. It seems plausible to also store general into about the application, or data about another transaction recently completed. Keeping the session small should be the actual suggestion.

11. In websphere… … turn on caching. Maybe – don’t know enough about their caching implementation to comment.

12. Prefer CMP Entity Beans for the productivity benefits. Although EJB 2.0 has made great strides, the Entity Bean model is already so cumbersome and has some limitations that make it a questionable choice at best. This is typical vendor-speak.

A rant driven by an HTML shortcoming. I want something simple – I want to be able to create a layout like this without using frames. But I can’t. Simple desire – I want a left menu and a top header that are fixed, and a content area that fills the rest of the browser area, and can scroll, but the content scrollbar should be the only scrollbar on the screen, and the header and navigation should remain fixed.

The fact of the matter is that frames suck – the page you see is driven by frames. Many mobile devices that support HTML don’t support frames, and it’s silly to have to load 4 different html pages to display that one screen. It’s nearly impossible using Struts to get a good Tiles template together to use frames. The main option seems to be using the getAsString tag in your layout file to indicate which page should be loaded into that frame. The problem is that you really want a more detailed template than that. You’d like your template to be define parts of each frame as well, but since the user’s browser loads the frameset, and the browser then requests each of the 4 pages, you lose your request context, and you can’t use tiles:insert in each frame. Further, any data that you stored in request scope is lost by the time you get to rendering actual content.

I’ve tried this technique to render the same view using scrollable DIV areas, but it failed. The problem is that the header needs to be a fixed size, and the content area should be able to take up the rest of the page. Frames have the * operator to indicate that an area should take whatever space is available. A COLSET can use the same thing. Strangely, for rows, there’s no such attribute. It’s as though the idea of a page designer wanting the height of the page to match the height of the browser window is completely foreign. It truly amazes me that we’ve been using HTML for so long and there’s still no way to express such a simple idea without using the atrocity (and web app unfriendly construct) that is frames.

Addendum: I realize that HTML was never intended to do half the things it does currently. What amazes me is that we haven’t managed to standardize something better (where standardize means cross-browser compatible).

Recent entries from Emmanuel and Cedric have me seriously thinking about the long term impact of JSR 175, the standard metadata interface for Java. I don’t think the average user will have much use for defining their own metadata interfaces, but I do think there is a great deal of room for application frameworks to rethink the way they configure their apps.

The use of XDoclet and the creation of this spec seem to be a reaction to the XML hell that many frameworks create. In frameworks like Struts and Hibernate, the idea of using XML to decouple your mappings from your objects is somewhat of a red herring, in that the very objects you’re writing are tied to that framework, tied to that metadata. What good is a StrutsAction without Struts? And for Hibernate, you have to include information about your class in the mappings, so they’re still tightly coupled. The only other flexibility given by xml configurations is the ability to tweak the application without rebuilding the app, but how often will you roll in a production change without first at least running some tests on it in another environment? Is typing “ant” really that hard?

Still, the inability of XDoclet to handle many scenarios for frameworks (Hibernate composite-id generation) and its non-standard nature have prevented its full adoption as a means of code generation. The metadata spec seems to offer enough flexibility to overcome this, and combined with the ability to inspect the metadata programmatically at runtime I believe it can be a powerful alternative to XML config files.

What if a Struts action looked like this?:

@StrutsAction(
  @ActionMappings({
    @ActionMapping(
      path=”index”,
      @ActionForwards({
        @ActionForward(name=”success”, path=”index.jsp”),
        @ActionForward(name=”failure”, path=”error.jsp”)
      })
    )
  })
)
public class IndexAction extends Action
{
….

So when ActionServlet initializes, it can search the classpath for classes with StrutsAction annotations and register them into its configuration. Additional metadata provided in an extension of ActionServlet could give instructions on what classpath to search for annotated struts elements. ActionForm could be similar designed and discovered.

Does it make your code pretty? Not necessarily. But are XML mapping files pretty? No. But metadata can simplify the number of files we need to maintain for these frameworks while still giving full control over the configuration. It’s more standard, more complete, and more strongly defined than XDoclet.

The following metadata interfaces would back up the suggested approach:

public @interface StrutsAction {
  ActionMappings mappings();
}

public @interface ActionMappings {
 ActionMapping[] value();
}
public @interface ActionMapping {
  String path();
  String form() default””;
  String input() default “”;
  ActionForwards value();
}

public @interface ActionForwards {
  ActionForward[] value();
}

public @interface ActionForward {
  String name();
  String path();
}

P.S. – If I’ve got the syntax wrong, let me know. There’s not much example code out there at the moment.

Update: After looking at Matt Raible’s thoughts on the look of this code, I cleaned it up a little bit – consolidating the lines for the ActionForwards.

JSR-175, standardized metadata, may have more potential to simplify configuration of Hibernate than of Struts. Why do I say this?

• Hibernate has a one-to-one relationship between mapped objects and mapping files.
• Shortcomings in XDoclet make it impossible to generate composite-id mappings, so there’s an immediate value-add.
• Unlike Struts, there’s no large configuration file shared by the whole framework. hibernate.properties is small and used only for configuration.
• The mappings are generated at the attribute level, so more of the bindings (return type, etc) can be determined by reflection rather than the user needing to enter them (Xdoclet can generate this).

Let’s take a look at an example (supplemental code will be at the bottom):

@HibernateMapping( table="employees")
public class Employee
{
    private Name name;  //Yes, name as primary key is dumb
    private String job;
    private Date startDate;

    @HibernateCompositeId({
      @HibernateCompositeIdAttribute(name="firstName", column="first_name"),
      @HibernateCompositeIdAttribute(name="lastName", column="last_name")
    })
    public Name getName() { return name;}

    @HibernateAttribute(column="start_date")
    public Date getStartDate() { return startDate; }

    @HibernateAttribute(column="current_job")
    public String getJob() { return job; }

    //The setters go here

In this case, the metadata approach almost matches the line length of the XDoclet tags to accomplish the same task, and as mentioned, exceeds XDoclet’s capabilities in capturing the composite-id in metadata. (Don’t get me wrong, I like and use XDoclet.)

Don’t give me this story about the advantage a separate config file gives you (in this specfic case). There’s 2 main types of change that affect an hbm.xml file – one is changes to the class. That’s where the existing approach can be a pain – you have to add/remove/change the attribute in the class and the mapping. The other case is a database change, which isn’t a trivial thing. The planning that goes into making changes to a production database can certainly include planning to change the metadata and rebuild your app. It could help you if you have different table and column names in your different environments, but that sounds like a recipe for disaster anyhow.

Because annotations can be reflected at runtime, Hibernate could automatically detect @HibernateMapping classes and add them to its Configuration. Clearly, an @Configuration annotation would be needed to specify some configuration parameters, and could even give a limited classpath to search (e.g. com.kischuk.*) to speed the search for persistable classes. The metadata approach also causes at least some constraints on the format of the metadata to be enforced at compile time rather than runtime.

Supporting code follows (4 different interfaces):

public @interface HibernateMapping
{
   String table();
}

public @interface HibernateAttribute
{
    public String column();
}

public @interface HibernateCompositeId
{
    public HibernateCompositeIdAttribute[] value();
}

public @interface HibernateCompositeIdAttribute
{
    public String name();
    public String column();
}