2 isn't how it is 'supposed' to work. The Configuration object is how you pass to the job any name - value pairs.
The more right way is for the Driver to copy the properties entries into Configuration. Everything downstream can see that. I think we would do well to keep it simple here. There are already props files and two flavors of command line args in play for configuration. Sean On Sep 12, 2010 7:41 PM, "Ted Dunning" <[email protected]> wrote: > The reflection option sounds dangerous because it isn't clear that the > classes will be loaded yet which would mean that they wouldn't be seen. > > Option 2 is, as you say, relatively simple. > > On Sun, Sep 12, 2010 at 10:21 AM, Grant Ingersoll <[email protected] >wrote: > >> My first thought is to create a JOB jar that contains the properties, but >> the thought occurred to me that there might be a way to enhance the >> classpath. Other thoughts: >> 1. Instead of requiring driver.classes.props, we could just have an >> Interface that each of those drivers implements that reports it's short name >> and description and then we just need to do some reflection at startup to >> get all implementers of the interface. >> 2. We create a "default.driver.classes.props" that is actually packaged >> into the JOB jar. We first look for driver.classes.props then we look for >> default.driver.classes.props, then we throw an exception. >> >> I guess my preference is #2, since that is the least code, still allows the >> existing functionality to work and provides reasonable defaults w/o any >> setup. >>
