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 <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> 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/6326003a104ac4ac825e8dda4c... -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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 >> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> >> 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/6326003a104ac4ac825e8dda4c... >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> <mailto:jboss-as7-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >

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

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 >>>>> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> >>>>> 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/6326003a104ac4ac825e8dda4c... >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Software Engineer >>>>> JBoss by Red Hat >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> <mailto:jboss-as7-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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>

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'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/6326003a104ac4ac825e8dda4c...

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/6326003a104ac4ac825e8dda4c... >

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/6326003a104ac4ac825e8dda4c...

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 <thomas.diesler(a)jboss.com <mailto:thomas.diesler@jboss.com>> 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?

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/6326003a104ac4ac825e8dda4c... >