Hi Chris, yeah as you said a decision was made to separate out properties which can be defined only at global level in one file reminiscent to Tomcat's server.xml and a web app descriptor file which can be defined at global level and can also be overridden at context level reminiscent to web.xml of Tomcat.
I am using LifeCycleListeners to load configurations and anyone using the configurations in valves will be able to load them using ValveBase.initInternal() method. On Sat, Feb 20, 2016 at 8:23 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Chiranga, > > On 2/12/16 1:27 AM, Chiranga Alwis wrote: > > There are some custom configurations which we intend to add to this > config > > file. We have a custom made single-sign-on valve based on SAML 2.0 which > > has plenty of configuration properties plus there are some custom > > classloading code which I am not that entirely proficient about. > > > > We intend to separate out these from default Tomcat configs in web.xml > and > > improve the users' usability. > > How does introducing a new type of global configuration file improve > users' usability? > > -chris > > > On Thu, Feb 11, 2016 at 10:53 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Chiranga, > > > > On 2/11/16 6:45 AM, Chiranga Alwis wrote: > >>>> Hi, > >>>> > >>>> I have been working on adding a custom configurations file which > >>>> follow a pattern similar to the web.xml, i.e. the file can be > >>>> defined globally but several predefined configuration properties > >>>> can be overridden at web-app level. > >>>> > >>>> For this purpose, my initial plan was to load the content in global > >>>> level file by implementing the LifeCycleListener interface and in > >>>> the case of a web-app or context use a ServletContextListener. > >>>> > >>>> Is this the most appropriate procedure to achieve this or is it an > >>>> incorrect approach? > > > > Can you explain how this is different from what is possible using > > conf/web.xml and conf/context.xml for site-wide defaults? > > > > -chris > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >