geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Network Properties & Naming
Date Tue, 23 Aug 2005 15:18:59 GMT

Joe Bohn wrote:
> I agree with Jeremy.   One other aspect to consider is that technology 
> is constantly changing.  If we settle on terminology today that isn't 
> confusing for either tomcat or jetty that doesn't mean that it won't 
> cause confusion for container X in the future.    We will never be able 
> to pick terms that are generic for all time, all containers, all 
> components.  I think attempting to come up with some common terminology 
> will also be confusing to the user and will make it difficult to explain 
> concepts that are similar or very different between containers.    
> If we do end up with some common mapping, then I think we need to pick 
> the most obvious terminology for the user.

Bingo.  Lets pick the appropriate term now.  Its 1 single term that is 
in question here.  This should be a simple resolution and does not need 
endless debate.  The Tomcat integration, in particular, the connector 
has had many terms changed for Geronimo.  Only 1 causes confusion.  Why 
is this an issue to change this one term?  It is explained more clearly 
below why I think this need changing.

> Most users will consider
> "host" to be the IP host name and so I think we should use that term in 
> general and cover the appropriate mapping to tomcat or jetty in 
> documentation.  

Sorry, but I think this is an opinionated statement without any merit. 
It's a simple fact that the host is mapped to an ip address, not the 
address itself.

Per Webopeodia:

"A computer that is connected to a TCP/IP network, including the 
Internet. Each host has a unique IP address."

Per The Telecom Glossary: it 

The definition of host is "A fully qualified domain name (usually 
alphabetic) identifying the address of one specific host computer on the 

So I do not agree with your statement that 'Most users will consider 
"host" to be the IP.'  You are also alienating those who use Tomcat that 
their definition of a "host" coincides with your opinion, which again, 
is simply incorrect.

>The user will have to coordinate settings between many 
> different elements and using common terms will make that much easier 
> than avoiding those terms because they bring specific meaning to some 
> particular component.

Geronimo is a conglomeration of different technologies.  I see no 
problem with trying our best to carry out the best in naming conventions 
and not cross define/name terms.  Now is the time to use best-practice 
naming conventions.  Again, I do not see why this is a problem, 
especially at a point that its feasible to change.  I must point out 
that "host" is what is in question...and this will be terribly confusing 
with how a Host is utilized in a Tomcat configuration.  We need to be 
sensitive to this for those users coming to use Geronimo from Tomcat. 
This may help clarify...

o.a.t.Host - The Host object...the attribute "name" is the DNS resolved 
name of the host.

o.a.t.Engine - contains a defaultHost paramater that is mandatory.  The 
defaultHost *must* match a DNS Host named object.

o.a.t.Connector - has a parameter named "address".  This is mapped to 
the physical or logical *IP ADDRESS* to which to listen on for handling 
requests.  It is not a host.

Geronimo connector wants to use "host" for the address.  Understand that 
the connectors are configured in the j2ee-server-plan.xml file (or 
tomcat-conig.xml in the source code).  Understand the confusion this 
will cause when Tomcat is using the word "host" or a subset of the word 
"host" in its configuration, and the the connector definition of a host 
is completely different.

Why is this an issue that we cannot use a generic term such as "address" 
or "inetaddress" or anything else that does not use the term "host"? 
Understand the implication of this.

> Joe
> Jeremy Boynes wrote:
>> Aaron Mulder wrote:
>>>     I disagree -- I think it's important to have a common management 
>>> interface (currently, for example, NetworkConnector), and having the 
>>> same properties called something different in every networkable GBean 
>>> totally defeats that.
>> I agree a common management interface is desirable. Unfortunately the 
>> containers we are integrating appear to have little in common. From 
>> what I hear Jeff saying, apparently simple concepts like "host" differ.
>> What this means is that we will need substantial extensions to the 
>> "common" interface to deal with these container specific concepts; the 
>> lowest common denominator is proving to be too low.
>> This does mean more work for us: alternative deployment 
>> infrastructure, alternative management APIs, multiple management 
>> portlets, and so on. However, it provides a simple and more intuitive 
>> interface for the user so should be done.
>> -- 
>> Jeremy

View raw message