yes
On Fri, Sep 26, 2014 at 9:06 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
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