Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Phil Steitz 




On 8/30/20 4:00 PM, Gary Gregory wrote:

On Sun, Aug 30, 2020 at 2:30 PM Phil Steitz  wrote:


On 8/30/20 9:22 AM, Gary Gregory wrote:

Hm... would we need the flexibility of passing custom enums? For example,
CloseMode could be an interface implemented by various enums in the style
of the JRE's NIO public enum StandardOpenOption implements OpenOption?
We could have:
PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)

Remember this is only called by the pool, so I don't see the need for
custom enums, but it would be good to be able to add enum values so as
you suggested we start with the simplest but then add more granularity
as needed.


Phil,

Do you plan on providing this feature? I'm a bit busy with other components
and work ATM (aren't we all!)
If others agree it is a good idea for dbcp, I can do it.  I can see the 
argument that its better to stay with close() even for abandoned and I 
have not been able to get the deadlock to happen, so I would like to 
wait a bit and allow others to weigh in.  Similarly for pool, I would 
like to get more community feedback before adding to the interface.


Phil


Gary


Phil


Where DestroyOption is an empty interface and we provide a
StandardDestroyOption enum that implements DestroyOption.
?
Gary

On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
wrote:


So concretely, we would
add

org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,

CloseMode*) as a default method.
[*] New enum

?

Gary


On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
wrote:


On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver

bug,

but in [2], the driver maintainer makes the good point that to avoid

the

problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO,

as

it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in

the

Java

8 Javadoc).

Yes, bad idea to do that, I think.


or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it

could

be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real

resource

leak in the sense that (if) abort() leaks database resources, then

the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current

close/destroy

is

OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This

is

similar to what we did in HttpCore's CloseMode(IMMEDIATE vs

GRACEFUL):
https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle

destroy

differently for abandoned (or other) cases.


What I propose is that we make these change to pool:

1. Add a new method to PooledObjectFactory called "abandonObject"

with

   default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would

be

easier to find.

Yes, I think that would be better.  That raises the interesting

question

of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to

support

the new behavior backed by Connection#abort() in DBCP.
A third "escape hatch" mode could see passing in a lamba I suppose.

Re: [VOTE] Release Apache Commons Codec 1.15 based on RC1

2020-08-30 Thread Rob Tompkins 
Will look tomorrow...last few weeks were particularly busy.

-Rob

> On Aug 30, 2020, at 3:36 PM, Gary Gregory  wrote:
> 
> Ping.
> 
>> On Fri, Aug 28, 2020, 08:34 Alex Herbert  wrote:
>> 
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache Commons Codec 1.14 was released, so I would like to release
>> Apache Commons Codec 1.15.
>> 
>> Apache Commons Codec 1.15 RC1 is available for review here:
>>https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1 (svn
>> revision 41154 )
>> 
>> The Git tag commons-codec-1.15-RC1 commit for this RC is
>> c89d2af770f05457fbefa5fb4713c888bf177fb2 which you can browse here:
>> 
>> 
>> https://git-wip-us.apache.org/repos/asf?p=commons-codec.git;a=tag;h=refs/tags/commons-codec-1.15-RC1
>> 
>> Maven artifacts are here:
>> 
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1523/commons-codec/commons-codec/1.15/
>> 
>> These are the Maven artifacts and their hashes in Nexus:
>> 
>> #Release SHA-512s
>> #Fri Aug 28 13:02:53 BST 2020
>> 
>> commons-codec-1.15-bin.tar.gz=b6d517db15aedc424d112b8f3282c63f56aae66adaf317baf9853da65e291eb03fb5da51792aa437c7fdce63f6685c75373265e2a035b51e7525048716d7bfe3
>> 
>> commons-codec-1.15-bin.zip=2495a5dcc2e57280882e8bb13972c1881b074e3e06ae13f45025c63e96cdc77c3af2a19f8417dce538172738eee31a3a8ce73227427b4f5db2214f18b71efc7d
>> 
>> commons-codec-1.15-javadoc.jar=0aac697eb0d11b39013b458aa4ba24e5408b9f1435cbc12ebde9cabe39f8fb8fb37a84737a25b31f88f148cbf69a27c34e65952118cc7356511a1eefeb0a9497
>> 
>> commons-codec-1.15-sources.jar=4c451f148d4c4c4f09e93aa12345dcf39e17ccba3c30f638a75a5df3af622e12595946619cb4553dffcc6f77d7ad43b1e216a637942e02da955a376150393804
>> 
>> commons-codec-1.15-src.tar.gz=dcf0b86f269a96362dca5b36b9e764a07e390634804b359d4dbd1a0c50bfcc9f778e3797f196e1f553d76dd25b3c6fd016f0ffbbca856fa6c88d3d55791889ce
>> 
>> commons-codec-1.15-src.zip=41f380634710cc5523426587de0cca7d06ba3b7933f8e1b488c85cbb58fb9e97e0ff48c09f2ae5f09b95f4f4994621d5bf9e60e3c08412b545b4bb6969dfcd95
>> 
>> commons-codec-1.15-test-sources.jar=a77c00eb1a9d976b8f53536248a0c08d1e068b1634cf5ae232728ff01fd553ff9aa5832538fe99ae0017a0a71e11df86156fb6a576ef88a9c11571129094
>> 
>> commons-codec-1.15-tests.jar=3c338b6f4e95d2cec4d16f140f5f4cf4de1ffac6128038bce3058266b7555f037566b6553729d1067caf42770ae1d35726f20837787366014bca5ae86e7f3ba9
>> 
>> 
>> I have tested this with 'mvn clean test package site -Pjapicmp' using:
>> 
>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>> Maven home: /usr/local/apache-maven-3.6.3
>> Java version: 1.8.0_265, vendor: Private Build, runtime:
>> /usr/lib/jvm/java-8-openjdk-amd64/jre
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.0-186-generic", arch: "amd64", family:
>> "unix"
>> 
>> Details of changes since 1.14 are in the release notes:
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/RELEASE-NOTES.txt
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/changes-report.html
>> 
>> Site:
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/index.html
>>(note some *relative* links are broken and the 1.15 directories are not
>> yet created - these will be OK once the site is deployed.)
>> 
>> JApiCmp Report (compared to 1.14):
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/japicmp.html
>> 
>> RAT Report:
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/rat-report.html
>> 
>> KEYS:
>>  https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now.
>> 
>>  [ ] +1 Release these artifacts
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
>>  [ ] -1 I oppose this release because...
>> 
>> Thank you,
>> 
>> Alex Herbert,
>> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>> 
>> For following is intended as a helper and refresher for reviewers.
>> 
>> Validating a release candidate
>> ==
>> 
>> These guidelines are NOT complete.
>> 
>> Requirements: Git, Java, Maven.
>> 
>> You can validate a release from a release candidate (RC) tag as follows.
>> 
>> 1) Clone and checkout the RC tag
>> 
>> git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch
>> commons-codec-1.15-RC1 commons-codec-1.15-RC1
>> cd commons-codec-1.15-RC1
>> 
>> 2) Check Apache licenses
>> 
>> This step is not required if the site includes a RAT report page which you
>> then must check.
>> 
>> mvn apache-rat:check
>> 
>> 3) Check binary compatibility
>> 
>> Newer components use JApiCmp with the japicmp Maven Profile:
>> 
>> This step is not required if the site includes a JApiCmp report page which
>> you then must check.
>> 
>> mvn install -DskipTests -P japicmp japicmp:cmp
>> 
>> 4) Build the package
>> 
>> mvn -V clean package
>> 
>> You can record the

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Gary Gregory 
On Sun, Aug 30, 2020 at 2:30 PM Phil Steitz  wrote:

>
> On 8/30/20 9:22 AM, Gary Gregory wrote:
> > Hm... would we need the flexibility of passing custom enums? For example,
> > CloseMode could be an interface implemented by various enums in the style
> > of the JRE's NIO public enum StandardOpenOption implements OpenOption?
> > We could have:
> > PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)
>
> Remember this is only called by the pool, so I don't see the need for
> custom enums, but it would be good to be able to add enum values so as
> you suggested we start with the simplest but then add more granularity
> as needed.
>

Phil,

Do you plan on providing this feature? I'm a bit busy with other components
and work ATM (aren't we all!)

Gary

>
> Phil
>
> > Where DestroyOption is an empty interface and we provide a
> > StandardDestroyOption enum that implements DestroyOption.
> > ?
> > Gary
> >
> > On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
> > wrote:
> >
> >> So concretely, we would
> >> add
> org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,
> >> CloseMode*) as a default method.
> >> [*] New enum
> >>
> >> ?
> >>
> >> Gary
> >>
> >>
> >> On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
> >> wrote:
> >>
> >>> On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
> >>> wrote:
> >>>
>  On 8/29/20 11:03 AM, Gary Gregory wrote:
> > On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 
>  wrote:
> >> A pool-related deadlock was reported recently in [1] to tomcat-user.
> >> The OP was using a different pool, but it looks to me like the same
> >> deadlock could happen with dbcp.  The source is arguably a driver
> bug,
> >> but in [2], the driver maintainer makes the good point that to avoid
>  the
> >> problem in [1] (and others like it) it would be better if pool
> >> maintainers used abort instead of close to disconnect "stuck" or
> >> abandoned connections.  That makes sense to me.
> >>
> >> To implement this in dbcp, we would need to either always use abort
> >> instead of close when closing physical connections (a bad idea, IMO,
>  as
> >> it could mess up counters due to async execution and add overhead)
> > I agree that changing the happy path from close() to abort() is a bad
>  idea;
> > especially since the Connection#close() Javadoc contract releases
>  database
> > resources while abort() does not or is vague about it (at least in
> the
>  Java
> > 8 Javadoc).
>  Yes, bad idea to do that, I think.
> 
> >
> >> or
> >> modify pool to call a different factory method than destroy when
> >> triggering close-abandoned.  I think the latter makes sense and it
>  could
> >> be useful for other pool clients to be able to this kind of thing as
>  well.
> > This means that we would treat abandoned connections like a real
>  resource
> > leak in the sense that (if) abort() leaks database resources, then
> the
>  DBA
> > would have to deal with that.
>  Yeah, unless the driver does it cleanly.  The other thing to note here
>  is that abort is async and is supposed to allow ops in progress to
>  complete, etc.  That is kinder to clients but technically allows
>  maxActive to exceed the cap while the abort is in progress.
> 
> > I think formally surfacing an abort path vs. the current
> close/destroy
>  is
> > OK since it reflects what JDBC allows. If that means trickling the
>  concept
> > down to Pool, then that's OK as well IMO. This could be generically
> > surfaced with a "close mode" enum passed to close/destroy APIs. This
> is
> > similar to what we did in HttpCore's CloseMode(IMMEDIATE vs
> GRACEFUL):
> >
> 
> https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html
> 
>  Exactly.  I think the abandoned-destroy is legitimately different from
>  the other destroy use cases and I could see other kinds of pools
>  (sockets, jms, etc) benefiting from having the ability to handle
> destroy
>  differently for abandoned (or other) cases.
> 
> >
> >> What I propose is that we make these change to pool:
> >>
> >>1. Add a new method to PooledObjectFactory called "abandonObject"
>  with
> >>   default implementation delegating to destroyObject.
> >>
> > That or overload destroyObject with a destroyObject(CloseMode) would
> be
> > easier to find.
>  Yes, I think that would be better.  That raises the interesting
> question
>  of what are the CloseModes.  All we need for this issue is normal vs
>  abandoned, but I can see value in providing fuller context to
>  factories.  So if we are doing it, why not something like:
> 
>  invalidated
>  abandoned
>  evicted
>  excess idle
>  failed validation
>  failed activation
>  failed

Re: [COMPRESS] Pack200 support in pack200 branch

2020-08-30 Thread Gary Gregory 
Hi All,

As the next step in the pack200 branch, I've renamed the package
org.apache.harmony to org.apache.commons.compress.harmony to more easily
track potential future changes. If this looks acceptable, it can be merged
and documented.

The builds are green here
https://github.com/apache/commons-compress/actions/runs/231719106

Gary


On Mon, Aug 24, 2020 at 11:14 AM Gary Gregory 
wrote:

> Thanks Peter, I updated the branch and the build passes for me locally,
> the CI is building now here
> https://github.com/apache/commons-compress/actions/runs/19115
>
> Gary
>
>
> On Sun, Aug 23, 2020 at 11:40 PM Peter Lee  wrote:
>
>> After some debugging I found this at
>> org.apache.harmony.pack200.Archive#171 :
>>
>> if (classes.size() > 0 && files.size() > 0) {
>> segmentUnitList.add(new SegmentUnit(classes, files));
>> }
>> Seems the Pack200 implementation in harmony requires existing of both
>> classes AND files at the same time. The tests are passing if I modified a
>> little bit here :
>>
>> if (classes.size() > 0 || files.size() > 0)
>> Not sure if this is a problem, cause I'm not familiar with Pack200 and
>> Apache Harmony.
>>
>> Lee
>> On 8 23 2020, at 11:27 , Gary Gregory  wrote:
>> > Hi All,
>> >
>> > I created a branch called *pack200* which contains the Apache Harmony
>> > Pack200 code.
>> >
>> > If there are 2 failing unit test ATM if anyone wants to help out.
>> > Gary
>
>

Re: [VOTE] Release Apache Commons Codec 1.15 based on RC1

2020-08-30 Thread Gary Gregory 
Ping.

On Fri, Aug 28, 2020, 08:34 Alex Herbert  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.14 was released, so I would like to release
> Apache Commons Codec 1.15.
>
> Apache Commons Codec 1.15 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1 (svn
> revision 41154 )
>
> The Git tag commons-codec-1.15-RC1 commit for this RC is
> c89d2af770f05457fbefa5fb4713c888bf177fb2 which you can browse here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=commons-codec.git;a=tag;h=refs/tags/commons-codec-1.15-RC1
>
> Maven artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1523/commons-codec/commons-codec/1.15/
>
> These are the Maven artifacts and their hashes in Nexus:
>
> #Release SHA-512s
> #Fri Aug 28 13:02:53 BST 2020
>
> commons-codec-1.15-bin.tar.gz=b6d517db15aedc424d112b8f3282c63f56aae66adaf317baf9853da65e291eb03fb5da51792aa437c7fdce63f6685c75373265e2a035b51e7525048716d7bfe3
>
> commons-codec-1.15-bin.zip=2495a5dcc2e57280882e8bb13972c1881b074e3e06ae13f45025c63e96cdc77c3af2a19f8417dce538172738eee31a3a8ce73227427b4f5db2214f18b71efc7d
>
> commons-codec-1.15-javadoc.jar=0aac697eb0d11b39013b458aa4ba24e5408b9f1435cbc12ebde9cabe39f8fb8fb37a84737a25b31f88f148cbf69a27c34e65952118cc7356511a1eefeb0a9497
>
> commons-codec-1.15-sources.jar=4c451f148d4c4c4f09e93aa12345dcf39e17ccba3c30f638a75a5df3af622e12595946619cb4553dffcc6f77d7ad43b1e216a637942e02da955a376150393804
>
> commons-codec-1.15-src.tar.gz=dcf0b86f269a96362dca5b36b9e764a07e390634804b359d4dbd1a0c50bfcc9f778e3797f196e1f553d76dd25b3c6fd016f0ffbbca856fa6c88d3d55791889ce
>
> commons-codec-1.15-src.zip=41f380634710cc5523426587de0cca7d06ba3b7933f8e1b488c85cbb58fb9e97e0ff48c09f2ae5f09b95f4f4994621d5bf9e60e3c08412b545b4bb6969dfcd95
>
> commons-codec-1.15-test-sources.jar=a77c00eb1a9d976b8f53536248a0c08d1e068b1634cf5ae232728ff01fd553ff9aa5832538fe99ae0017a0a71e11df86156fb6a576ef88a9c11571129094
>
> commons-codec-1.15-tests.jar=3c338b6f4e95d2cec4d16f140f5f4cf4de1ffac6128038bce3058266b7555f037566b6553729d1067caf42770ae1d35726f20837787366014bca5ae86e7f3ba9
>
>
> I have tested this with 'mvn clean test package site -Pjapicmp' using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/apache-maven-3.6.3
> Java version: 1.8.0_265, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-186-generic", arch: "amd64", family:
> "unix"
>
> Details of changes since 1.14 are in the release notes:
>
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/RELEASE-NOTES.txt
>
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/changes-report.html
>
> Site:
>
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/index.html
> (note some *relative* links are broken and the 1.15 directories are not
> yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.14):
>
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/japicmp.html
>
> RAT Report:
>
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch
> commons-codec-1.15-RC1 commons-codec-1.15-RC1
> cd commons-codec-1.15-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Newer components use JApiCmp with the japicmp Maven Profile:
>
> This step is not required if the site includes a JApiCmp report page which
> you then must check.
>
> mvn install -DskipTests -P japicmp japicmp:cmp
>
> 4) Build the package
>
> mvn -V clean package
>
> You can record the Maven and Java version produced by -V in your VOTE
> reply.
> To gather OS information from a command line:
> Windows: ver
> Linux: uname -a
>
> 5) Build the site for a single module project
>
> Note: Some plugins require the components to be installed instead of
> packaged.
>
> mvn site
> Check the site reports

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

2020-08-30 Thread Gary Gregory 
Ping.

On Fri, Aug 28, 2020, 16:35 Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Crypto 1.0.0 was released, so I would like to release
> Apache Commons Crypto 1.1.0.
>
> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> revision 41177)
>
> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Aug 28 16:20:02 EDT 2020
>
> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
>
> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
>
> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
>
> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
>
> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
>
> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
>
> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
>
> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> Docker to produce the various native binaries using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /opt/apache-maven-3.6.3
> Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"
>
> Details of changes since 1.0.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.1.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> *** JApiCmp Report (compared to 1.0.0):
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git --branch
> commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> cd commons-crypto-1.1.0-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page which
> you then must check.
>
> mvn clirr:check
>
> Newer components use JApiCmp with the japicmp Maven

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Bernd Eckenfels 
Hello,

A common case we saw are  missing keep alive with the oracle driver and a 
hanging read (due to destroyed connection state of firewall) or vip failover of 
sql server. Besides close we also tried rollback which is also affected of most 
drivers synchronized blocks.

--
https://Bernd.eckenfels.net

Von: Phil Steitz 
Gesendet: Sunday, August 30, 2020 8:27:04 PM
An: dev@commons.apache.org 
Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections?


On 8/29/20 9:58 PM, Bernd Eckenfels wrote:
> We have a pool implementation where we had to call abort especially for 
> revoked long running transactions, since they regularly have been locked up 
> in a connection wide synchronized in the close. However we only use it for 
> that case and try to close the objects after the abort anyway. We don’t use 
> it to close connections when they are only idle or too old - owned by the 
> pool.

Right.  I was thinking only of the abandoned case.

Interestingly, I have not been able to replicate the deadlock that
started me thinking about this.  I have always worried though about
problems with close hanging or deadlocking in the abandoned use case
where what is going on is a transaction is stuck or the abandoned
timeout is just set too low.

Phil

>
> It seems to be however still a good idea to run the abort/close in a separate 
> task as it can also take ages for example when TLS close handshakes hang (we 
> did try to reduce the connection timeout before but that also can be blocked 
> before the abort)
>
> Gruss
> Bernd
> --
> https://Bernd.eckenfels.net
> 
> Von: Gary Gregory 
> Gesendet: Saturday, August 29, 2020 10:02:42 PM
> An: Commons Developers List 
> Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned 
> connections?
>
> On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz  wrote:
>
>> On 8/29/20 11:03 AM, Gary Gregory wrote:
>>> On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 
>> wrote:
 A pool-related deadlock was reported recently in [1] to tomcat-user.
 The OP was using a different pool, but it looks to me like the same
 deadlock could happen with dbcp.  The source is arguably a driver bug,
 but in [2], the driver maintainer makes the good point that to avoid the
 problem in [1] (and others like it) it would be better if pool
 maintainers used abort instead of close to disconnect "stuck" or
 abandoned connections.  That makes sense to me.

 To implement this in dbcp, we would need to either always use abort
 instead of close when closing physical connections (a bad idea, IMO, as
 it could mess up counters due to async execution and add overhead)
>>> I agree that changing the happy path from close() to abort() is a bad
>> idea;
>>> especially since the Connection#close() Javadoc contract releases
>> database
>>> resources while abort() does not or is vague about it (at least in the
>> Java
>>> 8 Javadoc).
>> Yes, bad idea to do that, I think.
>>
>>>
 or
 modify pool to call a different factory method than destroy when
 triggering close-abandoned.  I think the latter makes sense and it could
 be useful for other pool clients to be able to this kind of thing as
>> well.
>>> This means that we would treat abandoned connections like a real resource
>>> leak in the sense that (if) abort() leaks database resources, then the
>> DBA
>>> would have to deal with that.
>> Yeah, unless the driver does it cleanly.  The other thing to note here
>> is that abort is async and is supposed to allow ops in progress to
>> complete, etc.  That is kinder to clients but technically allows
>> maxActive to exceed the cap while the abort is in progress.
>>
>>> I think formally surfacing an abort path vs. the current close/destroy is
>>> OK since it reflects what JDBC allows. If that means trickling the
>> concept
>>> down to Pool, then that's OK as well IMO. This could be generically
>>> surfaced with a "close mode" enum passed to close/destroy APIs. This is
>>> similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):
>>>
>> https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html
>>
>> Exactly.  I think the abandoned-destroy is legitimately different from
>> the other destroy use cases and I could see other kinds of pools
>> (sockets, jms, etc) benefiting from having the ability to handle destroy
>> differently for abandoned (or other) cases.
>>
>>>
 What I propose is that we make these change to pool:

1. Add a new method to PooledObjectFactory called "abandonObject" with
   default implementation delegating to destroyObject.

>>> That or overload destroyObject with a destroyObject(CloseMode) would be
>>> easier to find.
>> Yes, I think that would be better.  That raises the interesting question
>> of what are the CloseModes.  All we need for this issue is normal vs
>> abandoned, but I

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Phil Steitz 



On 8/30/20 9:22 AM, Gary Gregory wrote:

Hm... would we need the flexibility of passing custom enums? For example,
CloseMode could be an interface implemented by various enums in the style
of the JRE's NIO public enum StandardOpenOption implements OpenOption?
We could have:
PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)


Remember this is only called by the pool, so I don't see the need for 
custom enums, but it would be good to be able to add enum values so as 
you suggested we start with the simplest but then add more granularity 
as needed.


Phil


Where DestroyOption is an empty interface and we provide a
StandardDestroyOption enum that implements DestroyOption.
?
Gary

On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
wrote:


So concretely, we would
add org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,
CloseMode*) as a default method.
[*] New enum

?

Gary


On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
wrote:


On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid

the

problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO,

as

it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in the

Java

8 Javadoc).

Yes, bad idea to do that, I think.




or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it

could

be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real

resource

leak in the sense that (if) abort() leaks database resources, then the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current close/destroy

is

OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This is
similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):


https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle destroy
differently for abandoned (or other) cases.




What I propose is that we make these change to pool:

   1. Add a new method to PooledObjectFactory called "abandonObject"

with

  default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would be
easier to find.

Yes, I think that would be better.  That raises the interesting question
of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to support
the new behavior backed by Connection#abort() in DBCP.
A third "escape hatch" mode could see passing in a lamba I suppose. I
really think we should start by just focusing on the one issue at hand
before we enlarge the solution.

2c,
Gary



Phil




Gary



   2. Change the logic in removeAbandoned to call the new factory

method

  instead of destroyObject

And then in dbcp:

* Add implementation of abandonObject in PoolableConnectionFactory

to

  call abort.

wdyt?

Phil

[1]



https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomcat.apache.org%3E

[2] https://bugs.mysql.com/bug.php?id=64954

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Phil Steitz 



On 8/29/20 9:58 PM, Bernd Eckenfels wrote:

We have a pool implementation where we had to call abort especially for revoked 
long running transactions, since they regularly have been locked up in a 
connection wide synchronized in the close. However we only use it for that case 
and try to close the objects after the abort anyway. We don’t use it to close 
connections when they are only idle or too old - owned by the pool.


Right.  I was thinking only of the abandoned case.

Interestingly, I have not been able to replicate the deadlock that 
started me thinking about this.  I have always worried though about 
problems with close hanging or deadlocking in the abandoned use case 
where what is going on is a transaction is stuck or the abandoned 
timeout is just set too low.


Phil



It seems to be however still a good idea to run the abort/close in a separate 
task as it can also take ages for example when TLS close handshakes hang (we 
did try to reduce the connection timeout before but that also can be blocked 
before the abort)

Gruss
Bernd
--
https://Bernd.eckenfels.net

Von: Gary Gregory 
Gesendet: Saturday, August 29, 2020 10:02:42 PM
An: Commons Developers List 
Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections?

On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz  wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid the
problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO, as
it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in the

Java

8 Javadoc).

Yes, bad idea to do that, I think.




or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it could
be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real resource
leak in the sense that (if) abort() leaks database resources, then the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current close/destroy is
OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This is
similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):


https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle destroy
differently for abandoned (or other) cases.




What I propose is that we make these change to pool:

   1. Add a new method to PooledObjectFactory called "abandonObject" with
  default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would be
easier to find.

Yes, I think that would be better.  That raises the interesting question
of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to support
the new behavior backed by Connection#abort() in DBCP.
A third "escape hatch" mode could see passing in a lamba I suppose. I
really think we should start by just focusing on the one issue at hand
before we enlarge the solution.

2c,
Gary



Phil




Gary



   2. Change the logic in removeAbandoned to call the new factory method
  instead of destroyObject

And then in dbcp:

* Add

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Gary Gregory 
Hm... would we need the flexibility of passing custom enums? For example,
CloseMode could be an interface implemented by various enums in the style
of the JRE's NIO public enum StandardOpenOption implements OpenOption?
We could have:
PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)
Where DestroyOption is an empty interface and we provide a
StandardDestroyOption enum that implements DestroyOption.
?
Gary

On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
wrote:

> So concretely, we would
> add org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,
> CloseMode*) as a default method.
> [*] New enum
>
> ?
>
> Gary
>
>
> On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
> wrote:
>
>> On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
>> wrote:
>>
>>>
>>> On 8/29/20 11:03 AM, Gary Gregory wrote:
>>> > On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 
>>> wrote:
>>> >
>>> >> A pool-related deadlock was reported recently in [1] to tomcat-user.
>>> >> The OP was using a different pool, but it looks to me like the same
>>> >> deadlock could happen with dbcp.  The source is arguably a driver bug,
>>> >> but in [2], the driver maintainer makes the good point that to avoid
>>> the
>>> >> problem in [1] (and others like it) it would be better if pool
>>> >> maintainers used abort instead of close to disconnect "stuck" or
>>> >> abandoned connections.  That makes sense to me.
>>> >>
>>> >> To implement this in dbcp, we would need to either always use abort
>>> >> instead of close when closing physical connections (a bad idea, IMO,
>>> as
>>> >> it could mess up counters due to async execution and add overhead)
>>> >
>>> > I agree that changing the happy path from close() to abort() is a bad
>>> idea;
>>> > especially since the Connection#close() Javadoc contract releases
>>> database
>>> > resources while abort() does not or is vague about it (at least in the
>>> Java
>>> > 8 Javadoc).
>>>
>>> Yes, bad idea to do that, I think.
>>>
>>> >
>>> >
>>> >> or
>>> >> modify pool to call a different factory method than destroy when
>>> >> triggering close-abandoned.  I think the latter makes sense and it
>>> could
>>> >> be useful for other pool clients to be able to this kind of thing as
>>> well.
>>> >>
>>> > This means that we would treat abandoned connections like a real
>>> resource
>>> > leak in the sense that (if) abort() leaks database resources, then the
>>> DBA
>>> > would have to deal with that.
>>>
>>> Yeah, unless the driver does it cleanly.  The other thing to note here
>>> is that abort is async and is supposed to allow ops in progress to
>>> complete, etc.  That is kinder to clients but technically allows
>>> maxActive to exceed the cap while the abort is in progress.
>>>
>>> >
>>> > I think formally surfacing an abort path vs. the current close/destroy
>>> is
>>> > OK since it reflects what JDBC allows. If that means trickling the
>>> concept
>>> > down to Pool, then that's OK as well IMO. This could be generically
>>> > surfaced with a "close mode" enum passed to close/destroy APIs. This is
>>> > similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):
>>> >
>>> https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html
>>>
>>> Exactly.  I think the abandoned-destroy is legitimately different from
>>> the other destroy use cases and I could see other kinds of pools
>>> (sockets, jms, etc) benefiting from having the ability to handle destroy
>>> differently for abandoned (or other) cases.
>>>
>>> >
>>> >
>>> >> What I propose is that we make these change to pool:
>>> >>
>>> >>   1. Add a new method to PooledObjectFactory called "abandonObject"
>>> with
>>> >>  default implementation delegating to destroyObject.
>>> >>
>>> > That or overload destroyObject with a destroyObject(CloseMode) would be
>>> > easier to find.
>>>
>>> Yes, I think that would be better.  That raises the interesting question
>>> of what are the CloseModes.  All we need for this issue is normal vs
>>> abandoned, but I can see value in providing fuller context to
>>> factories.  So if we are doing it, why not something like:
>>>
>>> invalidated
>>> abandoned
>>> evicted
>>> excess idle
>>> failed validation
>>> failed activation
>>> failed passivation
>>> clearing pool
>>>
>>
>> I think a YAGNI-style approach would work well here by starting with 2
>> modes: one to support the current behavior (default) and another to support
>> the new behavior backed by Connection#abort() in DBCP.
>> A third "escape hatch" mode could see passing in a lamba I suppose. I
>> really think we should start by just focusing on the one issue at hand
>> before we enlarge the solution.
>>
>> 2c,
>> Gary
>>
>>
>>> Phil
>>>
>>>
>>>
>>> >
>>> > Gary
>>> >
>>> >
>>> >>   2. Change the logic in removeAbandoned to call the new factory
>>> method
>>> >>  instead of destroyObject
>>> >>
>>> >> And then in dbcp:
>>> >>
>>> >>* Add implementation of abandonObject in

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

2020-08-30 Thread Gary Gregory 
So concretely, we would
add org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,
CloseMode*) as a default method.
[*] New enum

?

Gary


On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory  wrote:

> On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz  wrote:
>
>>
>> On 8/29/20 11:03 AM, Gary Gregory wrote:
>> > On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 
>> wrote:
>> >
>> >> A pool-related deadlock was reported recently in [1] to tomcat-user.
>> >> The OP was using a different pool, but it looks to me like the same
>> >> deadlock could happen with dbcp.  The source is arguably a driver bug,
>> >> but in [2], the driver maintainer makes the good point that to avoid
>> the
>> >> problem in [1] (and others like it) it would be better if pool
>> >> maintainers used abort instead of close to disconnect "stuck" or
>> >> abandoned connections.  That makes sense to me.
>> >>
>> >> To implement this in dbcp, we would need to either always use abort
>> >> instead of close when closing physical connections (a bad idea, IMO, as
>> >> it could mess up counters due to async execution and add overhead)
>> >
>> > I agree that changing the happy path from close() to abort() is a bad
>> idea;
>> > especially since the Connection#close() Javadoc contract releases
>> database
>> > resources while abort() does not or is vague about it (at least in the
>> Java
>> > 8 Javadoc).
>>
>> Yes, bad idea to do that, I think.
>>
>> >
>> >
>> >> or
>> >> modify pool to call a different factory method than destroy when
>> >> triggering close-abandoned.  I think the latter makes sense and it
>> could
>> >> be useful for other pool clients to be able to this kind of thing as
>> well.
>> >>
>> > This means that we would treat abandoned connections like a real
>> resource
>> > leak in the sense that (if) abort() leaks database resources, then the
>> DBA
>> > would have to deal with that.
>>
>> Yeah, unless the driver does it cleanly.  The other thing to note here
>> is that abort is async and is supposed to allow ops in progress to
>> complete, etc.  That is kinder to clients but technically allows
>> maxActive to exceed the cap while the abort is in progress.
>>
>> >
>> > I think formally surfacing an abort path vs. the current close/destroy
>> is
>> > OK since it reflects what JDBC allows. If that means trickling the
>> concept
>> > down to Pool, then that's OK as well IMO. This could be generically
>> > surfaced with a "close mode" enum passed to close/destroy APIs. This is
>> > similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):
>> >
>> https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html
>>
>> Exactly.  I think the abandoned-destroy is legitimately different from
>> the other destroy use cases and I could see other kinds of pools
>> (sockets, jms, etc) benefiting from having the ability to handle destroy
>> differently for abandoned (or other) cases.
>>
>> >
>> >
>> >> What I propose is that we make these change to pool:
>> >>
>> >>   1. Add a new method to PooledObjectFactory called "abandonObject"
>> with
>> >>  default implementation delegating to destroyObject.
>> >>
>> > That or overload destroyObject with a destroyObject(CloseMode) would be
>> > easier to find.
>>
>> Yes, I think that would be better.  That raises the interesting question
>> of what are the CloseModes.  All we need for this issue is normal vs
>> abandoned, but I can see value in providing fuller context to
>> factories.  So if we are doing it, why not something like:
>>
>> invalidated
>> abandoned
>> evicted
>> excess idle
>> failed validation
>> failed activation
>> failed passivation
>> clearing pool
>>
>
> I think a YAGNI-style approach would work well here by starting with 2
> modes: one to support the current behavior (default) and another to support
> the new behavior backed by Connection#abort() in DBCP.
> A third "escape hatch" mode could see passing in a lamba I suppose. I
> really think we should start by just focusing on the one issue at hand
> before we enlarge the solution.
>
> 2c,
> Gary
>
>
>> Phil
>>
>>
>>
>> >
>> > Gary
>> >
>> >
>> >>   2. Change the logic in removeAbandoned to call the new factory method
>> >>  instead of destroyObject
>> >>
>> >> And then in dbcp:
>> >>
>> >>* Add implementation of abandonObject in PoolableConnectionFactory
>> to
>> >>  call abort.
>> >>
>> >> wdyt?
>> >>
>> >> Phil
>> >>
>> >> [1]
>> >>
>> >>
>> https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomcat.apache.org%3E
>> >>
>> >> [2] https://bugs.mysql.com/bug.php?id=64954
>> >>
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: 404 on https://commons.apache.org/proper/commons-lang/

2020-08-30 Thread Gary Gregory 
Fixed, thank you.

Gary


On Sun, Aug 30, 2020 at 1:02 AM Xeno Amess  wrote:

> The Javadoc API documents are available online:
>
>- The current stable release 3.11
>
>  
> [Java
>8 and up]
>- The legacy release 2.6
>
>  
> [Java
>1.2 and up]
>
>
> The link , current stable release 3.11, will return 404.
> (
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.11/index.html
> )
>
> BUT
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.10/index.html
> is good.
> So, looks like we forgot to host the apidoc for lang 3.11
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Gary Gregory 
On Sun, Aug 30, 2020 at 10:03 AM Rob Tompkins  wrote:

>
>
> > On Aug 30, 2020, at 10:00 AM, Gary Gregory 
> wrote:
> >
> > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  > wrote:
> >
> >>
> >>
> >>> On Aug 30, 2020, at 9:44 AM, sebb  seb...@gmail.com>> wrote:
> >>>
> >>> Some questions:
> >>>
> >>> - does it affect any existing usage?
> >>> i.e. can people continue to use the individual repos exactly as before
> >>
> >> no they can’t
> >>
> >
> > Yes they can... this would be a new repo, and changes nothing for current
> > usage. This does not affect existing repos.
>
> Oh…interesting. Then my head isn’t fully wrapped around the ideas at hand.
> I suppose that pulls me up to a +1 to see what ideas are at play.
>

Please have a quick read of the links I posted.

Gary


>
> -Rob
>
> >
> > Gary
> >
> >>
> >>>
> >>> - does it affect Git emails in any way?
> >>> e.g. do they have different text?
> >>
> >> same emails
> >>
> >>>
> >>> - will it need much maintenance?
> >>> If so, how do we know when it needs updating?
> >>
> >> more maintainance, have to maintain a git hash at a symlink pointing to
> an
> >> external repository
> >>
> >> -Rob
> >>
> >>>
> >>> On Sun, 30 Aug 2020 at 14:26, Gary Gregory 
> >> wrote:
> 
>  Yes yes "girl" -> "git"
> 
>  On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> >> wrote:
> 
> > I'm talking about girl's own submodules:
> >
> > https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >
> > https://git-scm.com/docs/git-submodule
> >
> > Gary
> >
> > On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> >
> >> By git submodules, are you talking about a symlink to another git
> >> repository inside one of our repositories?
> >>
> >> -Rob
> >>
> >>> On Aug 29, 2020, at 6:52 PM, Gary Gregory 
> >> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Any thoughts for or against creating a new git repository which
> would
> >>> contain all 'proper' Commons components as git submodules?
> >>>
> >>> The idea is to be able to checkout all of Commons 'proper' in one
> go
> >> in
> >> one
> >>> place.
> >>>
> >>> Gary
> >>
> >>
> >>
> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org  dev-unsubscr...@commons.apache.org>
> >> For additional commands, e-mail: dev-h...@commons.apache.org  dev-h...@commons.apache.org>
>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Rob Tompkins 


> On Aug 30, 2020, at 10:00 AM, Gary Gregory  wrote:
> 
> On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  > wrote:
> 
>> 
>> 
>>> On Aug 30, 2020, at 9:44 AM, sebb >> > wrote:
>>> 
>>> Some questions:
>>> 
>>> - does it affect any existing usage?
>>> i.e. can people continue to use the individual repos exactly as before
>> 
>> no they can’t
>> 
> 
> Yes they can... this would be a new repo, and changes nothing for current
> usage. This does not affect existing repos.

Oh…interesting. Then my head isn’t fully wrapped around the ideas at hand. I 
suppose that pulls me up to a +1 to see what ideas are at play.

-Rob

> 
> Gary
> 
>> 
>>> 
>>> - does it affect Git emails in any way?
>>> e.g. do they have different text?
>> 
>> same emails
>> 
>>> 
>>> - will it need much maintenance?
>>> If so, how do we know when it needs updating?
>> 
>> more maintainance, have to maintain a git hash at a symlink pointing to an
>> external repository
>> 
>> -Rob
>> 
>>> 
>>> On Sun, 30 Aug 2020 at 14:26, Gary Gregory 
>> wrote:
 
 Yes yes "girl" -> "git"
 
 On Sun, Aug 30, 2020, 09:24 Gary Gregory 
>> wrote:
 
> I'm talking about girl's own submodules:
> 
> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> 
> https://git-scm.com/docs/git-submodule
> 
> Gary
> 
> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> 
>> By git submodules, are you talking about a symlink to another git
>> repository inside one of our repositories?
>> 
>> -Rob
>> 
>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Any thoughts for or against creating a new git repository which would
>>> contain all 'proper' Commons components as git submodules?
>>> 
>>> The idea is to be able to checkout all of Commons 'proper' in one go
>> in
>> one
>>> place.
>>> 
>>> Gary
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Gary Gregory 
On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  wrote:

>
>
> > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> >
> > Some questions:
> >
> > - does it affect any existing usage?
> >  i.e. can people continue to use the individual repos exactly as before
>
> no they can’t
>

Yes they can... this would be a new repo, and changes nothing for current
usage. This does not affect existing repos.

Gary

>
> >
> > - does it affect Git emails in any way?
> >  e.g. do they have different text?
>
> same emails
>
> >
> > - will it need much maintenance?
> > If so, how do we know when it needs updating?
>
> more maintainance, have to maintain a git hash at a symlink pointing to an
> external repository
>
> -Rob
>
> >
> > On Sun, 30 Aug 2020 at 14:26, Gary Gregory 
> wrote:
> >>
> >> Yes yes "girl" -> "git"
> >>
> >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> wrote:
> >>
> >>> I'm talking about girl's own submodules:
> >>>
> >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >>>
> >>> https://git-scm.com/docs/git-submodule
> >>>
> >>> Gary
> >>>
> >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> >>>
>  By git submodules, are you talking about a symlink to another git
>  repository inside one of our repositories?
> 
>  -Rob
> 
> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>  wrote:
> >
> > Hi All,
> >
> > Any thoughts for or against creating a new git repository which would
> > contain all 'proper' Commons components as git submodules?
> >
> > The idea is to be able to checkout all of Commons 'proper' in one go
> in
>  one
> > place.
> >
> > Gary
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Bernd Eckenfels 
I don't mind if I don't have to maintain additional tracking revisions. If you 
check out all Repos once, you can easily do common work scripted across them, 
don't think a shared Repo root would help with that, but of course there is 
nothing speaking against it if you prefer that.

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

Von: Rob Tompkins 
Gesendet: Sunday, August 30, 2020 3:46:27 PM
An: Commons Developers List 
Betreff: Re: [All] New repo for all proper components as submodules?

I’m a +/0 here. I’ve always had a headache in dealing with this mechanism of 
dependency managment. I would think we’d do better to rely on on the default 
dependency management system of the language (e.g. maven). That said, when 
there is no other mechanism (maybe with C++), then submodules can be 
acceptable. But they are hard to manage for folks that aren’t particularly 
adept at git. If it is for C, our expectation of our contributers is that they 
be quite good, so in that case it is indeed ok.

 Thoughts?

-Rob

> On Aug 30, 2020, at 9:25 AM, Gary Gregory  wrote:
>
> Yes yes "girl" -> "git"
>
> On Sun, Aug 30, 2020, 09:24 Gary Gregory  wrote:
>
>> I'm talking about girl's own submodules:
>>
>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>>
>> https://git-scm.com/docs/git-submodule
>>
>> Gary
>>
>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>>
>>> By git submodules, are you talking about a symlink to another git
>>> repository inside one of our repositories?
>>>
>>> -Rob
>>>
 On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>>> wrote:

 Hi All,

 Any thoughts for or against creating a new git repository which would
 contain all 'proper' Commons components as git submodules?

 The idea is to be able to checkout all of Commons 'proper' in one go in
>>> one
 place.

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


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

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Rob Tompkins 



> On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> 
> Some questions:
> 
> - does it affect any existing usage?
>  i.e. can people continue to use the individual repos exactly as before

no they can’t

> 
> - does it affect Git emails in any way?
>  e.g. do they have different text?

same emails

> 
> - will it need much maintenance?
> If so, how do we know when it needs updating?

more maintainance, have to maintain a git hash at a symlink pointing to an 
external repository

-Rob

> 
> On Sun, 30 Aug 2020 at 14:26, Gary Gregory  wrote:
>> 
>> Yes yes "girl" -> "git"
>> 
>> On Sun, Aug 30, 2020, 09:24 Gary Gregory  wrote:
>> 
>>> I'm talking about girl's own submodules:
>>> 
>>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>>> 
>>> https://git-scm.com/docs/git-submodule
>>> 
>>> Gary
>>> 
>>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>>> 
 By git submodules, are you talking about a symlink to another git
 repository inside one of our repositories?
 
 -Rob
 
> On Aug 29, 2020, at 6:52 PM, Gary Gregory 
 wrote:
> 
> Hi All,
> 
> Any thoughts for or against creating a new git repository which would
> contain all 'proper' Commons components as git submodules?
> 
> The idea is to be able to checkout all of Commons 'proper' in one go in
 one
> place.
> 
> Gary
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Rob Tompkins 
I’m a +/0 here. I’ve always had a headache in dealing with this mechanism of 
dependency managment. I would think we’d do better to rely on on the default 
dependency management system of the language (e.g. maven). That said, when 
there is no other mechanism (maybe with C++), then submodules can be 
acceptable. But they are hard to manage for folks that aren’t particularly 
adept at git. If it is for C, our expectation of our contributers is that they 
be quite good, so in that case it is indeed ok.

 Thoughts?

-Rob

> On Aug 30, 2020, at 9:25 AM, Gary Gregory  wrote:
> 
> Yes yes "girl" -> "git"
> 
> On Sun, Aug 30, 2020, 09:24 Gary Gregory  wrote:
> 
>> I'm talking about girl's own submodules:
>> 
>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>> 
>> https://git-scm.com/docs/git-submodule
>> 
>> Gary
>> 
>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>> 
>>> By git submodules, are you talking about a symlink to another git
>>> repository inside one of our repositories?
>>> 
>>> -Rob
>>> 
 On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>>> wrote:
 
 Hi All,
 
 Any thoughts for or against creating a new git repository which would
 contain all 'proper' Commons components as git submodules?
 
 The idea is to be able to checkout all of Commons 'proper' in one go in
>>> one
 place.
 
 Gary
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 


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

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread sebb 
Some questions:

- does it affect any existing usage?
  i.e. can people continue to use the individual repos exactly as before

- does it affect Git emails in any way?
  e.g. do they have different text?

- will it need much maintenance?
 If so, how do we know when it needs updating?

On Sun, 30 Aug 2020 at 14:26, Gary Gregory  wrote:
>
> Yes yes "girl" -> "git"
>
> On Sun, Aug 30, 2020, 09:24 Gary Gregory  wrote:
>
> > I'm talking about girl's own submodules:
> >
> > https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >
> > https://git-scm.com/docs/git-submodule
> >
> > Gary
> >
> > On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> >
> >> By git submodules, are you talking about a symlink to another git
> >> repository inside one of our repositories?
> >>
> >> -Rob
> >>
> >> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
> >> wrote:
> >> >
> >> > Hi All,
> >> >
> >> > Any thoughts for or against creating a new git repository which would
> >> > contain all 'proper' Commons components as git submodules?
> >> >
> >> > The idea is to be able to checkout all of Commons 'proper' in one go in
> >> one
> >> > place.
> >> >
> >> > Gary
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>

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

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Gary Gregory 
Yes yes "girl" -> "git"

On Sun, Aug 30, 2020, 09:24 Gary Gregory  wrote:

> I'm talking about girl's own submodules:
>
> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>
> https://git-scm.com/docs/git-submodule
>
> Gary
>
> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>
>> By git submodules, are you talking about a symlink to another git
>> repository inside one of our repositories?
>>
>> -Rob
>>
>> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>> wrote:
>> >
>> > Hi All,
>> >
>> > Any thoughts for or against creating a new git repository which would
>> > contain all 'proper' Commons components as git submodules?
>> >
>> > The idea is to be able to checkout all of Commons 'proper' in one go in
>> one
>> > place.
>> >
>> > Gary
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Gary Gregory 
I'm talking about girl's own submodules:

https://git-scm.com/book/en/v2/Git-Tools-Submodules

https://git-scm.com/docs/git-submodule

Gary

On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:

> By git submodules, are you talking about a symlink to another git
> repository inside one of our repositories?
>
> -Rob
>
> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
> wrote:
> >
> > Hi All,
> >
> > Any thoughts for or against creating a new git repository which would
> > contain all 'proper' Commons components as git submodules?
> >
> > The idea is to be able to checkout all of Commons 'proper' in one go in
> one
> > place.
> >
> > Gary
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Xeno Amess 
Ohhh
I misunderstand your thought lol.
I thought you wanna make a repo which can we ensure all commons projects
can build/run smothly together, without dependency-hell.

Gary Gregory  于2020年8月30日周日 下午8:59写道：

> My goal is not to duplicate Gump, this is about convenience of seeing and
> tracking all of Commons Proper.
>
> Gary
>
> On Sun, Aug 30, 2020, 00:50 Xeno Amess  wrote:
>
> > I doubt it can pass ci at any time...
> >
> >
> > Gary Gregory  于 2020年8月30日周日 上午6:52写道：
> >
> > > Hi All,
> > >
> > > Any thoughts for or against creating a new git repository which would
> > > contain all 'proper' Commons components as git submodules?
> > >
> > > The idea is to be able to checkout all of Commons 'proper' in one go in
> > one
> > > place.
> > >
> > > Gary
> > >
> >
>

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Rob Tompkins 
By git submodules, are you talking about a symlink to another git repository 
inside one of our repositories?

-Rob

> On Aug 29, 2020, at 6:52 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> Any thoughts for or against creating a new git repository which would
> contain all 'proper' Commons components as git submodules?
> 
> The idea is to be able to checkout all of Commons 'proper' in one go in one
> place.
> 
> Gary


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

Re: [All] New repo for all proper components as submodules?

2020-08-30 Thread Gary Gregory 
My goal is not to duplicate Gump, this is about convenience of seeing and
tracking all of Commons Proper.

Gary

On Sun, Aug 30, 2020, 00:50 Xeno Amess  wrote:

> I doubt it can pass ci at any time...
>
>
> Gary Gregory  于 2020年8月30日周日 上午6:52写道：
>
> > Hi All,
> >
> > Any thoughts for or against creating a new git repository which would
> > contain all 'proper' Commons components as git submodules?
> >
> > The idea is to be able to checkout all of Commons 'proper' in one go in
> one
> > place.
> >
> > Gary
> >
>