This sounds good since I was wondering how these two services fit
together.
Can you shed some more light on how you plan to resolve this?
Well, I haven't thought it through all the way, which is why I
volunteered to play with the code myself rather than subject someone
else to my vague ramblings. But I'll try to describe what I had in
mind.
First, note that the ConfigurationProvider interface is in lib, and
is completely general. It has no notion of specs or persistent
stores. The ProductDerivation interface, on the other hand, is in
kernel, and it does understand specs and stores (not specific ones,
just that those concepts exist). So to move ConfigurationProvider
functionality into ProductDerivation while maintaining the meaning of
lib vs. kernel, we either have to move the utility methods that
utilize ConfigurationProviders out of lib and into kernel, or move a
base ProductDerivation interface without spec and store knowledge
from kernel into lib. In the latter case, kernel would then derive
an OpenJPAProductDerivation interface to add back spec and store
knowledge. Granted, OpenJPA (and its extensions) is the only product
that builds on lib, so having a distinct, non-persistence-aware lib
is of questionable value now, but while it exists I intend to
maintain its meaning. Plus, Kodo does have some internal services
that use lib without being persistence-specific (and for that reason,
it'd be nice to use the latter approach in which ProductDerivation is
generalized for use in lib, rather than the former where some current
functionality is moved from lib into kernel, though I'm sure we could
live with either).
As to the details of how the ProductDerivation interface would take
over for ConfiguraitonProvider: I was thinking we could move
ConfigurationProvider's load() methods into ProductDerivation, but
change them to return a ConfigurationProvider, which will now consist
of just getProperties(), addProperty(ies)(), setInto(). This keeps
ProductDerivations stateless and therefore cacheable and threadsafe.
So when looking for configuration, instead of instantiating
ConfigurationProviders from services and looping through them to find
one that loads, we instead use our loop through our list of
ProductDerviations in order from most-specific (highest return value
from ProductDerivation.getType()) to least, until one returns a non-
null ConfigurationProvider.
So that's basically it for combining ConfigurationProviders and
ProductDerivations into a single service. In a followup email I'll
address how we can give ProductDerivations the ability to extend the
EMF, etc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
