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.

Reply via email to