Hi Jan,
>> In GFv2 the situation was following:
>>
>> virtual-server referenced list of supported http-listeners,
>> http-listener had a reference to default virtual-server
>>
>> In GFv3 the situation is different:
>>
>> virtual-server references list of supported network-listeners,
>> network-listener has a reference to protocol (which MAY be HTTP
>> protocol, but may be not)
>> HTTP protocol has reference to default virtual-server
>>
>> So, besides inconsistency, we also have a problem - network-
>> listener may be bound to protocol, which is not HTTP and in this
>> case virtual-server can not reference such a network-listener.
>>
>> I think the easiest solution we can apply here - is to make virtual-
>> server reference HTTP protocol, not network-listener. Can we do that?
>
> We need the association between virtual-server and network-listener,
> so that
> we can satisfy the contract of VirtualServer#getPorts, which is
> supposed to return
> the port numbers of all the listeners that a given VirtualServer has
> been associated
> with.
IMO the same info could be collected if virtual-server will reference
http protocol by looking up network-listeners, which reference the
http protocol.
> This info is used by MapperListener, which is associated with a
> network-listener:
> A MapperListener will ignore a VirtualServer registration event
> unless the port number
> of its associated network-listener is included in the array returned
> by VirtualServer#getPorts.
>
> Otherwise, it will process the event and add the VirtualServer (and
> all its host names)
> to the network-listener's Mapper.
>
> I think it would be an error if a virtual-server referenced a
> network-listener whose protocol
> was different from http(s).
Right, it will be error, but currently it's quite easy to make this
error and other config related errors.
For example this issue [1], where user creates new virtual-server
("myvs"), which references a new network-listener ("new-network-
listener"), which in its turn references existing http-protocol ("http-
listener-1"), so we come to situation:
<virtual-server id="server" network-listeners="http-listener-1,http-
listener-2" />
<virtual-server id ="myvs" network-listeners="new-network-listener"/>
<network-listener port="8080" protocol="http-listener-1"
transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />
<network-listener port="7777" protocol="new-network-listener"
transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />
<protocol name="http-listener-1">
<http default-virtual-server="server" max-connections="250"
server-name="">
<file-cache />
</http>
</protocol>
it appears that "http-listener-1" protocol has default-virtual-
server="server", so network-listener "new-network-listener" is
actually misconfigured, because it doesn't belong to virtual-server
"server".
Actually the similar misconfiguration may occur even if we will make
virtual-server to reference http protocol, but currently, IMO, it's
quite difficult to track such issues.
Thanks.
WBR,
Alexey.
[1]
https://glassfish.dev.java.net/issues/show_bug.cgi?id=8289
>
> Does this help?
>
>
> Jan
>
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>