Default Values

4 views
Skip to first unread message

Dominik Obermaier

unread,
Aug 13, 2012, 6:59:22 PM8/13/12
to roc...@googlegroups.com
I am evaluating Rocoto at the moment. I like the simplicity, however, I did not find a nice way to define default values from the code. Let's assume the following scenario:

@Inject
@Named("port")
int port;

Of course it will work fine, if the properties file contains an integer for the value "port". When "port" contains characters, The application cannot start, because of a Guice Converter Exception. I think it would be great to add the ability to use a manual "fallback" value, if any exceptions occur while injecting property file values. Is something like this already implemented and I did just overlook it? If not, what do you think about a feature like this?

Simone Tripodi

unread,
Aug 14, 2012, 1:07:24 AM8/14/12
to roc...@googlegroups.com
Hi Dominik,

unfortunately default values defined in the code are not supported
(yet) - I had the idea of supporting variable interpolation also in
annotations but have't found the time yet to add that feature.

So, the only work around ATM is specify the property :(

Pull requests are anyway welcome, if you find a way to add the
requested support, I would be glad to add it :)

All the best, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

Dominik Obermaier

unread,
Aug 14, 2012, 5:23:27 AM8/14/12
to roc...@googlegroups.com
Hi Simone,

I built a POC based upon commons-configuration for Typesafe Injection of Properties from a properties file. This is how it looks at the moment:

@Property(name="mypropertyfromfile")
@DefaultValue("my default")
private String string;

The code is just in prototype state and it needs a bit of polishing. I hope you get the idea. I would be glad to contribute these custom annotation injections to rocoto, if you would like. I don't see a reason to start another project for property injections for guice :)

If you like the idea, please give me feedback about the idea or if you do have better annotations in mind :) I am not sure, if it would be good to merge the two annotations...

All the best,

Dominik

Simone Tripodi

unread,
Aug 14, 2012, 10:18:21 AM8/14/12
to roc...@googlegroups.com
Hi Dominik!

I honestly dropped the commons-configuration in rocoto a long time
ago, due to its nature of binding variables in its own dom tree, but
this is something easy to manage due to Rocoto's interfaces to bind
properties.
Moreover, I was looking for a lightweight and dependencies-less
solution, but definitively commons-configuration support could be
released as a secondary module.

I wouldn't add a layer of custom annotations, but rather extending the
@Named JSR330/Guice's ones, something like:

@Named( "${service.port|8080}" )
private int port;

using a syntax Rocoto's users are already used to, in that way if
`service.port` property is not available, 8080 will be used as
default.

Sisu-Inject already supports dynamic variable interpolation in @Named
annotations, I should read that code more carefully.

WDYT?
best,
On Tue, Aug 14, 2012 at 11:23 AM, Dominik Obermaier

Dominik Obermaier

unread,
Aug 21, 2012, 12:51:53 PM8/21/12
to roc...@googlegroups.com
Hi Simone,

I personally prefer a custom annotation for property injection, but I guess this is a matter of taste :)

My final solution which I implemented in my application is like this:

@Property(value = "stringDefaultValue", defaultValue = "myDefaultValue")
String myVariable;

When there is not default Value, this is just a

@Property("stringValue")
String myVariable

I think, that my solution has an other scope than Rocoto because my solution is a bit "heavier", because it relies on commons-configuration and will also be used to read out configuration of a database in my application. For other projects where a simple and small Guice extension is sufficient, I will definitively look into Rocoto again, I like the simplicity and the single-dependency approach.

Nevertheless, It would be great to see default values in Rocoto for property injection, I think there are many use cases for that :)

Thanks for your thoughts about that!

Simone Tripodi

unread,
Aug 22, 2012, 3:10:06 AM8/22/12
to roc...@googlegroups.com
Hi Dominik,

> My final solution which I implemented in my application is like this:
>
> @Property(value = "stringDefaultValue", defaultValue = "myDefaultValue")
> String myVariable;

I wonder why you need to specify the default value in the annotation
rather than in the variable initialization itself, I mean, I would
implement the same logic you implemented using a different (more
"traditional") approach:

@Property( value = "myFramework.lazyLoadingEnabled" )
booelan lazyLoadingEnabled = false;

that should mean: if "myFramework.lazyLoadingEnabled" property is
bound, using it to override the 'lazyLoadingEnabled' field, otherwise
Guice just ignore it.

WDYT?
All the best,
On Tue, Aug 21, 2012 at 6:51 PM, Dominik Obermaier

Dominik Obermaier

unread,
Aug 22, 2012, 4:17:57 AM8/22/12
to roc...@googlegroups.com
Hi Simone,

ah, great idea! I didn't think of that. I personally prefer to do all the "magic" in annotations, but I think this kind of default value initialization would be great for Rocoto, since it would fit perfectly into the concept as I understand it (= no new Annotations, just plain Guice awesomeness) :)

So, for the moment I will stick with my homebrewed implementation, since my coworkers also like the annotation concept but if something like this will go into Rocoto I will definitely use Rocoto for other projects.

Also, if you change your mind about the Annotation approach, I would be glad to donate the code to Rocoto.

Thank you so much for your feedback!

Best,

Simone Tripodi

unread,
Aug 22, 2012, 7:15:08 AM8/22/12
to roc...@googlegroups.com
Hi Dominik,

Apologize but I still haven't caught what is the advantage of
expressing default values in annotations, while you could initialize
the field itself - in a more type-safe way :P

I mean, unless you are strict to string, everything goes well, but
unfortunately you will have to bind values that need to be converted -
and you will get the potential errors at runtime only - so, why adding
that overhead for default values?

TIA, have a nice day!
On Wed, Aug 22, 2012 at 10:17 AM, Dominik Obermaier
Reply all
Reply to author
Forward
0 new messages