Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536159#536159
--------------------------------------------------------------
I agree that a given piece of metadata only existing one place in the model should be the pattern. The template idea makes that relatively painless.
An exception I could see to that would be an element that represents a more general notion of a system property. Formalize the system property substition concept with an element that represents a variable that could be referenced elsewhere.
As to the homogeneous group notion, my thoughts on this were to have a "profile" notion that would encapsulate most of the common configuration. Then clusters, groups or standalone servers would declare what profile they run. This is copied from something I whipped up on a plane to show people in recent clustering meetings, so take it as an illustration only:
<domain>
<profile name=”jee”>.... define a set of capabilities, configuration thereof</profile>
<profile name=”datagrid”>.... define a different set of capabilities</profile>
<profile name=”XYZ">.... define a third set of capabilities</profile>
<cluster name=”JEECluster” mcast_addr=”234.5.6.7” default_stack=”udp” profile=”jee”/>
<cluster name=”DataGrid” mcast_addr=”235.6.7.8” default_stack=”udp” profile=”datagrid”/>
<server-group name="SomeGroup">
<server-group-property name="foo">bar</server-group-property>
</server-group>
<server name=”jee1” bind_address=”192.168.0.100”>
<cluster-ref name=”JEECluster” cluster_address=”10.0.0.100”/>
</server>
<server name=”jee2” bind_address=”192.168.0.101”>
<cluster-ref name=”JEECluster” cluster_address=”10.0.0.101”/>
</server>
<server name=”grid1” bind_address=”192.168.0.102”>
<cluster-ref name=”JEECluster” cluster_address=”10.0.0.102”/>
</server>
<server name=”grid2” bind_address=”192.168.0.103”>
<cluster-ref name=”JEECluster” cluster_address=”10.0.0.103”/>
</server>
<server name=”somegroupA” bind_address=”192.168.0.104”>
<server-group-ref name=”SomeGroup”/>
</server>
<server name=”somegroupB” bind_address=”192.168.0.105”> <server-group-ref name=”SomeGroup”/>
</server>
<server name=”standalone” bind_address=”192.168.0.106”>
<profile-ref name=”XYZ”/> <!-- Standalone server -->
</server>
</domain>
A "cluster" element defines some clustering-related configuration. A server-group is a general group but not a cluster. Not sure exactly what that would be; but I threw it in, as Rich Sharples mentioned it had proved useful. Then a standalone server.
Jason, I'm not sure what a "clustered-service" is.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536159#536159]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/536158#536158
--------------------------------------------------------------
For reference, here is the glassfish domain model structure:
The element hierarchy for the domain.xml file is as follows. To make the hierarchy more readable, elements having property as their last or only subelement are marked with a P, and the property subelements are not shown. Parent/child relationships between elements are shown, but not cardinality. For those details, see the element descriptions.
domain P
. system-applications
. . application P
. . . engine P
. applications
. . application P
. . . engine P
. resources
. . jdbc-resource P
. . jdbc-connection-pool P
. configs
. . config P
. . . http-service P
. . . . access-log
. . . . request-processing
. . . . keep-alive
. . . . connection-pool
. . . . http-protocol
. . . . http-file-cache
. . . . http-listener P
. . . . . ssl
. . . . virtual-server P
. . . . . http-access-log
. . . iiop-service
. . . . orb P
. . . . ssl-client-config
. . . . . ssl
. . . . iiop-listener P
. . . . . ssl
. . . admin-service P
. . . . jmx-connector P
. . . . . ssl
. . . . das-config P
. . . web-container P
. . . . session-config
. . . . . session-manager
. . . . . . manager-properties P
. . . . . . store-properties P
. . . . . session-properties P
. . . ejb-container P
. . . . ejb-timer-service P
. . . mdb-container P
. . . jms-service P
. . . . jms-host P
. . . log-service P
. . . . module-log-levels P
. . . security-service P
. . . . auth-realm P
. . . . jacc-provider P
. . . . audit-module P
. . . . message-security-config
. . . . . provider-config P
. . . . . . request-policy
. . . . . . response-policy
. . . transaction-service P
. . . monitoring-service P
. . . . module-monitoring-levels P
. . . java-config P
. . . . profiler P
. . . . . jvm-options
. . . . jvm-options
. . . thread-pools
. . . . thread-pool P
. . . system-property
. servers
. . server P
. . . application-ref
. . . resource-ref
. . . system-property
. system-property
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536158#536158]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/536144#536144
--------------------------------------------------------------
> Brian Stansberry wrote:
>
> > Jason Greene wrote:
> >
> > > Scott Stark wrote:
> > >
> > > I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable.
> >
> > I totally agree. We should focus on the requirements, use-cases and the model/configuration itself. I also agree that something has to be in domain.xml for it to be truly managable. I kind of saw runtime management of components not in domain.xml as more of a stop-gap. However, it probably is easier to just focus on the domain model, and look at the non-classified runtime stuff later, if it is even relevant anymore.
>
> Great. I'm a lot more comfortable with this approach. Multiple different management approaches coexisting in the same management API, some of which map back to domain.xml and some not -- yuck.
So do we agree that we should drop requirement 6? This would mean that if it's not in domain.xml you can't manage it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536144#536144]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536133#536133
--------------------------------------------------------------
There is always scoping as we need to know how a property specified at the cluster or domain level applies to the server as in the example of system or jvn properties. There its straightforward; the more specific value overrides the more general.
We have not talked about cluster or admin domain metadata, I mean a, so I view your example as just introducing that notion.
The various domain model elements map onto a ManagedComponent in a way that need to be clearly defined. Logically I stil think about it in terms of scopes that have to be applied to a piece of deployment metadata, and each layer adds the opportunity to specify a default that can be overriden by a more specific value.
So, looking at your little fragment, a clustered-service at at group (which I'm thinking of as admin-domain notion), is a specification of clustering aspects that hae to be applied to a bean or spec component. The resource element is a profile default saying that the profile that maps to the "
Production" group should include a "Production DB" jca factory.
This is our initial major challenge to moving to the domain model. We need a mapping from domain metadata namespaces onto a ManagedComponent/ManagedProperty. There can be multiple domain metadata namespaces mapping onto a given ManagedComponent/ManagedProperty.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536133#536133]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years