[wildfly-dev] Subsystem exposing a port?

[Heiko Braun]

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