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.
