Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 43772 invoked from network); 24 Aug 2005 20:56:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Aug 2005 20:56:34 -0000 Received: (qmail 28836 invoked by uid 500); 24 Aug 2005 20:56:31 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 28797 invoked by uid 500); 24 Aug 2005 20:56:31 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 28783 invoked by uid 99); 24 Aug 2005 20:56:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2005 13:56:31 -0700 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.136.173.31] (HELO smtp011.mail.yahoo.com) (216.136.173.31) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 24 Aug 2005 13:56:47 -0700 Received: (qmail 58974 invoked from network); 24 Aug 2005 20:56:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=kV4j29R2IBalyheP3VotXscqhEFUn3xz6mzNfKyahb6gL4u/0jAH1L4ZUBznrdOiQHNhz+C85onrA+wRmzWz3enn6pEh7Y8NViULvRnr6+/K65Q60rksN2VHGYgMrWRCLGSFTq5Io7qd28dqsl4NJfw1ysptMgFVqwa9tOwxYwk= ; Received: from unknown (HELO ?192.168.1.105?) (david?jencks@66.93.38.137 with plain) by smtp011.mail.yahoo.com with SMTP; 24 Aug 2005 20:56:27 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <430CDC18.9010307@earthlink.net> References: <05224bfa3a977cc51ff1d29fd7b380e8@yahoo.com> <430CDC18.9010307@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <210a85fe4180890cfe3fc1300099d751@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: User Configuration of ports, etc. Date: Wed, 24 Aug 2005 13:56:22 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.622) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> localhost >>>>>> 8080 >>>>>> 8443 >>>>>> >>>>>> >>>>>> localhost >>>>>> 8443 >>>>>> >>>>>> >>>>>> localhost >>>>>> 8080 >>>>>> 8443 >>>>>> >>>>>> >>>>>> localhost >>>>>> 8009 >>>>>> 8443 >>>>>> >>>>>> >>>>>> localhost >>>>>> 8443 >>>>>> >>>>>> >>>>>> localhost >>>>>> 4201 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> localhost >>>>>> 61616 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> localhost >>>>>> 1527 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >