Are you saying "localhost" doesn't work? Aaron
On Mon, 22 Aug 2005, Jeff Genender wrote: > More to add here. "Host" is a misnomer for the connectors in Tomcat. They > will not accept a "host"...it must be an ip address. So I think "adress" is > most approppriate. > > > Jeff > > ________________________________ > > > 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. > > And...at 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. > > Jeff > > > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 22, 2005 6:51 PM > To: [email protected] > Subject: Re: Network Properties & Naming > > > > Jeff Genender <[EMAIL PROTECTED]> 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. > > John > > > > > Jeff > > > > Aaron Mulder wrote: > > > So we have 3 properties for every network connector. > They are probably > > > most clearly described by using the analogous java.net > 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, and > > > 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 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. > > > > >
