On 29 Jun 2011, at 16:57, Brian Stansberry wrote:
On 6/29/11 2:45 AM, Heiko W.Rupp wrote:
> Hey,
>
> Am 28.06.2011 um 13:08 schrieb Heiko Braun:
>> The recently introduced split into "ha", "default" and
"web-base" profiles,
>> excludes a lot of the subsystems (messaging, ws, etc)
>
> On a related note: "default" includes "web-base".
Note that for 7.0 we removed the used of <include/>.
> What are the expected semantics when I run default for one SG and
> web-base for another and I want to e.g. change the web-http-connector
> port for default to 18080 and want to leave it as is on web-base?
>
> Does the server support copy on write?
>
The intent is that an element in a profile or socket-binding-group takes
precedence over the same-named element from an included profile or
socket-binding-group. So if you added an http port config to
socket-binding-group "default", that would take precedence.
I don't want to attempt to do any sort of fine-grained merging, i.e. if
there is a subsystem=web config in a "default" profile, that and only
that config is used on any server running the "default" profile; any
details from any subsystem=web in "web-base" would be ignored.
Re: copy-on-write, doing a lot of stuff automagically in this area makes
me nervous. If a user intends to change subsystem=web only on the
servers running "default" I think they should have to take explicit
action to make that happen. That could be as simple as addressing their
change to /profile=default/subsystem=web instead of
/profile=web-base/subsystem=web, but there needs to be something.
That said, assuming the user somehow indicates that only changing the
"default" profile is their intent, a copy-on-write approach sounds good.
It may make it much easier to apply a change to the servers (which know
nothing about multiple profiles and includes; a server just knows it was
given a config for subsystem=web.)
Thinking out loud here:
Ike mentions wanting <include/> to just be syntactic sugar in the xml.
So if profile=default includes profile=web-base and web-base has
subsystem=web, that would largely be relevant in the xml. Looking at the
management resources, you would see:
/profile=web-base/subsystem=web
/profile=default/subsystem=web
The <include profile="web-base"/> in the XML would just be a trigger to
the parser to generate those resources in the model.
Changes to /profile=default/subsystem=web would result in that subsystem
now being persisted in the <profile name=default> section of the xml.
(What magic would trigger that persistence: TBD. Perhaps the in-memory
model for the subsystem includes an included-from-profile="web-base"
attribute, and the presence of that attribute disable persistence to xml.)
Trickier would be a change to /profile=web-base/subsystem=web. What's
the user intent there? Should servers running profile=default be updated
as well, and the syntactic sugar in the xml be maintained? Or is
/profile=default/subsystem=web now decoupled from
/profile=web-base/subsystem=web?
I like having the subsystems managed centrally, and think included profiles should be
"included" only. If we want subsystems from an included profile to be displayed
in the including profile (the syntactic sugar), maybe add an additional attribute on
subsystem such as source-profile="web-base", or included="true"? That
way we can stop them from being edited in any other place than the source profile. We
could also prevent them from appearing in the read-resource results unless an additional
parameter (e.g. include-included) is true. If they want to override subsystem stuff in the
including profile, we could provide a copy function that needs to be called explicitly to
do the decoupling of the subsystem.
One not totally satisfying way to clarify things is to have a notion of
an "abstract" profile. An abstract profile cannot be applied to a server
group. A change to an abstract profile applies to all profiles that
include it and don't themselves override the relevant subsystem. Other
profiles could only include abstract profiles.
</end-brain-dump>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev