Yes, correct, so next time when sipxconfig will be started, will load mybuddy password from DB, instead of spring, and password won't be regenerated, so adding this behavior we will cover the case when restarting sipxconfig as well and prevent password regeneration
mircea On Sun, Apr 1, 2012 at 6:17 PM, George Niculae <[email protected]> wrote: > Right, the flow should be as: when mybuddy feaure enabled rand password > generated and saved in db, then on subsequent calls to load settings / pass > from db > > > George > > On Sunday, April 1, 2012, Mircea Carasel <[email protected]> wrote: > > Settings not loaded from database? Settings are loaded from database as > long as you save them there...but if you don't, settings will be retrieved > from Spring. > > Therefore, IMO, there is no point to inherit prototype behavior for > child settings. In this case, every time you call getSettings, initialize > method will be called again and again, and the test > > mircea > > > > On Sun, Apr 1, 2012 at 4:44 PM, George Niculae <[email protected]> wrote: > >> > >> I don't think this logic stands, from what I understand you'll see same > behaviour when restarting config (that is when new settings instantied). > >> I'd look at why settings not loaded, maybe hibernate interceptor not > applied? > >> > >> George > >> > >> On Sunday, April 1, 2012, Mircea Carasel <[email protected]> wrote: > >> > Hi, > >> > During investigations in 4.6 on why mybuddy is not connecting to > openfire (authorized exception) I found out that the mybuddy password is > always overwritten in sipximbot.properties and > >> > xmpp-account-info.xml at every "getSettings()" call > >> > The cause of this is that at every m_beanFactory.getBean(m_class) > call (in BeanWithSettingsDaoImpl) a new instance of a setting bean is > created in spring > >> > Related to ImBotSettings.java, every time when we call getSettings() > (ImBotImpl.getSettings), it is called: ImbotSettings.initialize, that > regenerated mybuddy password, given the fact that always a new instance of > BeanWIthSettings.m_settings is created > >> > protected void initialize() { > >> > if > (StringUtils.isEmpty(getSettingValue(PA_PASSWORD_SETTING))) { > >> > setSettingValue(PA_PASSWORD_SETTING, > randomAlphanumeric(PASS_LENGTH)); > >> > } > >> > } > >> > BeanWithSettings.getSettings() method: > >> > public Setting getSettings() { > >> > if (m_settings != null) { > >> > return m_settings; > >> > } > >> > setSettings(loadSettings()); > >> > initialize(); > >> > return m_settings; > >> > } > >> > It will never match the mybuddy password initially stored in openfire. > >> > Here are the spring definitions: > >> > imbot.beans.xml > >> > <bean id="imBotSettings" > class="org.sipfoundry.sipxconfig.imbot.ImBotSettings" parent="settingsBean"> > >> > </bean> > >> > parent settingsBean definition: > >> > <bean id="settingsBean" > class="org.sipfoundry.sipxconfig.setting.PersistableSettings" > scope="prototype" parent="beanWithSettings" > >> > abstract="true"> > >> > <property name="modelFilesContext" ref="modelFilesContext"/> > >> > </bean> > >> > the scope "prototype" is inherited to every child bean, such as > "imBotSettings" starting with spring 3.0: > >> > https://jira.springsource.org/browse/SPR-3542 > >> > The solution here is to specifically add scope="singleton" to > "imBotSettings" definition. I added this and MyBuddy works just fine > >> > More than this, the scope="singleton" should be added to all child, > instantiable setting beans. > >> > Please let me know your thoughts, but I strongly recommend not to let > settings creation every time until when the user changes a setting value in > UI and saves settings object in database > >> > Thanks, > >> > Mircea > >> _______________________________________________ > >> sipx-dev mailing list > >> [email protected] > >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
