Currently the config overhaul project is broken into 3+ tickets. 1. Create a .NET Config service that doesn't talk to anything
2. Modify .NET to communicate thru the config service 3. Upgrade config service to send its own endpoint address for lookup in the services table. 4. Create Config UI tab in clients and make any additional config service upgrades, etc None of these should break the build, but #1 is arguable not entirely useful without #2, so should #1 not get committed until #2 is completed as well? Also, my previous question was specifically geared towards implementing functionally for #4 in ticket #1. Is that jumping the gun? Should we leave it out until the time comes to work on #4? For the record my thoughts are that we should. -Ben -----Original Message----- From: Scott Golightly [mailto:[email protected]] Sent: Friday, June 12, 2009 5:52 PM To: Stonehenge Development Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service There is probably an already established precedence but my vote would be to only commit completed code. If I want to test the current code I can do so from the patch. Just my 2 cents. Scott Golightly > From: [email protected] > To: [email protected] > Date: Fri, 12 Jun 2009 17:30:53 -0400 > Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service > > In regards to the items needed in the future (ie set/get DbConfig): > > What's the procedure for commiting code that has two parts or planned > upgrades? > Should we avoid committing a bunch of commented-out code? > Should we just commit code that's directly applicable? > > -Ben > > > -----Original Message----- > From: Avantika Agrawal (JIRA) [mailto:[email protected]] > Sent: Friday, June 12, 2009 3:29 PM > To: [email protected] > Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service > > > [ > https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Avantika Agrawal updated STONEHENGE-66: > --------------------------------------- > > Attachment: Stonehenge-66.patch > > Here's what I have so far. > > You will find a new folder called Config_Service which hs the same structure > as the OrderProcessor_Service - it should have a ConfigServiceSolution > Also, there are some addtions made to the common folder - an IConfig > interface and its implementation. > > I am sticking with the format of the php. Ben, you may find that I changed > your contract very slightly, but this is in line with the php format so I > don't think it should be an issue. I have left comments in areas which still > need work. Moreover, I have not implemented setActiveDB, getDBConfig, and > other methos relating to DB configuration yet - I think we should come to > those later, once we have this service up and running. > > This service builds successfully but it is not running. I am getting a few > errors. Will update this when those are fixed, but for now, you guys can take > a look at what I've done so far and send me any feedback you may have. > > > > Create a .NET Config Service > > ---------------------------- > > > > Key: STONEHENGE-66 > > URL: https://issues.apache.org/jira/browse/STONEHENGE-66 > > Project: Stonehenge > > Issue Type: New Feature > > Reporter: Avantika Agrawal > > Priority: Minor > > Attachments: Stonehenge-66.patch > > > > > > Implement Ben's ConfigContract to create a configuration service attached > > to the .NET Client > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
