Am 08.02.2011 14:52, schrieb Douglas Hubler:
> On Tue, Feb 8, 2011 at 3:37 AM, David Becker<[email protected]>
> wrote:
>> The patch is attached, it's extremely unfinished of course.
> Ok, I'll check it out soon
>
>> I'm not sure if it's suitable for contribution, it doesn't use the plug-in
>> system because it's meant to be deployed to production relatively soon after
>> completion and we don't expect the plug-in system to hit the stable version
>> for a long time.
> That's ok, you can base your work off any stable sipxecs version you
> want (e.g. 4.4), you maintain your custom patches. You also submit
> your contribution to sipXecs upstream (e.g. 4.5) so that in the next
> sipXecs release (e.g. 4.6), you can remove patches.
>
> The goal is to unload as many patches as you can because
> 1.) they are a burden to maintain and remove conflicts
> 2.) if you modify LGPL code you have to make it public anyway
> 3.) submitting it upstream means users will test it
> 4.) submitting it upstream means developers will maintain it (at least
> maintain it more than they would by not having the code)
> 5.) more likely to get fixes/improvements/feedback
> _______________________________________________
> sipx-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
I managed to fix this, apparently using UserSession.getUser(CoreContext)
doesn't just return the same reference every time, either it resets the
changes or something else prevents CoreContext.saveUser(User) from
saving the settings if it's given its own call to getUser instead of
storing the result of the first time.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
