Thank you very much Warrell, Cédric, Greg and Chris. I'm happy to hear that you believe Cocoon poses a very low security risk as long as Tomcat and Java are up to date, and that Cocoon should continue to work well with future versions of T & J as long as the dependency libraries in Cocoon are updated. (At least until Tomcat 9 is no longer supported.)
best wishes, Vincent On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Vincent, > > On 7/19/21 08:03, Vincent Neyt wrote: > > Hi Cocoon users, > > > > I'd like to ask your opinion on the long-term security risks of running > > Cocoon on a server. The colleague responsible for the servers at my > > university is inquiring if the software I'm using for my website is up > > to date and is concerned that I'm using outdated software that could in > > the future pose a security risk. > > > > I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 > > without many problems. But I'm concerned about the long-term, and > > wondering if it would perhaps be better to reprogram the website I've > > been working on for 10 years into eXist DB (which would be a huge time > > investment). I like cocoon very much and would love to continue using it > > if it's possible. > > > > I'm curious to hear your thoughts about using Cocoon 2.1 for the long > > term: will it still work well inside future versions of servlet > > containers like Tomcat? What about the java dependencies? And will > > cocoon 2.1 continue to put out updates when security risks are > identified? > > I, like you, have been running Cocoon 2.1.x for years and would like to > continue to rely on it for some important functions at $work. > > I don't see any reason it wouldn't run on current and future Tomcat > versions. There are a few "current" versions of Tomcat, and the only one > I would expect to have some issues would be the Tomcat 10.x series, > which implement the "Jakarta EE" specifications instead of the "Java EE" > specifications. For the most part, these specifications are simply > package-renamed versions of the original Java EE specs. So, for example, > javax.servlet.whatever becomes jakarta.servlet.whatever and so on. > > Tomcat has a migration tool which can migrate a binary web application > (e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if > that tool works on a webapp which is Cocoon itself and/or > Cocoon-bundled-with-your-application. > > I'm a Tomcat committer and if there are any problems, we could work > together to make sure Cocoon has plenty of life left in it. > > With the semi-recent release of Cocoon 2.2, are there members of the > community who would be interested in converting the project into a > Jakarta EE-based project? There is no particular rush, and most of the > conversion can be done essentially with a single sed script. But working > that into the build process so you can say "build me a Java EE-based > Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really > beneficial moving into the future. > > [As a Cocoon user, I'd love to know what is necessary to upgrade from > Cocoon 2.1 to 2.2. We have an ant-based build process for our > application which starts with a pre-built cocoon.war and customizes it > with everything we need. So if e.g. Maven can build Cocoon into a WAR > file, I might be all set.] > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org > For additional commands, e-mail: users-h...@cocoon.apache.org > >
