[jboss-as7-dev] Recent profile changes

[Brian Stansberry]

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?

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