From: Volker K. <vol...@gm...> - 2014-12-07 14:00:09
|
thanks to every one for your explanations! The difference between the 3 different method was not clear to me. The filter method would be the best one for me, as then the configuration and the setup ist part of the application and no additional server has to be setup. But the filter is not working as desired for me -- form submits are not working and background cache revalidation yields to some exceptions in the application. there is no need to be sorry about the french mails in the list. As long as it is not to complicated my school french helps a little. :-) 2014-12-04 8:54 GMT+01:00 Nicolas Richeton <nic...@gm...>: > Hi Volker, > > I agree with Alexis and François-Xavier. > > A few additional comments on esigate-server : > > > 2) esigate-server is a pre-packaged version of the EsiGate filter deployed > inside a Jetty server. It is easy to run and you have nothing to install, > that is why it is often used in development. I think you could safely use > it in production but it still lacks some features like init scripts (but > this is currently in progress > <https://github.com/esigate/esigate/issues/61>) so you would have a > little work to setup everything > > In the 4.X branch you cannot configure provider mappings in > esigate-server. Threads, max connections, … are also not configurable. This > is why it is not suited for real projects. > > In the 5.x branch, these issues are fixed. It can be used the same way > than esigate-war, but this setup is less tested than the standard one. > > > The whole 5.X branch is still in development. It is quite stable, but > configuration/behavior may slightly change before release. Using it during > development ensure there are no upcoming breaking changes for your project. > If you find any bug, feel free to open issues on github. > > -- > Nicolas > |