I have to try it...I am going off of the doco on the Tomcat web: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/http.html
But it definitely doesn't hurt to try ;-) Jeff > -----Original Message----- > From: Aaron Mulder [mailto:[EMAIL PROTECTED] > Sent: Monday, August 22, 2005 7:49 PM > To: [email protected] > Subject: RE: Network Properties & Naming > > 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. > > > > > > > > > > >
