EJB.next Connector/Bean API : JAX-RS and beyond

It isn't commonly known that MessageDrivenBeans (MDBs) are not directly tied to the Java Message Service (JMS). In fact, they are tied to the Java EE Connector Architecture. It's even less commonly known that MDBs are not necessarily asynchronous. It's really the Connector that drives the communication style.

Overall, it is a very cool model that does allow for some pretty impressive and standard extension to any compliant Java EE platform. It is, however, incredibly underused. With a few changes to the model, it could be made to support even things like JAX-RS. Let's break it down.

The touchpoints between the Connector and the MDB are the ActivationSpec/ActivationConfig and the MessageListener interface. Using a fictitious "Email" Connector idea, let's see how this looks.

EmailConsumer (MessageListener) interface*

package org.superemail.connector;

// other imports...
    
public interface EmailConsumer {
    public void receiveEmail(Properties headers, String body);
}

EmailAccountInfo (ActivationSpec) class

package org.superemail.connector;
    
/**
 * This class is basically an old-style JavaBean with get/set for each property
 */
public class EmailAccountInfo implements javax.resource.spi.ActivationSpec {

    private String address;

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public void validate() throws InvalidPropertyException {
    }
}

That's it for the Connector (aside from the Connector itself). I have left out a little detail on the ActivationSpec, we'll cover that later.

Now for the MDB's side of things. The MDB needs to implement the Connector's EmailConsumer interface and configure the Connector'sEmailAccountInfo JavaBean which is done via the activation-config tag of the ejb-jar.xml or via @ActivationConfigPropertyannotations in the @MessageDriven declaration.

@MessageDriven(activationConfig = 
        {@ActivationConfigProperty(
                propertyName = "address", 
                propertyValue = "dblevins@apache.org")
        })
public class EmailBean implements EmailConsumer {

    @PostConstruct
    public void init() {
    }

    public void receiveEmail(Properties headers, String body) {
        // do your thing!
    }
}

Done. Those are the basics. The Connector supplies a MessageListener interface and an ActivationConfig JavaBean, the MDB implements the interface and configures the JavaBean via the loosely-typed @ActivationConfigProperty.

There are a few things that prevent this model from reaching its true potential:

• Metadata is loosely typed in the bean code
• Only class-level metadata is allowed, not method-level
• Requiring an interface can limit expressiveness

Let's see how life might look if we eliminate the JavaBean and allow the Connector to instead supply an annotation.

package org.superemail.connector;
    
@Target(TYPE)
@Retention(RUNTIME)
@javax.resource.annotation.ActivationSpec
public @interface EmailAccountInfo {
    String address();
}

Side Note: The original javax.resource.spi.ActivationSpec interface has a 'validate()' method on it to validate the JavaBean. A clear update to that part of the API would be to instead use the Bean Validation API.

Which gives us a bean that might look like this:

@MessageDriven
@EmailAccountInfo(address = "dblevins@apache.org")
public static class EmailBean implements EmailConsumer {

    @PostConstruct
    public void init() {
    }

    public void receiveEmail(Properties headers, String body) {
        // do your thing!
    }
}

Now we're getting somewhere!

Ok, let's get rid of that message listener interface and image our Email Connector uses a very JAX-RS inspired API for consuming emails. If you know a little JAX-RS you'll see where I'm going with this.

@MessageDriven
@EmailAccountInfo(address = "dblevins@apache.org")
public static class EmailBean {

    @PostConstruct
    public void init() {
    }

    @Deliver @Header("Subject: {subject}")
    public void receiveEmail(@HeaderParam("subject") String subject, @Body String body) {
        // do your thing!
    }
}

Pretty neat, huh?

Side note: For the rare few of you that speak Connector implementation, instead of giving your Resource Adapter a MessageEndpoint that is a proxy that only implements the MessageListener interface and the standard MessageEndpoint interface, the Container would instead give you an @LocalBean proxy that also implements MessageEndpoint. If you're thinking that an API like that would be great to use... imagine with the above changes you could make that API ... and use it in any compliant Java EE platform. Maybe even submit your own JSR if you came up with something great.

Truthfully speaking, it's the Connector who controls the lifecycle of the bean (MDB). The Connector API already allows for the Connector to say to the Container, "create me a bean" and "destroy this bean". So really, we don't need @MessageDriven anymore. Instead we can do this:

import javax.annotation.ManagedBean;

@ManagedBean
@EmailAccountInfo(address = "dblevins@apache.org")
public static class EmailBean {
 // ....
}

That's a little more modern and perhaps a bit clearer.

At this point, we have a generic API to hook arbitrary "Connectors" up to arbitrary "Beans" that are managed by a container. Were this the case when JAX-RS was created, they wouldn't have had to put so much effort into duplicating all the services that people who have managed beans expect: injection of resources, lifecycle callbacks, interceptors.

Summary: A few improvements to the expressiveness of the metadata passed between a Bean and its Connector could kick the MDB/Connector model into the mainstream as was the intention of the API from the beginning. New specifications could be created based on this model and be introduced incrementally as they are developed and needed.

The impact of fully opening up the Bean metadata to the Connector is quite deep and wide and likely not something that will scream at you immediately. Ask yourself, could something like the new EJB 3.1 @Schedule API have been done with a Connector/Bean model like this? To some extent probably it could. Certainly there already existed a few Quartz Connectors out there prior to the introduction of @Schedule.

Take a moment to daydream. What kind of Connectors could you create with this model?

UPDATE - Feb 7th, 2013

Save this proposal.  Without more voices it will be delayed till Java EE 8.  Let's not wait 4 years!  Take action and celebrate the Java Community Process openness by showing your support for including this in Java EE 7.  Act now.

VOTE AND COMMENT HERE http://java.net/jira/browse/EJB_SPEC-60

Interceptor Advisor Pattern

Your standard CDI/EJB Interceptor example uses a logger as an around advice. Generally this gives you an interceptor that looks like so:

@Log
public class LoggingInterceptor {

    private java.util.logging.Logger logger =
            java.util.logging.Logger.getLogger("theLogger");

    @AroundInvoke
    public Object intercept(InvocationContext context) throws Exception {
        logger.info("" + context.getMethod().getName());
        return context.proceed();
    }
}

As of the Interceptors 1.1 spec, you can bind that to a bean via creating our own javax.interceptor.InterceptorBinding annotation. In our example, we've created one called @Log:

@InterceptorBinding
@Target(value = {ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Log {
}

Now we just apply that to the bean as follows.

@Log
public class FooBean {

    public void somethingCommon(){
        //...
    }

    public void somethingImportant() {
        //...
    }

    public void somethingNoteworthy() {
        //...
    }
}

Great! Now we are done. Every time that bean is invoked, the LoggerInterceptor will issue a log message on info level. Aren't interceptors wonderful! End of story, right? Not quite.

Fundamentally, our example is still very contrived. Who wants to log everything on the same level?

Here is a little pattern that you can use to better advise your LoggerInterceptor around advice. First, we create a couple new annotations for log levels: @Fine and @Info

@Target(value = {ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Fine {
}

@Target(value = {ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Info {
}

Then we apply those to the bean...

@Log
public class FooBean {

    public void somethingCommon(){
        //...
    }

    @Info
    public void somethingImportant() {
        //...
    }

    @Fine
    public void somethingNoteworthy() {
        //...
    }
}

Now we alter our LoggerInterceptor to check for our new annotations and alter its behavior.

@Log
public class LoggingInterceptor {

    private java.util.logging.Logger logger =
            java.util.logging.Logger.getLogger("theLogger");

    @AroundInvoke
    public Object intercept(InvocationContext context) throws Exception {
        final Method method = context.getMethod();
        if (method.isAnnotationPresent(Info.class)) {
            return info(context);
        } else if (method.isAnnotationPresent(Fine.class)) {
            return fine(context);
        } else {
            return finest(context);
        }
    }

    public Object info(InvocationContext context) throws Exception {
        logger.info("" + context.getMethod().getName());
        return context.proceed();
    }

    public Object fine(InvocationContext context) throws Exception {
        logger.finest("" + context.getMethod().getName());
        return context.proceed();
    }

    public Object finest(InvocationContext context) throws Exception {
        logger.finest("" + context.getMethod().getName());
        return context.proceed();
    }
}

Done! Now we have a pattern to advise our interceptor!

This will totally work today. But this pattern is so simple and elegant what if we could support it right inside the container? Imagine how cool it would be if we could just do this in our interceptor and the container would just figure it out.

@Log
public class LoggingInterceptor {

    private java.util.logging.Logger logger =
            java.util.logging.Logger.getLogger("theLogger");

    @Info
    public Object info(InvocationContext context) throws Exception {
        logger.info("" + context.getMethod().getName());
        return context.proceed();
    }

    @Fine
    public Object fine(InvocationContext context) throws Exception {
        logger.finest("" + context.getMethod().getName());
        return context.proceed();
    }

    @AroundInvoke
    public Object finest(InvocationContext context) throws Exception {
        logger.finest("" + context.getMethod().getName());
        return context.proceed();
    }
}

Definitely something I plan to propose for the next round of specifications....

As always, comments welcome.

EJB.next Interceptor Improvements - Method signatures

Interceptors are great, but some parts of them are odd when applied practically. For as fundamentally reflective as interceptors are, it isn't possible to pass all interceptable calls through a single method, like so:

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.PostActivate;
import javax.ejb.PrePassivate;
import javax.interceptor.AroundInvoke;
import javax.interceptor.AroundTimeout;
import javax.interceptor.InvocationContext;
import java.util.concurrent.TimeUnit;
import static java.util.concurrent.TimeUnit.MILLISECONDS;
import static java.util.concurrent.TimeUnit.NANOSECONDS;

public class StatsInterceptor {

    @PostConstruct
    @PreDestroy
    @PrePassivate
    @PostActivate
    @AroundInvoke
    @AroundTimeout
    public Object intercept(InvocationContext context) throws Exception {
        final long start = System.nanoTime();
        try {
            return context.proceed();
        } finally {
            final long nanos = System.nanoTime() - start;
            final long millis = MILLISECONDS.convert(nanos, NANOSECONDS);
            System.out.println("invoke time "+ millis +" milleseconds");
        }
    }
}

This looks very nice, but currently is not legal. The spec currently requires different formats for callback-based interception vs business-method-based interception. This sounds like a nice safe and conservative rule, but is it benefiting users? Not really. Let's see what we have to do to our interceptor to make it compliant.

First, callback intercept methods are not allowed to return anything and must have a void return type. The logic here is that since callbacks have no return value, interceptors should know this. So fine, let's work around that and just make a new method:

    @PostConstruct
    @PreDestroy
    @PrePassivate
    @PostActivate
    @AroundInvoke
    public void callback(InvocationContext context) throws Exception {
        intercept(context);
    }

Second, callback intercept methods are not allowed to throw any exceptions. Again the rationale is that callbacks aren't allowed to throw checked exceptions, so interceptors should be aware of that as well. The trick is we can't simply remove the 'throws Exception' clause without doing any extra work. The InvocationContext.proceed() method throws java.lang.Exception but we can't, so we are forced to take responsibility for it. If we just catch and ignore the exception all hell will break loose, so instead we should at least wrap it as a RuntimeException.

    @PostConstruct
    @PreDestroy
    @PrePassivate
    @PostActivate
    @AroundTimeout
    public void callback(InvocationContext context) {
        try {
            intercept(context);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

We've just made a mistake. Did you see it? If there are several interceptors in the chain and all of them wrap the exception like this, when an actual exception is thrown it will end up wrapped N times -- once per interceptor -- before finally reaching the container. Instead, we should at least check if the exception needs wrapping and hope that other interceptors do the same:

    @PostConstruct
    @PreDestroy
    @PrePassivate
    @PostActivate
    @AroundTimeout
    public void callback(InvocationContext context) {
        try {
            intercept(context);
        } catch (Exception e) {
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            } else{
                throw new RuntimeException(e);
            }
        }
    }

Now we're done. Summary: all of the above is boilerplate code you need in any well implemented callback-based interceptor.

What have we achieved? Not much.

In terms of user code, it doesn't help you any to have these restrictions. If you wanted special logic for callback-based interceptor methods you can easily put that annotation on a separate method.

In terms of container code, there's little gain as well. Ultimately, most containers use reflection to kick off the interceptor chain. The java.lang.reflect.Method.invoke() method returns Object and throws InvocationTargetException. Restricting users from returning Object and throwing Exception have no real impact on the container code. It's a callback. Ultimately all exceptions, checked or not, go into the log file and no further and return values are simply ignored.

Summary: The restriction on returning void and throwing Exception should be lifted. For backwards compatibility we can just say this former requirement is now optional and allow interceptor signatures of 'Object <method>(InvocationContext c) throws Exception' even if what is being intercepted is a callback.

@ApplicationException is evil... sort of

Historically EJB has frowned on RuntimeExceptions. Throwing them results in your transaction getting rolled back and your bean instance being immediately destroyed. You're welcome to try your transaction again ... just as long as you weren't keeping your data in your @Stateful session bean, cause, you know, the container just destroyed that... hope you didn't need it to retry your commit.

In EJB 3.0 the @ApplicationException type was added so that beans could throw RuntimeExceptions and not have their beans destroyed and have the choice to rollback any transaction in progress. Great! Only... how do you really use this for built-in exception types? XML you say? Yuk!

<ejb-jar>
    <assembly-descriptor>
        <application-exception>java.lang.RuntimeExceptions</application-exception>
    </assembly-descriptor>
</ejb-jar>

And is the above even a good idea? Definitely not! With something like that you're just asking for trouble. The bad part is that it effectively shuts off transaction exception handling for all beans in the entire application. Currently, though, this is your only option.

The problem is it is hard to use this annotation responsibly. It's often too bold and too difficult to take the hard line that a specific exception type is always fine to throw. It is completely lacking in pragmatism. There is no ability for developers to make a more refined choice.

Bottom line, it should be possible to specify how you would like a RuntimeException handled for a specific bean or method. Imagine @ApplicationException where modified like so:

@java.lang.annotation.Target({TYPE, METHOD})
@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
public static @interface ApplicationException {
    Class value();

    boolean rollback() default false;
}

Now, we can do things a little more refined:

@LocalBean
public static class OrangeBean {

    @ApplicationException(RuntimeException.class)
    public void doSomething() {

    }

    public void doSomethingElse() {
        
    }
}

In the above, the OrangeBean doSomething method would be allowed to throw a RuntimeException without a transaction rollback or the bean instance being destroyed.

As well, the annotation could be placed on the class level. Say we have an @Stateful bean that wraps an EXTENDED PersistenceContext so that business logic could more easily be done elsewhere, perhaps by an @Stateless bean that uses Bean-Managed Transactions and wishes to batch process several transactions against the EXTENDED persistence context in a loop:

@Stateful
@ApplicationException(javax.persistence.PersistenceException.class)
@TransactionAttribute(MANDATORY)
public static class EntityManagerWrapper implements EntityManager {

    @PersistenceContext(type = EXTENDED)
    private EntityManager delegate;

    @Override
    public void persist(Object o) {
        delegate.persist(o);
    }

    @Override
    public  T merge(T t) {
        return delegate.merge(t);
    }

    @Override
    public void remove(Object o) {
        delegate.remove(o);
    }

    @Override
    public  T find(Class tClass, Object o) {
        return delegate.find(tClass, o);
    }

    //... and so on
}

The EntityManager API does not throw checked exceptions, only derivatives of javax.persistence.PersistenceException which is itself a RuntimeException. To wrap an EntityManager the bean also need the ability to throw javax.persistence.PersistenceException without causing its destruction and transaction rollback. In that vein, the bean is marked @TransactionAttribute(MANDATORY) so it isn't possible to use the bean without already having a transaction in progress, making it clear that transaction management is not it's responsibility.

In another example, say we would like to create a bean that wishes not be destroyed when a RuntimeException is thrown, but it would still like the transactions it starts (via @TransactionAttribute(REQUIRES_NEW)) to be rolled back should a RuntimeException occur.

@Stateful
@TransactionAttribute(REQUIRES_NEW)
@ApplicationException(value = RuntimeException.class, rollback = true)
public static class YellowBean {

    public void doSomething() {

    }

    public void doSomethingElse() {

    }
}

Naturally, to make this API work with more than one exception type per method or bean, we would of course need a new @ApplicationExceptions (note the plural) to group several @ApplicationException annotations -- for those that are not annotation-aware, you cannot use the same annotation twice on a type, method, field or any member.

@java.lang.annotation.Target({TYPE, METHOD})
@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
public static @interface ApplicationExceptions {
    ApplicationException[] value() default {};
}

With that it would be possible to do all of the above for a few different exception types:

@Stateful
public static class RedBean {

    @ApplicationExceptions({
        @ApplicationException(NumberFormatException.class),
        @ApplicationException(ArrayIndexOutOfBoundsException.class),
        @ApplicationException(value = RuntimeException.class, rollback = true)
    })
    public void doSomething() {

    }

    public void doSomethingElse() {

    }
}

In the above the NumberFormatException and ArrayIndexOutOfBoundsException are considered OK and will not cause instance destruction or transaction rollback, however the '@ApplicationException(value = RuntimeException.class, rollback = true)' acts as a default clause of sorts and says all other RuntimeExceptions do not cause instance destruction, but do cause transaction rollback.

Conclusion: Being able to be more specific with @ApplicationException would be a great improvement. I definitely plan to propose it in EJB.next. If you like the idea, please leave a comment as numbers do greatly increase the likelihood of it being added. Other ideas on how to achieve a similar result more then welcome!

EJB annotations and Stereotyping

Certainly for the EJB-related annotations, I would love to see @Stateless, @Stateful, @Singleton and @MessageDriven be used for stereotyping as well as all the other class level annotations for transactions, security, locking, timeouts and scheduling.

Great security example:

 @RolesAllowed({"SuperUser", "AccountAdmin", "SystemAdmin"})
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface Admins {}

In one swoop all the security rolls become controlled in one spot and there's no need to go changing a million usages to modify the roll names.

Here's a couple great scheduling examples:

 @Schedule(second=”0”, minute=”0”, hour=”0”, month=”*”, dayOfWeek=”*”, year=”*”)
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface Daily {}

 @Schedule(second=”0”, minute=”0”, hour=”0”, month=”*”, dayOfMonth=”15,Last”, year=”*”)
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface BiMonthly {}

The list goes on and on. A much fuller example:

@Stereotype
@Singleton
@TransactionManagement(CONTAINER)
@TransactionAttribute(REQUIRED)
@ConcurrencyManagement(CONTAINER)
@Lock(READ)
@RolesAllowed({"SuperUser", "AccountAdmin", "SystemAdmin"})
@Interceptors({LoggingInterceptor.class, StatisticsInterceptor.class})
@Target(TYPE)
@Retention(RUNTIME)
public @interface SuperBean {}

And to use all that, just:

@SuperBean
public class MyBean {

    public void doSomething() {
        
    }
}

Annotation Scanning Standard

We (the industry) need to get something in place for Java EE 7 to get scanning under control at a platform level. The metadata-complete concept of each individual spec is less helpful given the growing number of specifications that can have class-level "discoverable" annotations.

The rules we have for scanning for ejbs in a webapp are quite unintuitive. And how they relate to the scanning of the new Java EE 6 level annotations are unintuitive to the point that how they are handled, I bet, is rather vendor specific:

@DataSourceDefinition(s)

@ManagedBean

The cost of scanning a jar is constant in that it doesn't matter how many annotations you might be looking for or what spec they come from. If each individual spec continues to add spec-specific descriptor support for specifying which jars to scan, we're going to wind up with a rather big mess.

We should lock this down with a clean and simple file to control which jars.

Something as simple as the following would be a massive improvement.

META-INF/scanning.xml

<scanning>
  <jars>
    <jar>foo.jar</jar>
    <jar>bar.jar</jar>
  </jars>
  <packages>
    <package>org.foo.widgets</package>
    <package>com.bar.components</package>
  </packages>
</scanning>

I'd love it to have regex support, but even without it there's a big improvement.

If Software is pizza, EJB is the House Special

If you can stand terrible food metaphors and have ever been exposed to EJB positively or negatively, keep reading....

I don't know about you, but I love the simplicity of a good pepperoni pizza now and then. Imagine asking for a plain Pepperoni pizza and being told your only option was to get the House Special and to pick off all the onions, black olives, green pepper and whatever else comes on top. Any person with options would simply go to another pizza shop. Well, that's EJB. Something I hope we can change in EJB 4.0.

To setup the metaphor a bit more, let's say the dough and cheese is the component itself and the proxy to the component. The toppings are the various QOSs (qualities of service) such as transaction management, interceptors, concurrency management, cron-like scheduling, asynchronous method calls, and other goodness. Each bean type such as Stateful, Stateless, Singleton and Message Driven are certain styles of pizza with a fixed set of toppings; say Meat Lovers, Vegetarian, or Hawaiian. The toppings of each style of pizza have been selected carefully to compliment each other perfectly and guarantee good results.

Currently though, if you want to start with a plain pizza and add only the toppings you want or need, you cannot do it with EJB. If you want pepperoni, you need to pick a style of pizza that has pepperoni as a topping and deal with the other toppings that come with it, wanted or not. EJB is somewhat flexible and there are usually ways to neutralize some features that amounts to picking off the toppings you don't like, but it's not the same as if they weren't ever there and you are still going to get an odd tasting and odd looking pizza.

Say you don't really want the transaction management topping. You try to pick off the topping by selecting SUPPORTS as your default transaction attribute so if a transaction is there, your bean participates in it, if not, it still does it's work regardless. All is fine until your bean throws a runtime exception and the container decides to rollback the current transaction on your behalf. Say you instead choose to try and pick off the transactional topping by making your bean use bean-managed transactions. Things work fine except now all transactions are suspended by the container so that the bean cannot mess with the state of what was the current transaction. What you really wanted was your bean to not be transactionally aware in the first place.

Unfortunately if you want one of the other toppings like container managed concurrency, cron-like scheduling, or asynchronous method calls, you have to learn to like the transaction management topping, period.

There will always be a need for specific pizza styles with pre-selected toppings -- who doesn't love a good Greek pizza or a Hawaiian now and then. The EJB spec does that well with its perfectly selected bean types, each sprinkled with the select set of QOSs deemed appropriate for that specific bean type. That said, it really should be possible to start with a plain cheese pizza and just add the toppings you want.

Forget the dough and cheese. EJB should be about the toppings.

Ideally, every QOS the EJB spec has to offer would be an option that can be applied to a plain component. Imagine if there was a "plain cheese pizza" bean type that would by default have no QOSs at all and for all intense purposes be a true POJO. There's nothing to learn or study to code it or use it. It's just a POJO created by the container. Then one day you decide you'd like it to be transaction aware. At that point you annotate it with @TransactionManagement and then go read the self contained "transaction management" section of the spec to see what is now expected of you and the users of the bean.

It may be that certain QOSs cannot be combined, which is in fact the case at times. The concept of a container managed persistence context (i.e. a field like "@PersistenceContext EntityManager myEntityManager") cannot be combined with the new @ConcurrencyManagement annotation because EntityManagers themselves are not guaranteed to be capable of concurrency. As a result EJB Singletons are not allowed to use container managed persistence contexts. That may work for some, but maybe you want a Singleton that uses a container managed persistence contexts and do not need concurrency anyway. Such a thing would be possible if you were able to choose the QOSs for your bean regardless of its lifecycle.

It's time to break up the big specs and let people build their own pizzas.

Man-page based Bash Completion

Hacked up this little function which you can use to get generic bash completion on any command based on the man page. You just need to source this file. Here's what it looks like when executed

mingus:~ 03:16:45 
$ wget --c[TAB]
--ca-certificate=file      --certificate=file         --convert-links
--ca-directory=directory   --connect-timeout=seconds  --cut-dirs=number
--certificate-type=type    --continue                 

Theoretically you could take this a step further and complete the values of the options as well. Many of the options say "--foo=file", "--foo file", "--bar host", etc.. You could parse out this "file" or "host" keyword and switch the completion style accordingly. If you 'apt-get install bash-completion' you'll get a ton of completion functions which specialize in host, file, and directory completion. Shouldn't be too hard to wire them in. If anyone gets the urge to do it, definitely share your results. The above code is stored in gist.github.com, so fork away!