Subsystem specific deployer configurations in standalone.xml/domain.xml

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
I've been working $subject in order to help support Thomas Diesler's
request for AS7-3694[1]. The gist of this request is to add deployment
unit processing (DUP) configuration as children of the deployment
resource itself. Thomas' OSGi use case is one place where this would be
used. I expect HASingleton deployment will be another.

WIP is at [2]. I'm looking for feedback. :)

What I've done is based on what Thomas did at [3]. What I want to do is
move from the generic key/value pairs in that patch to a more formally
describable management API. Instead of:

<deployment name="foo.war"...>
  <properties>
   <property name="start.policy" value="DEFERRED"/>
  <property>
</deployment>

It would be something analogous to how a profile configuration is done:

<deployment name="foo.war"...>
  <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
    <start-policy value="deferred"/>
  </deployment>
</deployment>

The existing Extension API already has the hooks to support this.
Extensions can register xml parsers for children of the <deployment>
element and can register management resources to act as children of the
/deployment=foo.war resource as well. Several subsystems already take
advantage of the latter. Until now the former has been an unimplemented
API. The commit at [4] implements it.

A couple things giving me some concern:

1) The above xml:

<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">

Nicer would be something like:

<deployers>
   <subsystem xmlns="urn:jboss:domain:osgi:1.2">

I need to figure out if I can do some tricks with the parsing to allow
that to happen.

2) The structure of the resource tree. We already support resources like
this:

/deployment=foo.war/subsystem=web

Subsystems register resources like those to expose metrics. The commit
at [4] uses that same tree. When subsystems could now register child
resources to the deployment=* resource, they could include both runtime
stuff and configuration stuff.

I'm not sure that mixing the two is ideal, although it's what we do for
the regular subsystem resources in the profile. I'm vaguely concerned
that if someday the configuration that subsystems choose to expose via
this mechanism gets complex, the mixing of metrics with configuration in
the same tree will start to break down.

Comments are appreciated.


[1] https://issues.jboss.org/browse/AS7-3694
[2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
[3] https://github.com/jbossas/jboss-as/pull/3230
[4]
https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
--
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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Tomaž Cerar-2
Why are introducing yet another configuration mechanism for deployments?

now we have
- jboss-deployment-structure.xml
- jboss-deployment-dependencies.xml
- jboss-all.xml
- jboss-xyz.xml - (too) many of them

that in combination with overlays this could provide same capability.
AFAIR primary idea behind jboss-all.xml was to unify configuration for all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml, jboss-app.xml,....)

and overlays just add this extra capability of exposing/manipulating this trough management.
This new approach has only one extra capability that is to enable subsystem itself to push/write/change some configuration that is deployment-wise.
>From my point of view that is just wrong. Subsystems should not run-time decide and change some deployment parameters that you can than also manipulate trough mgmt.

Maybe I am not seeing some use-case but in general I don't like this approach...

--
tomaz


On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry <[hidden email]> wrote:
I've been working $subject in order to help support Thomas Diesler's
request for AS7-3694[1]. The gist of this request is to add deployment
unit processing (DUP) configuration as children of the deployment
resource itself. Thomas' OSGi use case is one place where this would be
used. I expect HASingleton deployment will be another.

WIP is at [2]. I'm looking for feedback. :)

What I've done is based on what Thomas did at [3]. What I want to do is
move from the generic key/value pairs in that patch to a more formally
describable management API. Instead of:

<deployment name="foo.war"...>
  <properties>
   <property name="start.policy" value="DEFERRED"/>
  <property>
</deployment>

It would be something analogous to how a profile configuration is done:

<deployment name="foo.war"...>
  <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
    <start-policy value="deferred"/>
  </deployment>
</deployment>

The existing Extension API already has the hooks to support this.
Extensions can register xml parsers for children of the <deployment>
element and can register management resources to act as children of the
/deployment=foo.war resource as well. Several subsystems already take
advantage of the latter. Until now the former has been an unimplemented
API. The commit at [4] implements it.

A couple things giving me some concern:

1) The above xml:

<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">

Nicer would be something like:

<deployers>
   <subsystem xmlns="urn:jboss:domain:osgi:1.2">

I need to figure out if I can do some tricks with the parsing to allow
that to happen.

2) The structure of the resource tree. We already support resources like
this:

/deployment=foo.war/subsystem=web

Subsystems register resources like those to expose metrics. The commit
at [4] uses that same tree. When subsystems could now register child
resources to the deployment=* resource, they could include both runtime
stuff and configuration stuff.

I'm not sure that mixing the two is ideal, although it's what we do for
the regular subsystem resources in the profile. I'm vaguely concerned
that if someday the configuration that subsystems choose to expose via
this mechanism gets complex, the mixing of metrics with configuration in
the same tree will start to break down.

Comments are appreciated.


[1] https://issues.jboss.org/browse/AS7-3694
[2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
[3] https://github.com/jbossas/jboss-as/pull/3230
[4]
https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
--
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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
Good question.

I see it as a matter of roles. The jboss-all.xml file is full of
configurations that are basically about how the deployment functions
internally. That stuff is primarily the concern of the application
developer. The admin may want to make some adaptations to tailor to the
environment, but the contents of that file are basically the province of
the app developers.

The AS7-3694 request and HASingleton are primarily about under what
conditions the deployment is installed at all. That is something the
admin controls.

So, we could:

1) Go with jboss-all.xml + overlays and force the admin to mix his stuff
in with the app developer's stuff, keeping them in sync. (An overlay is
a complete override, not a merge.)

2) Add new xxx.xml files to control this stuff and use overlays to let
the admin insert his desired configs into the deployment. This would
basically just be a hack workaround because we don't want to do overlay
merging.

3) The management resource approach.

On 10/15/12 5:32 PM, Tomaž Cerar wrote:

> Why are introducing yet another configuration mechanism for deployments?
>
> now we have
> - jboss-deployment-structure.xml
> - jboss-deployment-dependencies.xml
> - jboss-all.xml
> - jboss-xyz.xml - (too) many of them
>
> that in combination with overlays this could provide same capability.
> AFAIR primary idea behind jboss-all.xml was to unify configuration for
> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
> jboss-app.xml,....)
>
> and overlays just add this extra capability of exposing/manipulating
> this trough management.
> This new approach has only one extra capability that is to enable
> subsystem itself to push/write/change some configuration that is
> deployment-wise.
>  From my point of view that is just wrong. Subsystems should not
> run-time decide and change some deployment parameters that you can than
> also manipulate trough mgmt.
>
> Maybe I am not seeing some use-case but in general I don't like this
> approach...
>
> --
> tomaz
>
>
> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I've been working $subject in order to help support Thomas Diesler's
>     request for AS7-3694[1]. The gist of this request is to add deployment
>     unit processing (DUP) configuration as children of the deployment
>     resource itself. Thomas' OSGi use case is one place where this would be
>     used. I expect HASingleton deployment will be another.
>
>     WIP is at [2]. I'm looking for feedback. :)
>
>     What I've done is based on what Thomas did at [3]. What I want to do is
>     move from the generic key/value pairs in that patch to a more formally
>     describable management API. Instead of:
>
>     <deployment name="foo.war"...>
>        <properties>
>         <property name="start.policy" value="DEFERRED"/>
>        <property>
>     </deployment>
>
>     It would be something analogous to how a profile configuration is done:
>
>     <deployment name="foo.war"...>
>        <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>          <start-policy value="deferred"/>
>        </deployment>
>     </deployment>
>
>     The existing Extension API already has the hooks to support this.
>     Extensions can register xml parsers for children of the <deployment>
>     element and can register management resources to act as children of the
>     /deployment=foo.war resource as well. Several subsystems already take
>     advantage of the latter. Until now the former has been an unimplemented
>     API. The commit at [4] implements it.
>
>     A couple things giving me some concern:
>
>     1) The above xml:
>
>     <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
>     Nicer would be something like:
>
>     <deployers>
>         <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
>     I need to figure out if I can do some tricks with the parsing to allow
>     that to happen.
>
>     2) The structure of the resource tree. We already support resources like
>     this:
>
>     /deployment=foo.war/subsystem=web
>
>     Subsystems register resources like those to expose metrics. The commit
>     at [4] uses that same tree. When subsystems could now register child
>     resources to the deployment=* resource, they could include both runtime
>     stuff and configuration stuff.
>
>     I'm not sure that mixing the two is ideal, although it's what we do for
>     the regular subsystem resources in the profile. I'm vaguely concerned
>     that if someday the configuration that subsystems choose to expose via
>     this mechanism gets complex, the mixing of metrics with configuration in
>     the same tree will start to break down.
>
>     Comments are appreciated.
>
>
>     [1] https://issues.jboss.org/browse/AS7-3694
>     [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>     [3] https://github.com/jbossas/jboss-as/pull/3230
>     [4]
>     https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Jaikiran Pai
I'm unclear about a couple of things related to this change:

1) Will this (whatever property is being configured) apply to all
deployments?Looking at the example you pasted it looks like each
deployment can potentially be treated differently by setting a different
value for the property, which kind of comes back to what Tomaz says
about the other options available. Introducing this new way might be a
problem if other subsystems decide to introduce a new child of the
deployment resource to configure something that can already be done via
jboss-foo.xml which brings up the question about which one of those
values takes priority.

2) AS7-3694 looks like a case where a deployment has to be attached (or
processed) in a certain way by the OSGi DUPs by using a configured
property. Shouldn't the OSGi subsystem be introducing such a management
resource/attribute within that subsystem instead of doing it at the
deployment resource? For example, consider the "default distinct name"
that the EJB3 subsystem DUPs need to apply to deployments. This default
distinct name is configured by an admin and hence is exposed as a
management attribute via the EJB3 subsystem. Is the OSGi usecase any
different from this?

-Jaikiran
On Tuesday 16 October 2012 04:43 AM, Brian Stansberry wrote:

> Good question.
>
> I see it as a matter of roles. The jboss-all.xml file is full of
> configurations that are basically about how the deployment functions
> internally. That stuff is primarily the concern of the application
> developer. The admin may want to make some adaptations to tailor to the
> environment, but the contents of that file are basically the province of
> the app developers.
>
> The AS7-3694 request and HASingleton are primarily about under what
> conditions the deployment is installed at all. That is something the
> admin controls.
>
> So, we could:
>
> 1) Go with jboss-all.xml + overlays and force the admin to mix his stuff
> in with the app developer's stuff, keeping them in sync. (An overlay is
> a complete override, not a merge.)
>
> 2) Add new xxx.xml files to control this stuff and use overlays to let
> the admin insert his desired configs into the deployment. This would
> basically just be a hack workaround because we don't want to do overlay
> merging.
>
> 3) The management resource approach.
>
> On 10/15/12 5:32 PM, Tomaž Cerar wrote:
>> Why are introducing yet another configuration mechanism for deployments?
>>
>> now we have
>> - jboss-deployment-structure.xml
>> - jboss-deployment-dependencies.xml
>> - jboss-all.xml
>> - jboss-xyz.xml - (too) many of them
>>
>> that in combination with overlays this could provide same capability.
>> AFAIR primary idea behind jboss-all.xml was to unify configuration for
>> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
>> jboss-app.xml,....)
>>
>> and overlays just add this extra capability of exposing/manipulating
>> this trough management.
>> This new approach has only one extra capability that is to enable
>> subsystem itself to push/write/change some configuration that is
>> deployment-wise.
>>   From my point of view that is just wrong. Subsystems should not
>> run-time decide and change some deployment parameters that you can than
>> also manipulate trough mgmt.
>>
>> Maybe I am not seeing some use-case but in general I don't like this
>> approach...
>>
>> --
>> tomaz
>>
>>
>> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>      I've been working $subject in order to help support Thomas Diesler's
>>      request for AS7-3694[1]. The gist of this request is to add deployment
>>      unit processing (DUP) configuration as children of the deployment
>>      resource itself. Thomas' OSGi use case is one place where this would be
>>      used. I expect HASingleton deployment will be another.
>>
>>      WIP is at [2]. I'm looking for feedback. :)
>>
>>      What I've done is based on what Thomas did at [3]. What I want to do is
>>      move from the generic key/value pairs in that patch to a more formally
>>      describable management API. Instead of:
>>
>>      <deployment name="foo.war"...>
>>         <properties>
>>          <property name="start.policy" value="DEFERRED"/>
>>         <property>
>>      </deployment>
>>
>>      It would be something analogous to how a profile configuration is done:
>>
>>      <deployment name="foo.war"...>
>>         <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>           <start-policy value="deferred"/>
>>         </deployment>
>>      </deployment>
>>
>>      The existing Extension API already has the hooks to support this.
>>      Extensions can register xml parsers for children of the <deployment>
>>      element and can register management resources to act as children of the
>>      /deployment=foo.war resource as well. Several subsystems already take
>>      advantage of the latter. Until now the former has been an unimplemented
>>      API. The commit at [4] implements it.
>>
>>      A couple things giving me some concern:
>>
>>      1) The above xml:
>>
>>      <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>>      Nicer would be something like:
>>
>>      <deployers>
>>          <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>>      I need to figure out if I can do some tricks with the parsing to allow
>>      that to happen.
>>
>>      2) The structure of the resource tree. We already support resources like
>>      this:
>>
>>      /deployment=foo.war/subsystem=web
>>
>>      Subsystems register resources like those to expose metrics. The commit
>>      at [4] uses that same tree. When subsystems could now register child
>>      resources to the deployment=* resource, they could include both runtime
>>      stuff and configuration stuff.
>>
>>      I'm not sure that mixing the two is ideal, although it's what we do for
>>      the regular subsystem resources in the profile. I'm vaguely concerned
>>      that if someday the configuration that subsystems choose to expose via
>>      this mechanism gets complex, the mixing of metrics with configuration in
>>      the same tree will start to break down.
>>
>>      Comments are appreciated.
>>
>>
>>      [1] https://issues.jboss.org/browse/AS7-3694
>>      [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>      [3] https://github.com/jbossas/jboss-as/pull/3230
>>      [4]
>>      https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email] <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
On 10/16/12 8:09 AM, Jaikiran Pai wrote:
> I'm unclear about a couple of things related to this change:
>
> 1) Will this (whatever property is being configured) apply to all
> deployments?

It is scoped to the individual deployment.

> Looking at the example you pasted it looks like each
> deployment can potentially be treated differently by setting a different
> value for the property, which kind of comes back to what Tomaz says
> about the other options available. Introducing this new way might be a
> problem if other subsystems decide to introduce a new child of the
> deployment resource to configure something that can already be done via
> jboss-foo.xml which brings up the question about which one of those
> values takes priority.
>

If we allow these resources to set things that can also be set in a
deployment descriptor, then the settings in the resource should control.
Admins rule. ;)

It's a very good question as to whether that kind of override should be
allowed. It can't really be prevented of course, except via code review.

> 2) AS7-3694 looks like a case where a deployment has to be attached (or
> processed) in a certain way by the OSGi DUPs by using a configured
> property. Shouldn't the OSGi subsystem be introducing such a management
> resource/attribute within that subsystem instead of doing it at the
> deployment resource? For example, consider the "default distinct name"
> that the EJB3 subsystem DUPs need to apply to deployments. This default
> distinct name is configured by an admin and hence is exposed as a
> management attribute via the EJB3 subsystem. Is the OSGi usecase any
> different from this?
>

AIUI the EJB3 subsystem is only setting a global default that should be
used if something is not provided in the deployment itself. It can still
be changed on a per deployment basis though, by changing something in
the deployment.

In the OSGi case there is nothing in the deployment itself that
specifies this. The crux of the question is whether this configuration
should be forced into the deployment itself.

> -Jaikiran
> On Tuesday 16 October 2012 04:43 AM, Brian Stansberry wrote:
>> Good question.
>>
>> I see it as a matter of roles. The jboss-all.xml file is full of
>> configurations that are basically about how the deployment functions
>> internally. That stuff is primarily the concern of the application
>> developer. The admin may want to make some adaptations to tailor to the
>> environment, but the contents of that file are basically the province of
>> the app developers.
>>
>> The AS7-3694 request and HASingleton are primarily about under what
>> conditions the deployment is installed at all. That is something the
>> admin controls.
>>
>> So, we could:
>>
>> 1) Go with jboss-all.xml + overlays and force the admin to mix his stuff
>> in with the app developer's stuff, keeping them in sync. (An overlay is
>> a complete override, not a merge.)
>>
>> 2) Add new xxx.xml files to control this stuff and use overlays to let
>> the admin insert his desired configs into the deployment. This would
>> basically just be a hack workaround because we don't want to do overlay
>> merging.
>>
>> 3) The management resource approach.
>>
>> On 10/15/12 5:32 PM, Tomaž Cerar wrote:
>>> Why are introducing yet another configuration mechanism for deployments?
>>>
>>> now we have
>>> - jboss-deployment-structure.xml
>>> - jboss-deployment-dependencies.xml
>>> - jboss-all.xml
>>> - jboss-xyz.xml - (too) many of them
>>>
>>> that in combination with overlays this could provide same capability.
>>> AFAIR primary idea behind jboss-all.xml was to unify configuration for
>>> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
>>> jboss-app.xml,....)
>>>
>>> and overlays just add this extra capability of exposing/manipulating
>>> this trough management.
>>> This new approach has only one extra capability that is to enable
>>> subsystem itself to push/write/change some configuration that is
>>> deployment-wise.
>>>   From my point of view that is just wrong. Subsystems should not
>>> run-time decide and change some deployment parameters that you can than
>>> also manipulate trough mgmt.
>>>
>>> Maybe I am not seeing some use-case but in general I don't like this
>>> approach...
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
>>> <[hidden email] <mailto:[hidden email]>>
>>> wrote:
>>>
>>>      I've been working $subject in order to help support Thomas
>>> Diesler's
>>>      request for AS7-3694[1]. The gist of this request is to add
>>> deployment
>>>      unit processing (DUP) configuration as children of the deployment
>>>      resource itself. Thomas' OSGi use case is one place where this
>>> would be
>>>      used. I expect HASingleton deployment will be another.
>>>
>>>      WIP is at [2]. I'm looking for feedback. :)
>>>
>>>      What I've done is based on what Thomas did at [3]. What I want
>>> to do is
>>>      move from the generic key/value pairs in that patch to a more
>>> formally
>>>      describable management API. Instead of:
>>>
>>>      <deployment name="foo.war"...>
>>>         <properties>
>>>          <property name="start.policy" value="DEFERRED"/>
>>>         <property>
>>>      </deployment>
>>>
>>>      It would be something analogous to how a profile configuration
>>> is done:
>>>
>>>      <deployment name="foo.war"...>
>>>         <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>           <start-policy value="deferred"/>
>>>         </deployment>
>>>      </deployment>
>>>
>>>      The existing Extension API already has the hooks to support this.
>>>      Extensions can register xml parsers for children of the
>>> <deployment>
>>>      element and can register management resources to act as children
>>> of the
>>>      /deployment=foo.war resource as well. Several subsystems already
>>> take
>>>      advantage of the latter. Until now the former has been an
>>> unimplemented
>>>      API. The commit at [4] implements it.
>>>
>>>      A couple things giving me some concern:
>>>
>>>      1) The above xml:
>>>
>>>      <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>
>>>      Nicer would be something like:
>>>
>>>      <deployers>
>>>          <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>
>>>      I need to figure out if I can do some tricks with the parsing to
>>> allow
>>>      that to happen.
>>>
>>>      2) The structure of the resource tree. We already support
>>> resources like
>>>      this:
>>>
>>>      /deployment=foo.war/subsystem=web
>>>
>>>      Subsystems register resources like those to expose metrics. The
>>> commit
>>>      at [4] uses that same tree. When subsystems could now register
>>> child
>>>      resources to the deployment=* resource, they could include both
>>> runtime
>>>      stuff and configuration stuff.
>>>
>>>      I'm not sure that mixing the two is ideal, although it's what we
>>> do for
>>>      the regular subsystem resources in the profile. I'm vaguely
>>> concerned
>>>      that if someday the configuration that subsystems choose to
>>> expose via
>>>      this mechanism gets complex, the mixing of metrics with
>>> configuration in
>>>      the same tree will start to break down.
>>>
>>>      Comments are appreciated.
>>>
>>>
>>>      [1] https://issues.jboss.org/browse/AS7-3694
>>>      [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>>      [3] https://github.com/jbossas/jboss-as/pull/3230
>>>      [4]
>>>
>>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>>
>>>      --
>>>      Brian Stansberry
>>>      Principal Software Engineer
>>>      JBoss by Red Hat
>>>      _______________________________________________
>>>      jboss-as7-dev mailing list
>>>      [hidden email]
>>> <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Jaikiran Pai
By the way, I just realized last night that if we go by this approach of
setting up child resources of deployment resource, then it won't work
with filesystem based deployments since those deployments do not have
their info persisted in the standalone*.xml.

-Jaikiran
On Tuesday 16 October 2012 07:42 PM, Brian Stansberry wrote:

> On 10/16/12 8:09 AM, Jaikiran Pai wrote:
>> I'm unclear about a couple of things related to this change:
>>
>> 1) Will this (whatever property is being configured) apply to all
>> deployments?
>
> It is scoped to the individual deployment.
>
>> Looking at the example you pasted it looks like each
>> deployment can potentially be treated differently by setting a different
>> value for the property, which kind of comes back to what Tomaz says
>> about the other options available. Introducing this new way might be a
>> problem if other subsystems decide to introduce a new child of the
>> deployment resource to configure something that can already be done via
>> jboss-foo.xml which brings up the question about which one of those
>> values takes priority.
>>
>
> If we allow these resources to set things that can also be set in a
> deployment descriptor, then the settings in the resource should
> control. Admins rule. ;)
>
> It's a very good question as to whether that kind of override should
> be allowed. It can't really be prevented of course, except via code
> review.
>
>> 2) AS7-3694 looks like a case where a deployment has to be attached (or
>> processed) in a certain way by the OSGi DUPs by using a configured
>> property. Shouldn't the OSGi subsystem be introducing such a management
>> resource/attribute within that subsystem instead of doing it at the
>> deployment resource? For example, consider the "default distinct name"
>> that the EJB3 subsystem DUPs need to apply to deployments. This default
>> distinct name is configured by an admin and hence is exposed as a
>> management attribute via the EJB3 subsystem. Is the OSGi usecase any
>> different from this?
>>
>
> AIUI the EJB3 subsystem is only setting a global default that should
> be used if something is not provided in the deployment itself. It can
> still be changed on a per deployment basis though, by changing
> something in the deployment.
>
> In the OSGi case there is nothing in the deployment itself that
> specifies this. The crux of the question is whether this configuration
> should be forced into the deployment itself.
>
>> -Jaikiran
>> On Tuesday 16 October 2012 04:43 AM, Brian Stansberry wrote:
>>> Good question.
>>>
>>> I see it as a matter of roles. The jboss-all.xml file is full of
>>> configurations that are basically about how the deployment functions
>>> internally. That stuff is primarily the concern of the application
>>> developer. The admin may want to make some adaptations to tailor to the
>>> environment, but the contents of that file are basically the
>>> province of
>>> the app developers.
>>>
>>> The AS7-3694 request and HASingleton are primarily about under what
>>> conditions the deployment is installed at all. That is something the
>>> admin controls.
>>>
>>> So, we could:
>>>
>>> 1) Go with jboss-all.xml + overlays and force the admin to mix his
>>> stuff
>>> in with the app developer's stuff, keeping them in sync. (An overlay is
>>> a complete override, not a merge.)
>>>
>>> 2) Add new xxx.xml files to control this stuff and use overlays to let
>>> the admin insert his desired configs into the deployment. This would
>>> basically just be a hack workaround because we don't want to do overlay
>>> merging.
>>>
>>> 3) The management resource approach.
>>>
>>> On 10/15/12 5:32 PM, Tomaž Cerar wrote:
>>>> Why are introducing yet another configuration mechanism for
>>>> deployments?
>>>>
>>>> now we have
>>>> - jboss-deployment-structure.xml
>>>> - jboss-deployment-dependencies.xml
>>>> - jboss-all.xml
>>>> - jboss-xyz.xml - (too) many of them
>>>>
>>>> that in combination with overlays this could provide same capability.
>>>> AFAIR primary idea behind jboss-all.xml was to unify configuration for
>>>> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
>>>> jboss-app.xml,....)
>>>>
>>>> and overlays just add this extra capability of exposing/manipulating
>>>> this trough management.
>>>> This new approach has only one extra capability that is to enable
>>>> subsystem itself to push/write/change some configuration that is
>>>> deployment-wise.
>>>>   From my point of view that is just wrong. Subsystems should not
>>>> run-time decide and change some deployment parameters that you can
>>>> than
>>>> also manipulate trough mgmt.
>>>>
>>>> Maybe I am not seeing some use-case but in general I don't like this
>>>> approach...
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
>>>> <[hidden email] <mailto:[hidden email]>>
>>>> wrote:
>>>>
>>>>      I've been working $subject in order to help support Thomas
>>>> Diesler's
>>>>      request for AS7-3694[1]. The gist of this request is to add
>>>> deployment
>>>>      unit processing (DUP) configuration as children of the deployment
>>>>      resource itself. Thomas' OSGi use case is one place where this
>>>> would be
>>>>      used. I expect HASingleton deployment will be another.
>>>>
>>>>      WIP is at [2]. I'm looking for feedback. :)
>>>>
>>>>      What I've done is based on what Thomas did at [3]. What I want
>>>> to do is
>>>>      move from the generic key/value pairs in that patch to a more
>>>> formally
>>>>      describable management API. Instead of:
>>>>
>>>>      <deployment name="foo.war"...>
>>>>         <properties>
>>>>          <property name="start.policy" value="DEFERRED"/>
>>>>         <property>
>>>>      </deployment>
>>>>
>>>>      It would be something analogous to how a profile configuration
>>>> is done:
>>>>
>>>>      <deployment name="foo.war"...>
>>>>         <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>           <start-policy value="deferred"/>
>>>>         </deployment>
>>>>      </deployment>
>>>>
>>>>      The existing Extension API already has the hooks to support this.
>>>>      Extensions can register xml parsers for children of the
>>>> <deployment>
>>>>      element and can register management resources to act as children
>>>> of the
>>>>      /deployment=foo.war resource as well. Several subsystems already
>>>> take
>>>>      advantage of the latter. Until now the former has been an
>>>> unimplemented
>>>>      API. The commit at [4] implements it.
>>>>
>>>>      A couple things giving me some concern:
>>>>
>>>>      1) The above xml:
>>>>
>>>>      <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>
>>>>      Nicer would be something like:
>>>>
>>>>      <deployers>
>>>>          <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>
>>>>      I need to figure out if I can do some tricks with the parsing to
>>>> allow
>>>>      that to happen.
>>>>
>>>>      2) The structure of the resource tree. We already support
>>>> resources like
>>>>      this:
>>>>
>>>>      /deployment=foo.war/subsystem=web
>>>>
>>>>      Subsystems register resources like those to expose metrics. The
>>>> commit
>>>>      at [4] uses that same tree. When subsystems could now register
>>>> child
>>>>      resources to the deployment=* resource, they could include both
>>>> runtime
>>>>      stuff and configuration stuff.
>>>>
>>>>      I'm not sure that mixing the two is ideal, although it's what we
>>>> do for
>>>>      the regular subsystem resources in the profile. I'm vaguely
>>>> concerned
>>>>      that if someday the configuration that subsystems choose to
>>>> expose via
>>>>      this mechanism gets complex, the mixing of metrics with
>>>> configuration in
>>>>      the same tree will start to break down.
>>>>
>>>>      Comments are appreciated.
>>>>
>>>>
>>>>      [1] https://issues.jboss.org/browse/AS7-3694
>>>>      [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>>>      [3] https://github.com/jbossas/jboss-as/pull/3230
>>>>      [4]
>>>>
>>>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd 
>>>>
>>>>
>>>>      --
>>>>      Brian Stansberry
>>>>      Principal Software Engineer
>>>>      JBoss by Red Hat
>>>> _______________________________________________
>>>>      jboss-as7-dev mailing list
>>>>      [hidden email]
>>>> <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Stuart Douglas
You could probably handle that by having a seperate .xml file for the
deployment:

foo.war
foo.war.settings.xml

Or something like that. I don't really like it though, as if you just
copy both in there and are not using .dodeploy its possible for the
deployment to be deployed before the xml file has been copied (you could
argue this is user error I suppose).

Stuart

Jaikiran Pai wrote:
> By the way, I just realized last night that if we go by this approach of
> setting up child resources of deployment resource, then it won't work
> with filesystem based deployments since those deployments do not have
> their info persisted in the standalone*.xml.
>
> -Jaikiran
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Stuart Douglas
In reply to this post by Tomaž Cerar-2


Tomaž Cerar wrote:
> Why are introducing yet another configuration mechanism for deployments?
>
> now we have
> - jboss-deployment-structure.xml
> - jboss-deployment-dependencies.xml

This is just part of jboss-all, it is not a separate file.

> - jboss-all.xml
> - jboss-xyz.xml - (too) many of them

This is the problem that jboss-all.xml is supposed to solve, in that it
can contain any of these files, so you only need a single Jboss specific
descriptor in the deployment.

The big problem is though that because we do not have any fine grained
overlays, using jboss-all with overlays is a bit problematic, as you
have to overlay the whole file, even if you just want to modify a single
line.

 From an administrator point of view I don't think this is to big a
deal, an admin that does hit this problem should know how to use diff
and patch to re-generate the overlay automatically (and this problem can
occur with other descriptors as well, e.g. if you want to change one
line of jboss-ejb3.xml).

One thing I have been thinking a bit about is fine grained deployment
descriptors, so deployment descriptors basically translate to a list of
operations (similar to management operations). You could then have a
mechanism for removing / adding / changing a single operation).

>
> that in combination with overlays this could provide same capability.
> AFAIR primary idea behind jboss-all.xml was to unify configuration for
> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
> jboss-app.xml,....)

It is a replacement for them, but we can't just remove the existing ones
for compatibility reasons.

>
> and overlays just add this extra capability of exposing/manipulating
> this trough management.
> This new approach has only one extra capability that is to enable
> subsystem itself to push/write/change some configuration that is
> deployment-wise.
>  >From my point of view that is just wrong. Subsystems should not
> run-time decide and change some deployment parameters that you can than
> also manipulate trough mgmt.
>
> Maybe I am not seeing some use-case but in general I don't like this
> approach...

I think with Thomas' OSGI use case the OSGI subsystem can decide to
change these properties. e.g. If it is deployed with
start.policy=DEFERRED, but then it is actually activated, this deferred
policy is not longer relevant and should be removed (as I understand it).

Stuart


>
> --
> tomaz
>
>
> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I've been working $subject in order to help support Thomas Diesler's
>     request for AS7-3694[1]. The gist of this request is to add deployment
>     unit processing (DUP) configuration as children of the deployment
>     resource itself. Thomas' OSGi use case is one place where this would be
>     used. I expect HASingleton deployment will be another.
>
>     WIP is at [2]. I'm looking for feedback. :)
>
>     What I've done is based on what Thomas did at [3]. What I want to do is
>     move from the generic key/value pairs in that patch to a more formally
>     describable management API. Instead of:
>
>     <deployment name="foo.war"...>
>     <properties>
>     <property name="start.policy" value="DEFERRED"/>
>     <property>
>     </deployment>
>
>     It would be something analogous to how a profile configuration is done:
>
>     <deployment name="foo.war"...>
>     <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>     <start-policy value="deferred"/>
>     </deployment>
>     </deployment>
>
>     The existing Extension API already has the hooks to support this.
>     Extensions can register xml parsers for children of the <deployment>
>     element and can register management resources to act as children of the
>     /deployment=foo.war resource as well. Several subsystems already take
>     advantage of the latter. Until now the former has been an unimplemented
>     API. The commit at [4] implements it.
>
>     A couple things giving me some concern:
>
>     1) The above xml:
>
>     <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
>     Nicer would be something like:
>
>     <deployers>
>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
>     I need to figure out if I can do some tricks with the parsing to allow
>     that to happen.
>
>     2) The structure of the resource tree. We already support resources like
>     this:
>
>     /deployment=foo.war/subsystem=web
>
>     Subsystems register resources like those to expose metrics. The commit
>     at [4] uses that same tree. When subsystems could now register child
>     resources to the deployment=* resource, they could include both runtime
>     stuff and configuration stuff.
>
>     I'm not sure that mixing the two is ideal, although it's what we do for
>     the regular subsystem resources in the profile. I'm vaguely concerned
>     that if someday the configuration that subsystems choose to expose via
>     this mechanism gets complex, the mixing of metrics with configuration in
>     the same tree will start to break down.
>
>     Comments are appreciated.
>
>
>     [1] https://issues.jboss.org/browse/AS7-3694
>     [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>     [3] https://github.com/jbossas/jboss-as/pull/3230
>     [4]
>     https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
In reply to this post by Jaikiran Pai
Besides the persistence issue, a scanner wouldn't be able to add these
resources in the first place.

In some earlier discussions in #jboss-as7 making this kind of config
available in jboss-all.xml as well.

It's a long discussion, but probably worth while if folks want to
understand some of the background on all this:

http://echelog.com/logs/browse/jboss-as7/1348005600

Some more discussion was at:

http://echelog.com/logs/browse/jboss-as7/1348092000

On 10/16/12 8:24 PM, Jaikiran Pai wrote:

> By the way, I just realized last night that if we go by this approach of
> setting up child resources of deployment resource, then it won't work
> with filesystem based deployments since those deployments do not have
> their info persisted in the standalone*.xml.
>
> -Jaikiran
> On Tuesday 16 October 2012 07:42 PM, Brian Stansberry wrote:
>> On 10/16/12 8:09 AM, Jaikiran Pai wrote:
>>> I'm unclear about a couple of things related to this change:
>>>
>>> 1) Will this (whatever property is being configured) apply to all
>>> deployments?
>>
>> It is scoped to the individual deployment.
>>
>>> Looking at the example you pasted it looks like each
>>> deployment can potentially be treated differently by setting a different
>>> value for the property, which kind of comes back to what Tomaz says
>>> about the other options available. Introducing this new way might be a
>>> problem if other subsystems decide to introduce a new child of the
>>> deployment resource to configure something that can already be done via
>>> jboss-foo.xml which brings up the question about which one of those
>>> values takes priority.
>>>
>>
>> If we allow these resources to set things that can also be set in a
>> deployment descriptor, then the settings in the resource should
>> control. Admins rule. ;)
>>
>> It's a very good question as to whether that kind of override should
>> be allowed. It can't really be prevented of course, except via code
>> review.
>>
>>> 2) AS7-3694 looks like a case where a deployment has to be attached (or
>>> processed) in a certain way by the OSGi DUPs by using a configured
>>> property. Shouldn't the OSGi subsystem be introducing such a management
>>> resource/attribute within that subsystem instead of doing it at the
>>> deployment resource? For example, consider the "default distinct name"
>>> that the EJB3 subsystem DUPs need to apply to deployments. This default
>>> distinct name is configured by an admin and hence is exposed as a
>>> management attribute via the EJB3 subsystem. Is the OSGi usecase any
>>> different from this?
>>>
>>
>> AIUI the EJB3 subsystem is only setting a global default that should
>> be used if something is not provided in the deployment itself. It can
>> still be changed on a per deployment basis though, by changing
>> something in the deployment.
>>
>> In the OSGi case there is nothing in the deployment itself that
>> specifies this. The crux of the question is whether this configuration
>> should be forced into the deployment itself.
>>
>>> -Jaikiran
>>> On Tuesday 16 October 2012 04:43 AM, Brian Stansberry wrote:
>>>> Good question.
>>>>
>>>> I see it as a matter of roles. The jboss-all.xml file is full of
>>>> configurations that are basically about how the deployment functions
>>>> internally. That stuff is primarily the concern of the application
>>>> developer. The admin may want to make some adaptations to tailor to the
>>>> environment, but the contents of that file are basically the
>>>> province of
>>>> the app developers.
>>>>
>>>> The AS7-3694 request and HASingleton are primarily about under what
>>>> conditions the deployment is installed at all. That is something the
>>>> admin controls.
>>>>
>>>> So, we could:
>>>>
>>>> 1) Go with jboss-all.xml + overlays and force the admin to mix his
>>>> stuff
>>>> in with the app developer's stuff, keeping them in sync. (An overlay is
>>>> a complete override, not a merge.)
>>>>
>>>> 2) Add new xxx.xml files to control this stuff and use overlays to let
>>>> the admin insert his desired configs into the deployment. This would
>>>> basically just be a hack workaround because we don't want to do overlay
>>>> merging.
>>>>
>>>> 3) The management resource approach.
>>>>
>>>> On 10/15/12 5:32 PM, Tomaž Cerar wrote:
>>>>> Why are introducing yet another configuration mechanism for
>>>>> deployments?
>>>>>
>>>>> now we have
>>>>> - jboss-deployment-structure.xml
>>>>> - jboss-deployment-dependencies.xml
>>>>> - jboss-all.xml
>>>>> - jboss-xyz.xml - (too) many of them
>>>>>
>>>>> that in combination with overlays this could provide same capability.
>>>>> AFAIR primary idea behind jboss-all.xml was to unify configuration for
>>>>> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
>>>>> jboss-app.xml,....)
>>>>>
>>>>> and overlays just add this extra capability of exposing/manipulating
>>>>> this trough management.
>>>>> This new approach has only one extra capability that is to enable
>>>>> subsystem itself to push/write/change some configuration that is
>>>>> deployment-wise.
>>>>>   From my point of view that is just wrong. Subsystems should not
>>>>> run-time decide and change some deployment parameters that you can
>>>>> than
>>>>> also manipulate trough mgmt.
>>>>>
>>>>> Maybe I am not seeing some use-case but in general I don't like this
>>>>> approach...
>>>>>
>>>>> --
>>>>> tomaz
>>>>>
>>>>>
>>>>> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
>>>>> <[hidden email] <mailto:[hidden email]>>
>>>>> wrote:
>>>>>
>>>>>      I've been working $subject in order to help support Thomas
>>>>> Diesler's
>>>>>      request for AS7-3694[1]. The gist of this request is to add
>>>>> deployment
>>>>>      unit processing (DUP) configuration as children of the deployment
>>>>>      resource itself. Thomas' OSGi use case is one place where this
>>>>> would be
>>>>>      used. I expect HASingleton deployment will be another.
>>>>>
>>>>>      WIP is at [2]. I'm looking for feedback. :)
>>>>>
>>>>>      What I've done is based on what Thomas did at [3]. What I want
>>>>> to do is
>>>>>      move from the generic key/value pairs in that patch to a more
>>>>> formally
>>>>>      describable management API. Instead of:
>>>>>
>>>>>      <deployment name="foo.war"...>
>>>>>         <properties>
>>>>>          <property name="start.policy" value="DEFERRED"/>
>>>>>         <property>
>>>>>      </deployment>
>>>>>
>>>>>      It would be something analogous to how a profile configuration
>>>>> is done:
>>>>>
>>>>>      <deployment name="foo.war"...>
>>>>>         <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>           <start-policy value="deferred"/>
>>>>>         </deployment>
>>>>>      </deployment>
>>>>>
>>>>>      The existing Extension API already has the hooks to support this.
>>>>>      Extensions can register xml parsers for children of the
>>>>> <deployment>
>>>>>      element and can register management resources to act as children
>>>>> of the
>>>>>      /deployment=foo.war resource as well. Several subsystems already
>>>>> take
>>>>>      advantage of the latter. Until now the former has been an
>>>>> unimplemented
>>>>>      API. The commit at [4] implements it.
>>>>>
>>>>>      A couple things giving me some concern:
>>>>>
>>>>>      1) The above xml:
>>>>>
>>>>>      <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>
>>>>>      Nicer would be something like:
>>>>>
>>>>>      <deployers>
>>>>>          <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>
>>>>>      I need to figure out if I can do some tricks with the parsing to
>>>>> allow
>>>>>      that to happen.
>>>>>
>>>>>      2) The structure of the resource tree. We already support
>>>>> resources like
>>>>>      this:
>>>>>
>>>>>      /deployment=foo.war/subsystem=web
>>>>>
>>>>>      Subsystems register resources like those to expose metrics. The
>>>>> commit
>>>>>      at [4] uses that same tree. When subsystems could now register
>>>>> child
>>>>>      resources to the deployment=* resource, they could include both
>>>>> runtime
>>>>>      stuff and configuration stuff.
>>>>>
>>>>>      I'm not sure that mixing the two is ideal, although it's what we
>>>>> do for
>>>>>      the regular subsystem resources in the profile. I'm vaguely
>>>>> concerned
>>>>>      that if someday the configuration that subsystems choose to
>>>>> expose via
>>>>>      this mechanism gets complex, the mixing of metrics with
>>>>> configuration in
>>>>>      the same tree will start to break down.
>>>>>
>>>>>      Comments are appreciated.
>>>>>
>>>>>
>>>>>      [1] https://issues.jboss.org/browse/AS7-3694
>>>>>      [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>>>>      [3] https://github.com/jbossas/jboss-as/pull/3230
>>>>>      [4]
>>>>>
>>>>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>>>>
>>>>>
>>>>>      --
>>>>>      Brian Stansberry
>>>>>      Principal Software Engineer
>>>>>      JBoss by Red Hat
>>>>> _______________________________________________
>>>>>      jboss-as7-dev mailing list
>>>>>      [hidden email]
>>>>> <mailto:[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
|

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Heiko Braun
In reply to this post by Brian Stansberry
Please see my comments inline.

On Oct 15, 2012, at 11:45 PM, Brian Stansberry <[hidden email]> wrote:

It would be something analogous to how a profile configuration is done:

<deployment name="foo.war"...>
 <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
   <start-policy value="deferred"/>
 </deployment>
</deployment>

I think this makes sense and I can see the benefit. One thing to consider:
Will this be self-describing (in terms of :read-resource-description or something similar)?

The use case would be to query the possible options for subsystem specific deployment settings when actually creating a deployment (i.e. through the console)




2) The structure of the resource tree. We already support resources like 
this:

/deployment=foo.war/subsystem=web

Subsystems register resources like those to expose metrics. The commit 
at [4] uses that same tree. When subsystems could now register child 
resources to the deployment=* resource, they could include both runtime 
stuff and configuration stuff.

I'm not sure that mixing the two is ideal, although it's what we do for 
the regular subsystem resources in the profile. I'm vaguely concerned 
that if someday the configuration that subsystems choose to expose via 
this mechanism gets complex, the mixing of metrics with configuration in 
the same tree will start to break down.

I would prefer if this two concepts could somehow be distinguished. Either a separate resource [1], or a dedicated child [2]:

[1] /deployment=foo.war/subsystem-config=web
[2] /deployment=foo.war/subsystem=web/overlay=config(start-policy=deferred)





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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
On 10/18/12 10:51 AM, Heiko Braun wrote:

> Please see my comments inline.
>
> On Oct 15, 2012, at 11:45 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>> It would be something analogous to how a profile configuration is done:
>>
>> <deployment name="foo.war"...>
>>  <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>    <start-policy value="deferred"/>
>>  </deployment>
>> </deployment>
>
> I think this makes sense and I can see the benefit. One thing to consider:
> Will this be self-describing (in terms of :read-resource-description or
> something similar)?
>

Yes. In the branch I linked, making this fully describable was the core
purpose of the couple of commits I added on top of what Thomas had
previously done.

> The use case would be to query the possible options for subsystem
> specific deployment settings when actually creating a deployment (i.e.
> through the console)
>
>
>>
>>
>> 2) The structure of the resource tree. We already support resources like
>> this:
>>
>> /deployment=foo.war/subsystem=web
>>
>> Subsystems register resources like those to expose metrics. The commit
>> at [4] uses that same tree. When subsystems could now register child
>> resources to the deployment=* resource, they could include both runtime
>> stuff and configuration stuff.
>>
>> I'm not sure that mixing the two is ideal, although it's what we do for
>> the regular subsystem resources in the profile. I'm vaguely concerned
>> that if someday the configuration that subsystems choose to expose via
>> this mechanism gets complex, the mixing of metrics with configuration in
>> the same tree will start to break down.
>
> I would prefer if this two concepts could somehow be distinguished.
> Either a separate resource [1], or a dedicated child [2]:
>
> [1] /deployment=foo.war/subsystem-config=web
> [2] /deployment=foo.war/subsystem=web/overlay=config(start-policy=deferred)
>
>
>
>


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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Thomas Diesler
In reply to this post by Brian Stansberry
I'd like to point out that the 'start.policy' property needed for OSGi
deployments is a workaround for the general lifecycle disconnect that we
have between AS7 deployments and OSGi deployments.

In AS7 we have

* ADD - bring the bytes across
* DEPLOY - parse metadata, resolve (a.k.a create module/classloader),
install services
* UNDEPLOY - remove services, destroy classloader, etc
* REMOVE - take the bytes off the system

In OSGi we have

* INSTALL - bring the bytes across, parse the metadata
* RESOLVE - (may be implicit) link to other installed bundles, create
the classloader
* START/STOP - (repeatedly) install/uninstall services
* UNDEPLOY - take the bytes off the system

The fundamental disconnect is that the AS7 DEPLOY operation is a an all
or nothing approach, which creates an ordering issue for the user. For a
large set of interconnected deployments, the user has to know in which
order they can be deployed. Generally, this ordering concern should not
be delegated to the user because he/she cannot know the complex
dependencies between deployment capabilities/requirements. IOW, given a
set of deployments the admin cannot know in which order they need to be
dropped into the deployments folder.

I'm mentioning this because I believe we might want to apply the
deferred start.policy behaviour to non-osgi deployments as well.
This raises the question about properties that should be shared between
subsystems? Brian's approach binds them to one subsystem only.

I would prefer a global set of properties that the deployment layer
knows about and can validate. These can be document and they become part
of the API. Any other prop is passed through but not part of the API (it
would not show up in console/cli). This is much like any other shared
concept that can be seen from any subsystem.

------

Making props be part of the deployment ...

One of the value propositions of OSGi is that you can easily bring in
functionality by deploying 3rd party bundles. Those bundles cannot be
touched. Properties that modify (bundle) deployment behaviour like
auto-start and start-level must be defined external to the deployment.

------

Concerning jboss-all.xml and using overlays ...

An overlay is currently not a child of the deployment itself. When you
undeploy the properties related to that deployment must get removed as
well, which is currently not the case with overlays.

cheers
--thomas

On 10/15/2012 11:45 PM, Brian Stansberry wrote:

> I've been working $subject in order to help support Thomas Diesler's
> request for AS7-3694[1]. The gist of this request is to add deployment
> unit processing (DUP) configuration as children of the deployment
> resource itself. Thomas' OSGi use case is one place where this would be
> used. I expect HASingleton deployment will be another.
>
> WIP is at [2]. I'm looking for feedback. :)
>
> What I've done is based on what Thomas did at [3]. What I want to do is
> move from the generic key/value pairs in that patch to a more formally
> describable management API. Instead of:
>
> <deployment name="foo.war"...>
>    <properties>
>     <property name="start.policy" value="DEFERRED"/>
>    <property>
> </deployment>
>
> It would be something analogous to how a profile configuration is done:
>
> <deployment name="foo.war"...>
>    <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>      <start-policy value="deferred"/>
>    </deployment>
> </deployment>
>
> The existing Extension API already has the hooks to support this.
> Extensions can register xml parsers for children of the <deployment>
> element and can register management resources to act as children of the
> /deployment=foo.war resource as well. Several subsystems already take
> advantage of the latter. Until now the former has been an unimplemented
> API. The commit at [4] implements it.
>
> A couple things giving me some concern:
>
> 1) The above xml:
>
> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> Nicer would be something like:
>
> <deployers>
>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> I need to figure out if I can do some tricks with the parsing to allow
> that to happen.
>
> 2) The structure of the resource tree. We already support resources like
> this:
>
> /deployment=foo.war/subsystem=web
>
> Subsystems register resources like those to expose metrics. The commit
> at [4] uses that same tree. When subsystems could now register child
> resources to the deployment=* resource, they could include both runtime
> stuff and configuration stuff.
>
> I'm not sure that mixing the two is ideal, although it's what we do for
> the regular subsystem resources in the profile. I'm vaguely concerned
> that if someday the configuration that subsystems choose to expose via
> this mechanism gets complex, the mixing of metrics with configuration in
> the same tree will start to break down.
>
> Comments are appreciated.
>
>
> [1] https://issues.jboss.org/browse/AS7-3694
> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
> [3] https://github.com/jbossas/jboss-as/pull/3230
> [4]
> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

David Lloyd-2
Non-OSGi deployments can be "fixed" by deploying the missing dependecies
into the deploy directory, because they do not *really* have (or need) a
user-controllable lifecycle; this is an OSGi artifact that results from
its resolver algorithm afaict.  Please be cautious trying to fit
non-OSGi deployments into an OSGi-shaped box.

On 10/22/2012 03:36 AM, Thomas Diesler wrote:

> I'd like to point out that the 'start.policy' property needed for OSGi
> deployments is a workaround for the general lifecycle disconnect that we
> have between AS7 deployments and OSGi deployments.
>
> In AS7 we have
>
> * ADD - bring the bytes across
> * DEPLOY - parse metadata, resolve (a.k.a create module/classloader),
> install services
> * UNDEPLOY - remove services, destroy classloader, etc
> * REMOVE - take the bytes off the system
>
> In OSGi we have
>
> * INSTALL - bring the bytes across, parse the metadata
> * RESOLVE - (may be implicit) link to other installed bundles, create
> the classloader
> * START/STOP - (repeatedly) install/uninstall services
> * UNDEPLOY - take the bytes off the system
>
> The fundamental disconnect is that the AS7 DEPLOY operation is a an all
> or nothing approach, which creates an ordering issue for the user. For a
> large set of interconnected deployments, the user has to know in which
> order they can be deployed. Generally, this ordering concern should not
> be delegated to the user because he/she cannot know the complex
> dependencies between deployment capabilities/requirements. IOW, given a
> set of deployments the admin cannot know in which order they need to be
> dropped into the deployments folder.
>
> I'm mentioning this because I believe we might want to apply the
> deferred start.policy behaviour to non-osgi deployments as well.
> This raises the question about properties that should be shared between
> subsystems? Brian's approach binds them to one subsystem only.
>
> I would prefer a global set of properties that the deployment layer
> knows about and can validate. These can be document and they become part
> of the API. Any other prop is passed through but not part of the API (it
> would not show up in console/cli). This is much like any other shared
> concept that can be seen from any subsystem.
>
> ------
>
> Making props be part of the deployment ...
>
> One of the value propositions of OSGi is that you can easily bring in
> functionality by deploying 3rd party bundles. Those bundles cannot be
> touched. Properties that modify (bundle) deployment behaviour like
> auto-start and start-level must be defined external to the deployment.
>
> ------
>
> Concerning jboss-all.xml and using overlays ...
>
> An overlay is currently not a child of the deployment itself. When you
> undeploy the properties related to that deployment must get removed as
> well, which is currently not the case with overlays.
>
> cheers
> --thomas
>
> On 10/15/2012 11:45 PM, Brian Stansberry wrote:
>> I've been working $subject in order to help support Thomas Diesler's
>> request for AS7-3694[1]. The gist of this request is to add deployment
>> unit processing (DUP) configuration as children of the deployment
>> resource itself. Thomas' OSGi use case is one place where this would be
>> used. I expect HASingleton deployment will be another.
>>
>> WIP is at [2]. I'm looking for feedback. :)
>>
>> What I've done is based on what Thomas did at [3]. What I want to do is
>> move from the generic key/value pairs in that patch to a more formally
>> describable management API. Instead of:
>>
>> <deployment name="foo.war"...>
>>     <properties>
>>      <property name="start.policy" value="DEFERRED"/>
>>     <property>
>> </deployment>
>>
>> It would be something analogous to how a profile configuration is done:
>>
>> <deployment name="foo.war"...>
>>     <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>       <start-policy value="deferred"/>
>>     </deployment>
>> </deployment>
>>
>> The existing Extension API already has the hooks to support this.
>> Extensions can register xml parsers for children of the <deployment>
>> element and can register management resources to act as children of the
>> /deployment=foo.war resource as well. Several subsystems already take
>> advantage of the latter. Until now the former has been an unimplemented
>> API. The commit at [4] implements it.
>>
>> A couple things giving me some concern:
>>
>> 1) The above xml:
>>
>> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>> Nicer would be something like:
>>
>> <deployers>
>>      <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>> I need to figure out if I can do some tricks with the parsing to allow
>> that to happen.
>>
>> 2) The structure of the resource tree. We already support resources like
>> this:
>>
>> /deployment=foo.war/subsystem=web
>>
>> Subsystems register resources like those to expose metrics. The commit
>> at [4] uses that same tree. When subsystems could now register child
>> resources to the deployment=* resource, they could include both runtime
>> stuff and configuration stuff.
>>
>> I'm not sure that mixing the two is ideal, although it's what we do for
>> the regular subsystem resources in the profile. I'm vaguely concerned
>> that if someday the configuration that subsystems choose to expose via
>> this mechanism gets complex, the mixing of metrics with configuration in
>> the same tree will start to break down.
>>
>> Comments are appreciated.
>>
>>
>> [1] https://issues.jboss.org/browse/AS7-3694
>> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>> [3] https://github.com/jbossas/jboss-as/pull/3230
>> [4]
>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>


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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
In reply to this post by Thomas Diesler
On 10/22/12 3:36 AM, Thomas Diesler wrote:

> I'd like to point out that the 'start.policy' property needed for OSGi
> deployments is a workaround for the general lifecycle disconnect that we
> have between AS7 deployments and OSGi deployments.
>
> In AS7 we have
>
> * ADD - bring the bytes across
> * DEPLOY - parse metadata, resolve (a.k.a create module/classloader),
> install services
> * UNDEPLOY - remove services, destroy classloader, etc
> * REMOVE - take the bytes off the system
>
> In OSGi we have
>
> * INSTALL - bring the bytes across, parse the metadata
> * RESOLVE - (may be implicit) link to other installed bundles, create
> the classloader
> * START/STOP - (repeatedly) install/uninstall services
> * UNDEPLOY - take the bytes off the system
>
> The fundamental disconnect is that the AS7 DEPLOY operation is a an all
> or nothing approach, which creates an ordering issue for the user. For a
> large set of interconnected deployments, the user has to know in which
> order they can be deployed. Generally, this ordering concern should not
> be delegated to the user because he/she cannot know the complex
> dependencies between deployment capabilities/requirements. IOW, given a
> set of deployments the admin cannot know in which order they need to be
> dropped into the deployments folder.
>
> I'm mentioning this because I believe we might want to apply the
> deferred start.policy behaviour to non-osgi deployments as well.
> This raises the question about properties that should be shared between
> subsystems? Brian's approach binds them to one subsystem only.
>
> I would prefer a global set of properties that the deployment layer
> knows about and can validate. These can be document and they become part
> of the API.

I'm interested in what Paul Ferraro is thinking regarding HASingleton
deployments. This is the other very similar case. I can imagine there
could be some common configuration between the two that therefore
belongs at the global level. But I'd like to see the real case first.

> Any other prop is passed through but not part of the API (it
> would not show up in console/cli). This is much like any other shared
> concept that can be seen from any subsystem.
>

-1. Any place we are using generic properties in our management API for
something other than configuring a custom plugin that we can't know
anything about, that's a flaw in our API. We have some, and probably
always will, but the existence of one shouldn't justify another.

> ------
>
> Making props be part of the deployment ...
>
> One of the value propositions of OSGi is that you can easily bring in
> functionality by deploying 3rd party bundles. Those bundles cannot be
> touched. Properties that modify (bundle) deployment behaviour like
> auto-start and start-level must be defined external to the deployment.
>
> ------
>
> Concerning jboss-all.xml and using overlays ...
>
> An overlay is currently not a child of the deployment itself. When you
> undeploy the properties related to that deployment must get removed as
> well,

Why "must"? I certainly understand why it's desirable to help keep
things tidy, but why "must"?

> which is currently not the case with overlays.
>
> cheers
> --thomas
>
> On 10/15/2012 11:45 PM, Brian Stansberry wrote:
>> I've been working $subject in order to help support Thomas Diesler's
>> request for AS7-3694[1]. The gist of this request is to add deployment
>> unit processing (DUP) configuration as children of the deployment
>> resource itself. Thomas' OSGi use case is one place where this would be
>> used. I expect HASingleton deployment will be another.
>>
>> WIP is at [2]. I'm looking for feedback. :)
>>
>> What I've done is based on what Thomas did at [3]. What I want to do is
>> move from the generic key/value pairs in that patch to a more formally
>> describable management API. Instead of:
>>
>> <deployment name="foo.war"...>
>>    <properties>
>>     <property name="start.policy" value="DEFERRED"/>
>>    <property>
>> </deployment>
>>
>> It would be something analogous to how a profile configuration is done:
>>
>> <deployment name="foo.war"...>
>>    <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>      <start-policy value="deferred"/>
>>    </deployment>
>> </deployment>
>>
>> The existing Extension API already has the hooks to support this.
>> Extensions can register xml parsers for children of the <deployment>
>> element and can register management resources to act as children of the
>> /deployment=foo.war resource as well. Several subsystems already take
>> advantage of the latter. Until now the former has been an unimplemented
>> API. The commit at [4] implements it.
>>
>> A couple things giving me some concern:
>>
>> 1) The above xml:
>>
>> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>> Nicer would be something like:
>>
>> <deployers>
>>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>
>> I need to figure out if I can do some tricks with the parsing to allow
>> that to happen.
>>
>> 2) The structure of the resource tree. We already support resources like
>> this:
>>
>> /deployment=foo.war/subsystem=web
>>
>> Subsystems register resources like those to expose metrics. The commit
>> at [4] uses that same tree. When subsystems could now register child
>> resources to the deployment=* resource, they could include both runtime
>> stuff and configuration stuff.
>>
>> I'm not sure that mixing the two is ideal, although it's what we do for
>> the regular subsystem resources in the profile. I'm vaguely concerned
>> that if someday the configuration that subsystems choose to expose via
>> this mechanism gets complex, the mixing of metrics with configuration in
>> the same tree will start to break down.
>>
>> Comments are appreciated.
>>
>>
>> [1] https://issues.jboss.org/browse/AS7-3694
>> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>> [3] https://github.com/jbossas/jboss-as/pull/3230
>> [4]
>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>
>


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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Jason T. Greene
In reply to this post by Brian Stansberry
Right, in the OSGi case it's very common to deploy many thirdparty artifacts. So having this as a deployment time option makes a lot of sense. No breaking open the deployment. OSGi also exposes these capabilities in its Bundle APIs.

In the HA singleton case, the admin probably wants to be able to do this in the actual web interface. Its easier to facilitate that in a management API.


On Oct 17, 2012, at 6:55 PM, Brian Stansberry <[hidden email]> wrote:

> Besides the persistence issue, a scanner wouldn't be able to add these
> resources in the first place.
>
> In some earlier discussions in #jboss-as7 making this kind of config
> available in jboss-all.xml as well.
>
> It's a long discussion, but probably worth while if folks want to
> understand some of the background on all this:
>
> http://echelog.com/logs/browse/jboss-as7/1348005600
>
> Some more discussion was at:
>
> http://echelog.com/logs/browse/jboss-as7/1348092000
>
> On 10/16/12 8:24 PM, Jaikiran Pai wrote:
>> By the way, I just realized last night that if we go by this approach of
>> setting up child resources of deployment resource, then it won't work
>> with filesystem based deployments since those deployments do not have
>> their info persisted in the standalone*.xml.
>>
>> -Jaikiran
>> On Tuesday 16 October 2012 07:42 PM, Brian Stansberry wrote:
>>> On 10/16/12 8:09 AM, Jaikiran Pai wrote:
>>>> I'm unclear about a couple of things related to this change:
>>>>
>>>> 1) Will this (whatever property is being configured) apply to all
>>>> deployments?
>>>
>>> It is scoped to the individual deployment.
>>>
>>>> Looking at the example you pasted it looks like each
>>>> deployment can potentially be treated differently by setting a different
>>>> value for the property, which kind of comes back to what Tomaz says
>>>> about the other options available. Introducing this new way might be a
>>>> problem if other subsystems decide to introduce a new child of the
>>>> deployment resource to configure something that can already be done via
>>>> jboss-foo.xml which brings up the question about which one of those
>>>> values takes priority.
>>>
>>> If we allow these resources to set things that can also be set in a
>>> deployment descriptor, then the settings in the resource should
>>> control. Admins rule. ;)
>>>
>>> It's a very good question as to whether that kind of override should
>>> be allowed. It can't really be prevented of course, except via code
>>> review.
>>>
>>>> 2) AS7-3694 looks like a case where a deployment has to be attached (or
>>>> processed) in a certain way by the OSGi DUPs by using a configured
>>>> property. Shouldn't the OSGi subsystem be introducing such a management
>>>> resource/attribute within that subsystem instead of doing it at the
>>>> deployment resource? For example, consider the "default distinct name"
>>>> that the EJB3 subsystem DUPs need to apply to deployments. This default
>>>> distinct name is configured by an admin and hence is exposed as a
>>>> management attribute via the EJB3 subsystem. Is the OSGi usecase any
>>>> different from this?
>>>
>>> AIUI the EJB3 subsystem is only setting a global default that should
>>> be used if something is not provided in the deployment itself. It can
>>> still be changed on a per deployment basis though, by changing
>>> something in the deployment.
>>>
>>> In the OSGi case there is nothing in the deployment itself that
>>> specifies this. The crux of the question is whether this configuration
>>> should be forced into the deployment itself.
>>>
>>>> -Jaikiran
>>>> On Tuesday 16 October 2012 04:43 AM, Brian Stansberry wrote:
>>>>> Good question.
>>>>>
>>>>> I see it as a matter of roles. The jboss-all.xml file is full of
>>>>> configurations that are basically about how the deployment functions
>>>>> internally. That stuff is primarily the concern of the application
>>>>> developer. The admin may want to make some adaptations to tailor to the
>>>>> environment, but the contents of that file are basically the
>>>>> province of
>>>>> the app developers.
>>>>>
>>>>> The AS7-3694 request and HASingleton are primarily about under what
>>>>> conditions the deployment is installed at all. That is something the
>>>>> admin controls.
>>>>>
>>>>> So, we could:
>>>>>
>>>>> 1) Go with jboss-all.xml + overlays and force the admin to mix his
>>>>> stuff
>>>>> in with the app developer's stuff, keeping them in sync. (An overlay is
>>>>> a complete override, not a merge.)
>>>>>
>>>>> 2) Add new xxx.xml files to control this stuff and use overlays to let
>>>>> the admin insert his desired configs into the deployment. This would
>>>>> basically just be a hack workaround because we don't want to do overlay
>>>>> merging.
>>>>>
>>>>> 3) The management resource approach.
>>>>>
>>>>> On 10/15/12 5:32 PM, Tomaž Cerar wrote:
>>>>>> Why are introducing yet another configuration mechanism for
>>>>>> deployments?
>>>>>>
>>>>>> now we have
>>>>>> - jboss-deployment-structure.xml
>>>>>> - jboss-deployment-dependencies.xml
>>>>>> - jboss-all.xml
>>>>>> - jboss-xyz.xml - (too) many of them
>>>>>>
>>>>>> that in combination with overlays this could provide same capability.
>>>>>> AFAIR primary idea behind jboss-all.xml was to unify configuration for
>>>>>> all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml,
>>>>>> jboss-app.xml,....)
>>>>>>
>>>>>> and overlays just add this extra capability of exposing/manipulating
>>>>>> this trough management.
>>>>>> This new approach has only one extra capability that is to enable
>>>>>> subsystem itself to push/write/change some configuration that is
>>>>>> deployment-wise.
>>>>>>  From my point of view that is just wrong. Subsystems should not
>>>>>> run-time decide and change some deployment parameters that you can
>>>>>> than
>>>>>> also manipulate trough mgmt.
>>>>>>
>>>>>> Maybe I am not seeing some use-case but in general I don't like this
>>>>>> approach...
>>>>>>
>>>>>> --
>>>>>> tomaz
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
>>>>>> <[hidden email] <mailto:[hidden email]>>
>>>>>> wrote:
>>>>>>
>>>>>>     I've been working $subject in order to help support Thomas
>>>>>> Diesler's
>>>>>>     request for AS7-3694[1]. The gist of this request is to add
>>>>>> deployment
>>>>>>     unit processing (DUP) configuration as children of the deployment
>>>>>>     resource itself. Thomas' OSGi use case is one place where this
>>>>>> would be
>>>>>>     used. I expect HASingleton deployment will be another.
>>>>>>
>>>>>>     WIP is at [2]. I'm looking for feedback. :)
>>>>>>
>>>>>>     What I've done is based on what Thomas did at [3]. What I want
>>>>>> to do is
>>>>>>     move from the generic key/value pairs in that patch to a more
>>>>>> formally
>>>>>>     describable management API. Instead of:
>>>>>>
>>>>>>     <deployment name="foo.war"...>
>>>>>>        <properties>
>>>>>>         <property name="start.policy" value="DEFERRED"/>
>>>>>>        <property>
>>>>>>     </deployment>
>>>>>>
>>>>>>     It would be something analogous to how a profile configuration
>>>>>> is done:
>>>>>>
>>>>>>     <deployment name="foo.war"...>
>>>>>>        <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>>          <start-policy value="deferred"/>
>>>>>>        </deployment>
>>>>>>     </deployment>
>>>>>>
>>>>>>     The existing Extension API already has the hooks to support this.
>>>>>>     Extensions can register xml parsers for children of the
>>>>>> <deployment>
>>>>>>     element and can register management resources to act as children
>>>>>> of the
>>>>>>     /deployment=foo.war resource as well. Several subsystems already
>>>>>> take
>>>>>>     advantage of the latter. Until now the former has been an
>>>>>> unimplemented
>>>>>>     API. The commit at [4] implements it.
>>>>>>
>>>>>>     A couple things giving me some concern:
>>>>>>
>>>>>>     1) The above xml:
>>>>>>
>>>>>>     <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>>
>>>>>>     Nicer would be something like:
>>>>>>
>>>>>>     <deployers>
>>>>>>         <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>>>>
>>>>>>     I need to figure out if I can do some tricks with the parsing to
>>>>>> allow
>>>>>>     that to happen.
>>>>>>
>>>>>>     2) The structure of the resource tree. We already support
>>>>>> resources like
>>>>>>     this:
>>>>>>
>>>>>>     /deployment=foo.war/subsystem=web
>>>>>>
>>>>>>     Subsystems register resources like those to expose metrics. The
>>>>>> commit
>>>>>>     at [4] uses that same tree. When subsystems could now register
>>>>>> child
>>>>>>     resources to the deployment=* resource, they could include both
>>>>>> runtime
>>>>>>     stuff and configuration stuff.
>>>>>>
>>>>>>     I'm not sure that mixing the two is ideal, although it's what we
>>>>>> do for
>>>>>>     the regular subsystem resources in the profile. I'm vaguely
>>>>>> concerned
>>>>>>     that if someday the configuration that subsystems choose to
>>>>>> expose via
>>>>>>     this mechanism gets complex, the mixing of metrics with
>>>>>> configuration in
>>>>>>     the same tree will start to break down.
>>>>>>
>>>>>>     Comments are appreciated.
>>>>>>
>>>>>>
>>>>>>     [1] https://issues.jboss.org/browse/AS7-3694
>>>>>>     [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>>>>>     [3] https://github.com/jbossas/jboss-as/pull/3230
>>>>>>     [4]
>>>>>>
>>>>>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     Brian Stansberry
>>>>>>     Principal Software Engineer
>>>>>>     JBoss by Red Hat
>>>>>> _______________________________________________
>>>>>>     jboss-as7-dev mailing list
>>>>>>     [hidden email]
>>>>>> <mailto:[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

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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Thomas Diesler
In reply to this post by Brian Stansberry

On 10/22/2012 05:46 PM, Brian Stansberry wrote:

> On 10/22/12 3:36 AM, Thomas Diesler wrote:
>> I'd like to point out that the 'start.policy' property needed for OSGi
>> deployments is a workaround for the general lifecycle disconnect that we
>> have between AS7 deployments and OSGi deployments.
>>
>> In AS7 we have
>>
>> * ADD - bring the bytes across
>> * DEPLOY - parse metadata, resolve (a.k.a create module/classloader),
>> install services
>> * UNDEPLOY - remove services, destroy classloader, etc
>> * REMOVE - take the bytes off the system
>>
>> In OSGi we have
>>
>> * INSTALL - bring the bytes across, parse the metadata
>> * RESOLVE - (may be implicit) link to other installed bundles, create
>> the classloader
>> * START/STOP - (repeatedly) install/uninstall services
>> * UNDEPLOY - take the bytes off the system
>>
>> The fundamental disconnect is that the AS7 DEPLOY operation is a an all
>> or nothing approach, which creates an ordering issue for the user. For a
>> large set of interconnected deployments, the user has to know in which
>> order they can be deployed. Generally, this ordering concern should not
>> be delegated to the user because he/she cannot know the complex
>> dependencies between deployment capabilities/requirements. IOW, given a
>> set of deployments the admin cannot know in which order they need to be
>> dropped into the deployments folder.
>>
>> I'm mentioning this because I believe we might want to apply the
>> deferred start.policy behaviour to non-osgi deployments as well.
>> This raises the question about properties that should be shared between
>> subsystems? Brian's approach binds them to one subsystem only.
>>
>> I would prefer a global set of properties that the deployment layer
>> knows about and can validate. These can be document and they become part
>> of the API.
>
> I'm interested in what Paul Ferraro is thinking regarding HASingleton
> deployments. This is the other very similar case. I can imagine there
> could be some common configuration between the two that therefore
> belongs at the global level. But I'd like to see the real case first.
merci

>
>> Any other prop is passed through but not part of the API (it
>> would not show up in console/cli). This is much like any other shared
>> concept that can be seen from any subsystem.
>>
>
> -1. Any place we are using generic properties in our management API
> for something other than configuring a custom plugin that we can't
> know anything about, that's a flaw in our API. We have some, and
> probably always will, but the existence of one shouldn't justify another.
fine

>
>> ------
>>
>> Making props be part of the deployment ...
>>
>> One of the value propositions of OSGi is that you can easily bring in
>> functionality by deploying 3rd party bundles. Those bundles cannot be
>> touched. Properties that modify (bundle) deployment behaviour like
>> auto-start and start-level must be defined external to the deployment.
>>
>> ------
>>
>> Concerning jboss-all.xml and using overlays ...
>>
>> An overlay is currently not a child of the deployment itself. When you
>> undeploy the properties related to that deployment must get removed as
>> well,
>
> Why "must"? I certainly understand why it's desirable to help keep
> things tidy, but why "must"?
Its a usability issue. If an admin undeploys a bundle that has
associated properties in an overlay those properties would
unintentionally apply a few days later to a bundle deployment (with the
same runtime name).

>
>> which is currently not the case with overlays.
>>
>> cheers
>> --thomas
>>
>> On 10/15/2012 11:45 PM, Brian Stansberry wrote:
>>> I've been working $subject in order to help support Thomas Diesler's
>>> request for AS7-3694[1]. The gist of this request is to add deployment
>>> unit processing (DUP) configuration as children of the deployment
>>> resource itself. Thomas' OSGi use case is one place where this would be
>>> used. I expect HASingleton deployment will be another.
>>>
>>> WIP is at [2]. I'm looking for feedback. :)
>>>
>>> What I've done is based on what Thomas did at [3]. What I want to do is
>>> move from the generic key/value pairs in that patch to a more formally
>>> describable management API. Instead of:
>>>
>>> <deployment name="foo.war"...>
>>>    <properties>
>>>     <property name="start.policy" value="DEFERRED"/>
>>>    <property>
>>> </deployment>
>>>
>>> It would be something analogous to how a profile configuration is done:
>>>
>>> <deployment name="foo.war"...>
>>>    <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>      <start-policy value="deferred"/>
>>>    </deployment>
>>> </deployment>
>>>
>>> The existing Extension API already has the hooks to support this.
>>> Extensions can register xml parsers for children of the <deployment>
>>> element and can register management resources to act as children of the
>>> /deployment=foo.war resource as well. Several subsystems already take
>>> advantage of the latter. Until now the former has been an unimplemented
>>> API. The commit at [4] implements it.
>>>
>>> A couple things giving me some concern:
>>>
>>> 1) The above xml:
>>>
>>> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>
>>> Nicer would be something like:
>>>
>>> <deployers>
>>>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>>>
>>> I need to figure out if I can do some tricks with the parsing to allow
>>> that to happen.
>>>
>>> 2) The structure of the resource tree. We already support resources
>>> like
>>> this:
>>>
>>> /deployment=foo.war/subsystem=web
>>>
>>> Subsystems register resources like those to expose metrics. The commit
>>> at [4] uses that same tree. When subsystems could now register child
>>> resources to the deployment=* resource, they could include both runtime
>>> stuff and configuration stuff.
>>>
>>> I'm not sure that mixing the two is ideal, although it's what we do for
>>> the regular subsystem resources in the profile. I'm vaguely concerned
>>> that if someday the configuration that subsystems choose to expose via
>>> this mechanism gets complex, the mixing of metrics with
>>> configuration in
>>> the same tree will start to break down.
>>>
>>> Comments are appreciated.
>>>
>>>
>>> [1] https://issues.jboss.org/browse/AS7-3694
>>> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
>>> [3] https://github.com/jbossas/jboss-as/pull/3230
>>> [4]
>>> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd 
>>>
>>>
>>
>
>

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Thomas Diesler
In reply to this post by Brian Stansberry
Ragarding the representation of these properties on the management UIs ...

I'm not clear on how this is supposed to work. Currently, the properties
are modeled on the ADD operation. From the UI perspective there is no
notion of target subsystem nor deployment type. How does the UI decide
which properties are available in the context of a given ADD operation.

Lets take the auto-start and start-level props as an example.
How would this look like in the GWT console and on the CLI?

--thomas

On 10/15/2012 11:45 PM, Brian Stansberry wrote:

> I've been working $subject in order to help support Thomas Diesler's
> request for AS7-3694[1]. The gist of this request is to add deployment
> unit processing (DUP) configuration as children of the deployment
> resource itself. Thomas' OSGi use case is one place where this would be
> used. I expect HASingleton deployment will be another.
>
> WIP is at [2]. I'm looking for feedback. :)
>
> What I've done is based on what Thomas did at [3]. What I want to do is
> move from the generic key/value pairs in that patch to a more formally
> describable management API. Instead of:
>
> <deployment name="foo.war"...>
>    <properties>
>     <property name="start.policy" value="DEFERRED"/>
>    <property>
> </deployment>
>
> It would be something analogous to how a profile configuration is done:
>
> <deployment name="foo.war"...>
>    <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>      <start-policy value="deferred"/>
>    </deployment>
> </deployment>
>
> The existing Extension API already has the hooks to support this.
> Extensions can register xml parsers for children of the <deployment>
> element and can register management resources to act as children of the
> /deployment=foo.war resource as well. Several subsystems already take
> advantage of the latter. Until now the former has been an unimplemented
> API. The commit at [4] implements it.
>
> A couple things giving me some concern:
>
> 1) The above xml:
>
> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> Nicer would be something like:
>
> <deployers>
>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> I need to figure out if I can do some tricks with the parsing to allow
> that to happen.
>
> 2) The structure of the resource tree. We already support resources like
> this:
>
> /deployment=foo.war/subsystem=web
>
> Subsystems register resources like those to expose metrics. The commit
> at [4] uses that same tree. When subsystems could now register child
> resources to the deployment=* resource, they could include both runtime
> stuff and configuration stuff.
>
> I'm not sure that mixing the two is ideal, although it's what we do for
> the regular subsystem resources in the profile. I'm vaguely concerned
> that if someday the configuration that subsystems choose to expose via
> this mechanism gets complex, the mixing of metrics with configuration in
> the same tree will start to break down.
>
> Comments are appreciated.
>
>
> [1] https://issues.jboss.org/browse/AS7-3694
> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
> [3] https://github.com/jbossas/jboss-as/pull/3230
> [4]
> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Heiko Braun


I think this is where the description I've asked for comes into play.
If these parameters can be extracted from the DMR model (similar to :read-resource-description or part of that), then the tools (CLI, GUI) might provide two things:


a) request these parameters when deployments are "add'ed", i.e. an additional step when applications are  deployed from the console

b) extend the subsystem specific deployment views to show these settings as well


But I am not sure if we can easily provide a), because the affected subsystems are not know until the deployment content is actually moved from the repository to the server and processed by the deployment layers.





On Oct 23, 2012, at 6:40 AM, Thomas Diesler <[hidden email]> wrote:

Ragarding the representation of these properties on the management UIs ...

I'm not clear on how this is supposed to work. Currently, the properties are modeled on the ADD operation. From the UI perspective there is no notion of target subsystem nor deployment type. How does the UI decide which properties are available in the context of a given ADD operation.

Lets take the auto-start and start-level props as an example.
How would this look like in the GWT console and on the CLI?


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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry
This UI issue is an argument against ever trying to extend the use of
these configuration elements to cover a broad subset of what is included
in deployment descriptors.

AIUI, the problem is not all of the options exposed by subsystems will
be relevant to a given deployment. That is much less of an issue if the
number of exposed options is quite small. For example, the actual use
cases we have identified are the OSGi start policy, the OSGi start level
and perhaps some things related to only deploying when a server becomes
an HASingleton master. That's comprehensible even if the options are
irrelevant to a particular deployment.

The distinction I see between these two use cases that are driving these
new management model elements and what is in the deployment descriptors
is that the latter are concerned with how the runtime services installed
by the deployment are and how they behave, while this new stuff is about
how the management layer treats the deployment -- what the criteria are
that result in the deployment being processed.

I doubt that that's a totally clear black and white distinction, but if
we restrict these new management model elements to the "how does the AS
manage this deployment" side of the line, I think we'll be better off.

On 10/23/12 1:57 AM, Heiko Braun wrote:

>
>
> I think this is where the description I've asked for comes into play.
> If these parameters can be extracted from the DMR model (similar to
> :read-resource-description or part of that), then the tools (CLI, GUI)
> might provide two things:
>
>
> a) request these parameters when deployments are "add'ed", i.e. an
> additional step when applications are  deployed from the console
>
> b) extend the subsystem specific deployment views to show these settings
> as well
>
>
> But I am not sure if we can easily provide a), because the affected
> subsystems are not know until the deployment content is actually moved
> from the repository to the server and processed by the deployment layers.
>
>
>
>
>
> On Oct 23, 2012, at 6:40 AM, Thomas Diesler <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> Ragarding the representation of these properties on the management UIs ...
>>
>> I'm not clear on how this is supposed to work. Currently, the
>> properties are modeled on the ADD operation. From the UI perspective
>> there is no notion of target subsystem nor deployment type. How does
>> the UI decide which properties are available in the context of a given
>> ADD operation.
>>
>> Lets take the auto-start and start-level props as an example.
>> How would this look like in the GWT console and on the CLI?
>


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

Re: Subsystem specific deployer configurations in standalone.xml/domain.xml

Thomas Diesler
In reply to this post by Brian Stansberry
Hi Brian,

wanted touch base with you on this - any news?

cheers
--thomas

On 10/15/2012 11:45 PM, Brian Stansberry wrote:

> I've been working $subject in order to help support Thomas Diesler's
> request for AS7-3694[1]. The gist of this request is to add deployment
> unit processing (DUP) configuration as children of the deployment
> resource itself. Thomas' OSGi use case is one place where this would be
> used. I expect HASingleton deployment will be another.
>
> WIP is at [2]. I'm looking for feedback. :)
>
> What I've done is based on what Thomas did at [3]. What I want to do is
> move from the generic key/value pairs in that patch to a more formally
> describable management API. Instead of:
>
> <deployment name="foo.war"...>
>    <properties>
>     <property name="start.policy" value="DEFERRED"/>
>    <property>
> </deployment>
>
> It would be something analogous to how a profile configuration is done:
>
> <deployment name="foo.war"...>
>    <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>      <start-policy value="deferred"/>
>    </deployment>
> </deployment>
>
> The existing Extension API already has the hooks to support this.
> Extensions can register xml parsers for children of the <deployment>
> element and can register management resources to act as children of the
> /deployment=foo.war resource as well. Several subsystems already take
> advantage of the latter. Until now the former has been an unimplemented
> API. The commit at [4] implements it.
>
> A couple things giving me some concern:
>
> 1) The above xml:
>
> <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> Nicer would be something like:
>
> <deployers>
>     <subsystem xmlns="urn:jboss:domain:osgi:1.2">
>
> I need to figure out if I can do some tricks with the parsing to allow
> that to happen.
>
> 2) The structure of the resource tree. We already support resources like
> this:
>
> /deployment=foo.war/subsystem=web
>
> Subsystems register resources like those to expose metrics. The commit
> at [4] uses that same tree. When subsystems could now register child
> resources to the deployment=* resource, they could include both runtime
> stuff and configuration stuff.
>
> I'm not sure that mixing the two is ideal, although it's what we do for
> the regular subsystem resources in the profile. I'm vaguely concerned
> that if someday the configuration that subsystems choose to expose via
> this mechanism gets complex, the mixing of metrics with configuration in
> the same tree will start to break down.
>
> Comments are appreciated.
>
>
> [1] https://issues.jboss.org/browse/AS7-3694
> [2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
> [3] https://github.com/jbossas/jboss-as/pull/3230
> [4]
> https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

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