Re: [jboss-as7-dev] Subsystem specific deployer configurations in standalone.xml/domain.xml

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