Jan Luehe wrote:

> 
>>>Bill Barker wrote:
>>>
>>>>>Currently, connector objectname includes address in this format:
>>>>>
>>>>>domain:type=Connector,port=8080,address=0.0.0.0.
>>>>>
>>>>>This causes a problem when IPV6 addresses are used since IPV6 addresses
>>>>>include colons.  The javax.management.ObjectName doesn't allow to have
>>>>>colon character in it and this causes
>>>>>javax.management.MalformedObjectNameException: ObjectName: invalid
>>>>>character ':' in value part of property.
>>>>>
>>>>>I propose to exclude address as connector objectname property since
>>>>>port number alone should keep the objectnames unique.
>>>>
>>>>What about the case where I have several V-Hosts, each with it's own
>>>>Connector listening on port 80?
>>>
>>>This seems a possible use case, but is that really useful ? I would
>>>always put the connector at the engine level, personally.
>>>
>> 
>> 
>> Regardless of where you put it, you still have one connector per V-Host
>> IP address.
> 
> 
> I may be totally off here, but in the most common cases, all your
> domain names (one for each V-Host) will map to the same IP address, in
> which case you cannot have more than one Connector listening on the
> same port (if you do that, you'll get a java.net.BindException when
> starting the 2nd and so forth Connector).

Not quite :-)

It is common to have multiple IP addresses - either by using multiple
ethernet cards, or by using ifconfig aliases. That's how virtual hosting
worked in the old days, and it is still used if you want to support 
old clients ( or command line / other tools that don't include Host ).
For vhost - it is probably valid to have different engines or configs for 
different vhosts.


I think it would be a bad idea to use only the port ( which will be 80 for
most hosts anyway ).

If mangling the IPv6 address is not a solution, then we'll need some unique
name or something.

Costin


> You can only have more than one Connector listening on the same port
> when they're listening on different IP addresses on the same server.
> 
> This is the case we need to resolve, right?




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to