You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Waibel <BW...@intarsys.de> on 2016/07/14 10:21:08 UTC

Running James as WAR [unsigned]

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


AW: AW: Running James as WAR [unsigned]

Posted by Bernd Waibel <BW...@intarsys.de>.
Hello Matthieu,

> We are writing a proposal about what we would like to see in James 3.0, 
> you can find it here : https://github.com/apache/james-project/pull/42
I will have a look at, and I will try to help, of course.

> Comments (and help, of course) are welcome. If you want the War 
> deployment to be supported, maybe you can offer some help ?
Yes. There are some restrictions, as always, but we will help.

The current decision is to use the webapp deployment for our production environments.
If we use it in production, we will support it. 

We have a commitment of deploying some of our own development to the community version.
Things like bug fixing, spam handling, mail handling at protocol level, and so on.
But we will still have closed source (which should be the main part of my working hours, I think).
And, as yours, my working hours are limited. Just another restriction...
;-)

Greetings,
Bernd Waibel

-----Ursprüngliche Nachricht-----
Von: Matthieu Baechler [mailto:mbaechler@linagora.com] 
Gesendet: Montag, 25. Juli 2016 18:05
An: server-dev@james.apache.org
Betreff: Re: AW: Running James as WAR [unsigned]

Hi Bernd,

I understand what you are trying to achieve and it makes perfect sense IMO.

We are writing a proposal about what we would like to see in James 3.0, 
you can find it here : https://github.com/apache/james-project/pull/42

Comments (and help, of course) are welcome. If you want the War 
deployment to be supported, maybe you can offer some help ?

I personally prefer a jar deployment with the http server built in. 
Security fix are more likely happening in anything but jetty nowadays so 
making a specific case just for the servlet container seems to 
complicated to me.

WDYT ?

-- 
Matthieu Baechler

On 07/18/2016 04:07 PM, Bernd Waibel wrote:
> 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:mbaechler@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,
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: AW: Running James as WAR [unsigned]

Posted by Matthieu Baechler <mb...@linagora.com>.
Hi Bernd,

I understand what you are trying to achieve and it makes perfect sense IMO.

We are writing a proposal about what we would like to see in James 3.0, 
you can find it here : https://github.com/apache/james-project/pull/42

Comments (and help, of course) are welcome. If you want the War 
deployment to be supported, maybe you can offer some help ?

I personally prefer a jar deployment with the http server built in. 
Security fix are more likely happening in anything but jetty nowadays so 
making a specific case just for the servlet container seems to 
complicated to me.

WDYT ?

-- 
Matthieu Baechler

On 07/18/2016 04:07 PM, Bernd Waibel wrote:
> 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:mbaechler@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,
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


AW: Running James as WAR [unsigned]

Posted by Bernd Waibel <BW...@intarsys.de>.
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:mbaechler@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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Running James as WAR [unsigned]

Posted by Matthieu Baechler <mb...@linagora.com>.
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org