[jboss-dev-forums] [Management Development] - Profiles in domain.xml

[David Lloyd]

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion

"Profiles in domain.xml"

To view the discussion, visit: http://community.jboss.org/message/546593#546593

--------------------------------------------------------------
> Alexey Loubyansky wrote:
> 
> > Scott Stark wrote:
> > I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.
> 
> Ok, this makes sense. Taking it further... The profiles in the domain schema (as they are now) are kind of redefined, i.e. it's not the same profile definition/configuration as the actual profile configuration like here  http://community.jboss.org/wiki/AS6ServerSideConfiguration http://community.jboss.org/wiki/AS6ServerSideConfiguration
Definitely.
> Alexey Loubyansky wrote:
> 
> So, I want to clarify the purpose and meaning of this redefinition in the domain config. Perhaps, it also makes sense to choose a different name not to confuse with the actual profiles.
> I think if we can make domain.xml contain only the concepts/notions that are defined in its schema, it would be the best. I.e. if it contained (was expressed in) only the terms defined for it and learning additional concepts/notions for the user wouldn't be a requirement to understand the configuration.
> 
> Can we think about the profiles here as a set of capabilities that might be activated once there is an application requiring them? I.e. not to think about them as defining capabailities that must be activated after the start-up?
> Perhaps, something like "environment" would describe it?
Yeah, that's exactly what I was getting at.  Though like I said, Scott indicated that we still need the ability to let administrators restrict the set of subsystems that are allowed to be active for a given server group.  But this is definitely not the same as specifying the subsystems that *will* be started up, so yes, I agree.  Though using "environment" might be too general a term?

> Alexey Loubyansky wrote:
> 
> So, what I think we can do:
> - define a set of implied capabilities associated with each application type (or define the "environment" for each application type);
> - if an application is mentioned in the domain.xml w/o specified by the admin "environment" it requires, we assume our defaults;
> - if the admin wants to be precise, it could look like
>   <application name="" path="">
>     <environment name=""/>
>     <environment-ref name=""/>
>   </application>
I'd rather localize the configuration overrides to an explicit deployment declaration.  This gets back to a previous post I made where I gave this example of a possible way to explicitly declare a deployment in XML:

    <!-- An application deployment which is assigned to two server groups -->
    <!-- Note the sha1 hash, so we know which version of my-app.ear to deploy -->
    <deployment name="my-app.ear" sha1="12b4...2b42" server-groups="group1 group2">
        <!--
          ~ Now inside here, we can put all the overrides which apply to a specific deployment,
          ~ using a format that is perhaps specific to each deployment type
          -->
    </deployment>


Or perhaps "deployment-unit" is a better name.

I see what you're getting at with "environments" - to add a level of indirection between deployment types and their capabilities - but I'm not sure that deployment type is the right association to make.  Wouldn't it make more sense to declare the capability restrictions on either a domain-wide or per-server-group basis?  It seems to me that forbidding the use of certain subsystems at a deployment level would be considerably more complex, and I'm not sure that there's a requirement driving that idea.

For example something like this mockup:

    <!-- Domain-wide whitelist -->
    <subsystems>
        <allow name="ejb"/>
        <allow name="http"/>
        <allow name="ws"/>
        <!-- Everything else is denied -->
    </subsystems>

    <!-- The back-end servers do not have HTTP, so blacklist them -->
    <subsystems server-groups="group1">
        <deny name="http"/>
    </subsystems>


Then any deployment going to the server group which implies a requirement on a subsystem which is forbidden would receive a deployment error.  (Assuming I understand the use case correctly, that is.)

One thing is certain though: we need to identify the subsystems in question so we know what set of capabilities we're talking about in the first place.

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/546593#546593]

Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2107]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100607/3cea9567/attachment.html