On Tue, Oct 20, 2009 at 9:09 AM, Robert Joly <[email protected]> wrote:
> > /opt/openfire/conf/openfire.xml gets overwritten
> >
> > On Mon, 2009-10-19 at 15:29 -0400, Martin Pepin wrote:
> > >
> > > Hi,
> > >
> > > To solve XX-6782 I need to dynamically modify file
> > "openfile.xml" when
> > > the "Instant Messaging" debug level is turned on. I have
> > noticed that
> > > there are 2 copies of the same file:
> > >
> > > 1) /opt/openfire/conf/openfire.xml
> > > 2)
> > > ${sipxecs_install}/share/java/sipXecs/sipXopenfire/conf/openfire.xml
> > >
> > > The reason why there are 2 copies is that when
> > "sipxopenfire-setup.sh"
> > > runs at sipXecs startup, it creates a softlink from
> > > ${sipxecs_install}/share/java/sipXecs/sipXopenfire/conf/openfire.xml
> > > to /opt/openfire/conf/openfire.xml. However, around 10
> > seconds after
> > > "SipXopenfire" starts, the openfire.xml file gets
> > overwritten and the
> > > softlink is removed. This seems to be overwritten by the
> > > "SipXopenfire" process itself. This is also happening when
> > I manually
> > > set the openfire debug level in the openfire web admin
> > > server->logs->debug tab and click save changes.
> > >
> > > I would like to propose that the softlink creation in
> > > "sipxopenfire-setup.sh" links to the "conf" directory where
> > > openfire.xml is located instead of linking to the actual file. Any
> > > comments?
> >
> >
> > Actually, the right fix is to just build the sipx-openfire
> > with the same prefix we use for everything else in the first
> > place, and then all that nonsense with /opt goes away.
>
> Scott, I think you may be missing some of the background. Openfire.xml
> is a configuration file that is used by the openfire server itself. The
> server looks for openfire.xml under $OPENFIRE_HOME/conf and that is not
> configurable. One of the attributes that openfire.xml contains it the
> server's logging level. The tracker that Martin is working on calls for
> synchronizing the logging level of the openfire server with that of our
> openfire plugin (the latter being configurable via sipXconfig and
> replicated in a properly named sipx... config file). To do so, Martin
> has to write to the openfire.xml and he is proposing a strategy to do
> so.
>
I think this can be accomplished by updating the database. Every property in
openfire.xml has a corresponding database entry.
However, I think this is not a valid issue. Do we really want to enable
debug for the container (openfire) or just our plugin (sipxopenfire)?
Regards
Ranga
> _______________________________________________
> sipx-dev mailing list [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
> sipXecs IP PBX -- http://www.sipfoundry.org/
>
--
M. Ranganathan
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
