Re: DBCP Database Connection Pools without transactionnal NO autocommit

[Bernd Eckenfels]

Just a BTW I think the two statements are not from you/DBCP but the driver 
emits them when you use the setAutocommit(). In some cases drivers remember the 
state and don’t emit something, in most cases they do. So a config option to 
not set/reset that state on checking/checkout - if you need to minimize the 
number of roundtrips - would be good for DBCP.

This would be setting defaultAutocommit to thr value you like and setting 
autocommitOnReturn to false to avoid resetting it. And your code should not 
call the setter, at least not without checking if it’s needed (it will depend 
on the driver if this causes a select).

I think Auto commit would be great if your log statements are a single atomic 
unit as it greatly reduces roundtrips and transaction time - if you still need 
to make multiple inserts in different tables perhaps consider calling a stored 
procedure instead?

 (And also some batching, but that can become tricky if you keep the 
connections for extended transactions). I am not sure how good the dbappender 
from log4j is in this regard.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Gary Gregory 
Gesendet: Monday, June 6, 2022 7:22:26 PM
An: Commons Users List 
Betreff: Re: DBCP Database Connection Pools without transactionnal NO autocommit

Any news?

Gary

On Thu, Jun 2, 2022 at 12:32 PM Gary Gregory  wrote:
>
> BTW, if that still does not work for you, make sure your are using the latest 
> version of DBCP and of your JDBC Driver. Please report which versions you are 
> using. If you are still stuck, the only way we can realistically help you 
> here is if you provide a PR with a reproducible test case using the H2 in 
> memory database, see the existing tests for inspiration. If you cannot 
> reproduce the issue, then this might be specific to your database of JDBC 
> driver, in which case, we would still need a standalone application that 
> reproduces the issue.
>
> Gary
>
> On Thu, Jun 2, 2022, 08:22 Gary Gregory  wrote:
>>
>> It might be simpler to avoid custom Java code. Is there a reason you are not 
>> using the log4j2-jdbc-dbcp2 module?
>>
>> For example 
>> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-jdbc-dbcp2/src/test/resources/log4j2-jdbc-dbcp2.xml
>>
>> Gary
>>
>> On Thu, Jun 2, 2022, 08:13 Sébastien Jachym 
>>  wrote:
>>>
>>> I'm logging with log4j2
>>>
>>> log4j2.xml :
>>> 
>>> 
>>> 
>>> >> method="getConnection" />
>>> ...
>>> 
>>> 
>>>
>>> ConnectionFactory class :
>>> public static Connection getConnection() throws SQLException {
>>> dataSource = new org.apache.commons.dbcp2.BasicDataSource();
>>> dataSource.setUp ( url, user, pass, driver )
>>>
>>> dataSource.setDefaultAutoCommit(false);
>>> dataSource.setAutoCommitOnReturn(false);
>>> dataSource.setRollbackOnReturn(false);
>>> dataSource.setValidationQuery("SELECT 1");
>>>
>>> //Connection connection = dataSource.getConnection();
>>> //connection.setAutoCommit(true); // no change, first is SET
>>> autocommit=(0|1) and log4j2 next is SET autocommit=0
>>> //return connection;
>>> return dataSource.getConnection();
>>>
>>> In code call :
>>> org.apache.logging.log4j.Logger.trace("hello")
>>>
>>> Finally calling logger,
>>> use JDBC Appender
>>> and get a connection from the BasicDataSource pool.
>>> And continu outside my code with the unwanted transactional statement.
>>> For writing log in my database.
>>>
>>> -Message d'origine-
>>> De : Gary Gregory 
>>> Envoyé : jeudi 2 juin 2022 11:23
>>> À : Commons Users List 
>>> Objet : Re: DBCP Database Connection Pools without transactionnal NO
>>> autocommit
>>>
>>> Something is not clear to me: are you in control of calling JDBC or are you
>>> using Log4j's JDBC Appender or something else? You description is not
>>> detailed enough for me to understand who does what.
>>>
>>> Gary
>>>
>>> On Wed, Jun 1, 2022, 19:49 Sébastien Jachym <
>>> sebastien.jac...@agri-commerce.fr> wrote:
>>>
>>> > Hello,
>>> > Thank you Gary for you reply, but it doesn’t work with configuring
>>> > BasicDataSource with :
>>> >dataSource.setDefaultAutoCommit(false);
>>> >dataSource.setAutoCommitOnReturn(false);
>>> >dataSource.setRollbackOnReturn(false);
>>> >
>>> > There are changes, but always transactional with "SET autocommit" :
>>> > SELECT @@session.transaction_isolation SELECT 1 -- ValidationQuery
>>> > dans ConnectionFactory SET autocommit=0 SET SQL_SELECT_LIMIT=1 select
>>> >
>>> > date,logger,level,message,exception,pid,idUtilisateur,version,ip,marke
>>> > rSimpleName,sqlLastInsertId,sqlTimeMillis
>>> > from log4j2 where 1=0
>>> > SET SQL_SELECT_LIMIT=DEFAULT
>>> > insert into log4j2
>>> >
>>> > (date,logger,level,message,exception,pid,idUtilisateur,version,ip,mark
>>> > erSimpleName,sqlLastInsertId,sqlTimeMillis)
>>> > values (... the values ...)
>>> > co

Re: DBCP Database Connection Pools without transactionnal NO autocommit

[Gary Gregory]

Any news?

Gary

On Thu, Jun 2, 2022 at 12:32 PM Gary Gregory  wrote:
>
> BTW, if that still does not work for you, make sure your are using the latest 
> version of DBCP and of your JDBC Driver. Please report which versions you are 
> using. If you are still stuck, the only way we can realistically help you 
> here is if you provide a PR with a reproducible test case using the H2 in 
> memory database, see the existing tests for inspiration. If you cannot 
> reproduce the issue, then this might be specific to your database of JDBC 
> driver, in which case, we would still need a standalone application that 
> reproduces the issue.
>
> Gary
>
> On Thu, Jun 2, 2022, 08:22 Gary Gregory  wrote:
>>
>> It might be simpler to avoid custom Java code. Is there a reason you are not 
>> using the log4j2-jdbc-dbcp2 module?
>>
>> For example 
>> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-jdbc-dbcp2/src/test/resources/log4j2-jdbc-dbcp2.xml
>>
>> Gary
>>
>> On Thu, Jun 2, 2022, 08:13 Sébastien Jachym 
>>  wrote:
>>>
>>> I'm logging with log4j2
>>>
>>> log4j2.xml :
>>> 
>>> 
>>> 
>>> >> method="getConnection" />
>>> ...
>>> 
>>> 
>>>
>>> ConnectionFactory class :
>>> public static Connection getConnection() throws SQLException {
>>> dataSource = new org.apache.commons.dbcp2.BasicDataSource();
>>> dataSource.setUp ( url, user, pass, driver )
>>>
>>> dataSource.setDefaultAutoCommit(false);
>>> dataSource.setAutoCommitOnReturn(false);
>>> dataSource.setRollbackOnReturn(false);
>>> dataSource.setValidationQuery("SELECT 1");
>>>
>>> //Connection connection = dataSource.getConnection();
>>> //connection.setAutoCommit(true); // no change, first is SET
>>> autocommit=(0|1) and log4j2 next is SET autocommit=0
>>> //return connection;
>>> return dataSource.getConnection();
>>>
>>> In code call :
>>> org.apache.logging.log4j.Logger.trace("hello")
>>>
>>> Finally calling logger,
>>> use JDBC Appender
>>> and get a connection from the BasicDataSource pool.
>>> And continu outside my code with the unwanted transactional statement.
>>> For writing log in my database.
>>>
>>> -Message d'origine-
>>> De : Gary Gregory 
>>> Envoyé : jeudi 2 juin 2022 11:23
>>> À : Commons Users List 
>>> Objet : Re: DBCP Database Connection Pools without transactionnal NO
>>> autocommit
>>>
>>> Something is not clear to me: are you in control of calling JDBC or are you
>>> using Log4j's JDBC Appender or something else? You description is not
>>> detailed enough for me to understand who does what.
>>>
>>> Gary
>>>
>>> On Wed, Jun 1, 2022, 19:49 Sébastien Jachym <
>>> sebastien.jac...@agri-commerce.fr> wrote:
>>>
>>> > Hello,
>>> > Thank you Gary for you reply, but it doesn’t work with configuring
>>> > BasicDataSource with :
>>> >dataSource.setDefaultAutoCommit(false);
>>> >dataSource.setAutoCommitOnReturn(false);
>>> >dataSource.setRollbackOnReturn(false);
>>> >
>>> > There are changes, but always transactional with "SET autocommit" :
>>> > SELECT @@session.transaction_isolation SELECT 1 -- ValidationQuery
>>> > dans ConnectionFactory SET autocommit=0 SET SQL_SELECT_LIMIT=1 select
>>> >
>>> > date,logger,level,message,exception,pid,idUtilisateur,version,ip,marke
>>> > rSimpleName,sqlLastInsertId,sqlTimeMillis
>>> > from log4j2 where 1=0
>>> > SET SQL_SELECT_LIMIT=DEFAULT
>>> > insert into log4j2
>>> >
>>> > (date,logger,level,message,exception,pid,idUtilisateur,version,ip,mark
>>> > erSimpleName,sqlLastInsertId,sqlTimeMillis)
>>> > values (... the values ...)
>>> > commit
>>> >
>>> > Also before returning the connection to my log4j2 Async Appenders
>>> > whith ConnectionFactory, I force : connection.setAutoCommit(false);
>>> > But result is same with transactional statements :
>>> > SET autocommit=0 -- [ OR "SET autocommit=0" WITH
>>> > connection.setAutoCommit(true); ] SET autocommit=0 SET
>>> > SQL_SELECT_LIMIT=1 select
>>> >
>>> > date,logger,level,message,exception,pid,idUtilisateur,version,ip,marke
>>> > rSimpleName,sqlLastInsertId,sqlTimeMillis
>>> > from log4j2 where 1=0
>>> > SET SQL_SELECT_LIMIT=DEFAULT
>>> > insert into log4j2
>>> >
>>> > (date,logger,level,message,exception,pid,idUtilisateur,version,ip,mark
>>> > erSimpleName,sqlLastInsertId,sqlTimeMillis)
>>> > values ...
>>> > commit
>>> >
>>> > Cheers.
>>> >
>>> >
>>> > -Message d'origine-
>>> > De : Gary Gregory  Envoyé : mercredi 1 juin
>>> > 2022 14:57 À : Commons Users List  Objet :
>>> > Re: DBCP Database Connection Pools without transactionnal NO
>>> > autocommit
>>> >
>>> > Hello,
>>> >
>>> > Try calling Connection#setAutoCommit(false) once you get a Connection.
>>> > You'll likely want to configure your data source with
>>> > org.apache.commons.dbcp2.BasicDataSource.setAutoCommitOnReturn(false)
>>> > to avoid resetting the auto-commit flag.
>>> >
>>> > Gary
>>> >
>>> > On Tue

RE: [External] Re: Question regarding the 3.x.x commons-collections library

[Amit Pande]

Yes, agree.

I understand these very helpful libraries didn't have many reasons to change as 
such and lot of production systems continue to use these "old age-wise but 
still latest" libraries. . Probably, CVEs would be the reason for the change.

But I think I didn't quite understand the process/plans for upgrading libraries 
such as commons-validator or beanutils to work with latest version of 
commons-collections.
I suppose many Java applications would be using these libraries very heavily 
and not getting the combination of latest versions to work would be an issue.

Thanks,
Amit

-Original Message-
From: Gary Gregory  
Sent: Monday, June 6, 2022 8:57 AM
To: Commons Users List 
Subject: Re: [External] Re: Question regarding the 3.x.x commons-collections 
library

It looks like Validator also depends on BeanUtils and that one depends on 
Collections as well. So we need to release BU 2.0 as well to rid Validator of 
Collections 3.x I think.

Gary

On Mon, Jun 6, 2022, 09:41 Gary Gregory  wrote:

> On Mon, Jun 6, 2022 at 8:40 AM Amit Pande 
>  wrote:
> >
> > Thank you, Gary, for the response.
> >
> > Yes, it would be ideal to upgrade to latest 4.x.
> > We can/should do that where there is direct dependency.
> >
> > But what about when this collections jar is pulled in as a 
> > transitive
> dependency?
> >
> > For example, commons validator requires 3.2.2. If we are using this
> library, how could we proceed?
>
> You can't.
>
> > Do we know if there is a plan for commons validator to consume this
> latest 4.y series of commons-collections?
>
> The head of Validator's master branch depends on Java 7 and the head 
> of Collections master branch depends on Java 8. Therefore, currency, 
> Validator could only migrate to a very old version of Collections 4 
> that also depends on Java 7. This would still require updating at 
> least the import statements in Validator.
>
> We could of course update Validator to Java 8 and then update the 
> imports to the latest Collections.
>
> Any of this happening depends on the interest and availability of the 
> volunteers here (like me) to do the work. There are currently no plans 
> that I know of to do this but it seems like the right path forward. I 
> think Validator might be the last Commons component that is not on 
> Java 8.
>
> Gary
>
> >
> > Thanks,
> > Amit
> >
> >
> > Get Outlook for 
> > iOS > 2Faka.ms%2Fo0ukef&data=05%7C01%7CAmit.Pande%40veritas.com%7Cca1a
> > 49afaaf14288ab4808da47c47e91%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%
> > 7C0%7C637901206516823304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > sdata=eiO3p%2BXuj9PdKVVIt1T4Gr30XR03dw4DyE%2FzZhJ1bMU%3D&reserve
> > d=0>
> > 
> > From: Gary Gregory 
> > Sent: Monday, June 6, 2022 7:31:38 AM
> > To: Commons Users List 
> > Subject: [External] Re: Question regarding the 3.x.x 
> > commons-collections
> library
> >
> > Hi Amit and all:
> >
> > I definitely recommend migrating to the latest of the 4.x line.
> >
> > We provide a kind of version 3.x support in the sense that anyone 
> > with historical knowledge or the inclination can answer questions 
> > here. As far as any new releases of the 3.x branch, I would say that 
> > this would be quite unlikely unless the community was made aware of 
> > a critical CVE and decided that a release was warranted, Security 
> > issues should be discussed according to
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> ons.apache.org%2Fsecurity.html&data=05%7C01%7CAmit.Pande%40veritas
> .com%7Cca1a49afaaf14288ab4808da47c47e91%7Cfc8e13c0422c4c55b3eaca318e6c
> ac32%7C0%7C0%7C637901206516823304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=3W%2FI6Eudr2%2B8ckD4lS8A%2B7FBSTlUeP2a2Ao8jbvViGk%3D&re
> served=0
> >
> > We have not made a formal EOL statement of the 3.x line but this 
> > would seem like a good idea.
> >
> > Gary
> >
> >
> > On Fri, Jun 3, 2022 at 4:23 PM Amit Pande 
> >  wrote:
> > >
> > > Greetings all!
> > >
> > > Given that we have around four versions of the commons-collections
> version 4.x.x, I wanted to check if the 3.y.y versions are still 
> supported or not? To put it differently, are the 3.y.y EOL'ed?
> > >
> > > If not, is it safe to believe that any security vulnerability 
> > > fixes in
> 3.y.y series will still be made?
> > >
> > > I could not find anything on EOL of 3.y.y series, but our 
> > > organization
> has recommended to move to the 4.x.x line.
> > > Unfortunately, this is not a drop-in replacement for 3.y.y 
> > > artifacts
> and more over in some cases, commons-collections gets pulled in as 
> transitive dependency of other libraries.
> > > As an example, the commons-validator mentions commons-collection 
> > > 3.y.y
> as its dependency. (
> https://nam12.safelinks.pro

Re: [External] Re: Question regarding the 3.x.x commons-collections library

[Gary Gregory]

It looks like Validator also depends on BeanUtils and that one depends on
Collections as well. So we need to release BU 2.0 as well to rid Validator
of Collections 3.x I think.

Gary

On Mon, Jun 6, 2022, 09:41 Gary Gregory  wrote:

> On Mon, Jun 6, 2022 at 8:40 AM Amit Pande
>  wrote:
> >
> > Thank you, Gary, for the response.
> >
> > Yes, it would be ideal to upgrade to latest 4.x.
> > We can/should do that where there is direct dependency.
> >
> > But what about when this collections jar is pulled in as a transitive
> dependency?
> >
> > For example, commons validator requires 3.2.2. If we are using this
> library, how could we proceed?
>
> You can't.
>
> > Do we know if there is a plan for commons validator to consume this
> latest 4.y series of commons-collections?
>
> The head of Validator's master branch depends on Java 7 and the head
> of Collections master branch depends on Java 8. Therefore, currency,
> Validator could only migrate to a very old version of Collections 4
> that also depends on Java 7. This would still require updating at
> least the import statements in Validator.
>
> We could of course update Validator to Java 8 and then update the
> imports to the latest Collections.
>
> Any of this happening depends on the interest and availability of the
> volunteers here (like me) to do the work. There are currently no plans
> that I know of to do this but it seems like the right path forward. I
> think Validator might be the last Commons component that is not on
> Java 8.
>
> Gary
>
> >
> > Thanks,
> > Amit
> >
> >
> > Get Outlook for iOS
> > 
> > From: Gary Gregory 
> > Sent: Monday, June 6, 2022 7:31:38 AM
> > To: Commons Users List 
> > Subject: [External] Re: Question regarding the 3.x.x commons-collections
> library
> >
> > Hi Amit and all:
> >
> > I definitely recommend migrating to the latest of the 4.x line.
> >
> > We provide a kind of version 3.x support in the sense that anyone with
> > historical knowledge or the inclination can answer questions here. As
> > far as any new releases of the 3.x branch, I would say that this would
> > be quite unlikely unless the community was made aware of a critical
> > CVE and decided that a release was warranted, Security issues should
> > be discussed according to
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fsecurity.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=46U4Z6G6vLFIC1j909U6w%2BiCtDIt93dbGZdyMh3p9CI%3D&reserved=0
> >
> > We have not made a formal EOL statement of the 3.x line but this would
> > seem like a good idea.
> >
> > Gary
> >
> >
> > On Fri, Jun 3, 2022 at 4:23 PM Amit Pande
> >  wrote:
> > >
> > > Greetings all!
> > >
> > > Given that we have around four versions of the commons-collections
> version 4.x.x, I wanted to check if the 3.y.y versions are still supported
> or not? To put it differently, are the 3.y.y EOL'ed?
> > >
> > > If not, is it safe to believe that any security vulnerability fixes in
> 3.y.y series will still be made?
> > >
> > > I could not find anything on EOL of 3.y.y series, but our organization
> has recommended to move to the 4.x.x line.
> > > Unfortunately, this is not a drop-in replacement for 3.y.y artifacts
> and more over in some cases, commons-collections gets pulled in as
> transitive dependency of other libraries.
> > > As an example, the commons-validator mentions commons-collection 3.y.y
> as its dependency. (
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fproper%2Fcommons-validator%2Fdependencies.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FyK64bzFK0tUzYD4d8Zf2j1jg9ghjG5%2F7sgpbXNe9BY%3D&reserved=0
> )
> > >
> > > Appreciate your feedback on this.
> > >
> > > Thanks,
> > > Amit
> > >
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
>

Re: [External] Re: Question regarding the 3.x.x commons-collections library

[Gary Gregory]

On Mon, Jun 6, 2022 at 8:40 AM Amit Pande
 wrote:
>
> Thank you, Gary, for the response.
>
> Yes, it would be ideal to upgrade to latest 4.x.
> We can/should do that where there is direct dependency.
>
> But what about when this collections jar is pulled in as a transitive 
> dependency?
>
> For example, commons validator requires 3.2.2. If we are using this library, 
> how could we proceed?

You can't.

> Do we know if there is a plan for commons validator to consume this latest 
> 4.y series of commons-collections?

The head of Validator's master branch depends on Java 7 and the head
of Collections master branch depends on Java 8. Therefore, currency,
Validator could only migrate to a very old version of Collections 4
that also depends on Java 7. This would still require updating at
least the import statements in Validator.

We could of course update Validator to Java 8 and then update the
imports to the latest Collections.

Any of this happening depends on the interest and availability of the
volunteers here (like me) to do the work. There are currently no plans
that I know of to do this but it seems like the right path forward. I
think Validator might be the last Commons component that is not on
Java 8.

Gary

>
> Thanks,
> Amit
>
>
> Get Outlook for iOS
> 
> From: Gary Gregory 
> Sent: Monday, June 6, 2022 7:31:38 AM
> To: Commons Users List 
> Subject: [External] Re: Question regarding the 3.x.x commons-collections 
> library
>
> Hi Amit and all:
>
> I definitely recommend migrating to the latest of the 4.x line.
>
> We provide a kind of version 3.x support in the sense that anyone with
> historical knowledge or the inclination can answer questions here. As
> far as any new releases of the 3.x branch, I would say that this would
> be quite unlikely unless the community was made aware of a critical
> CVE and decided that a release was warranted, Security issues should
> be discussed according to 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fsecurity.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=46U4Z6G6vLFIC1j909U6w%2BiCtDIt93dbGZdyMh3p9CI%3D&reserved=0
>
> We have not made a formal EOL statement of the 3.x line but this would
> seem like a good idea.
>
> Gary
>
>
> On Fri, Jun 3, 2022 at 4:23 PM Amit Pande
>  wrote:
> >
> > Greetings all!
> >
> > Given that we have around four versions of the commons-collections version 
> > 4.x.x, I wanted to check if the 3.y.y versions are still supported or not? 
> > To put it differently, are the 3.y.y EOL'ed?
> >
> > If not, is it safe to believe that any security vulnerability fixes in 
> > 3.y.y series will still be made?
> >
> > I could not find anything on EOL of 3.y.y series, but our organization has 
> > recommended to move to the 4.x.x line.
> > Unfortunately, this is not a drop-in replacement for 3.y.y artifacts and 
> > more over in some cases, commons-collections gets pulled in as transitive 
> > dependency of other libraries.
> > As an example, the commons-validator mentions commons-collection 3.y.y as 
> > its dependency. 
> > (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fproper%2Fcommons-validator%2Fdependencies.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FyK64bzFK0tUzYD4d8Zf2j1jg9ghjG5%2F7sgpbXNe9BY%3D&reserved=0)
> >
> > Appreciate your feedback on this.
> >
> > Thanks,
> > Amit
> >
> >
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [External] Re: Question regarding the 3.x.x commons-collections library

[Amit Pande]

Thank you, Gary, for the response.

Yes, it would be ideal to upgrade to latest 4.x.
We can/should do that where there is direct dependency.

But what about when this collections jar is pulled in as a transitive 
dependency?

For example, commons validator requires 3.2.2. If we are using this library, 
how could we proceed?
Do we know if there is a plan for commons validator to consume this latest 4.y 
series of commons-collections?

Thanks,
Amit


Get Outlook for iOS

From: Gary Gregory 
Sent: Monday, June 6, 2022 7:31:38 AM
To: Commons Users List 
Subject: [External] Re: Question regarding the 3.x.x commons-collections library

Hi Amit and all:

I definitely recommend migrating to the latest of the 4.x line.

We provide a kind of version 3.x support in the sense that anyone with
historical knowledge or the inclination can answer questions here. As
far as any new releases of the 3.x branch, I would say that this would
be quite unlikely unless the community was made aware of a critical
CVE and decided that a release was warranted, Security issues should
be discussed according to 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fsecurity.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=46U4Z6G6vLFIC1j909U6w%2BiCtDIt93dbGZdyMh3p9CI%3D&reserved=0

We have not made a formal EOL statement of the 3.x line but this would
seem like a good idea.

Gary


On Fri, Jun 3, 2022 at 4:23 PM Amit Pande
 wrote:
>
> Greetings all!
>
> Given that we have around four versions of the commons-collections version 
> 4.x.x, I wanted to check if the 3.y.y versions are still supported or not? To 
> put it differently, are the 3.y.y EOL'ed?
>
> If not, is it safe to believe that any security vulnerability fixes in 3.y.y 
> series will still be made?
>
> I could not find anything on EOL of 3.y.y series, but our organization has 
> recommended to move to the 4.x.x line.
> Unfortunately, this is not a drop-in replacement for 3.y.y artifacts and more 
> over in some cases, commons-collections gets pulled in as transitive 
> dependency of other libraries.
> As an example, the commons-validator mentions commons-collection 3.y.y as its 
> dependency. 
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fproper%2Fcommons-validator%2Fdependencies.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FyK64bzFK0tUzYD4d8Zf2j1jg9ghjG5%2F7sgpbXNe9BY%3D&reserved=0)
>
> Appreciate your feedback on this.
>
> Thanks,
> Amit
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Question regarding the 3.x.x commons-collections library

[Gary Gregory]

Hi Amit and all:

I definitely recommend migrating to the latest of the 4.x line.

We provide a kind of version 3.x support in the sense that anyone with
historical knowledge or the inclination can answer questions here. As
far as any new releases of the 3.x branch, I would say that this would
be quite unlikely unless the community was made aware of a critical
CVE and decided that a release was warranted, Security issues should
be discussed according to https://commons.apache.org/security.html

We have not made a formal EOL statement of the 3.x line but this would
seem like a good idea.

Gary


On Fri, Jun 3, 2022 at 4:23 PM Amit Pande
 wrote:
>
> Greetings all!
>
> Given that we have around four versions of the commons-collections version 
> 4.x.x, I wanted to check if the 3.y.y versions are still supported or not? To 
> put it differently, are the 3.y.y EOL'ed?
>
> If not, is it safe to believe that any security vulnerability fixes in 3.y.y 
> series will still be made?
>
> I could not find anything on EOL of 3.y.y series, but our organization has 
> recommended to move to the 4.x.x line.
> Unfortunately, this is not a drop-in replacement for 3.y.y artifacts and more 
> over in some cases, commons-collections gets pulled in as transitive 
> dependency of other libraries.
> As an example, the commons-validator mentions commons-collection 3.y.y as its 
> dependency. 
> (https://commons.apache.org/proper/commons-validator/dependencies.html)
>
> Appreciate your feedback on this.
>
> Thanks,
> Amit
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org