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

[Kabir Khan]

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