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:mbaech...@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: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,
>


---------------------------------------------------------------------
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

Reply via email to