On 25 Apr 2016, at 18:39, Kabir Khan <kabir.khan(a)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(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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev