Re: using cocoon 2.1 in the long-term, security concerns
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 > >
using cocoon 2.1 in the long-term, security concerns
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? thanks very much, Vincent
Re: Cocoon 2.1.11 problem with JDK release versions above 255
Hi all, thank you very much for all your reactions. I just found time to try Nico Verwer's suggestion, and that worked perfectly! It seems it was the very old version of icu4j.jar that caused the problem. As Nico suggested I exchanged it for icu4j-69.1.jar in the lib directory, and was able to start up cocoon without errors. thanks again! Vincent On Wed, Jun 30, 2021 at 5:20 PM Cédric Damioli wrote: > Hi Vincent, > > Do you have any stack trace to help finding the actual issue ? > > I know there's a similar issue with the ICU library. Do you use it, and if > so in which version ? > > Regards, > Cédric > > > Le 30/06/2021 à 17:11, Francesco Chicchiriccò a écrit : > > On 28/06/21 09:48, Vincent Neyt wrote: > > Hi list, > > I did a stupid thing, I posted to the user list without first subscribing, > so I'm sending my query again now that I am subscribed to the list. Sorry > for the inconvenience! > > Since 2011 I've been using a build of Cocoon 2.1.11 (inside Tomcat 8) as > the publishing framework for my website. I've recently found out that > Cocoon fails to start up when the installed java version has an update > number higher than 255. Things start up properly with Java SE Development > Kit 8u255 and lower, but fail to start up with Java SE Development Kit > 8u256 and higher (for instance the current Java SE Development Kit 8u291). > > The error I get is > > Initialization Problem: Scheduler with name 'Cocoon' already exists. > > but it has cost me blood sweat and tears to find out that the underlying > cause is the Java update version number. > > Is there a line in a file in my Cocoon 2.1.11 build that I could change to > get rid of this error? > > > Hi Vincent, > I am afraid I cannot be of much help here, not using Cocoon 2.1 since > quite some time. > > Anyway, did you find anything more than just the line reported above? Any > stacktrace? > > Regards. > > > -- > <http://www.ametys.org> > <http://www.facebook.com/ametysCMS> <http://twitter.com/ametysCMS> > <http://plus.google.com/+ametysOrg/posts> > <http://www.youtube.com/user/ametysWebCMS> > > Cédric Damioli > > Directeur associé > +33 (0)5 62 19 19 07 / +33 (0)6 87 03 61 63 | +33 (0)5 61 75 84 > 12 > cedric.dami...@ametys.org > 40 Rue du Village d'entreprises 31670 Labège > Inscrivez-vous à notre newsletter > <http://anyware-services.us2.list-manage2.com/subscribe?u=1cf1cbf2891b613e90fd95eb2=01c7bdfce3> > >
Cocoon 2.1.11 problem with JDK release versions above 255
Hi list, I did a stupid thing, I posted to the user list without first subscribing, so I'm sending my query again now that I am subscribed to the list. Sorry for the inconvenience! Since 2011 I've been using a build of Cocoon 2.1.11 (inside Tomcat 8) as the publishing framework for my website. I've recently found out that Cocoon fails to start up when the installed java version has an update number higher than 255. Things start up properly with Java SE Development Kit 8u255 and lower, but fail to start up with Java SE Development Kit 8u256 and higher (for instance the current Java SE Development Kit 8u291). The error I get is Initialization Problem: Scheduler with name 'Cocoon' already exists. but it has cost me blood sweat and tears to find out that the underlying cause is the Java update version number. Is there a line in a file in my Cocoon 2.1.11 build that I could change to get rid of this error? Thanks very much in advance! Vincent Neyt
