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:09:57 GMT

More to add here.  "Host" is a misnomer for the connectors in Tomcat.  They
will not accept a "host" must be an ip address.  So I think "adress" is
most approppriate.



	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
		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
		> > 
		> > 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, and 
		> > then at runtime you can get the host, port, or
		> > (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
		> > 
		> > Also, originally, the InetSocketAddress property was in
there so we could
		> > 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 by
		> > interface instead.  So we might drop that property.  But
it could also be
		> > useful to keep it and ask for it to represent the
"current listen state",
		> > 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 they
		> > 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