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 01:03:02 GMT
No, I seriously doubt that a network admin could not figure out what
inetaddress meant, or even address for that fact.  I also think its not
smart to go renaming Tomcat concepts...just because.  I don't view this as
the Tomcat plans as being misleading, they are using the Tomcat terms and
concepts (and objects).  The last thing I want to do is go renaming Tomcat
objects...that makes little sense.  
I am simply asking that we use a term that is not as ambiguous.  In Tomcat
land, they use the word "address" on the Connectors.  Host is referenced
throughout the plans and refers to a Host Tomcat object and a Host GBean. this point, this should not impact existing users...this is more of
an issue with the management API going in for the console.  I would think
the impact is quite minimal at this stage in the game.  Thats also not to
say that we cannot use the word "host" unofficially (undocumented) and allow
the word "address" as the official version...thus having no impact on
current users.
This is really simple folks, this does not need a huge decision and long
thread. (hint-hint).  At worst case, we can use "host" as the attribute.
Its easy to change the connectors now...but if we wait, we will be stuck.
Lets just be pragmatic about this.


From: [] 
Sent: Monday, August 22, 2005 6:51 PM
Subject: Re: Network Properties & Naming

Jeff Genender <> wrote on 23/08/2005 07:14:48 AM:

> I am for anything but the word "host".  This will definately cause 
> confusion.  I think "address" or "inetaddress" would be fine. 

I am wondering whether people who are not Java developers (and therefore not
familiar with the capabilities of the InetAddress class) will be configuring
the network configuration (e.g. when a system is moved into production).
Will they be asking us, why is it called "inetaddress" instead of host? 

What names should we be using for properties where the value can only be an
IP address (not a name)?  I think this is the case with the allowHosts
attribute in j2ee-server-plan.xml? 

Can we change the names in the Tomcat plans to be less misleading (e.g.
instead of using host to refer to a Tomcat host, call it tomcathost)? Tomcat
is only one of many services that will run on Geronimo that will require
network configuration?  The change to the Tomcat configuration should have
minimal impact to existing users since we haven't released a Tomcat enabled
Geronimo yet, as M5 was intended to be the first Tomcat enabled release. 

We should document any naming recommendations we come up with on the Wiki
for others writing GBeans. 


> Jeff
> Aaron Mulder wrote:
> > So we have 3 properties for every network connector.  They are probably
> > most clearly described by using the analogous objects:
> > 
> > InetAddress -- the hostname or IP to listen on, settable
> > port -- the port to listen on, settable
> > InetSocketAddress -- the combination of the previous two, read-only
> >   based on their settings
> > 
> > Right now, we use the property names (respectively):
> > 
> > "host" (String, for a host name or IP)
> > "port" (int)
> > "listenAddress" (InetSocketAddress)
> > 
> > So for any network listener, you configure the host and port, they 
> > typically get injected into the constructor of the GBean in question,
> > then at runtime you can get the host, port, or listenAddress 
> > (combination).  We like using the simple String and int for the settable

> > properties, to make the management interface simple.
> > 
> > Jeff's raised the concern that the name "host" might be misleading in
> > Tomcat, where there's already a well-known "Host" object with a name, so
> > it might not be clear what the "host" property is supposed to refer to.

> > I guess we could change our properties to "address", "port", and
> > "listenAddress", or "listenAddress", "port", and "socketAddress".
> > 
> > Also, originally, the InetSocketAddress property was in there so we
> > distinguish any network-related GBeans in order to show the list during
> > the startup sequence.  That's no longer needed since we can now search
> > interface instead.  So we might drop that property.  But it could also
> > useful to keep it and ask for it to represent the "current listen
> > so if you change the port in the management console the "port" property
> > might show the new port, but the "InetSocketAddress" property would show
> > the old port until the connector was restarted.
> > 
> > Any thoughts on whether it's worth changing these properties and what
> > should be changed to?
> > 
> > Thanks,
> >    Aaron

This e-mail message and any attachments may contain confidential,
proprietary or non-public information.  This information is intended solely
for the designated recipient(s).  If an addressing or transmission error has
misdirected this e-mail, please notify the sender immediately and destroy
this e-mail.  Any review, dissemination, use or reliance upon this
information by unintended recipients is prohibited.  Any opinions expressed
in this e-mail are those of the author personally. 

View raw message