On 02/14/2011 11:27 AM, Brian Stansberry wrote:
On 2/14/11 11:14 AM, David M. Lloyd wrote:
> The way we've solved this in other subsystems is by introducing optional
> dependencies at the service level. For example if the transaction
> subsystem is configured with an ORB present, we configure JTS, otherwise
> we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
> service.
>
> I'm not 100% certain we can extend this technique to all cases, but I
> think we should at least try to. JCA for example would obviously be
> quite crippled without JTA. So I do not have an answer to that case;
> maybe it suffices to print a warning message in this case. We should at
> least explore it before we throw out the idea though.
Let's assume for the sake of argument that we want to expose dependency
info via the management interface. I see here hard dependencies (e.g.
presumably JCA and JTA) and optional. Extensions could register these
dependencies when they initialize. It opens up a can of worms though, as
we'd need a proper language to describe the dependencies.
Yeah the can of worms is what I seek to avoid, though it might be
inevitable eventually.
Thinking out loud here, could we use the module dependency
information
for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
but says nothing about the impl.
I don't think module deps would cut it for this use case. The
dependency exists at purely a subsystem level, not at a module level,
and imposing a constraint between the two just for this reason really
rubs me the wrong way; anyway module dependencies are not by any means
static (we just use them that way, most of the time) and are definitely
not suitable as management layer metainformation.
--
- DML