[jboss-as7-dev] Subsystem specific deployer configurations in standalone.xml/domain.xml
Brian Stansberry
brian.stansberry at redhat.com
Wed Oct 17 19:54:43 EDT 2012
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 at redhat.com <mailto:brian.stansberry at 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/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org
>>>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list