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

Mon Apr 25 14:51:10 EDT 2016

> On 25 Apr 2016, at 18:56, Kabir Khan <kabir.khan at jboss.com> wrote:
> 
> 
>> 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

WFCORE-1506 and WFCORE-1504 also have PRs now.

>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev