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