Hi, > -----Ursprüngliche Nachricht----- > Von: robert burrell donkin [mailto:[EMAIL PROTECTED] > Gesendet: Samstag, 20. Januar 2007 09:32 > An: James Developers List > Betreff: Re: [VOTE RESULT] InetAddress unbounded cache patch backport > > On 1/18/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > Norman Maurer wrote: > > > > > i put the property in the startup(....) method of > > > org.apache.avalon.phoenix.launcher.Main . This method get called of > each > > > entry point (Main, CommonsDameonLauncher, DaemonLauncher). > > > > Oh good ... so now JAMES functionality is going to depend upon a local > > modification to the container launching it? > > running in a container introduces a coupling of functionality to the > container
So are we going to have a 2.3 based release that ist o be run in another container? Did I miss something? > > Does anyone believe that's a > > maintainable solution, as we look at alternative runtime environments? > > but i definitely take your point: just doing this would be an > unmaintainable solution going forward I keeping backward compatibility to jdk <1.3 a good thing when someone wants to look forward? > > Please do NOT put this into trunk, since it is not necessary. Also, > keep in > > mind that the faux TTL hack, if used, ought to be configurable. > > it seems to me that the debate has become unnecessarily polarised > > IMO we're in danger of losing focus That was lost a long time ago. It is no objective discussion. It has never been. It is 2 parties, who are incapable of looking at the others viewpoint. That is sad! > we need to elect a release manager who can shepherd the release > through these difficult waters. we need to take a release branch ASAP > so the short term push towards a release can be separated from medium > term concerns about design and maintainability. Really? I suggested this a long time ago. But certain people did not want to do it. because of their own reasons. The Person that wanted to do it was flamed. That is sad! > releases are about those outside this circle of committers. for the > next release, we should think about them, set aside our disagreements > and do the right thing. see previous paragraph. > we should backport noel's fixes even if there design is less than > elegant. we should fix every startup script that we can in case any > calls have been missed even though this is an unmaintainable solution. > we should write clearly in the release notes that JAMES may be > effected by a known issue with some Sun JVMs causing memory leaks and > note the fix for those running in other environments. all this should > be done on the release branch. So you are suggesting to do both? What is the benefit of doing both? > but on trunk, we should implement the best medium term solution. this > means implementing noel's fixes in a more elegant fashion. I think it was pointed out, that Noels fixes broke some serious design considerations. I think the 2 parties should come together and work on a new solution, which is suitable for everyone. Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
