[jboss-as7-dev] Subsystem specific deployer configurations in standalone.xml/domain.xml
Jaikiran Pai
jpai at redhat.com
Tue Oct 16 09:09:16 EDT 2012
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 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
>>
>>
>
More information about the jboss-as7-dev
mailing list