[jboss-as7-dev] Web UI: Profile & host sections mutable?

[Brian Stansberry]

On 2/14/11 12:01 PM, David M. Lloyd wrote:
> 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.
>

Where it can come in is via a graphical installer. As discussed 
elsewhere on this thread I don't think it's required for the web UI. For 
users of the CLI, native API or xml-editing I think proper documentation 
is sufficient. It's users of a graphical installer who would expect the 
installer to tell them about missing dependencies.

>> 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.
>

Yeah, that was just me thinking (and rejecting) out loud.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat