You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/08/24 22:03:23 UTC
Re: User Configuration of ports, etc.
How far does this go? Could I add things rather than override?
Could I add GBeans? If changed dynamically after startup, are the
new values written out at shutdown?
geir
On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
> I have a change ready that lets us mark certain GBean attributes
> as "manageable", meaning that we expect the user be interested in
> potentially overriding that value. Then there's a service that tracks
> values for some or all of these manageable attributes, currently
> storing
> them in an XML file. So the end result is there's a plain text file
> (currently var/config/config.xml) that looks like the sample
> below. The
> idea is that the user could change any values in there by hand if they
> like, particularly for network ports that would otherwise conflict
> with
> something running on their machine.
>
> I'm looking for feedback on this. David J seemed to largely
> approve but wondered whether it would be better to store separate
> config
> files for each Configuration. I prefer having one unified config file
> because I think it's clearer and easier to edit and cust down on
> config
> file sprawl. Any comments would be appreciated.
>
> Thanks,
> Aaron
>
> <attributes>
> <configuration name="org/apache/geronimo/Server">
> <gbean name="JettyWebConnector">
> <attribute name="host">localhost</attribute>
> <attribute name="port">8080</attribute>
> <attribute name="redirectPort">8443</attribute>
> </gbean>
> <gbean name="JettySSLConnector">
> <attribute name="host">localhost</attribute>
> <attribute name="port">8443</attribute>
> </gbean>
> <gbean name="TomcatWebConnector">
> <attribute name="host">localhost</attribute>
> <attribute name="port">8080</attribute>
> <attribute name="redirectPort">8443</attribute>
> </gbean>
> <gbean name="TomcatAJPConnector">
> <attribute name="host">localhost</attribute>
> <attribute name="port">8009</attribute>
> <attribute name="redirectPort">8443</attribute>
> </gbean>
> <gbean name="JettySSLConnector">
> <attribute name="host">localhost</attribute>
> <attribute name="port">8443</attribute>
> </gbean>
> <gbean name="openejb:type=NetworkService,name=EJB">
> <attribute name="host">localhost</attribute>
> <attribute name="port">4201</attribute>
> </gbean>
> </configuration>
> <configuration name="org/apache/geronimo/ActiveMQServer">
> <gbean name="ActiveMQ.tcp.localhost.61616">
> <attribute name="host">localhost</attribute>
> <attribute name="port">61616</attribute>
> </gbean>
> </configuration>
> <configuration name="org/apache/geronimo/SystemDatabase">
> <gbean name="DerbyNetwork">
> <attribute name="host">localhost</attribute>
> <attribute name="port">1527</attribute>
> </gbean>
> </configuration>
> </attributes>
>
> Note: while this sample deals with network settings, we can include
> any
> attributes in here.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: User Configuration of ports, etc.
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 24, 2005, at 7:10 PM, David Jencks wrote:
> On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:
>> Excellent point. I think that shipping an experimental
>> configuration system as the default is bit risky. As a long term
>> idea, I think that a binary configuration system would be a good
>> option, but I think in the near term we should focus providing a
>> tried an true text based configuration system as the default.
>>
>> Now the big question: Is can we deliver a text based configuration
>> system before 1.0 or should we expand on Aaron's configuration
>> overrider to fill in the gap?
>>
>
> umm, it seems to me that you are twisting reality here a little
> bit :-) I think using anything other than the existing known-to-
> work-although-sometimes-a-pain immutable binary configuration
> system we have been using for a year+ is way too risky for 1.0.
um... We don't have any one seriously using Geronimo, so no one
knows if it really will work. I and others have complained that it
doesn't even work well during development. Anyway, I just want to go
on the record to say that the binary configurations as they stand
don't work, so when we get users and they start complaining I can say
"I told you so" :)
> Getting the very limited config db idea to work for a limited set
> of easy to change attributes should eliminate much of the
> unbearable pain of e.g. not being able to change the ports without
> excessive risk, I hope. If not, I'm willing to live with not being
> able to change ports.
You're kidding? Right? There isn't a server out there that you can't
change the ports.
> A text based configuration system is not possible IMO with the
> current state of gbeans, where we have lots of complex attributes
> that really need to be serialized. If we had nested gbeans or
> their equivalent a couple months ago I would be much happier with
> the idea of text based gbeandata serialization in the configurations.
I agree this it would be difficult. I think we would be better off
spending the time to develop a really good configuration overrider as
stop gap.
-dain
Re: User Configuration of ports, etc.
Posted by David Blevins <da...@visi.com>.
On Aug 24, 2005, at 7:10 PM, David Jencks wrote:
>
> On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:
>
>>
>> Excellent point. I think that shipping an experimental
>> configuration system as the default is bit risky. As a long term
>> idea, I think that a binary configuration system would be a good
>> option, but I think in the near term we should focus providing a
>> tried an true text based configuration system as the default.
>>
>> Now the big question: Is can we deliver a text based configuration
>> system before 1.0 or should we expand on Aaron's configuration
>> overrider to fill in the gap?
>>
>
> umm, it seems to me that you are twisting reality here a little
> bit :-) I think using anything other than the existing known-to-
> work-although-sometimes-a-pain immutable binary configuration
> system we have been using for a year+ is way too risky for 1.0.
> Getting the very limited config db idea to work for a limited set
> of easy to change attributes should eliminate much of the
> unbearable pain of e.g. not being able to change the ports without
> excessive risk, I hope. If not, I'm willing to live with not being
> able to change ports.
>
> A text based configuration system is not possible IMO with the
> current state of gbeans, where we have lots of complex attributes
> that really need to be serialized. If we had nested gbeans or
> their equivalent a couple months ago I would be much happier with
> the idea of text based gbeandata serialization in the configurations.
>
I know a lot of this serialized configuration topic gets to changing
ports, but I want to go on record one more time and say that binary
configurations will not work for upgrades. It won't be till we
remove all details from our configurations that expose the inner-most
structure of classes that we will have the possibility to upgrade
without a complete redeploy.
As I've had this perspective for quite some time, I fault myself for
not breaking from mainline backing my opinion with code.
-David
Re: User Configuration of ports, etc.
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:
> On Aug 24, 2005, at 6:29 PM, David Jencks wrote:
>
>> On Aug 24, 2005, at 6:10 PM, Dain Sundstrom wrote:
>>
>>>>>>> Could I add things rather than override?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> No. You can do that in the console, but this file just lets
>>>>>> you
>>>>>> override certain attributes for GBeans that are already in the
>>>>>> server.
>>>>>> You'll notice in the sample there aren't full GBean definitions,
>>>>>> only what
>>>>>> amounts to attribute=value entries.
>>>>>>
>>>>>>
>>>>>
>>>>> Would anything stop you from doing that though?
>>>>>
>>>>>
>>>>
>>>> I would. The idea here is to allow a few attributes to be
>>>> customized locally even on a server with immutable configurations.
>>>> editing your configuration contents should use a different system.
>>>> Most attributes and all references will not be editable in this
>>>> config db.
>>>>
>>>
>>> I believe that this strategy is a bad idea. What is going to happen
>>> is every time we release the software, someone is going to want to
>>> tweak a setting that we either forgot to make manageable, or we
>>> wrongly believed shouldn't be managed. Why not make all attributes*
>>> manageable?
>>>
>>
>> I think perhaps ones point of view on this argument has something to
>> do with whether one thinks small versioned binary configurations
>> should be the basic unit of distributing and building a server. If
>> you think that versioned binary configurations basically won't work,
>> then there is no reason to ever inhibit any editing of any
>> configurations, ever, since each server has no discernable
>> relationship to any other server. If you think versioned binary
>> configurations are the one true path, then you need some way to make
>> sure that the allowed modifications to a versioned binary
>> configuration are rather small and don't affect its' essential
>> character: otherwise the version stops meaning anything.
>>
>> Personally I would like to give versioned binary configurations a
>> good chance to see if we can make them work: I don't think we have
>> tried them yet, and if they can be made to work I think they will be
>> a really cool feature. I would prefer to see "arbitrary edits" take
>> place using something like the console or a special tool, and only on
>> unversioned mutable configurations.
>
> Excellent point. I think that shipping an experimental configuration
> system as the default is bit risky. As a long term idea, I think that
> a binary configuration system would be a good option, but I think in
> the near term we should focus providing a tried an true text based
> configuration system as the default.
>
> Now the big question: Is can we deliver a text based configuration
> system before 1.0 or should we expand on Aaron's configuration
> overrider to fill in the gap?
umm, it seems to me that you are twisting reality here a little bit :-)
I think using anything other than the existing
known-to-work-although-sometimes-a-pain immutable binary configuration
system we have been using for a year+ is way too risky for 1.0.
Getting the very limited config db idea to work for a limited set of
easy to change attributes should eliminate much of the unbearable pain
of e.g. not being able to change the ports without excessive risk, I
hope. If not, I'm willing to live with not being able to change ports.
A text based configuration system is not possible IMO with the current
state of gbeans, where we have lots of complex attributes that really
need to be serialized. If we had nested gbeans or their equivalent a
couple months ago I would be much happier with the idea of text based
gbeandata serialization in the configurations.
thanks
david jencks
>
> -dain
>
Re: User Configuration of ports, etc.
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 24, 2005, at 6:29 PM, David Jencks wrote:
> On Aug 24, 2005, at 6:10 PM, Dain Sundstrom wrote:
>
>>>>>> Could I add things rather than override?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> No. You can do that in the console, but this file just
>>>>> lets you
>>>>> override certain attributes for GBeans that are already in the
>>>>> server.
>>>>> You'll notice in the sample there aren't full GBean
>>>>> definitions, only what
>>>>> amounts to attribute=value entries.
>>>>>
>>>>>
>>>>
>>>> Would anything stop you from doing that though?
>>>>
>>>>
>>>
>>> I would. The idea here is to allow a few attributes to be
>>> customized locally even on a server with immutable
>>> configurations. editing your configuration contents should use a
>>> different system. Most attributes and all references will not be
>>> editable in this config db.
>>>
>>
>> I believe that this strategy is a bad idea. What is going to
>> happen is every time we release the software, someone is going to
>> want to tweak a setting that we either forgot to make manageable,
>> or we wrongly believed shouldn't be managed. Why not make all
>> attributes* manageable?
>>
>
> I think perhaps ones point of view on this argument has something
> to do with whether one thinks small versioned binary configurations
> should be the basic unit of distributing and building a server. If
> you think that versioned binary configurations basically won't
> work, then there is no reason to ever inhibit any editing of any
> configurations, ever, since each server has no discernable
> relationship to any other server. If you think versioned binary
> configurations are the one true path, then you need some way to
> make sure that the allowed modifications to a versioned binary
> configuration are rather small and don't affect its' essential
> character: otherwise the version stops meaning anything.
>
> Personally I would like to give versioned binary configurations a
> good chance to see if we can make them work: I don't think we have
> tried them yet, and if they can be made to work I think they will
> be a really cool feature. I would prefer to see "arbitrary edits"
> take place using something like the console or a special tool, and
> only on unversioned mutable configurations.
Excellent point. I think that shipping an experimental configuration
system as the default is bit risky. As a long term idea, I think
that a binary configuration system would be a good option, but I
think in the near term we should focus providing a tried an true text
based configuration system as the default.
Now the big question: Is can we deliver a text based configuration
system before 1.0 or should we expand on Aaron's configuration
overrider to fill in the gap?
-dain
Re: User Configuration of ports, etc.
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2005, at 6:10 PM, Dain Sundstrom wrote:
>>>>> Could I add things rather than override?
>>>>>
>>>>>
>>>>
>>>> No. You can do that in the console, but this file just lets you
>>>> override certain attributes for GBeans that are already in the
>>>> server.
>>>> You'll notice in the sample there aren't full GBean definitions,
>>>> only what
>>>> amounts to attribute=value entries.
>>>>
>>>
>>> Would anything stop you from doing that though?
>>>
>>
>> I would. The idea here is to allow a few attributes to be customized
>> locally even on a server with immutable configurations. editing your
>> configuration contents should use a different system. Most
>> attributes and all references will not be editable in this config db.
>
> I believe that this strategy is a bad idea. What is going to happen
> is every time we release the software, someone is going to want to
> tweak a setting that we either forgot to make manageable, or we
> wrongly believed shouldn't be managed. Why not make all attributes*
> manageable?
I think perhaps ones point of view on this argument has something to do
with whether one thinks small versioned binary configurations should be
the basic unit of distributing and building a server. If you think
that versioned binary configurations basically won't work, then there
is no reason to ever inhibit any editing of any configurations, ever,
since each server has no discernable relationship to any other server.
If you think versioned binary configurations are the one true path,
then you need some way to make sure that the allowed modifications to a
versioned binary configuration are rather small and don't affect its'
essential character: otherwise the version stops meaning anything.
Personally I would like to give versioned binary configurations a good
chance to see if we can make them work: I don't think we have tried
them yet, and if they can be made to work I think they will be a really
cool feature. I would prefer to see "arbitrary edits" take place using
something like the console or a special tool, and only on unversioned
mutable configurations.
thanks
david jencks
>
> -dain
>
> * Of course a user could not set a binary attribute but you get the
> idea.
>
Re: User Configuration of ports, etc.
Posted by Dain Sundstrom <da...@iq80.com>.
>>>> Could I add things rather than override?
>>>>
>>>>
>>>
>>> No. You can do that in the console, but this file just lets you
>>> override certain attributes for GBeans that are already in the
>>> server.
>>> You'll notice in the sample there aren't full GBean definitions,
>>> only what
>>> amounts to attribute=value entries.
>>>
>>
>> Would anything stop you from doing that though?
>>
>
> I would. The idea here is to allow a few attributes to be
> customized locally even on a server with immutable configurations.
> editing your configuration contents should use a different system.
> Most attributes and all references will not be editable in this
> config db.
I believe that this strategy is a bad idea. What is going to happen
is every time we release the software, someone is going to want to
tweak a setting that we either forgot to make manageable, or we
wrongly believed shouldn't be managed. Why not make all attributes*
manageable?
-dain
* Of course a user could not set a binary attribute but you get the
idea.
Re: User Configuration of ports, etc.
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2005, at 1:44 PM, Joe Bohn wrote:
>
>
> David Jencks wrote:
>
>>
>> On Aug 24, 2005, at 1:11 PM, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Aug 24, 2005, at 4:21 PM, Aaron Mulder wrote:
>>>
>>>> On Wed, 24 Aug 2005, Geir Magnusson Jr. wrote:
>>>>
>>>>> How far does this go?
>>>>>
>>>>
>>>> 3.2 miles.
>>>
>>>
>>> A full 5K!
>>>
>>>>
>>>>
>>>>> Could I add things rather than override?
>>>>>
>>>>
>>>> No. You can do that in the console, but this file just lets you
>>>> override certain attributes for GBeans that are already in the
>>>> server.
>>>> You'll notice in the sample there aren't full GBean definitions,
>>>> only what
>>>> amounts to attribute=value entries.
>>>
>>>
>>> Would anything stop you from doing that though?
>>
>>
>> I would. The idea here is to allow a few attributes to be customized
>> locally even on a server with immutable configurations. editing your
>> configuration contents should use a different system. Most
>> attributes and all references will not be editable in this config db.
>
> I think that we should keep the limitations of what you can and cannot
> modify dynamically consistent then. Aaron indicated above that you
> could add attributes via the console but not the file. Based on this
> position we should not allow the attribute additions via the console
> either.
Well, my position is that you should normally modify the plan to
add/remove gbeans or change references. However, Aaron and I think
others want there to be a mode for some mutable, "Snapshot"
configurations where you can edit anything in the configuration while
running. I don't think the existence of this "interactive development"
mode should affect the functionality of the config database intended
for production use. In other words, I disagree :-)
>
>>>
>>>>
>>>>
>>>>> Could I add GBeans?
>>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>>>> If changed dynamically after startup, are the new values written
>>>>> out at
>>>>> shutdown?
>>>>>
>>>>
>>>> Yes.
>>>
>>>
>>> Boy howdy! To the XML, or to the binary?
>>
>>
>> to the xml. I think this should replace re-saving the configuration
>> binary for stable configurations.
>
> A related question would be "Are value changes in the file reflected
> in the running server if changed while the server is active?" I
> know it's not exactly the same thing ... but that's the way the log
> configurations are handled. I don't necessarily agree with that
> approach but I think we should be consistent for the sake (sanity) of
> the user.
I suggest we handle this by filing an enhancement request to find a
different way of updating log configurations other than changing the
file they are in. I don't think we want to get into the headache of
trying to notice external db changes and importing them.
thanks
david jencks
>
>>
>> david jencks
>>
>>>
>>>>
>>>> Aaron
>>>>
>>>>
>>>>> On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
>>>>>
>>>>>
>>>>>> I have a change ready that lets us mark certain GBean
>>>>>> attributes
>>>>>> as "manageable", meaning that we expect the user be interested in
>>>>>> potentially overriding that value. Then there's a service that
>>>>>> tracks
>>>>>> values for some or all of these manageable attributes, currently
>>>>>> storing
>>>>>> them in an XML file. So the end result is there's a plain text
>>>>>> file
>>>>>> (currently var/config/config.xml) that looks like the sample
>>>>>> below. The
>>>>>> idea is that the user could change any values in there by hand if
>>>>>> they
>>>>>> like, particularly for network ports that would otherwise conflict
>>>>>> with
>>>>>> something running on their machine.
>>>>>>
>>>>>> I'm looking for feedback on this. David J seemed to largely
>>>>>> approve but wondered whether it would be better to store separate
>>>>>> config
>>>>>> files for each Configuration. I prefer having one unified config
>>>>>> file
>>>>>> because I think it's clearer and easier to edit and cust down on
>>>>>> config
>>>>>> file sprawl. Any comments would be appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>> Aaron
>>>>>>
>>>>>> <attributes>
>>>>>> <configuration name="org/apache/geronimo/Server">
>>>>>> <gbean name="JettyWebConnector">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">8080</attribute>
>>>>>> <attribute name="redirectPort">8443</attribute>
>>>>>> </gbean>
>>>>>> <gbean name="JettySSLConnector">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">8443</attribute>
>>>>>> </gbean>
>>>>>> <gbean name="TomcatWebConnector">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">8080</attribute>
>>>>>> <attribute name="redirectPort">8443</attribute>
>>>>>> </gbean>
>>>>>> <gbean name="TomcatAJPConnector">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">8009</attribute>
>>>>>> <attribute name="redirectPort">8443</attribute>
>>>>>> </gbean>
>>>>>> <gbean name="JettySSLConnector">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">8443</attribute>
>>>>>> </gbean>
>>>>>> <gbean name="openejb:type=NetworkService,name=EJB">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">4201</attribute>
>>>>>> </gbean>
>>>>>> </configuration>
>>>>>> <configuration name="org/apache/geronimo/ActiveMQServer">
>>>>>> <gbean name="ActiveMQ.tcp.localhost.61616">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">61616</attribute>
>>>>>> </gbean>
>>>>>> </configuration>
>>>>>> <configuration name="org/apache/geronimo/SystemDatabase">
>>>>>> <gbean name="DerbyNetwork">
>>>>>> <attribute name="host">localhost</attribute>
>>>>>> <attribute name="port">1527</attribute>
>>>>>> </gbean>
>>>>>> </configuration>
>>>>>> </attributes>
>>>>>>
>>>>>> Note: while this sample deals with network settings, we can
>>>>>> include
>>>>>> any
>>>>>> attributes in here.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Geir Magnusson Jr +1-203-665-6437
>>>>> geirm@apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org
>>>
>>>
>>
>>
>>
>
> --
> 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: User Configuration of ports, etc.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 24 Aug 2005, Joe Bohn wrote:
> > I would. The idea here is to allow a few attributes to be customized
> > locally even on a server with immutable configurations. editing your
> > configuration contents should use a different system. Most attributes
> > and all references will not be editable in this config db.
>
> I think that we should keep the limitations of what you can and cannot
> modify dynamically consistent then. Aaron indicated above that you
> could add attributes via the console but not the file. Based on this
> position we should not allow the attribute additions via the console either.
At such a time as we're able to mark a configuration as immutable,
you would not be able to change an immutable configuration through the
console (at least, not while keeping it in the immutable state). On the
other hand, you would want to change mutable configurations, so you can
get them into a state you're satisfied with in order to mark them as
immutable. In either case, you'll be able to override things like ports
(using this mechanism, or the console which could hook in to this
mechanism), because even with an immutable configuration you might want to
run two instances on the same box where the ports would otherwise conflict
with each other. But the immutable flag is tied up with things like
configuration versioning, and still barely on the implementation radar. :)
Aaron
Re: User Configuration of ports, etc.
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
>
> On Aug 24, 2005, at 1:11 PM, Geir Magnusson Jr. wrote:
>
>>
>> On Aug 24, 2005, at 4:21 PM, Aaron Mulder wrote:
>>
>>> On Wed, 24 Aug 2005, Geir Magnusson Jr. wrote:
>>>
>>>> How far does this go?
>>>>
>>>
>>> 3.2 miles.
>>
>>
>> A full 5K!
>>
>>>
>>>
>>>> Could I add things rather than override?
>>>>
>>>
>>> No. You can do that in the console, but this file just lets you
>>> override certain attributes for GBeans that are already in the server.
>>> You'll notice in the sample there aren't full GBean definitions,
>>> only what
>>> amounts to attribute=value entries.
>>
>>
>> Would anything stop you from doing that though?
>
>
> I would. The idea here is to allow a few attributes to be customized
> locally even on a server with immutable configurations. editing your
> configuration contents should use a different system. Most attributes
> and all references will not be editable in this config db.
I think that we should keep the limitations of what you can and cannot
modify dynamically consistent then. Aaron indicated above that you
could add attributes via the console but not the file. Based on this
position we should not allow the attribute additions via the console either.
>>
>>>
>>>
>>>> Could I add GBeans?
>>>>
>>>
>>> See above.
>>>
>>>
>>>> If changed dynamically after startup, are the new values written
>>>> out at
>>>> shutdown?
>>>>
>>>
>>> Yes.
>>
>>
>> Boy howdy! To the XML, or to the binary?
>
>
> to the xml. I think this should replace re-saving the configuration
> binary for stable configurations.
A related question would be "Are value changes in the file reflected in
the running server if changed while the server is active?" I know
it's not exactly the same thing ... but that's the way the log
configurations are handled. I don't necessarily agree with that
approach but I think we should be consistent for the sake (sanity) of
the user.
>
> david jencks
>
>>
>>>
>>> Aaron
>>>
>>>
>>>> On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
>>>>
>>>>
>>>>> I have a change ready that lets us mark certain GBean attributes
>>>>> as "manageable", meaning that we expect the user be interested in
>>>>> potentially overriding that value. Then there's a service that
>>>>> tracks
>>>>> values for some or all of these manageable attributes, currently
>>>>> storing
>>>>> them in an XML file. So the end result is there's a plain text file
>>>>> (currently var/config/config.xml) that looks like the sample
>>>>> below. The
>>>>> idea is that the user could change any values in there by hand if
>>>>> they
>>>>> like, particularly for network ports that would otherwise conflict
>>>>> with
>>>>> something running on their machine.
>>>>>
>>>>> I'm looking for feedback on this. David J seemed to largely
>>>>> approve but wondered whether it would be better to store separate
>>>>> config
>>>>> files for each Configuration. I prefer having one unified config
>>>>> file
>>>>> because I think it's clearer and easier to edit and cust down on
>>>>> config
>>>>> file sprawl. Any comments would be appreciated.
>>>>>
>>>>> Thanks,
>>>>> Aaron
>>>>>
>>>>> <attributes>
>>>>> <configuration name="org/apache/geronimo/Server">
>>>>> <gbean name="JettyWebConnector">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">8080</attribute>
>>>>> <attribute name="redirectPort">8443</attribute>
>>>>> </gbean>
>>>>> <gbean name="JettySSLConnector">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">8443</attribute>
>>>>> </gbean>
>>>>> <gbean name="TomcatWebConnector">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">8080</attribute>
>>>>> <attribute name="redirectPort">8443</attribute>
>>>>> </gbean>
>>>>> <gbean name="TomcatAJPConnector">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">8009</attribute>
>>>>> <attribute name="redirectPort">8443</attribute>
>>>>> </gbean>
>>>>> <gbean name="JettySSLConnector">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">8443</attribute>
>>>>> </gbean>
>>>>> <gbean name="openejb:type=NetworkService,name=EJB">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">4201</attribute>
>>>>> </gbean>
>>>>> </configuration>
>>>>> <configuration name="org/apache/geronimo/ActiveMQServer">
>>>>> <gbean name="ActiveMQ.tcp.localhost.61616">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">61616</attribute>
>>>>> </gbean>
>>>>> </configuration>
>>>>> <configuration name="org/apache/geronimo/SystemDatabase">
>>>>> <gbean name="DerbyNetwork">
>>>>> <attribute name="host">localhost</attribute>
>>>>> <attribute name="port">1527</attribute>
>>>>> </gbean>
>>>>> </configuration>
>>>>> </attributes>
>>>>>
>>>>> Note: while this sample deals with network settings, we can include
>>>>> any
>>>>> attributes in here.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Geir Magnusson Jr +1-203-665-6437
>>>> geirm@apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>
>
>
--
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: User Configuration of ports, etc.
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2005, at 1:11 PM, Geir Magnusson Jr. wrote:
>
> On Aug 24, 2005, at 4:21 PM, Aaron Mulder wrote:
>
>> On Wed, 24 Aug 2005, Geir Magnusson Jr. wrote:
>>
>>> How far does this go?
>>>
>>
>> 3.2 miles.
>
> A full 5K!
>
>>
>>
>>> Could I add things rather than override?
>>>
>>
>> No. You can do that in the console, but this file just lets you
>> override certain attributes for GBeans that are already in the server.
>> You'll notice in the sample there aren't full GBean definitions, only
>> what
>> amounts to attribute=value entries.
>
> Would anything stop you from doing that though?
I would. The idea here is to allow a few attributes to be customized
locally even on a server with immutable configurations. editing your
configuration contents should use a different system. Most attributes
and all references will not be editable in this config db.
>
>>
>>
>>> Could I add GBeans?
>>>
>>
>> See above.
>>
>>
>>> If changed dynamically after startup, are the new values written out
>>> at
>>> shutdown?
>>>
>>
>> Yes.
>
> Boy howdy! To the XML, or to the binary?
to the xml. I think this should replace re-saving the configuration
binary for stable configurations.
david jencks
>
>>
>> Aaron
>>
>>
>>> On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
>>>
>>>
>>>> I have a change ready that lets us mark certain GBean attributes
>>>> as "manageable", meaning that we expect the user be interested in
>>>> potentially overriding that value. Then there's a service that
>>>> tracks
>>>> values for some or all of these manageable attributes, currently
>>>> storing
>>>> them in an XML file. So the end result is there's a plain text file
>>>> (currently var/config/config.xml) that looks like the sample
>>>> below. The
>>>> idea is that the user could change any values in there by hand if
>>>> they
>>>> like, particularly for network ports that would otherwise conflict
>>>> with
>>>> something running on their machine.
>>>>
>>>> I'm looking for feedback on this. David J seemed to largely
>>>> approve but wondered whether it would be better to store separate
>>>> config
>>>> files for each Configuration. I prefer having one unified config
>>>> file
>>>> because I think it's clearer and easier to edit and cust down on
>>>> config
>>>> file sprawl. Any comments would be appreciated.
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>> <attributes>
>>>> <configuration name="org/apache/geronimo/Server">
>>>> <gbean name="JettyWebConnector">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">8080</attribute>
>>>> <attribute name="redirectPort">8443</attribute>
>>>> </gbean>
>>>> <gbean name="JettySSLConnector">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">8443</attribute>
>>>> </gbean>
>>>> <gbean name="TomcatWebConnector">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">8080</attribute>
>>>> <attribute name="redirectPort">8443</attribute>
>>>> </gbean>
>>>> <gbean name="TomcatAJPConnector">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">8009</attribute>
>>>> <attribute name="redirectPort">8443</attribute>
>>>> </gbean>
>>>> <gbean name="JettySSLConnector">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">8443</attribute>
>>>> </gbean>
>>>> <gbean name="openejb:type=NetworkService,name=EJB">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">4201</attribute>
>>>> </gbean>
>>>> </configuration>
>>>> <configuration name="org/apache/geronimo/ActiveMQServer">
>>>> <gbean name="ActiveMQ.tcp.localhost.61616">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">61616</attribute>
>>>> </gbean>
>>>> </configuration>
>>>> <configuration name="org/apache/geronimo/SystemDatabase">
>>>> <gbean name="DerbyNetwork">
>>>> <attribute name="host">localhost</attribute>
>>>> <attribute name="port">1527</attribute>
>>>> </gbean>
>>>> </configuration>
>>>> </attributes>
>>>>
>>>> Note: while this sample deals with network settings, we can include
>>>> any
>>>> attributes in here.
>>>>
>>>>
>>>>
>>>
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: User Configuration of ports, etc.
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 24, 2005, at 4:21 PM, Aaron Mulder wrote:
> On Wed, 24 Aug 2005, Geir Magnusson Jr. wrote:
>
>> How far does this go?
>>
>
> 3.2 miles.
A full 5K!
>
>
>> Could I add things rather than override?
>>
>
> No. You can do that in the console, but this file just lets you
> override certain attributes for GBeans that are already in the server.
> You'll notice in the sample there aren't full GBean definitions,
> only what
> amounts to attribute=value entries.
Would anything stop you from doing that though?
>
>
>> Could I add GBeans?
>>
>
> See above.
>
>
>> If changed dynamically after startup, are the new values written
>> out at
>> shutdown?
>>
>
> Yes.
Boy howdy! To the XML, or to the binary?
>
> Aaron
>
>
>> On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
>>
>>
>>> I have a change ready that lets us mark certain GBean attributes
>>> as "manageable", meaning that we expect the user be interested in
>>> potentially overriding that value. Then there's a service that
>>> tracks
>>> values for some or all of these manageable attributes, currently
>>> storing
>>> them in an XML file. So the end result is there's a plain text file
>>> (currently var/config/config.xml) that looks like the sample
>>> below. The
>>> idea is that the user could change any values in there by hand if
>>> they
>>> like, particularly for network ports that would otherwise conflict
>>> with
>>> something running on their machine.
>>>
>>> I'm looking for feedback on this. David J seemed to largely
>>> approve but wondered whether it would be better to store separate
>>> config
>>> files for each Configuration. I prefer having one unified config
>>> file
>>> because I think it's clearer and easier to edit and cust down on
>>> config
>>> file sprawl. Any comments would be appreciated.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> <attributes>
>>> <configuration name="org/apache/geronimo/Server">
>>> <gbean name="JettyWebConnector">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">8080</attribute>
>>> <attribute name="redirectPort">8443</attribute>
>>> </gbean>
>>> <gbean name="JettySSLConnector">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">8443</attribute>
>>> </gbean>
>>> <gbean name="TomcatWebConnector">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">8080</attribute>
>>> <attribute name="redirectPort">8443</attribute>
>>> </gbean>
>>> <gbean name="TomcatAJPConnector">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">8009</attribute>
>>> <attribute name="redirectPort">8443</attribute>
>>> </gbean>
>>> <gbean name="JettySSLConnector">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">8443</attribute>
>>> </gbean>
>>> <gbean name="openejb:type=NetworkService,name=EJB">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">4201</attribute>
>>> </gbean>
>>> </configuration>
>>> <configuration name="org/apache/geronimo/ActiveMQServer">
>>> <gbean name="ActiveMQ.tcp.localhost.61616">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">61616</attribute>
>>> </gbean>
>>> </configuration>
>>> <configuration name="org/apache/geronimo/SystemDatabase">
>>> <gbean name="DerbyNetwork">
>>> <attribute name="host">localhost</attribute>
>>> <attribute name="port">1527</attribute>
>>> </gbean>
>>> </configuration>
>>> </attributes>
>>>
>>> Note: while this sample deals with network settings, we can include
>>> any
>>> attributes in here.
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: User Configuration of ports, etc.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 24 Aug 2005, Geir Magnusson Jr. wrote:
> How far does this go?
3.2 miles.
> Could I add things rather than override?
No. You can do that in the console, but this file just lets you
override certain attributes for GBeans that are already in the server.
You'll notice in the sample there aren't full GBean definitions, only what
amounts to attribute=value entries.
> Could I add GBeans?
See above.
> If changed dynamically after startup, are the new values written out at
> shutdown?
Yes.
Aaron
> On Aug 24, 2005, at 4:04 PM, Aaron Mulder wrote:
>
> > I have a change ready that lets us mark certain GBean attributes
> > as "manageable", meaning that we expect the user be interested in
> > potentially overriding that value. Then there's a service that tracks
> > values for some or all of these manageable attributes, currently
> > storing
> > them in an XML file. So the end result is there's a plain text file
> > (currently var/config/config.xml) that looks like the sample
> > below. The
> > idea is that the user could change any values in there by hand if they
> > like, particularly for network ports that would otherwise conflict
> > with
> > something running on their machine.
> >
> > I'm looking for feedback on this. David J seemed to largely
> > approve but wondered whether it would be better to store separate
> > config
> > files for each Configuration. I prefer having one unified config file
> > because I think it's clearer and easier to edit and cust down on
> > config
> > file sprawl. Any comments would be appreciated.
> >
> > Thanks,
> > Aaron
> >
> > <attributes>
> > <configuration name="org/apache/geronimo/Server">
> > <gbean name="JettyWebConnector">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">8080</attribute>
> > <attribute name="redirectPort">8443</attribute>
> > </gbean>
> > <gbean name="JettySSLConnector">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">8443</attribute>
> > </gbean>
> > <gbean name="TomcatWebConnector">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">8080</attribute>
> > <attribute name="redirectPort">8443</attribute>
> > </gbean>
> > <gbean name="TomcatAJPConnector">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">8009</attribute>
> > <attribute name="redirectPort">8443</attribute>
> > </gbean>
> > <gbean name="JettySSLConnector">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">8443</attribute>
> > </gbean>
> > <gbean name="openejb:type=NetworkService,name=EJB">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">4201</attribute>
> > </gbean>
> > </configuration>
> > <configuration name="org/apache/geronimo/ActiveMQServer">
> > <gbean name="ActiveMQ.tcp.localhost.61616">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">61616</attribute>
> > </gbean>
> > </configuration>
> > <configuration name="org/apache/geronimo/SystemDatabase">
> > <gbean name="DerbyNetwork">
> > <attribute name="host">localhost</attribute>
> > <attribute name="port">1527</attribute>
> > </gbean>
> > </configuration>
> > </attributes>
> >
> > Note: while this sample deals with network settings, we can include
> > any
> > attributes in here.
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>