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

[David M. Lloyd]

Non-OSGi deployments can be "fixed" by deploying the missing dependecies 
into the deploy directory, because they do not *really* have (or need) a 
user-controllable lifecycle; this is an OSGi artifact that results from 
its resolver algorithm afaict.  Please be cautious trying to fit 
non-OSGi deployments into an OSGi-shaped box.

On 10/22/2012 03:36 AM, Thomas Diesler wrote:
> 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
>


-- 
- DML