I have 0 data to back this up, but I'd say the common case would be a
1:1 match between network-listener and protocol. Having said that,
large systems might reuse elements quite a bit. Port unification might
blur those lines as well. I'd suggest getting feedback from
jeanfrancois, alexey, dhiru, and rajiv (I think). They were the
progenitors of the grizzly config spec. I just picked it up and
finished it up so some of those decisions pre-date my involvement so I
don't have all the rationalizations behind some of them.
Anissa Lam wrote:
>
> Thanks Kim for starting this thread. I also have a question, please
> see comment.
>
> Kim Haase wrote:
>> On 07/28/09 15:05, Justin Lee wrote:
>>> Kim Haase wrote:
>>>> Also, is it correct that a virtual server is normally associated
>>>> with one or more network listeners, but that you can create a
>>>> virtual server that isn't associated with any network listener,
>>>> then create the network listener, then edit the virtual server to
>>>> specify that network listener?
>>> That is correct. Though it'd save you a step to create the
>>> network-listener first, I'd think.
>>
>> Thanks, that may be worth mentioning. I notice the Admin Guide
>> doesn't cover this area just yet -- probably this kind of information
>> is worth including there, too.
>>
>> So with the Admin Console anyway, you'd want to create a protocol,
>> create a network listener, then create a virtual server that uses the
>> network listener.
> Actually I am thinking to change the way Admin Console works so that
> it behaves like the CLI with respect to creating a network listener.
> My question: what is the common use case ? How often does 2 or
> more network listener share/refer to the same protocol ? If the
> common case is 1-1 relationship, then GUI shouldn't require user to
> create a protocol first and then go create the network listener. GUI
> should just create the protocol for this network listener at the same
> time, just like the CLI does. I think Justin mentioned about this
> before. Justin, can you confirm ?
>
> thanks
> Anissa
>>
>> Kim
>>
>>>>
>>>> Thanks very much,
>>>> Kim Haase
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>