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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev