You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/08/22 23:09:03 UTC
Network Properties & Naming
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
Re: Network Properties & Naming
Posted by Dain Sundstrom <da...@iq80.com>.
+1 These are my sentiments as well.
-dain
On Aug 22, 2005, at 7:31 PM, Aaron Mulder wrote:
> I disagree -- I think it's important to have a common management
> interface (currently, for example, NetworkConnector), and having
> the same
> properties called something different in every networkable GBean
> totally
> defeats that.
>
> Aaron
>
> On Mon, 22 Aug 2005, Jeremy Boynes wrote:
>
>> Jeff Genender wrote:
>>
>>>
>>> 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.
>>>
>>>
>>
>> Sounds to me that Tomcat users have one set of terms, Jetty users
>> another, and who knows what other people use.
>>
>> Rather that trying to pick one name for all which pleases none, we
>> should let each container configuration use terms familiar to its
>> users.
>> That way people who want Tomcat see things Tomcat-esque and people
>> who
>> want Jetty see Jetty-esque names.
>>
>> This should apply to all naming: the container configuration, the
>> connectors/listeners, the deployment plans, the console, ...
>>
>> --
>> Jeremy
>>
>
Re: Network Properties & Naming
Posted by Jeff Genender <jg...@savoirtech.com>.
Joe Bohn wrote:
> I agree with Jeremy. One other aspect to consider is that technology
> is constantly changing. If we settle on terminology today that isn't
> confusing for either tomcat or jetty that doesn't mean that it won't
> cause confusion for container X in the future. We will never be able
> to pick terms that are generic for all time, all containers, all
> components. I think attempting to come up with some common terminology
> will also be confusing to the user and will make it difficult to explain
> concepts that are similar or very different between containers.
> If we do end up with some common mapping, then I think we need to pick
> the most obvious terminology for the user.
Bingo. Lets pick the appropriate term now. Its 1 single term that is
in question here. This should be a simple resolution and does not need
endless debate. The Tomcat integration, in particular, the connector
has had many terms changed for Geronimo. Only 1 causes confusion. Why
is this an issue to change this one term? It is explained more clearly
below why I think this need changing.
> Most users will consider
> "host" to be the IP host name and so I think we should use that term in
> general and cover the appropriate mapping to tomcat or jetty in
> documentation.
Sorry, but I think this is an opinionated statement without any merit.
It's a simple fact that the host is mapped to an ip address, not the
address itself.
Per Webopeodia: http://www.webopedia.com/TERM/h/host.html
"A computer that is connected to a TCP/IP network, including the
Internet. Each host has a unique IP address."
Per The Telecom Glossary: http://www.atis.org/tg2k/_host_address.html it
states...
The definition of host is "A fully qualified domain name (usually
alphabetic) identifying the address of one specific host computer on the
Internet."
So I do not agree with your statement that 'Most users will consider
"host" to be the IP.' You are also alienating those who use Tomcat that
their definition of a "host" coincides with your opinion, which again,
is simply incorrect.
>The user will have to coordinate settings between many
> different elements and using common terms will make that much easier
> than avoiding those terms because they bring specific meaning to some
> particular component.
Geronimo is a conglomeration of different technologies. I see no
problem with trying our best to carry out the best in naming conventions
and not cross define/name terms. Now is the time to use best-practice
naming conventions. Again, I do not see why this is a problem,
especially at a point that its feasible to change. I must point out
that "host" is what is in question...and this will be terribly confusing
with how a Host is utilized in a Tomcat configuration. We need to be
sensitive to this for those users coming to use Geronimo from Tomcat.
This may help clarify...
o.a.t.Host - The Host object...the attribute "name" is the DNS resolved
name of the host.
o.a.t.Engine - contains a defaultHost paramater that is mandatory. The
defaultHost *must* match a DNS Host named object.
o.a.t.Connector - has a parameter named "address". This is mapped to
the physical or logical *IP ADDRESS* to which to listen on for handling
requests. It is not a host.
Geronimo connector wants to use "host" for the address. Understand that
the connectors are configured in the j2ee-server-plan.xml file (or
tomcat-conig.xml in the source code). Understand the confusion this
will cause when Tomcat is using the word "host" or a subset of the word
"host" in its configuration, and the the connector definition of a host
is completely different.
Why is this an issue that we cannot use a generic term such as "address"
or "inetaddress" or anything else that does not use the term "host"?
Understand the implication of this.
> Joe
>
> Jeremy Boynes wrote:
>
>> Aaron Mulder wrote:
>>
>>> I disagree -- I think it's important to have a common management
>>> interface (currently, for example, NetworkConnector), and having the
>>> same properties called something different in every networkable GBean
>>> totally defeats that.
>>>
>>
>> I agree a common management interface is desirable. Unfortunately the
>> containers we are integrating appear to have little in common. From
>> what I hear Jeff saying, apparently simple concepts like "host" differ.
>>
>> What this means is that we will need substantial extensions to the
>> "common" interface to deal with these container specific concepts; the
>> lowest common denominator is proving to be too low.
>>
>> This does mean more work for us: alternative deployment
>> infrastructure, alternative management APIs, multiple management
>> portlets, and so on. However, it provides a simple and more intuitive
>> interface for the user so should be done.
>>
>> --
>> Jeremy
>>
>>
>
Re: Network Properties & Naming
Posted by Joe Bohn <jo...@earthlink.net>.
I agree with Jeremy. One other aspect to consider is that technology
is constantly changing. If we settle on terminology today that isn't
confusing for either tomcat or jetty that doesn't mean that it won't
cause confusion for container X in the future. We will never be able
to pick terms that are generic for all time, all containers, all
components. I think attempting to come up with some common terminology
will also be confusing to the user and will make it difficult to explain
concepts that are similar or very different between containers.
If we do end up with some common mapping, then I think we need to pick
the most obvious terminology for the user. Most users will consider
"host" to be the IP host name and so I think we should use that term in
general and cover the appropriate mapping to tomcat or jetty in
documentation. The user will have to coordinate settings between many
different elements and using common terms will make that much easier
than avoiding those terms because they bring specific meaning to some
particular component.
Joe
Jeremy Boynes wrote:
> Aaron Mulder wrote:
>
>> I disagree -- I think it's important to have a common management
>> interface (currently, for example, NetworkConnector), and having the
>> same properties called something different in every networkable GBean
>> totally defeats that.
>>
>
> I agree a common management interface is desirable. Unfortunately the
> containers we are integrating appear to have little in common. From
> what I hear Jeff saying, apparently simple concepts like "host" differ.
>
> What this means is that we will need substantial extensions to the
> "common" interface to deal with these container specific concepts; the
> lowest common denominator is proving to be too low.
>
> This does mean more work for us: alternative deployment
> infrastructure, alternative management APIs, multiple management
> portlets, and so on. However, it provides a simple and more intuitive
> interface for the user so should be done.
>
> --
> Jeremy
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Network Properties & Naming
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> I disagree -- I think it's important to have a common management
> interface (currently, for example, NetworkConnector), and having the same
> properties called something different in every networkable GBean totally
> defeats that.
>
I agree a common management interface is desirable. Unfortunately the
containers we are integrating appear to have little in common. From what
I hear Jeff saying, apparently simple concepts like "host" differ.
What this means is that we will need substantial extensions to the
"common" interface to deal with these container specific concepts; the
lowest common denominator is proving to be too low.
This does mean more work for us: alternative deployment infrastructure,
alternative management APIs, multiple management portlets, and so on.
However, it provides a simple and more intuitive interface for the user
so should be done.
--
Jeremy
Re: Network Properties & Naming
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I disagree -- I think it's important to have a common management
interface (currently, for example, NetworkConnector), and having the same
properties called something different in every networkable GBean totally
defeats that.
Aaron
On Mon, 22 Aug 2005, Jeremy Boynes wrote:
> Jeff Genender wrote:
> >
> > 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.
> >
>
> Sounds to me that Tomcat users have one set of terms, Jetty users
> another, and who knows what other people use.
>
> Rather that trying to pick one name for all which pleases none, we
> should let each container configuration use terms familiar to its users.
> That way people who want Tomcat see things Tomcat-esque and people who
> want Jetty see Jetty-esque names.
>
> This should apply to all naming: the container configuration, the
> connectors/listeners, the deployment plans, the console, ...
>
> --
> Jeremy
>
Re: Network Properties & Naming
Posted by Jeremy Boynes <jb...@apache.org>.
Jeff Genender wrote:
>
> 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.
>
Sounds to me that Tomcat users have one set of terms, Jetty users
another, and who knows what other people use.
Rather that trying to pick one name for all which pleases none, we
should let each container configuration use terms familiar to its users.
That way people who want Tomcat see things Tomcat-esque and people who
want Jetty see Jetty-esque names.
This should apply to all naming: the container configuration, the
connectors/listeners, the deployment plans, the console, ...
--
Jeremy
Re: Network Properties & Naming
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 22, 2005, at 6:03 PM, Jeff Genender wrote:
> 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.
+1
Who really cares if it is host, address, ipaddress or whatever as
long as it is consistent and not confusing? Jeff says host will be
confusing to tomcat users, so let's throw that one out an pick another.
Pragmatically,
-dain
RE: Network Properties & Naming
Posted by Jeff Genender <jg...@savoirtech.com>.
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:ammulder@alumni.princeton.edu]
> Sent: Monday, August 22, 2005 7:49 PM
> To: dev@geronimo.apache.org
> 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: sissonj@insession.com
> [mailto:sissonj@insession.com]
> > Sent: Monday, August 22, 2005 6:51 PM
> > To: dev@geronimo.apache.org
> > Subject: Re: Network Properties & Naming
> >
> >
> >
> > Jeff Genender <jg...@savoirtech.com> 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.
> >
> >
> >
> >
> >
>
RE: Network Properties & Naming
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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: sissonj@insession.com [mailto:sissonj@insession.com]
> Sent: Monday, August 22, 2005 6:51 PM
> To: dev@geronimo.apache.org
> Subject: Re: Network Properties & Naming
>
>
>
> Jeff Genender <jg...@savoirtech.com> 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.
>
>
>
>
>
RE: Network Properties & Naming
Posted by Jeff Genender <jg...@savoirtech.com>.
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: sissonj@insession.com [mailto:sissonj@insession.com]
Sent: Monday, August 22, 2005 6:51 PM
To: dev@geronimo.apache.org
Subject: Re: Network Properties & Naming
Jeff Genender <jg...@savoirtech.com> 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.
RE: Network Properties & Naming
Posted by Jeff Genender <jg...@savoirtech.com>.
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: sissonj@insession.com [mailto:sissonj@insession.com]
Sent: Monday, August 22, 2005 6:51 PM
To: dev@geronimo.apache.org
Subject: Re: Network Properties & Naming
Jeff Genender <jg...@savoirtech.com> 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.
Re: Network Properties & Naming
Posted by si...@insession.com.
Jeff Genender <jg...@savoirtech.com> 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.
Re: Network Properties & Naming
Posted by Jeff Genender <jg...@savoirtech.com>.
I am for anything but the word "host". This will definately cause
confusion. I think "address" or "inetaddress" would be fine.
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