I think the devil is definitely in the details. I see why Steve decided to
use a Map now. Here's the next issue:
Both the system bootstrap repo and the application repo can have proxy
settings associated with them and they may not be the same. Fine with me
that's just 8 more properties 4 for each repo to parameterize: the host,
port, username and password for both system and application repositories. I
will add the extra properties. However when accessing these values within
the KernelConfig bean I will use an application ProxyContext accessor and a
system ProxyContext accessor rather than accessing each property of a
ProxyContext individually.
We need to devise defaulting behaviors that take into account property
inheritance. To clarify consider the checkbox for setting the shipping
address equal to the billing address on websites. We need this kind of
defaulting behavior to minimize the property setup overhead. Now with these
extra proxy properties I think it is fitting. For example in the absence of
application repository properties we can presume the inheritance of system
repository property values. We do not have to define the policy in this
specific way but it's just an example.
The use of macro expansion within the properties file will be a big benefit
for things like:
merlin.application.repository.proxy.host =
${merlin.system.repository.proxy.host}
This way defaulting behavior can in many ways be specified within the always
present baseline merlin.properties file packaged into the jar. Rather than
hard code the logic we can express it via properties using macro expansion.
This way some defaulting behavior changes for property values need not
require a recompile and maintaining props is much easier.
Alex
P.S. For those on both lists please forgive the echo onto the LDAP list and
the replication it causes - I just want LDAP people to have a record of the
things we are doing to further both projects.
