File or properties based Module

[Sam.Ha...@gmail.com]

Hi all,

I've just tried out Guice for the first time today and it has
impressed me... I've only touched the surface.

Do all bindings have to be defined in the source code? I'd like to
make that sort of thing runtime definable. Perhaps through an
implementation of Module that searches the classpath for an
appropriately named properties file (possibly "guice.properties") and
sets up the bindings based on what it finds in there.

It doesn't seem to hard to set it up... but before I go reinventing
the wheel, does Guice have this functionality already?

Thanks

[Bob Lee]

Check out the Names class. It can convert a Properties into a Module
automatically.

Bob

[Adam Schaible]

Here's an example... I'm not sure how to property format it in this
format so I apologize:

public class PropertiesModule extends AbstractModule {

public void configure() {
Properties properties = new Properties();
try {
FileInputStream fis = new
FileInputStream("Properties.xml");

properties.loadFromXML(fis);
} catch (IOException e) {
// throw exception
}

Names.bindProperties(binder(), properties);
}
}

public class MadLibs {
private final String name;
private final String verb;
private final String noun;

@Inject
public MadLibs(@Named("nameOfPerson")String name,
@Named("pastTenseVerb") String verb, @Named("noun")String
noun) {
this.name = name;
this.verb = verb;
this.noun = noun;
}
public String getJoke() {
return "One day, " + name + " " + verb + " to New York to see
the " + noun + ".";
}
}

public static void main(String[] args) {
Module propertiesMoudule = new PropertiesModule();
Injector inj = Guice.createInjector(propertiesMoudule);
MadLibs madLibs = inj.getInstance(MadLibs.class);
String joke = madLibs.getJoke();
System.out.println(joke);
}

Hope that helps.

On Nov 9, 12:26 pm, "Bob Lee" <crazy...@crazybob.org> wrote:
> Check out the Names class. It can convert a Properties into a Module
> automatically.
>
> Bob
>

> On Nov 9, 2007 7:04 AM, Sam.halli...@gmail.com <Sam.Halli...@gmail.com> wrote:
>
>
>
>
>
> > Hi all,
>
> > I've just tried out Guice for the first time today and it has
> > impressed me... I've only touched the surface.
>
> > Do all bindings have to be defined in the source code? I'd like to
> > make that sort of thing runtime definable. Perhaps through an
> > implementation of Module that searches the classpath for an
> > appropriately named properties file (possibly "guice.properties") and
> > sets up the bindings based on what it finds in there.
>
> > It doesn't seem to hard to set it up... but before I go reinventing
> > the wheel, does Guice have this functionality already?
>

> > Thanks- Hide quoted text -
>
> - Show quoted text -

[Adam Schaible]

Oh, and the xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<entry key="nameOfPerson">Marco Polo</entry>
<entry key="pastTenseVerb">flew</entry>
<entry key="noun">clock</entry>
</properties>

> > - Show quoted text -- Hide quoted text -

[Sam.Ha...@gmail.com]

Thanks Rob and Adam... that was pretty much what I was after. Any
thoughts on expanding on this functionality? Personally I was a little
surprised that Guice didn't look for a properties (or horrible XML)
file by default... or that there wasn't a simple convenience class for
simply instantiating an Injector with a package-name based property
reader like

Guice.createInjector(new PropertyModule("my.package"));

I will probably do something like this... please let me know if you
are aware of any problems with this technique. (Of course, defaults
can be specified through annotations as usual).

[Bob Lee]

Regarding why Guice doesn't load the Properties for you, I figured
there are tons of different ways to do this and tons of libraries
which already tackle it, so there wasn't much of a need to duplicate
the effort in Guice. I suppose we could support a really simple case
out of the box though, i.e. looking for "/guice.properties" in the
classpath and blowing up if we find more than one (how often has that
problem bitten you?).

Bob

[Adam Schaible]

I think a big benefit of Guice is the lack of "magic". I can look at
my java code and understand what's going on. If a properties file was
automatically loaded up I think it would increase the magic factor -
which judging by the current design is something that's avoided.

I do see how it would be useful, though.

On Nov 9, 2:50 pm, "Bob Lee" <crazy...@crazybob.org> wrote:
> Regarding why Guice doesn't load the Properties for you, I figured
> there are tons of different ways to do this and tons of libraries
> which already tackle it, so there wasn't much of a need to duplicate
> the effort in Guice. I suppose we could support a really simple case
> out of the box though, i.e. looking for "/guice.properties" in the
> classpath and blowing up if we find more than one (how often has that
> problem bitten you?).
>
> Bob
>

> On Nov 9, 2007 11:42 AM, Sam.halli...@gmail.com <Sam.Halli...@gmail.com> wrote:
>
>
>
>
>
> > Thanks Rob and Adam... that was pretty much what I was after. Any
> > thoughts on expanding on this functionality? Personally I was a little
> > surprised that Guice didn't look for a properties (or horrible XML)
> > file by default... or that there wasn't a simple convenience class for
> > simply instantiating an Injector with a package-name based property
> > reader like
>
> > Guice.createInjector(new PropertyModule("my.package"));
>
> > I will probably do something like this... please let me know if you
> > are aware of any problems with this technique. (Of course, defaults

> > can be specified through annotations as usual).- Hide quoted text -

[Bob Lee]

On Nov 9, 2007 12:02 PM, Adam Schaible <adam.s...@gmail.com> wrote:
> I don't see how it can
> hurt, but one thing I like about Guice is there are no secrets in your
> code. I can figure everything out by reading the code - and if I auto-
> loaded some sort of properties file, I think it would add to the
> magic.

I couldn't agree more. There's nothing worse than having to debug
framework code. I can't count how many hours I wasted trying to get
XML files in just the right places with just the right names, and then
figuring out if they weren't having the desired affect because of my
mistake or an inadequacy in the framework. Usually, it was the latter.

Bob

[Dhanji R. Prasanna]

Classpath searching = slow. If you put that in please don't turn it on
by default!

Dhanji.

[Stuart McCulloch]

totally agree - I wouldn't want this enabled by default as it means you're at
the mercy of whoever assembled the classpath and the order of its entries

Bob

--
Cheers, Stuart