I still think that child settings should not be prototypes, but this is a
more generic topic and I would like to hear other opinions as well
On Sun, Apr 1, 2012 at 6:27 PM, George Niculae <geo...@ezuce.com> wrote:
>
> Exactly, so leave settings as prototypes ;)
>
>
> On Sunday, April 1, 2012, Mircea Carasel <mirc...@ezuce.com> wrote:
> > 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 <geo...@ezuce.com> 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 <mirc...@ezuce.com> 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 <geo...@ezuce.com>
> 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 <mirc...@ezuce.com> 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
> >>> sipx-dev@list.s
>
> _______________________________________________
> sipx-dev mailing list
> sipx-dev@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>
_______________________________________________
sipx-dev mailing list
sipx-dev@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
