Jerome explained how the annotations work in configbeans:
If you have a default value for the @Param, that will be used to
initialise the corresponding field in the decorator which will also be
used to inject into config attribute. However since you do not have a
default value of the @Attribute declaration, that means the attribute
does not have a default value so the command parameter default value
will always be stored.
think of it another way, if you were not using the CRUD commands (which
are the only ones looking at the @Param declaration) but create your
configuration with a normal config transaction (ConfigSupport.apply
methods for instance), your resulting xml will not have any value unless
you do and an explicit setXXX().
for instance :
@Attribute(defaultValue="bar") String getFoo();
@Param void setFoo(String foo);
no matter how your create your config (transaction, crud), if don't call
setFoo(), getFoo() will return "bar"
@Attribute String getFoo();
@Param(defaultValue="bar") void setFoo(String foo);
if you use a transaction to create the config and don't call setFoo()
then getFoo() will be null.
if you use CRUD, to create the config, user did not specify the foo
option, getFoo() will return "bar".
last example :
@Attribute(defaultValue="ba" String getFoo();
@Param(defaultValue="bar") void setFoo(String foo);
if u create your config with a transaction and don't call setFoo(),
getFoo() return "ba"
if u create your config with a CRUD and foo is not specified by the
user, getFoo() return "bar"
nobody returns "babar" ;-)
The @Param default value sets an initial value to the field that will be
used when creating the underlying config.
The @Attribute default value is the value of the field when not set.
In my last example, I cannot imagine why you would want to have
different @Param and @Attribute default values set on the @Configured
configuration but it's possible maybe for compatibility with previous
releases, etc