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

[Thomas Diesler]

On 10/22/2012 05:46 PM, Brian Stansberry wrote:
> On 10/22/12 3: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.
>
> I'm interested in what Paul Ferraro is thinking regarding HASingleton 
> deployments. This is the other very similar case. I can imagine there 
> could be some common configuration between the two that therefore 
> belongs at the global level. But I'd like to see the real case first.
merci
>
>> 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.
>>
>
> -1. Any place we are using generic properties in our management API 
> for something other than configuring a custom plugin that we can't 
> know anything about, that's a flaw in our API. We have some, and 
> probably always will, but the existence of one shouldn't justify another.
fine
>
>> ------
>>
>> 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,
>
> Why "must"? I certainly understand why it's desirable to help keep 
> things tidy, but why "must"?
Its a usability issue. If an admin undeploys a bundle that has 
associated properties in an overlay those properties would 
unintentionally apply a few days later to a bundle deployment (with the 
same runtime name).
>
>> 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