Recent profile changes

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Recent profile changes

Heiko Braun


The recently introduced split into "ha", "default" and "web-base" profiles,
excludes a lot of the subsystems (messaging, ws, etc)

Would it make sense to introduce a full blown "all" profile,
that provides all capabilities out of the box?

If not been used it would at least act as a configuration preset for people
that would like to include one of it's subsystems in a profile subset
(i.e. adding ”messaging" to profile "web-base").

Currently it looks like we ship an app server w/o these functionalities.
This is at least what the average user will perceive, IMO.

Ike
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Darran Lofthouse
On 06/28/2011 12:08 PM, Heiko Braun wrote:
>
>
> The recently introduced split into "ha", "default" and "web-base" profiles,
> excludes a lot of the subsystems (messaging, ws, etc)
>
> Would it make sense to introduce a full blown "all" profile,
> that provides all capabilities out of the box?

Isn't this already in the -preview.xml configurations?

> If not been used it would at least act as a configuration preset for people
> that would like to include one of it's subsystems in a profile subset
> (i.e. adding ”messaging" to profile "web-base").
>
> Currently it looks like we ship an app server w/o these functionalities.
> This is at least what the average user will perceive, IMO.
>
> Ike
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko Braun


Right. I wasn't aware of these changes.
Will the users be? Is it properly documented?


Isn't this already in the -preview.xml configurations?


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Shelly McGowan

Heiko,

This is going to be included in the Getting Started (Installation) Guide I'm working on.



Shelly McGowan
JBoss, by Red Hat



----- Original Message -----
From: "Heiko Braun" <[hidden email]>
To: "Darran Lofthouse" <[hidden email]>
Cc: [hidden email]
Sent: Tuesday, June 28, 2011 7:22:44 AM
Subject: Re: [jboss-as7-dev] Recent profile changes







Right. I wasn't aware of these changes.
Will the users be? Is it properly documented?






Isn't this already in the -preview.xml configurations?


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko Braun


How do I launch with the *-preview.xml configurations?


On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:

>
> Heiko,
>
> This is going to be included in the Getting Started (Installation) Guide I'm working on.
>
>
>
> Shelly McGowan
> JBoss, by Red Hat
>
>
>
> ----- Original Message -----
> From: "Heiko Braun" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, June 28, 2011 7:22:44 AM
> Subject: Re: [jboss-as7-dev] Recent profile changes
>
>
>
>
>
>
>
> Right. I wasn't aware of these changes.
> Will the users be? Is it properly documented?
>
>
>
>
>
>
> Isn't this already in the -preview.xml configurations?
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

David Bosschaert
jboss-7.x.x.x/bin/standalone.sh -server-config standalone-preview.xml

David

On 28/06/2011 13:34, Heiko Braun wrote:

>
> How do I launch with the *-preview.xml configurations?
>
>
> On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:
>
>> Heiko,
>>
>> This is going to be included in the Getting Started (Installation) Guide I'm working on.
>>
>>
>>
>> Shelly McGowan
>> JBoss, by Red Hat
>>
>>
>>
>> ----- Original Message -----
>> From: "Heiko Braun"<[hidden email]>
>> To: "Darran Lofthouse"<[hidden email]>
>> Cc: [hidden email]
>> Sent: Tuesday, June 28, 2011 7:22:44 AM
>> Subject: Re: [jboss-as7-dev] Recent profile changes
>>
>>
>>
>>
>>
>>
>>
>> Right. I wasn't aware of these changes.
>> Will the users be? Is it properly documented?
>>
>>
>>
>>
>>
>>
>> Isn't this already in the -preview.xml configurations?
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Shelly McGowan
In reply to this post by Heiko Braun



./standalone.sh --server-config=standalone-preview.xml

(thx, brian)

Shelly McGowan
JBoss, by Red Hat

----- Original Message -----
From: "Heiko Braun" <[hidden email]>
To: "Shelly McGowan" <[hidden email]>
Cc: [hidden email], "Darran Lofthouse" <[hidden email]>
Sent: Tuesday, June 28, 2011 8:34:50 AM
Subject: Re: [jboss-as7-dev] Recent profile changes



How do I launch with the *-preview.xml configurations?


On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:

>
> Heiko,
>
> This is going to be included in the Getting Started (Installation) Guide I'm working on.
>
>
>
> Shelly McGowan
> JBoss, by Red Hat
>
>
>
> ----- Original Message -----
> From: "Heiko Braun" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, June 28, 2011 7:22:44 AM
> Subject: Re: [jboss-as7-dev] Recent profile changes
>
>
>
>
>
>
>
> Right. I wasn't aware of these changes.
> Will the users be? Is it properly documented?
>
>
>
>
>
>
> Isn't this already in the -preview.xml configurations?
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Andrig Miller
Does the equal sign (=) work now?  It didn't work, and I needed to use a space in between before.

Andy


From: "Shelly McGowan" <[hidden email]>
To: "Heiko Braun" <[hidden email]>
Cc: [hidden email]
Sent: Tuesday, June 28, 2011 9:16:01 AM
Subject: Re: [jboss-as7-dev] Recent profile changes




./standalone.sh --server-config=standalone-preview.xml

(thx, brian)

Shelly McGowan
JBoss, by Red Hat

----- Original Message -----
From: "Heiko Braun" <[hidden email]>
To: "Shelly McGowan" <[hidden email]>
Cc: [hidden email], "Darran Lofthouse" <[hidden email]>
Sent: Tuesday, June 28, 2011 8:34:50 AM
Subject: Re: [jboss-as7-dev] Recent profile changes



How do I launch with the *-preview.xml configurations?


On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:

>
> Heiko,
>
> This is going to be included in the Getting Started (Installation) Guide I'm working on.
>
>
>
> Shelly McGowan
> JBoss, by Red Hat
>
>
>
> ----- Original Message -----
> From: "Heiko Braun" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, June 28, 2011 7:22:44 AM
> Subject: Re: [jboss-as7-dev] Recent profile changes
>
>
>
>
>
>
>
> Right. I wasn't aware of these changes.
> Will the users be? Is it properly documented?
>
>
>
>
>
>
> Isn't this already in the -preview.xml configurations?
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Brian Stansberry
As of last night these should all work:

--server-config=x
--server-config x
-server-config=x
-server-config x

The CLI uses the two-dash-and-equals-sign syntax, so I plan to change
the usage note you get from ./standalone.sh --help to use that syntax;
the other ones will work though. I figured it was easier to make them
work than explain a change. Misty, we should update the docs to the
two-dash-and-equals-sign syntax.

Same patterns apply for --domain-config and --host-config.

Basically, for command line options we supported before, we now support
single-dash or two-dash, and, if the option takes a value, either a
space or '=' as the separator.

A single char option will only support the single-dash. I also pulled
over a couple single char variants from AS 6.

-h
-help
--help

-V
-version
--version

But I don't want to support all these variants in the CLI, so I think we
should only document:

-x (no value)
-x=value
--xyz (no value)
--xyx=value

On 6/28/11 10:54 AM, Andrig Miller wrote:

> Does the equal sign (=) work now? It didn't work, and I needed to use a
> space in between before.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Shelly McGowan" <[hidden email]>
>     *To: *"Heiko Braun" <[hidden email]>
>     *Cc: *[hidden email]
>     *Sent: *Tuesday, June 28, 2011 9:16:01 AM
>     *Subject: *Re: [jboss-as7-dev] Recent profile changes
>
>
>
>
>     ./standalone.sh --server-config=standalone-preview.xml
>
>     (thx, brian)
>
>     Shelly McGowan
>     JBoss, by Red Hat
>
>     ----- Original Message -----
>     From: "Heiko Braun" <[hidden email]>
>     To: "Shelly McGowan" <[hidden email]>
>     Cc: [hidden email], "Darran Lofthouse"
>     <[hidden email]>
>     Sent: Tuesday, June 28, 2011 8:34:50 AM
>     Subject: Re: [jboss-as7-dev] Recent profile changes
>
>
>
>     How do I launch with the *-preview.xml configurations?
>
>
>     On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:
>
>      >
>      > Heiko,
>      >
>      > This is going to be included in the Getting Started
>     (Installation) Guide I'm working on.
>      >
>      >
>      >
>      > Shelly McGowan
>      > JBoss, by Red Hat
>      >
>      >
>      >
>      > ----- Original Message -----
>      > From: "Heiko Braun" <[hidden email]>
>      > To: "Darran Lofthouse" <[hidden email]>
>      > Cc: [hidden email]
>      > Sent: Tuesday, June 28, 2011 7:22:44 AM
>      > Subject: Re: [jboss-as7-dev] Recent profile changes
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > Right. I wasn't aware of these changes.
>      > Will the users be? Is it properly documented?
>      >
>      >
>      >
>      >
>      >
>      >
>      > Isn't this already in the -preview.xml configurations?
>      >
>      >
>      > _______________________________________________
>      > jboss-as7-dev mailing list
>      > [hidden email]
>      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Misty Stanley-Jones
Got it, thanks Brian.

Misty

----- Original Message -----

> From: "Brian Stansberry" <[hidden email]>
> To: "Andrig Miller" <[hidden email]>
> Cc: "Shelly McGowan" <[hidden email]>, [hidden email], "Misty Stanley-Jones" <[hidden email]>
> Sent: Wednesday, June 29, 2011 2:09:50 AM
> Subject: Re: [jboss-as7-dev] Recent profile changes
> As of last night these should all work:
>
> --server-config=x
> --server-config x
> -server-config=x
> -server-config x
>
> The CLI uses the two-dash-and-equals-sign syntax, so I plan to change
> the usage note you get from ./standalone.sh --help to use that syntax;
> the other ones will work though. I figured it was easier to make them
> work than explain a change. Misty, we should update the docs to the
> two-dash-and-equals-sign syntax.
>
> Same patterns apply for --domain-config and --host-config.
>
> Basically, for command line options we supported before, we now
> support
> single-dash or two-dash, and, if the option takes a value, either a
> space or '=' as the separator.
>
> A single char option will only support the single-dash. I also pulled
> over a couple single char variants from AS 6.
>
> -h
> -help
> --help
>
> -V
> -version
> --version
>
> But I don't want to support all these variants in the CLI, so I think
> we
> should only document:
>
> -x (no value)
> -x=value
> --xyz (no value)
> --xyx=value
>
> On 6/28/11 10:54 AM, Andrig Miller wrote:
> > Does the equal sign (=) work now? It didn't work, and I needed to
> > use a
> > space in between before.
> >
> > Andy
> >
> > ------------------------------------------------------------------------
> >
> >     *From: *"Shelly McGowan" <[hidden email]>
> >     *To: *"Heiko Braun" <[hidden email]>
> >     *Cc: *[hidden email]
> >     *Sent: *Tuesday, June 28, 2011 9:16:01 AM
> >     *Subject: *Re: [jboss-as7-dev] Recent profile changes
> >
> >
> >
> >
> >     ./standalone.sh --server-config=standalone-preview.xml
> >
> >     (thx, brian)
> >
> >     Shelly McGowan
> >     JBoss, by Red Hat
> >
> >     ----- Original Message -----
> >     From: "Heiko Braun" <[hidden email]>
> >     To: "Shelly McGowan" <[hidden email]>
> >     Cc: [hidden email], "Darran Lofthouse"
> >     <[hidden email]>
> >     Sent: Tuesday, June 28, 2011 8:34:50 AM
> >     Subject: Re: [jboss-as7-dev] Recent profile changes
> >
> >
> >
> >     How do I launch with the *-preview.xml configurations?
> >
> >
> >     On Jun 28, 2011, at 1:38 PM, Shelly McGowan wrote:
> >
> >      >
> >      > Heiko,
> >      >
> >      > This is going to be included in the Getting Started
> >     (Installation) Guide I'm working on.
> >      >
> >      >
> >      >
> >      > Shelly McGowan
> >      > JBoss, by Red Hat
> >      >
> >      >
> >      >
> >      > ----- Original Message -----
> >      > From: "Heiko Braun" <[hidden email]>
> >      > To: "Darran Lofthouse" <[hidden email]>
> >      > Cc: [hidden email]
> >      > Sent: Tuesday, June 28, 2011 7:22:44 AM
> >      > Subject: Re: [jboss-as7-dev] Recent profile changes
> >      >
> >      >
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > Right. I wasn't aware of these changes.
> >      > Will the users be? Is it properly documented?
> >      >
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > Isn't this already in the -preview.xml configurations?
> >      >
> >      >
> >      > _______________________________________________
> >      > jboss-as7-dev mailing list
> >      > [hidden email]
> >      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >     _______________________________________________
> >     jboss-as7-dev mailing list
> >     [hidden email]
> >     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
> >
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat

--


Misty Stanley-Jones, RHCE
Content Author, ECS Brisbane
☺: misty (Freenode IRC) ✉: [hidden email] ☏: +61 7 3514 8105 ☏: 88105

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko W.Rupp
In reply to this post by Heiko Braun
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".
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?

    Heiko


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

kkhan


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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Brian Stansberry
On 6/29/11 11:11 AM, Kabir Khan wrote:

>
>
> 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"?

I had included-from-profile="web-base" above, but
source-profile="web-base" is better.

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.

We'd have to apply that param to all the relevant global operations
(read-children-names etc). It also becomes a universal parameter that is
only meaningful when certain addresses are involved. These aren't
blocker problems, just things to be aware of.  A blocker issue would be
coming up with a better name. ;)

CLI navigation could be a problem here; you can do a
:read-children-names(include-included=true) but then can't navigate.
Unless we had logic on the server side to recognize that...

/profile=default/subsystem=web:read-resource

really means to read /profile=web-base/subsystem=web and then stick
source-profile="web-base" in the response.

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.

Ok, so you've defined the boundaries of a "no auto-magic, require the
user to clearly state their intent" approach, which is good.

I'm curious to hear other viewpoints.

>
>>
>> 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.
>>

WDYT about this 'abstract' notion? Whether or not we require a 'copy'
operation to decouple the included subsystem, I don't like having a
profile be both inherited and directly applied to servers. It makes it
too difficult to determine the user's intent when they modify the profile.

>> </end-brain-dump>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

kkhan

On 29 Jun 2011, at 17:46, Brian Stansberry wrote:

> On 6/29/11 11:11 AM, Kabir Khan wrote:
>>
>>
>> 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"?
>
> I had included-from-profile="web-base" above, but
> source-profile="web-base" is better.
>
> 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.
>
> We'd have to apply that param to all the relevant global operations
> (read-children-names etc). It also becomes a universal parameter that is
> only meaningful when certain addresses are involved. These aren't
> blocker problems, just things to be aware of.  A blocker issue would be
> coming up with a better name. ;)
>
> CLI navigation could be a problem here; you can do a
> :read-children-names(include-included=true) but then can't navigate.
> Unless we had logic on the server side to recognize that...
>
> /profile=default/subsystem=web:read-resource
>
> really means to read /profile=web-base/subsystem=web and then stick
> source-profile="web-base" in the response.
>
> 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.
>
> Ok, so you've defined the boundaries of a "no auto-magic, require the
> user to clearly state their intent" approach, which is good.
>
> I'm curious to hear other viewpoints.
>
>>
>>>
>>> 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.
>>>
>
> WDYT about this 'abstract' notion? Whether or not we require a 'copy'
> operation to decouple the included subsystem, I don't like having a
> profile be both inherited and directly applied to servers. It makes it
> too difficult to determine the user's intent when they modify the profile.

I don't really see the difference between an an abstract profile or any other included profile. So we have "abstract-profile" which can't be used in a server group, instead you would need to create a "concrete-profile" which includes "abstract-profile" and then use "concrete-profile" in the server group. So if "concrete-profile" is empty apart from the include I don't really see the benefit?



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko Braun
In reply to this post by Brian Stansberry

On Jun 29, 2011, at 6:46 PM, Brian Stansberry wrote:

> I'm curious to hear other viewpoints.


The initial idea of considering <include/> being syntactic sugar was mostly addressing
client operations with the assumption of eliminating the included profile and make it look and
behave like one single profile at runtime.


I.e. read and write operation would simply have to work on one address. This is currently causing most of the problems, since clients have to maintain the source reference on their own. But conceptually you don't care if
a profile is actually a composite of many others. At the end of the day, a server group does reference a single profile and that's how users will perceive it.

I would prefer a solution that's straight forward and easy to understand:

- <include/> is syntactic sugar
- at the end you'll address a  single profile (i.e /profile=web) for read & write operations
  (even if it includes other profiles)
- the domain layer takes care it properly distinguished and persisted into each source profile declaration
- no cyclic references are allowed. the parse should choke on this.
- subsystem overlays are not possible. This means re-declaring a subsystem in extended profiles is not allowed

The last point is especially important to keep things simple:
If we allow to re-declare profiles, we would need to think about other implications too:

- will it replace the existing declaration?
- or will it merged with an existing one

all the other problems described earlier do also apply:
- what profile do I address in write operations
- how will this be applied to servers?

I think we prevent all this, by simple not allowing subsystem re-declarations .

Ike





_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

kkhan

On 2 Jul 2011, at 09:18, Heiko Braun wrote:

>
> On Jun 29, 2011, at 6:46 PM, Brian Stansberry wrote:
>
>> I'm curious to hear other viewpoints.
>
>
> The initial idea of considering <include/> being syntactic sugar was mostly addressing
> client operations with the assumption of eliminating the included profile and make it look and
> behave like one single profile at runtime.
>
>
> I.e. read and write operation would simply have to work on one address. This is currently causing most of the problems, since clients have to maintain the source reference on their own. But conceptually you don't care if
> a profile is actually a composite of many others. At the end of the day, a server group does reference a single profile and that's how users will perceive it.
>
> I would prefer a solution that's straight forward and easy to understand:
>
> - <include/> is syntactic sugar
> - at the end you'll address a  single profile (i.e /profile=web) for read & write operations
>  (even if it includes other profiles)
> - the domain layer takes care it properly distinguished and persisted into each source profile declaration
> - no cyclic references are allowed. the parse should choke on this.
> - subsystem overlays are not possible. This means re-declaring a subsystem in extended profiles is not allowed
>
> The last point is especially important to keep things simple:
> If we allow to re-declare profiles, we would need to think about other implications too:
>
> - will it replace the existing declaration?
> - or will it merged with an existing one
Replace is easier
>
> all the other problems described earlier do also apply:
> - what profile do I address in write operations
> - how will this be applied to servers?
>
> I think we prevent all this, by simple not allowing subsystem re-declarations .

But at the same time if "web" and "other" both include "base" which declares "subsystemA". If I understood you correctly you would be able to change stuff under profile=>web,subsystem=>subsystemA and those changes would then show up in profile=>other,subsystem=>subsystemA which seems wrong to me.

I prefer it the way we have it set up now, but with the ability to see but not modify inherited stuff easily.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

kkhan

On 2 Jul 2011, at 10:56, Kabir Khan wrote:

>
> On 2 Jul 2011, at 09:18, Heiko Braun wrote:
>
>>
>> On Jun 29, 2011, at 6:46 PM, Brian Stansberry wrote:
>>
>>> I'm curious to hear other viewpoints.
>>
>>
>> The initial idea of considering <include/> being syntactic sugar was mostly addressing
>> client operations with the assumption of eliminating the included profile and make it look and
>> behave like one single profile at runtime.
>>
>>
>> I.e. read and write operation would simply have to work on one address. This is currently causing most of the problems, since clients have to maintain the source reference on their own. But conceptually you don't care if
>> a profile is actually a composite of many others. At the end of the day, a server group does reference a single profile and that's how users will perceive it.
>>
>> I would prefer a solution that's straight forward and easy to understand:
>>
>> - <include/> is syntactic sugar
>> - at the end you'll address a  single profile (i.e /profile=web) for read & write operations
>> (even if it includes other profiles)
>> - the domain layer takes care it properly distinguished and persisted into each source profile declaration
>> - no cyclic references are allowed. the parse should choke on this.
>> - subsystem overlays are not possible. This means re-declaring a subsystem in extended profiles is not allowed
>>
>> The last point is especially important to keep things simple:
>> If we allow to re-declare profiles, we would need to think about other implications too:
>>
>> - will it replace the existing declaration?
>> - or will it merged with an existing one
> Replace is easier
>>
>> all the other problems described earlier do also apply:
>> - what profile do I address in write operations
>> - how will this be applied to servers?
>>
>> I think we prevent all this, by simple not allowing subsystem re-declarations .
>
> But at the same time if "web" and "other" both include "base" which declares "subsystemA". If I understood you correctly you would be able to change stuff under profile=>web,subsystem=>subsystemA and those changes would then show up in profile=>other,subsystem=>subsystemA which seems wrong to me.
>
> I prefer it the way we have it set up now, but with the ability to see but not modify inherited stuff easily.
...ability to easily see but not modify inherited stuff

> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko Braun
In reply to this post by kkhan

Makes sense from your point of view, but for tools or users it's difficult to maintain
the proper source address and dealing with circular references.

Let's say profile B includes profile A. Profile A declares subsystem Foo.

Can we support both?

/profile=B/subsystem=Foo:write-attribute

and

/profile=A/subsystem=Foo:write-attribute

The point is that for most management tasks, it doesn't matter that the effective profile
actually consists of an inclusion hierarchy. I believe people care about the subsystem "Web" configuration
for a particular server, regardless of it's origin. So forcing them to deal with the inclusion hierarchy
doesn't make sense to me. I don't see the added value.

Apart from that there are other, related questions that we need address:

- Are subsystem re-declarations allowed within an inclusion hierarchy?
- What's the policy for this: replace or merge?

I think once these questions are answered we'll easily find a solution to the questions above.

Ike


On Jul 2, 2011, at 11:56 AM, Kabir Khan wrote:

> I prefer it the way we have it set up now, but with the ability to see but not modify inherited stuff easily.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent profile changes

Heiko W.Rupp
In reply to this post by Heiko Braun

Am 02.07.2011 um 10:18 schrieb Heiko Braun:
> - <include/> is syntactic sugar
> - at the end you'll address a  single profile (i.e /profile=web) for read & write operations
>  (even if it includes other profiles)

Yep, I see this as important too.

> - subsystem overlays are not possible. This means re-declaring a subsystem in extended profiles is not allowed

I may not understand this. So:
how do you e.g. have in web-base  subsys=web, connector=http and in profile X, building on
web-base also subsys=web,connector=https ? In this case X would need to redeclare the
subystem in oder to add the additional connector?

  pilhuhn
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12
Loading...