No, the only content types we propagate are deployments and rollout plans; the stuff that goes in the content repo. Way back at the beginning of AS 7, we decided provisioning was out of scope for the server and was a JON function. We've considered expanding beyond that from time to time, but have never had time. Considered it primarily people requesting that modules get pushed around the domain, particularly datasource drivers. This is basically a request for module propagation. It is a slightly easier variant of that request though. A key requirement with a general module propagation thing is we have to track what's available so newly joining hosts can request any necessary missing content. That basically means referring to those modules in the domain.xml config. With extensions though we already have that reference in place.

On 5/2/16 12:58 PM, John Mazzitelli wrote: > <TL;DR> > If I define my own subsystem configuration in one of the domain controller's profiles, can the DC/HC push out my subsystem extension module to the managed standalone servers just like it pushes out deployments to them? > </TL;DR> > > > In WildFly's Domain Operating Mode you can define Server Groups in your Domain Controller configuration [1]. In these Server Groups you say what deployments should be deployed on which servers, like this: > > <server-group name="main" profile="default"> > <deployments> > <deployment name="foo.war" runtime-name="foo.war" /> > </deployments> > </server-group> > > The DC and HC will do their thing to ensure those deployments are installed on the managed standalone servers. [3] > > Additionally in your Domain Controller configuration, you can define profiles with different subsystems [2] (so presumably some managed standalone servers can have some subsystems, where others in different profiles don't have to have them - or at least could be configured differently). For example: > > <profiles> > <profile name="default"> > <subsystem xmlns="urn:jboss:domain:web:1.0"> > <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/> > [...] > </subsystem> > <subsystem xmlns="urn:jboss:domain:fictional-example:1.0"> > <socket-to-use name="unique-to-bigger"/> > </subsystem> > [...] > </profile> > </profiles> > > My question is - does the DC and HC manage that "fictional-example" subsystem extension module just like they handle deployments? In other words, will that subsystem's module get pushed out to the managed standalone servers (in the same way the DC/HC ensures the deployments are pushed out to the managed standalone servers?) If so, where do you put the module directory? On the DC, like deployments [3]? If not, how does this "fictional-example" subsystem that is defined in the profile make its way to the managed standalone server? > > Thanks, > John Mazz > > [1] https://docs.jboss.org/author/display/WFLY10/Operating+modes > [2] https://docs.jboss.org/author/display/WFLY10/Domain+Setup > [3] https://docs.jboss.org/author/display/WFLY8/Application+deployment > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

> BTW, I was brainstorming a bit in that last paragraph, forgetting that > I'm talking to someone who works on something that is a proper > layer/add-on on top of WildFly, not an end user writing their own > extensions. Proper layers/add-ons need to patchable, which adds another > whole set of requirements beyond just needing to get bits replicated. My whole email was a brainstorming session :) I don't think we'll need that feature - but I was wondering if it did exist. If it did, might have been something to be considered for something, but since it doesn't exist, that makes it easy. ;)

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev