Re: using cocoon 2.1 in the long-term, security concerns

[Leszek Gawron]

I have never attempted a cocoon release - doesn't look like a trivial task,
so maybe someone here has more experience?

I'd like one more thing "fixed" if it's possible:

org.apache.cocoon.forms.formmodel.Repeater has some "crazy" limitation that
has hit me several times on production:

if (size > 500) {
//throw new RuntimeException("Client is not allowed to
specify a repeater size larger than 500.");
}

could we lift that off or at least make the constraint configurable ?


On Fri, Jul 30, 2021 at 1:37 PM Gabriel Gruber 
wrote:

> Hi Leszak,
>
>
>
> Yeah, a release would be nice – Fix version 2.2.1 was stated in this
> ticket https://issues.apache.org/jira/browse/COCOON-2347
>
>
>
> But was never released though…
>
> Cheers,
>
> Gabriel
>
>
>
> *From: *Leszek Gawron 
> *Date: *Friday, 30. July 2021 at 10:35
> *To: *users@cocoon.apache.org 
> *Subject: *Re: using cocoon 2.1 in the long-term, security concerns
>
> I am sorry for not reading the thread to the last message. Maybe a release
> then?
>
>
>
> On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber <
> gabriel.gru...@workflow.at> wrote:
>
> Hi Vincent,
>
>
>
> We at Workflow are also still using Cocoon 2.2 as part of our main product
> and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes.  In
> the past we did not see any major problem with cocoon which were not
> solvable. From a security perspective maybe the biggest thread was a
> directory traversal opportunity if you would use ResourceReader cocoon
> component in the wrong way allowing users to use the  /.. in
> URL/request-parameters  being forwarded to the path of the resource to be
> read in order to traverse the directory of the deployment.
>
>
>
> Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
>
>
>
> Cheers,
>
> Gabriel Gruber
>
> www.workflow.at
>
>
>
>
>
> *Von:* Vincent Neyt 
> *Gesendet:* Dienstag, 20. Juli 2021 12:28
> *An:* users@cocoon.apache.org
> *Betreff:* 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 wou

Re: using cocoon 2.1 in the long-term, security concerns

[Gabriel Gruber]

Hi Leszak,

Yeah, a release would be nice – Fix version 2.2.1 was stated in this ticket 
https://issues.apache.org/jira/browse/COCOON-2347

But was never released though…
Cheers,
Gabriel

From: Leszek Gawron 
Date: Friday, 30. July 2021 at 10:35
To: users@cocoon.apache.org 
Subject: Re: using cocoon 2.1 in the long-term, security concerns
I am sorry for not reading the thread to the last message. Maybe a release then?

On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber 
mailto:gabriel.gru...@workflow.at>> wrote:
Hi Vincent,

We at Workflow are also still using Cocoon 2.2 as part of our main product and 
are running it with Java 11 and Tomcat 9 on Windows and Linux OSes.  In the 
past we did not see any major problem with cocoon which were not solvable. From 
a security perspective maybe the biggest thread was a directory traversal 
opportunity if you would use ResourceReader cocoon component in the wrong way 
allowing users to use the  /.. in URL/request-parameters  being forwarded to 
the path of the resource to be read in order to traverse the directory of the 
deployment.

Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.

Cheers,
Gabriel Gruber
www.workflow.at<http://www.workflow.at>


Von: Vincent Neyt mailto:vincent.n...@gmail.com>>
Gesendet: Dienstag, 20. Juli 2021 12:28
An: users@cocoon.apache.org<mailto:users@cocoon.apache.org>
Betreff: 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 
mailto: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..

Re: using cocoon 2.1 in the long-term, security concerns

[Leszek Gawron]

I am sorry for not reading the thread to the last message. Maybe a release
then?

On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber 
wrote:

> Hi Vincent,
>
>
>
> We at Workflow are also still using Cocoon 2.2 as part of our main product
> and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes.  In
> the past we did not see any major problem with cocoon which were not
> solvable. From a security perspective maybe the biggest thread was a
> directory traversal opportunity if you would use ResourceReader cocoon
> component in the wrong way allowing users to use the  /.. in
> URL/request-parameters  being forwarded to the path of the resource to be
> read in order to traverse the directory of the deployment.
>
>
>
> Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
>
>
>
> Cheers,
>
> Gabriel Gruber
>
> www.workflow.at
>
>
>
>
>
> *Von:* Vincent Neyt 
> *Gesendet:* Dienstag, 20. Juli 2021 12:28
> *An:* users@cocoon.apache.org
> *Betreff:* 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
>
>

Re: using cocoon 2.1 in the long-term, security concerns

[Leszek Gawron]

On Mon, Jul 19, 2021 at 2:27 PM Cédric Damioli  wrote:

> Hi,
>
> Not only Tomcat, but each and every dependency your particular project
> uses.
> As of today, Cocoon 2.1 works well in a Java 11+/Tomcat 9+ environment,
> with all dependencies upgraded.
>
> Cocoon 2.1.13 itself contained a fix for a security-related issue, but in
> the past years, there wasn't many security issues targeting Cocoon core.
>
>
cocoon 2.2 does NOT work with spring 4+ - the fixes are trivial though
(some deprecated API usages have to be corrected)
Jetty 9 needs to have web fragments configuration disabled or it doesn't
start cocoon webapp at all

I've made some forked changes for my organization and ... lost the sources.
Fixing it again should be no problem if someone here would go for a
release.

Java 11 is no problem - the only thing I remember is some simple
commons-beanutils usage querying Java version - the forced maven dependency
fixed the issue.

Re: using cocoon 2.1 in the long-term, security concerns

[Vincent Neyt]

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

Re: using cocoon 2.1 in the long-term, security concerns

[Christopher Schultz]

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

Re: using cocoon 2.1 in the long-term, security concerns

[gelo1234]

Hello Vincent,

It depends on your future Strategy. Cocoon is very flexible. We've been
running Cocoon 3.0-beta in production with Tomcat9/10, Quarkus and even
Kubernetes 1.20 etc. No problems at all :)
with Java 8 :) We cannot switch to Java 11, because it's not compatible
with Cocoon libraries anymore :( That's the only obstacle.
Maybe someone could "update" cocoon stack to use Java 11 LTS JVM? Or now 17
LTS? :)

As long as it does its job, Cocoon is fine! Although the amount of
pipelines that are still in use in our Cocoon deployments decreased in
time.
We switched to Vue.js framework as frontend and Spring-Boot 2 as backend
technologies, all running on Kubernetes multi-clusters.
Both Vue and Spring-Boot 2 are very lightweight and suit our needs better
(to build Web-Portals) than Cocoon. Even though we still use Cocoon for
some integration stuff and fast
proxy/gateway to many "old" services or database access.

Greetings,
Greg


pon., 19 lip 2021 o 14:03 Vincent Neyt  napisał(a):

> 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: using cocoon 2.1 in the long-term, security concerns

[Cédric Damioli]

Hi,

Not only Tomcat, but each and every dependency your particular project uses.
As of today, Cocoon 2.1 works well in a Java 11+/Tomcat 9+ environment, 
with all dependencies upgraded.


Cocoon 2.1.13 itself contained a fix for a security-related issue, but 
in the past years, there wasn't many security issues targeting Cocoon core.


HTH,
Regards,
Cédric

Le 19/07/2021 à 14:05, warrell harries a écrit :

The Tomcat version must be updated to address these concerns.

That should do it

On Mon, 19 Jul 2021, 13: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?

thanks very much,
Vincent



--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: using cocoon 2.1 in the long-term, security concerns

[warrell harries]

The Tomcat version must be updated to address these concerns.

That should do it

On Mon, 19 Jul 2021, 13: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?
>
> thanks very much,
> Vincent
>