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

[Thomas Diesler]

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