Profile config strategy

[Rod Widdowson]

I think I need to see/imagine a worked example since I tend to end up with a
"it depends" depending on the case - for instance it seems stupid to have a
whole set/getter bean just to add a new encryption type (if that is a
relevant example) and at the other end of the spectrum one is adding
something so large that one is probably looking at a sub version change...

> 
> Well, my assumption was that we would have code in the -api package(s)
> that actually needed to access those interfaces/classes.
> 
> Now that you mention it, maybe that's an assumption. If it turns out that
> there aren't, or at least that the major ones don't, then this sort of
> answers itself, and some of the config classes might become -impl and are
> not part of the API, which then eliminates the versioning requirement to
> tweak them.

I'd have to back your judgment - you are closest to the code, the problem
space and the specifications.  Suffice to say that nothing proposed thusfar
seems like a bad idea so we seem to be faced with a "chose the best out of a
list of good solutions" situation, rather than a "chose the least-worst"
one.
 
> That's not really a problem, I think. For a native Spring config file,
> there's a reference to the actual implementation class, and that's going
> to have setters. That's all done indirectly with reflection already.

My problem here is that the xml file itself is not backwards compatible.
Either class name is not found in the earlier version of the jar and we die,
or the setter doesn't exist in the earlier version or the class and we
die...

/Rod