so for the simple case the idea is to declare a service dependency on the socket-binding:
serviceBuilder..addDependency(SocketBinding.JBOSS_BINDING_NAME.append(bindingRef),
SocketBinding.class, service.getBinding())
and on the opposite side (service impl) use an injectable field:
InjectedValue<SocketBinding> binding = new InjectedValue<>();
On 26 Sep 2014, at 08:38, Heiko Braun <hbraun(a)redhat.com> wrote:
Yes, my explanation was misleading. Since we try to reduce the overall number of ports
used, I did assume that any subsystem that needs remote communication needs to go down the
HTTP upgrade route. Isn't that the case? What's the policy behind this?
On 25 Sep 2014, at 16:49, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
> You are talking about two things now.
>
> One is exposing new port which can be done via SocketBinding infrastructure we have.
> for example see ListenerAdd in undertow subsystem.
>
> Completely different thing is protocol multiplexing aka utilizing http upgrade.
> In this case port is one already exposed by undertow (8080 by default)
> See RemotingHttpUpgradeService for example how http-remoting works.
> Before you go with this solution make sure also protocol client support this.
>
> --
> tomaz
>
>
> On Thu, Sep 25, 2014 at 4:29 PM, Heiko Braun <hbraun(a)redhat.com> wrote:
> Can someone give me a brief overview how a subsystem would expose a port? How are
services actually wired to the protocol multiplexing ? Can you point me to some examples?
>
> Regards, Heiko
> _______________________________________________
> 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