Something that's always slightly bemused me is that software development methodology is something you never seem to hear discussed in organizations whose business is technology. Sure, product companies are certainly very interested in practices and tools to support good practices. (For example, product companies certainly care about testing practices.) But technical practices are kinda orthogonal to methodology debates. And I never hear about a company like Red Hat paying any attention at all to the latest fashions sweeping through the world of agile consultants and project managers. In fact, I'd be very interested to hear of a single example of a truly great software product that was developed (at least initially) according to a methodology.

I have a number of theories as to what the difference might be, but I'm not sure which, if any, of those theories are correct:

• arguments about methodology help keep especially boring projects interesting
• methodology is important in an environment where developers are viewed as interchangeable resources
• methodology is important in an environment where developers have heterogeneous ability/experience levels
• methodologies like agile are used by project teams to defend themselves against ignorant managers
• good product companies just naturally do agile-ish stuff without really needing to think about it (or, if they don't, they die)
• methodology helps achieve predictability, but gets in the way of innovation

What I'm most interested in is why companies buy into this stuff without any real evidence that any of it is used by companies which are able to repeatedly build successful and innovative software. Or, does such evidence exist and I'm simply too disconnected from this world to know about it?

If this post sounds like snark, it's not. I'm actually genuinely interested...

Here's another usecase for the injection point metadata API that we're considering adding to Web Beans. I've always thought it would be nice to be able to inject entity instances by role, instead of passing references around the system. (In Seam, you can use home objects to achieve this.)

Of course, we need a way to distinguish which instance of a particular entity type we're interested in. For each conversation, there are certain roles. For example, in an user administration screen, there is the current user, and the user that is being administered.

In a Web Beans world, we would represent a role using an annotation. For example, we would refer to the @Administered User. What I would like to be able to do is associate an identifier with the role, at the beginning of a conversation, and then simply inject the entity with that identifier into any Web Bean that is invoked during that conversation. Of course, I could write a Web Bean with a producer method to do this:

@ConversationScoped
public class AdministeredUser {

    private @PersistenceContext EntityManager em;
    private String userId;
    
    public void setUserId(String userId) { 
        this.userId = userId; 
    }
    
    @Produces @Administered User getUser() {
        return userId==null ? null : em.find(userId);
    }
    
}

However, I don't really want to have to write a new Web Bean for every role! So let's generify this code. Instead of making @Administered a binding annotation, we'll use a generic binding type @Persistent, and use InjectionPoint to determine the role that was specified at the injection point:

@ConversationScoped
public class EntityRoles {

    private @PersistenceContext EntityManager em;
    private Map<Key, Object> idByRole = new HashMap<Key, Object>();
    
    public void setId(Class entity, Annotation role, Object Id) { 
        idByRole.put(new Key(entity, role), id);
    }
    
    @Produces @Persistent Object getInstance(InjectionPoint ij) {
        Object id = idByRole.get(new Key(ij.getType(), ij.getAnnotations()));
        return id==null ? null : em.find(id);
    }
    
}

(I'm leaving out the boring implementation of Key, and the binding annotation @Persistent.)

Now, the following code may be used to set the identifier, at the beginning of a conversation:

@Current EntityRoles er;

...

er.setId(User.class, Administered.class, userId);

And the User may be injected as follows:

@Administered @Persistent User user

We probably also want to make it possible to refer to the User by a name in Unified EL, but for that we'll need to write a ELResolver (which is also too boring for this post).

In the comments thread for this post, Bill got me thinking again about a problem that's been bugging me for a while.

The problem is that there are certain kinds of dependent objects (in the sense of the Web Beans @Dependent scope) that need to know something about the object or injection point into which they are injected in order to be able to do what they do. For example:

• the log category for a Logger depends upon the class of the object that owns it
• injection of a HTTP parameter or header value depends upon what parameter or header name was specified at the injection point
• injection of the result of an EL expression evaluation depends upon the expression that was specified at the injection point

The solution I've come up with is to allow injection of a special metadata object into any injected dependent object.

(Note that this functionality is specifically for @Dependent scope Web Beans - objects with normal scopes are shared between many clients and many injection points, so their behavior cannot depend upon anything relating to the client.)

Let's look at an example:

class LogFactory {

   @Produces Logger createLogger(InjectionPoint injectionPoint) { 
      return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName()); 
   }

}

This clever little producer method lets you inject a JDK Logger with the right log category. Instead of typing:

Logger log = Logger.getLogger(MyClass.class.getName());

You can write:

@Current Logger log;

which is shorter, and less vulnerable to refactoring problems.

Not convinced? OK then, let's see a second example...

To inject HTTP parameters, we need to define a binding type:

@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @annotation HttpParam {
   @NonBinding public String value();
}

We would use this binding type at injection points as follows:

@HttpParam("username") String username;
@HttpParam("password") String password;

The following producer method does the work:

class HttpParams

   @Produces @HttpParam("")
   String getParamValue(ServletRequest request, InjectionPoint ip) {
      return request.getParameter(ip.getAnnotation(HttpParam.class).value());
   }

}

I suppose this stuff is mainly useful for framework-type development, but it might also have other applications.

So how hard is it to add this feature to Web Beans? Not hard at all! The Web Beans specification would define the following API:

public interface InjectionPoint { 
   public Type getType();
   public Set<Annotation> getBindingTypes();
   public Object getInstance(); 
   public Bean<?> getBean(); 
   public Member getMember(): 
   public <T extends Annotation> T getAnnotation(Class<T> annotation); 
   public Set<T extends Annotation> getAnnotations(); 
}

And the Web Bean manager would be required to provide a built-in Web Bean that implements this interface.

What do you think?

It's fun to see what people are using Seam for:

• http://www.cocompose.com/
• http://www.trendrr.com/
• http://www.javelincrm.com/
• http://www.bikelogger.de/
• http://www.easycity.com/

And many more here.

Have you ever had an idea on how some web or desktop UI should look and needed to tell someone about ? Your text explanations would be misunderstood or you were just too lazy to even write it down or use any of the many useless expensive tool to make it ?

I've been in that situation many times lately while working on JBoss Tools and Developer Studio, but ever since I bumped into Balsamiq Mockups I'm (almost) enjoying doing mockups of UI features which I hated doing before.

It already helped me more than once in making discussions that normally takes very long to be much more focused on the problem at hand.

Thus instead of me trying to explain how it works go see the screencast here and see it for your self.

I do not have any associations with Balsamiq, I just find their product to be really good and solving a problem I know alot of others have and wanted to share that.