Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by 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/545949#545949
--------------------------------------------------------------
> Scott Stark wrote:
>
> We need the ability to lock down the features and configuration on a server. That is not to say that there is a need to support the implied capabilities given a set of applications. However, that would require some processing of the deployment in order to determine what capabilities were in use, including resources. So, if there is an abstraction like:
>
> <applications>
> <web-app name="my-store" context-root="/the-best-store" ...>
> </web-app>
> </applications>
>
> how much work has to be done to adequately identify the required capabilities? We can define the default capabilities implied by the various application types, but ultimately the user should be able to trim that down if they are not using certain features.
>
> 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 so what I'm getting from this is a new requirement:
> "It shall be possible within domain.xml to specify what capabilities/subsystems are allowed (whitelist) or disallowed (blacklist) in order to ensure that undesired subsystems are not inadvertently started causing unexpected performance penalties."
If we make this optional we get the best of both possible worlds. On the one hand, only minimal configuration is required (the default would be an empty blacklist). On the other hand, administrators can ban only certain subsystems, or lock it down tight if they want.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545949#545949]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by 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/545947#545947
--------------------------------------------------------------
> Brian Stansberry wrote:
>
> > David Lloyd wrote:
> > > Brian Stansberry wrote:
> > >
> > > Can't/shouldn't these defaults exist in the schema itself?
> >
> > Maybe in principle, but think of things whose default value might depend on environmental settings (i.e memory size or number of CPUs), or the case where we make a mistake and supply a default which is not reasonable and we have to fix it. The schema is a lot less mutable than our runtime configuration could be.
>
> If the default is a derived from environment settings then we should either expose the non-enviromental portion of the calculation or come up with some other way to express it.
>
> The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.
I get where you're coming from. I'd just be concerned though if it got to a point where it is impossible to start up a server without a large and complex domain.xml file. I don't like the idea of merging XML documents though. I don't think the defaults would be coming from everyplace, just from components which are (a) managed and (b) are in use but were not specified in the domain.xml.
Another scenario this could be relevant is where a component is upgraded, causing more features to become available. The component might want to update its domain configuration with the new default values for the new features. Patching a secondary XML file at upgrade time seems much messier than just using the defaults from a management perspective.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545947#545947]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/545946#545946
--------------------------------------------------------------
We need the ability to lock down the features and configuration on a server. That is not to say that there is a need to support the implied capabilities given a set of applications. However, that would require some processing of the deployment in order to determine what capabilities were in use, including resources. So, if there is an abstraction like:
<applications>
<web-app name="my-store" context-root="/the-best-store" ...>
</web-app>
</applications>
how much work has to be done to adequately identify the required capabilities? We can define the default capabilities implied by the various application types, but ultimately the user should be able to trim that down if they are not using certain features.
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545946#545946]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/545944#545944
--------------------------------------------------------------
> David Lloyd wrote:
> > Brian Stansberry wrote:
> >
> > Can't/shouldn't these defaults exist in the schema itself?
>
> Maybe in principle, but think of things whose default value might depend on environmental settings (i.e memory size or number of CPUs), or the case where we make a mistake and supply a default which is not reasonable and we have to fix it. The schema is a lot less mutable than our runtime configuration could be.
If the default is a derived from environment settings then we should either expose the non-enviromental portion of the calculation or come up with some other way to express it.
The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.
[1] A joke name, reference to the old standardjboss.xml that serves a similar function.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545944#545944]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
[Management Development] - Editing domain.xml
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] created the discussion
"Editing domain.xml"
To view the discussion, visit: http://community.jboss.org/message/545940#545940
--------------------------------------------------------------
domain.xml potentially includes everything, just about all kinds of data there can be related to the AS and its environment. From profiles and high level components to JVM args, IP addresses, ports, etc.
It's potentially a large and complex file with coarse and fine grained configs mixed. I can imagine it might be difficult by openning and reading this file to get a big picture of the domain. That might be just my imagination, though. Anyway, it's still complex and large file, possibly.
How is it supposed to be edited? To begin with, probably, manually. But given the complexity, in perspective, probably more with the tools. JON, admin console, command line, etc. Now ones there are tools, who will want to edit the file manually? Which means domain.xml becomes an implementation detail?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545940#545940]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months