[wildfly-dev] trying to run subsystem extension in host controller

[Kabir Khan]

> On 25 Apr 2016, at 18:39, Kabir Khan <kabir.khan at jboss.com> wrote:
> 
> Seems you have hit some of the tweaks needed that I mentioned :) 
> 
> I'll try to explain a bit below. Other things to look out for are that all the paths relating to data, configuration paths etc. have a different name in the HC to on a server (see the constants in ServerEnvironment vs HostControllerEnvironment).
>> On 25 Apr 2016, at 17:15, John Mazzitelli <mazz at redhat.com> wrote:
>> 
>> 
>> <TL;DR>
>> Trying to run a subsystem extension in host controller and it fails because some of its service dependencies are missing. Am I doing something wrong (it would not be a shocker if I was) or are these services really not deployed inside the Host Controller?
>> </TL;DR>
>> 
>> 
>> I'm trying to get a subsystem extension to run inside of the Host Controller. This is a subsystem extension that runs fine in a standalone WildFly container - just trying to get it to run in a host controller (and maybe later in a domain controller as well).
>> 
>> In domain/configuration/host.xml, I add my own <subsystem> in the <profile> - and that seems to run OK (well, not OK, but I know it is getting its initialization method invoked by the container).
>> 
>> Because I need an outbound socket binding defined, I put add a socket-binding-groups in the host.xml (there are no socket-binding-groups in here by default):
>> 
>>  <socket-binding-groups>
>>    <socket-binding-group default-interface="public" name="standard-sockets">
>>        <outbound-socket-binding name="hawkular">
>>            <remote-destination host="127.0.0.1" port="8080"/>
>>        </outbound-socket-binding>
>>    </socket-binding-group>
>>  </socket-binding-groups>
>> 
>> That causes the container to abort with "WFLYCTL0198: Unexpected element '{urn:jboss:domain:4.0}socket-binding-groups' encountered" So I remove <socket-binding-groups> so that <socket-binding-group> is a direct child of the top-level <host>. The container starts OK when I do this.
> Correct. According to the xsd, only one socket-binding-group is allowed in host.xml
> 
>> 
>> But now the problems - my subsystem registers itself with a few service dependencies that do not exist at the time my service is initialized - specifically:
>> 
>> jboss.naming.context.java (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME)
> This would be installed by the naming subsystem, which is not a host capable subsystem. So there cannot be any jndi on a HC at the moment.
>> 
>> jboss.outbound-socket-binding (o.j.a.network.OutboundSocketBinding.OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME)
> I see the same thing https://issues.jboss.org/browse/WFCORE-1505. 
> 
>> 
>> jboss.server.environment (o.j.a.server.ServerEnvironmentService.SERVICE_NAME)
> This would only be available in a server. However, there is no corresponding service in a host controller to get the HostControllerEnvironment. Perhaps we should add one https://issues.jboss.org/browse/WFCORE-1506.
>> 
>> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER)
> 
> In a HC you need to depend on the DomainModelControllerService instead, it's name is in DomainModelControllerService.SERVICE_NAME.
> Both services contain a ModelController, you will need to choose the name to depend on according to the process type.
> 
>> 
>> When the host controller runs, I get this startup error:
>> 
>> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>>   ("host" => "master"),
>>   ("subsystem" => "hawkular-wildfly-agent")
>> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
>>   "\"org.hawkular.agent.\".hawkular-wildfly-agent is missing [jboss.outbound-socket-binding.hawkular, jboss.server.environment, jboss.as.server-controller]",
>>   "jboss.naming.context.java.abc is missing [jboss.naming.context.java]"
>> ]}
>> 
>> Sooo..... my question is - what happens if a subsystem needs these things? Do I need to do something special to make them available or are they really not deployed in the host controller?
>> 
>> What I need these for is:
>> 
>> jboss.naming.context.java - so I can store something in JNDI (actually, for my use case, I can probably skip this dependency - I don't think I will need it when running in the host controller)
> I don't think this is anything we can do at the moment, so hopefully you can do without.
>> 
>> jboss.outbound-socket-binding - my subsystem needs to talk to an external server and this defines what host/port that server is on
> I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, please let us know so we can put it into the process.
>> 
>> jboss.server.environment - I need this to find out where the host controller's data directory is (e.g. domain/data). Is there another way to get this?
> I believe you should be able to get this by reading the following system property (taken from HostControllerEnvironment):
> 
> <code>
> /**
> * Constant that holds the name of the system property
> * for specifying {@link #getDomainDataDir()} the domain data directory}.
> *
> * <p>Defaults to <tt><em>DOMAIN_BASE_DIR</em>/data</tt>.
> */
> public static final String DOMAIN_DATA_DIR = "jboss.domain.data.dir";
> </code
>> 
>> jboss.as.server-controller - I need this to obtain information from the management model such as "/:uuid" (which it looks like HCs do not have), the "/:launch-type" attribute and others.
> You will need to use the HC one as mentioned above
> 
> 
> I think that of the bugs/missing things you mention https://issues.jboss.org/browse/WFCORE-1505 (missing outbound socket binding service) is the one that looks like it blocks you the most, so I will see if that is fixable first.
https://github.com/wildfly/wildfly-core/pull/1520
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev