Hello Mathieu, the reason for this:
We do have a web application for managing some features in James 2.3.2. I do not want to do advertising here, cause this is a non-commercial forum, but you personally may have a look at this screenshot: "https://wiki.intarsys.de/confluence/display/SMG/Aktionen+in+den+Regeln"; Sorry, this page is currently only in German language, but some screenshots may make clear what we are doing. The managing application is running in Tomcat7, and the web app is managing James and our own mailet (via JMX, and via our own mailet). So the idea is to manage James via our Tomcat-Servlet. We need to work with shared databases here, which may be of concern at runtime. So, if Tomcat is already installed at the running machines of our customers, so why not run James in Tomcat? We hope the deployment would be easier, cause on an update we just want to replace the war file, and let tomcat do the deployment. This has not been enabled in James2.3.2, I think, so it is a new feature. We could use the standalone-runner, too. The "Phoenix" implementation of james2 has been gone dead, which made the deployment tricky. Would this happen again? Is the new runtime stable enough? What's about security fixes? Tomcat has some good reputation on fixing security issues. If you recommend to use the standalone service, because the James web app may become deprecated, please let me know. Best Regards Bernd Waibel -----Ursprüngliche Nachricht----- Von: Matthieu Baechler [mailto:mbaech...@linagora.com] Gesendet: Montag, 18. Juli 2016 12:22 An: server-dev@james.apache.org Betreff: Re: Running James as WAR [unsigned] Could you explain why you would like to use it as a WAR ? It looks like the trend is to have a self contained service. I'm eager to know what would be the rational for that in 2016 and if it would be interesting to actually support that for James 3.0 or not. Regards, -- Matthieu Baechler On 07/14/2016 12:21 PM, Bernd Waibel wrote: > Hello together, > > We would like to run James3 as WebApplication inside Tomcat. > > The configuration directory (conf) is located inside the war file, and is > deployed to the WEB-INF directory. > This is a problem, if we like to redeploy or to update the war file. E.g. if > we would update from beta4 to beta5, we may lose the config files. > So it would be nice to offer an option to define the conf directory (to lay > outside of the deployed directory structure). > > The JamesServerWebApplicationContext does define a root directory of > "return > JamesServerWebApplicationContext.this.getServletContext().getRealPath("/");" > > This is fine, cause we only want to define the "conf" directory, not the > "var" directory and so on. > We do not want to change the ServletContext, cause this may tend to create > other problems. > > The WebApp Context could be changed per installation, by creating a > independent file "<webappname>.xml" inside /Catalina/localhost/". > > I could not find any option to change the conf directory path. > Is this right? Is there an option? > > Now there are some possible solutions to us: > > - Create a own WebApplicationContext class, and change the web.xml > file to use this class, and deploy that. > > o Would work for our application. > > - Update the existing JamesServerWebApplicationContext class, to > allow flexible configuration of the directories via > > o A runtime environment variable (System environment) > > o An entry in the webapp Context (web.xml, or > /Catalina/localhost/james-server-app-3.0.0-beta5-SNAPSHOT.xml) > > o Or both, in order, with fallback to > JamesServerWebApplicationContext.this.getServletContext().getRealPath("/");. > > I would tend to do the last one, what do you mean? > We would implement and offer pull request on github, if you like. > > Best regards, > Bernd Waibel > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
