[GitHub] [tomcat] KeiichiFujino commented on issue #140: jdbc-pool: Improve maxAge handling

2019-03-17 Thread GitBox
KeiichiFujino commented on issue #140: jdbc-pool: Improve maxAge handling
URL: https://github.com/apache/tomcat/pull/140#issuecomment-473776997
 
 
   Thanks for the fix.
   I have no objections to the current code.
   I'll merge this into master branch.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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



Re: Default Number of Test Threads

2019-03-17 Thread Igal Sapir
Chris,

On Sat, Mar 16, 2019 at 8:22 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Igal,
>
> On 3/15/19 22:38, Igal Sapir wrote:
> > Chris,
> >
> > On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >> Igal,
> >>
> >> On 3/15/19 16:45, Igal Sapir wrote:
> >>>  I looked deeper into build.xml and I found some
> >>> interesting information and a simple solution for my issue.  In
> >>> build.xml we have the following:
> >>>
> >>>   >>> file="build.properties"/>  >>> file="build.properties.default"/>
> >>>
> >>> So I can place my settings for test.threads in
> >>> ~/build.properties.
> >>>
> >>> The current order of precedence, however, gives
> >>> ${user.home}/build.properties a higher priority than the one
> >>> at {tomcat}/build.properties.
> >>>
> >>> That is wrong IMHO and should be the other way around, i.e.
> >>> {tomcat}/build.properties should
> >>> override${user.home}/build.properties .  I would like to
> >>> change that order if everyone agrees.
> >>
> >> I do not agree. The local configuration (~/build.properties)
> >> should override the default configuration (build.properties).
> >> That's why it's called "local configuration".
> >>
> >> Besides, if you implement your proposed switch, then you will be
> >> UNABLE to use ~/build.properties to customize this configuration
> >> that you don't like.
> >>
> >
> > Perhaps I'm missing something, but I think that the term "Local"
> > is ambiguous here, so I will avoid using it to prevent confusion.
> > We have (applied in order):
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > Instance Config: {tomcat}/build.properties 3) System
> > Config..: {user.home}/build.properties
> >
> > Tomcat only ships with the Project Default Config file.  The other
> > two are optional and can be created by the user.
> >
> > Suppose that I usually want to run tests with 8 threads.  I can
> > set `test.threads=8` in the System Config file and each time I
> > download a new version of Tomcat I simply run `ant test` in the
> > directory of that instance.  It will run with 8 threads, resolving
> > my original issue here.
> >
> > But, if now I download a version and want to run only that one with
> > 4 threads (a more likely scenario would be to set different
> > versions or paths for OpenSSL), I can not simply set the new value
> > for the Instance Configuration, {tomcat}/build.properties, to
> > affect only that instance -- I have to modify the System Config,
> > which will change the settings for all other instances.
> >
> > The way I see it, the System Config is Default for the system, and
> > each instance should be able to specify its own Instance
> > Configuration which will override both the Project's Defaults and
> > the System Defaults.  My proposal is therefore that the order of
> > applying the settings will be:
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > System Config..: {user.home}/build.properties 3) Instance
> > Config: {tomcat}/build.properties
> >
> > That way I do not need to add an Instance Config anywhere unless a
> > specific instance requires unique settings.  I can set my System
> > Config (~/build.properties) with the values that I normally use,
> > and only override them with an Instance Config, i.e.
> > {tomcat}/build.properties where needed.
> >
> > What am I missing?
>
> Just remember that ant properties are write-once, so all your orders
> above are backward. If you want the instance config to override all
> others, you'll have to load it first.
>

You are right.  I tried to simplify my example with pseudo-config that has
a "last value wins", but that probably caused more confusion, so I'll try
to avoid that in the future.


>
> Nobody is going to agree on this, so maybe:
>
> {tomcat}/build.first.properties
> {user.home}/build.properties (which is a really weird default, IMO)
> {tomcat}/build.properties
> {tomcat}/build.default.properties
>
> This preserves the current behavior in all environments and allows you
> to have your new type of overriding configuration.
>

I don't think that I would use `build.first.properties` if I have to create
or copy it to the {tomcat} directory each time.

If anything, I would prefer to specify a path to a properties file, e.g.
`build.properties.file` or something like that, which will be read first.
That will allow me to have multiple properties file at the home directory,
and specify them as needed.  For example, I could then add a file named
`{user.home}/build.properties.tomcat7` with Tomcat 7-specific settings in
it, and then point to it in ANT_OPTS for Tomcat 7 tests.

If I'm the only one who thinks that that would be useful then there's no
need to change anything.  I can set a few properties that I usually use,
e.g. `test.threads` and 

[GUMP@vmgump-vm3]: Project tomcat-tc7.0.x-validate (in module tomcat-7.0.x) failed

2019-03-17 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc7.0.x-validate has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc7.0.x-validate :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-validate.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 sec
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-build-libs 
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar
 -Dexecute.validate=true validate 
[Working Directory: /srv/gump/public/workspace/tomcat-7.0.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/commons-beanutils/dist/commons-beanutils-20190318.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.9-SNAPSHOT.jar:/srv/gump/pu
 
blic/workspace/apache-commons/logging/target/commons-logging-20190318.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20190318.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-HEAD-jre-SNAPSHOT.jar
-
Buildfile: /srv/gump/public/workspace/tomcat-7.0.x/build.xml

build-prepare:
   [delete] Deleting directory 
/srv/gump/public/workspace/tomcat-7.0.x/output/build/temp
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-7.0.x/output/build/temp

compile-prepare:

download-validate:

proxyflags:

setproxy:

testexist:
 [echo] Testing  for 
/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar

downloadfile:

validate:
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-7.0.x/output/res/checkstyle

BUILD FAILED
/srv/gump/public/workspace/tomcat-7.0.x/build.xml:548: Unable to create Root 
Module: config {res/checkstyle/checkstyle.xml}, classpath {null}.

Total time: 1 second
-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/rss.xml
- Atom: 
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 2019031807, vmgump-vm3.apache.org:vmgump:2019031807
Gump E-mail Identifier (unique within run) #5.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump-vm3]

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



[GUMP@vmgump-vm3]: Project tomcat-tc7.0.x-test-apr (in module tomcat-7.0.x) failed

2019-03-17 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc7.0.x-test-apr has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc7.0.x-test-apr :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-test-apr/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-7.0.x/output/logs-APR
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-7.0.x/output/test-tmp-APR/logs



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-test-apr/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test-apr.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test-apr (Type: Build)
Work ended in a state of : Failed
Elapsed: 20 mins 28 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-3.1-SNAPSHOT.jar
 -Dtest.reports=output/logs-APR -Dexamples.sources.skip=true 
-Dbase.path=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-build-libs 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar
 
-Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-1.2-1.0.2/dest-20190317/lib
 -Dtest.relaxTiming=true 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
 -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false 
-Dtest.exclude=**/TestFlushableGZIPOutputStream.java -Dexecute.test.bio=false 
-Dexecute.test.apr=true -Dtes
 t.excludePerformance=true 
-Deasymock.jar=/srv/gump/packages/easymock3/easymock-3.6.jar 
-Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar 
-Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-7.0.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-dbcp.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/
 
tomcat7-websocket.jar:/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar:/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar:/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar:/srv/gump/packages/cglib/cglib-nodep-2.2.jar:/srv/gump/public

[tomcat] branch 7.0.x updated: Add missing @Deprecated annotations

2019-03-17 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 25d385d  Add missing @Deprecated annotations
25d385d is described below

commit 25d385d83c12db28907122ca73b064b484f1aaa1
Author: Mark Thomas 
AuthorDate: Sun Mar 17 22:34:57 2019 +

Add missing @Deprecated annotations
---
 java/org/apache/tomcat/dbcp/dbcp/DbcpException.java   | 1 +
 java/org/apache/tomcat/dbcp/dbcp/DelegatingCallableStatement.java | 1 +
 java/org/apache/tomcat/dbcp/dbcp/DelegatingPreparedStatement.java | 1 +
 java/org/apache/tomcat/dbcp/dbcp/DelegatingResultSet.java | 4 
 java/org/apache/tomcat/dbcp/dbcp/PoolingDriver.java   | 1 +
 java/org/apache/tomcat/dbcp/dbcp/SQLNestedException.java  | 1 +
 java/org/apache/tomcat/dbcp/pool/impl/StackObjectPoolFactory.java | 1 +
 7 files changed, 10 insertions(+)

diff --git a/java/org/apache/tomcat/dbcp/dbcp/DbcpException.java 
b/java/org/apache/tomcat/dbcp/dbcp/DbcpException.java
index eb72203..3a95383 100644
--- a/java/org/apache/tomcat/dbcp/dbcp/DbcpException.java
+++ b/java/org/apache/tomcat/dbcp/dbcp/DbcpException.java
@@ -28,6 +28,7 @@ package org.apache.tomcat.dbcp.dbcp;
  * 
  * @deprecated This will be removed in a future version of DBCP.
  **/
+@Deprecated
 public class DbcpException extends RuntimeException {
 
 private static final long serialVersionUID = 2477800549022838103L;
diff --git a/java/org/apache/tomcat/dbcp/dbcp/DelegatingCallableStatement.java 
b/java/org/apache/tomcat/dbcp/dbcp/DelegatingCallableStatement.java
index 0fc5938..0b5f50b 100644
--- a/java/org/apache/tomcat/dbcp/dbcp/DelegatingCallableStatement.java
+++ b/java/org/apache/tomcat/dbcp/dbcp/DelegatingCallableStatement.java
@@ -138,6 +138,7 @@ public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
 { checkOpen(); try { return ((CallableStatement)_stmt).getDouble( 
parameterIndex); } catch (SQLException e) { handleException(e); return 0; } }
 
 /** @deprecated */
+@Deprecated
 @Override
 public BigDecimal getBigDecimal(int parameterIndex, int scale) throws 
SQLException
 { checkOpen(); try { return ((CallableStatement)_stmt).getBigDecimal( 
parameterIndex,  scale); } catch (SQLException e) { handleException(e); return 
null; } }
diff --git a/java/org/apache/tomcat/dbcp/dbcp/DelegatingPreparedStatement.java 
b/java/org/apache/tomcat/dbcp/dbcp/DelegatingPreparedStatement.java
index ac33296..706deb4 100644
--- a/java/org/apache/tomcat/dbcp/dbcp/DelegatingPreparedStatement.java
+++ b/java/org/apache/tomcat/dbcp/dbcp/DelegatingPreparedStatement.java
@@ -179,6 +179,7 @@ public class DelegatingPreparedStatement extends 
DelegatingStatement
 { checkOpen(); try { 
((PreparedStatement)_stmt).setAsciiStream(parameterIndex,x,length); } catch 
(SQLException e) { handleException(e); } }
 
 /** @deprecated */
+@Deprecated
 @Override
 public void setUnicodeStream(int parameterIndex, java.io.InputStream x, 
int length) throws SQLException
 { checkOpen(); try { 
((PreparedStatement)_stmt).setUnicodeStream(parameterIndex,x,length); } catch 
(SQLException e) { handleException(e); } }
diff --git a/java/org/apache/tomcat/dbcp/dbcp/DelegatingResultSet.java 
b/java/org/apache/tomcat/dbcp/dbcp/DelegatingResultSet.java
index a2738fb..2812f12 100644
--- a/java/org/apache/tomcat/dbcp/dbcp/DelegatingResultSet.java
+++ b/java/org/apache/tomcat/dbcp/dbcp/DelegatingResultSet.java
@@ -249,6 +249,7 @@ public class DelegatingResultSet extends AbandonedTrace 
implements ResultSet {
 { try { return _res.getDouble(columnIndex); } catch (SQLException e) { 
handleException(e); return 0; } }
 
 /** @deprecated */
+@Deprecated
 @Override
 public BigDecimal getBigDecimal(int columnIndex, int scale) throws 
SQLException
 { try { return _res.getBigDecimal(columnIndex); } catch (SQLException e) { 
handleException(e); return null; } }
@@ -274,6 +275,7 @@ public class DelegatingResultSet extends AbandonedTrace 
implements ResultSet {
 { try { return _res.getAsciiStream(columnIndex); } catch (SQLException e) 
{ handleException(e); return null; } }
 
 /** @deprecated */
+@Deprecated
 @Override
 public InputStream getUnicodeStream(int columnIndex) throws SQLException
 { try { return _res.getUnicodeStream(columnIndex); } catch (SQLException 
e) { handleException(e); return null; } }
@@ -315,6 +317,7 @@ public class DelegatingResultSet extends AbandonedTrace 
implements ResultSet {
 { try { return _res.getDouble(columnName); } catch (SQLException e) { 
handleException(e); return 0; } }
 
 /** @deprecated */
+@Deprecated
 @Override
 public BigDecimal getBigDecimal(String columnName, int scale) throws 
SQLException
 { try { return _res.getBigDecimal(columnName); } catch (SQLException e) 

Re: Wiki migration

2019-03-17 Thread Mark Thomas

It was a permission issue. I've just fixed that.

Mark


On 17/03/2019 20:02, Tim Funk wrote:

Hmm ...

Either I don't have permissions to make edits, or I need read a tutorial. I
was going to delete some obvious spam pages which were migrated and then
start moving other questionable pages to a sandbox to be debated later.

I signed up via my apache email address.

-Tim



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



Re: Wiki migration

2019-03-17 Thread Tim Funk
Hmm ...

Either I don't have permissions to make edits, or I need read a tutorial. I
was going to delete some obvious spam pages which were migrated and then
start moving other questionable pages to a sandbox to be debated later.

I signed up via my apache email address.

-Tim


Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 19:35, Gaël Lalire  a
écrit :

>
> Le 17 mars 2019 à 16:22, Romain Manni-Bucau  a
> écrit :
>
> > Le dim. 17 mars 2019 à 14:51, Gaël Lalire  a
> > écrit :
> >
> >>
> >> Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a
> >> écrit :
> >>
> >>> Le dim. 17 mars 2019 à 12:56, Gaël Lalire 
> a
> >>> écrit :
> >>>
>  Hello Romain,
> 
>  I already explained why I do not want to give file or jar:file URL,
> even
>  if I have it.
>  Maven resolver is giving me File, I create a VestigeJar from it
> 
> >>
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
>  I also create a mvn: URL accessible through getCodeBase however it is
>  only for policy permission you should not use openStream on it
> >> (although I
>  had to make it possible to get BouncyCastle working).
> 
> >>>
> >>> I get that but it also can conflict with other resolver using mvn:,
> open
> >>> new security issues and break some libs - speaking having dropped a lib
> >>> doing exactly that at work for all these reasons.
> >>
> >> mvn: was implemented two weeks before, it is only for ProtectionDomain.
> >> And ProtectionDomain is used by almost no library.
> >> VestigeClassloader send vrt: URL. These ones start with / and does not
> >> break libraries relying on context URL.
> >> It will break those expecting jar:file URL though but Java9 with its
> jrt:
> >> URL will also break them, so I don't care.
> >>
> >
> > Paxurl uses it for a long tile. Also jrt is different cause excluded from
> > most scanner - it is only the jvm - whereas your jars are not excluded
> and
> > scanning will fail. Check out spring, weld, openwebbeans etc...
> >
>
> I mean implemented in Vestige. I use a sub format of Paxurl (no
> repository, no version range).
> Also I could use vmvn: instead, as I said it's only for code base URL.
>
> Scanning in openwebbeans will not work because it is expecting an
> URLClassLoader or using java.class.path property.
> Java9 is not providing URLClassLoader ... these scanners must evolve.
>


No, it uses getResources to find root urls then unpack the url to find the
folders and jars to scan.

Look jboss vfs, it has extensions in all frameworks for that and this is
why this kind of impl will not match much app until it becomes mainstream
(or $$) IMHO.


> I see 2 types of scanning :
> - hinted one -> for example with beans.xml. These ones can be written to
> be working only using clean Java (context URL will do the job).
>

You still need to scan the jar even with a beans.xml

- blind one -> searching for annotations in all jars. These ones have to
> hack the system to find all jars (there is no listAllJar in classloader),
> they should provide an API so its container can give it the jar list, and
> by jar list I think of  something like (InputStream, JarName, JarSize)
> rather than a JarFile or URL.
>


This is what cdi is and what sole spring config does.


> >
> >
> >>>
> >>>
>  I think that SecureClassLoader is not secure enough because it only
> >> checks
>  classes not resources.
>  In a world using XML to create, configure and link instances (Spring),
> >> it
>  is terrible to let resources unchecked.
> 
>  That's also why VestigeClassLoader#getResource is returning vrt: URL
> and
>  not jar:file: URL.
> 
> >>>
> >>> Classloaders generally check in their own calls, not in the resource
> >>> itself. Can' t you validate the resource before actually reasing it?
> >> Sounds
> >>> saner and closer to security manager common configs.
> >>
> >> Yes but it is not secure even with read lock.
> >> The read lock is on the file not the path. You can remove and even
> replace
> >> the file while the read lock is still here.
> >> So my check succeeds, I give a jar:file URL then the file is replaced,
> the
> >> jar:file is open and get the new file (hacked one).
> >>
> >
> > Sounds like you want to implement a jvm filesystem and not a new url
> > handler explained this way otherwise you still have this issue with other
> > concurrent accesses.
> >
>
> I have not yet implemented it.
> Concurrent accesses can be solved in multiple ways :
> - open a new RandomAccessFile each time and check the signature each time
> (probably the slowest way)
> - create a cache system
> - share the RandomAccessFile and synchronize read calls between each
> InputStream
>
> vrt format is
> vrt:/[ClassLoaderNumber]/[JarOfClassLoaderNumber]!/[PathOfFile]
> for example
> vrt:/56/3!/META-INF/MANIFEST.MF
>
> I don't see it as a file system.
>


If you do you can embrace jar url then no more issue anywhere, you build a
symb link solution :).


>
> >
> >>>
> >>>
>  The easiest way to implements War Maven artifacts deployment is to use
>  directly Maven resolver API and give file or jar:file URL to Tomcat.
> 
> >>>
> >>> Or war: since tomcat supports it.
> >>
> >> Of course
> >>
> >>>
> >>>
> >>>

Re: War Maven artifacts deployment

2019-03-17 Thread Gaël Lalire

Le 17 mars 2019 à 16:22, Romain Manni-Bucau  a écrit :

> Le dim. 17 mars 2019 à 14:51, Gaël Lalire  a
> écrit :
> 
>> 
>> Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a
>> écrit :
>> 
>>> Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
>>> écrit :
>>> 
 Hello Romain,
 
 I already explained why I do not want to give file or jar:file URL, even
 if I have it.
 Maven resolver is giving me File, I create a VestigeJar from it
 
>> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
 I also create a mvn: URL accessible through getCodeBase however it is
 only for policy permission you should not use openStream on it
>> (although I
 had to make it possible to get BouncyCastle working).
 
>>> 
>>> I get that but it also can conflict with other resolver using mvn:, open
>>> new security issues and break some libs - speaking having dropped a lib
>>> doing exactly that at work for all these reasons.
>> 
>> mvn: was implemented two weeks before, it is only for ProtectionDomain.
>> And ProtectionDomain is used by almost no library.
>> VestigeClassloader send vrt: URL. These ones start with / and does not
>> break libraries relying on context URL.
>> It will break those expecting jar:file URL though but Java9 with its jrt:
>> URL will also break them, so I don't care.
>> 
> 
> Paxurl uses it for a long tile. Also jrt is different cause excluded from
> most scanner - it is only the jvm - whereas your jars are not excluded and
> scanning will fail. Check out spring, weld, openwebbeans etc...
> 

I mean implemented in Vestige. I use a sub format of Paxurl (no repository, no 
version range).
Also I could use vmvn: instead, as I said it's only for code base URL.

Scanning in openwebbeans will not work because it is expecting an 
URLClassLoader or using java.class.path property.
Java9 is not providing URLClassLoader ... these scanners must evolve.

I see 2 types of scanning :
- hinted one -> for example with beans.xml. These ones can be written to be 
working only using clean Java (context URL will do the job).
- blind one -> searching for annotations in all jars. These ones have to hack 
the system to find all jars (there is no listAllJar in classloader), they 
should provide an API so its container can give it the jar list, and by jar 
list I think of  something like (InputStream, JarName, JarSize) rather than a 
JarFile or URL.

> 
> 
>>> 
>>> 
 I think that SecureClassLoader is not secure enough because it only
>> checks
 classes not resources.
 In a world using XML to create, configure and link instances (Spring),
>> it
 is terrible to let resources unchecked.
 
 That's also why VestigeClassLoader#getResource is returning vrt: URL and
 not jar:file: URL.
 
>>> 
>>> Classloaders generally check in their own calls, not in the resource
>>> itself. Can' t you validate the resource before actually reasing it?
>> Sounds
>>> saner and closer to security manager common configs.
>> 
>> Yes but it is not secure even with read lock.
>> The read lock is on the file not the path. You can remove and even replace
>> the file while the read lock is still here.
>> So my check succeeds, I give a jar:file URL then the file is replaced, the
>> jar:file is open and get the new file (hacked one).
>> 
> 
> Sounds like you want to implement a jvm filesystem and not a new url
> handler explained this way otherwise you still have this issue with other
> concurrent accesses.
> 

I have not yet implemented it.
Concurrent accesses can be solved in multiple ways :
- open a new RandomAccessFile each time and check the signature each time 
(probably the slowest way)
- create a cache system
- share the RandomAccessFile and synchronize read calls between each InputStream

vrt format is
vrt:/[ClassLoaderNumber]/[JarOfClassLoaderNumber]!/[PathOfFile]
for example
vrt:/56/3!/META-INF/MANIFEST.MF

I don't see it as a file system.


> 
>>> 
>>> 
 The easiest way to implements War Maven artifacts deployment is to use
 directly Maven resolver API and give file or jar:file URL to Tomcat.
 
>>> 
>>> Or war: since tomcat supports it.
>> 
>> Of course
>> 
>>> 
>>> 
>>> 
 I could have done that, but guess what, I'm willing to give TomEE EAR
 Maven artifacts deployment after Tomcat.
 In the TomEE my company uses there is a horrible CLASSPATH because they
 wanted to avoid RMI call between EAR.
 That is where Vestige is useful, it allows to choose which jar(s) should
 be shared without any global impact.
 
>>> 
>>> Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
>>> about it cause all is there to do it afaik.
>> 
>> Thanks for the pointer, I will check it because I really don't like global
>> CLASSPATH.
>> For my business case it will almost certainly work, however I'm pretty
>> sure it has not the power of Vestige.
>> I don't know if you chose to create 

buildbot success in on tomcat-7-trunk

2019-03-17 Thread buildbot
The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1295

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] dfe07f0599d14b97ffa41d9c486dc7e17fffd72d
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




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



[tomcat] branch 7.0.x updated: Code clean-up. Remove unnecessary casts.

2019-03-17 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new dfe07f0  Code clean-up. Remove unnecessary casts.
dfe07f0 is described below

commit dfe07f0599d14b97ffa41d9c486dc7e17fffd72d
Author: Mark Thomas 
AuthorDate: Sun Mar 17 17:20:06 2019 +

Code clean-up. Remove unnecessary casts.
---
 java/org/apache/catalina/valves/ErrorReportValve.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/catalina/valves/ErrorReportValve.java 
b/java/org/apache/catalina/valves/ErrorReportValve.java
index dc3e6e9..8ca0b40 100644
--- a/java/org/apache/catalina/valves/ErrorReportValve.java
+++ b/java/org/apache/catalina/valves/ErrorReportValve.java
@@ -116,7 +116,7 @@ public class ErrorReportValve extends ValveBase {
 // Close immediately to signal to the client that something 
went
 // wrong
 response.getCoyoteResponse().action(ActionCode.CLOSE_NOW,
-(Throwable) 
request.getAttribute(RequestDispatcher.ERROR_EXCEPTION));
+
request.getAttribute(RequestDispatcher.ERROR_EXCEPTION));
 }
 return;
 }


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



[tomcat] branch 7.0.x updated: Update changelog

2019-03-17 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new b5e4a0f  Update changelog
b5e4a0f is described below

commit b5e4a0f92a50184013894ddb74cb3728ecc6082d
Author: Mark Thomas 
AuthorDate: Sun Mar 17 17:18:28 2019 +

Update changelog
---
 webapps/docs/changelog.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 174a05a..e812a97 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -152,6 +152,10 @@
 Update the copy of Apache Commons Pool to 1.6.x to pick up the generics
 changes. (markt)
   
+  
+Add JDBC 4.1 support to the default database connection pool provided 
by
+Tomcat. (markt)
+  
 
   
 


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



[tomcat] branch 7.0.x updated (9a1a15d -> 1ed5e0e)

2019-03-17 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 9a1a15d  Remove the unnecessary JDBC 4.0 markers since Java 6 is 
minimum version
 new 6706da0  Add JDBC 4.1 support when running on Java 7 or later
 new 1ed5e0e  Add JreCompat to the util JAR and have tomcat-dbcp depend on 
it

The 11906 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 build.xml  |   2 +
 .../dbcp/dbcp/DelegatingCallableStatement.java |  13 +-
 .../tomcat/dbcp/dbcp/DelegatingConnection.java |  36 ++-
 .../dbcp/dbcp/DelegatingDatabaseMetaData.java  |   9 +-
 .../tomcat/dbcp/dbcp/DelegatingResultSet.java  |   7 +-
 .../tomcat/dbcp/dbcp/DelegatingStatement.java  |  15 +-
 java/org/apache/tomcat/util/compat/Jre7Compat.java | 265 -
 java/org/apache/tomcat/util/compat/JreCompat.java  |  94 
 java/org/apache/tomcat/util/compat/TLS.java|   6 +-
 res/checkstyle/org-import-control.xml  |   2 +
 res/maven/tomcat-dbcp.pom  |   8 +
 11 files changed, 429 insertions(+), 28 deletions(-)


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



Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 14:51, Gaël Lalire  a
écrit :

>
> Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a
> écrit :
>
> > Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
> > écrit :
> >
> >> Hello Romain,
> >>
> >> I already explained why I do not want to give file or jar:file URL, even
> >> if I have it.
> >> Maven resolver is giving me File, I create a VestigeJar from it
> >>
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
> >> I also create a mvn: URL accessible through getCodeBase however it is
> >> only for policy permission you should not use openStream on it
> (although I
> >> had to make it possible to get BouncyCastle working).
> >>
> >
> > I get that but it also can conflict with other resolver using mvn:, open
> > new security issues and break some libs - speaking having dropped a lib
> > doing exactly that at work for all these reasons.
>
> mvn: was implemented two weeks before, it is only for ProtectionDomain.
> And ProtectionDomain is used by almost no library.
> VestigeClassloader send vrt: URL. These ones start with / and does not
> break libraries relying on context URL.
> It will break those expecting jar:file URL though but Java9 with its jrt:
> URL will also break them, so I don't care.
>

Paxurl uses it for a long tile. Also jrt is different cause excluded from
most scanner - it is only the jvm - whereas your jars are not excluded and
scanning will fail. Check out spring, weld, openwebbeans etc...



> >
> >
> >> I think that SecureClassLoader is not secure enough because it only
> checks
> >> classes not resources.
> >> In a world using XML to create, configure and link instances (Spring),
> it
> >> is terrible to let resources unchecked.
> >>
> >> That's also why VestigeClassLoader#getResource is returning vrt: URL and
> >> not jar:file: URL.
> >>
> >
> > Classloaders generally check in their own calls, not in the resource
> > itself. Can' t you validate the resource before actually reasing it?
> Sounds
> > saner and closer to security manager common configs.
>
> Yes but it is not secure even with read lock.
> The read lock is on the file not the path. You can remove and even replace
> the file while the read lock is still here.
> So my check succeeds, I give a jar:file URL then the file is replaced, the
> jar:file is open and get the new file (hacked one).
>

Sounds like you want to implement a jvm filesystem and not a new url
handler explained this way otherwise you still have this issue with other
concurrent accesses.


> >
> >
> >> The easiest way to implements War Maven artifacts deployment is to use
> >> directly Maven resolver API and give file or jar:file URL to Tomcat.
> >>
> >
> > Or war: since tomcat supports it.
>
> Of course
>
> >
> >
> >
> >> I could have done that, but guess what, I'm willing to give TomEE EAR
> >> Maven artifacts deployment after Tomcat.
> >> In the TomEE my company uses there is a horrible CLASSPATH because they
> >> wanted to avoid RMI call between EAR.
> >> That is where Vestige is useful, it allows to choose which jar(s) should
> >> be shared without any global impact.
> >>
> >
> > Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
> > about it cause all is there to do it afaik.
>
> Thanks for the pointer, I will check it because I really don't like global
> CLASSPATH.
> For my business case it will almost certainly work, however I'm pretty
> sure it has not the power of Vestige.
> I don't know if you chose to create one classloader grouping all jars in
> jar.txt in which case you will have issues when a library is deployed in 2
> different versions.
> Or if you chose to create one classloader per entry in jar.txt in which
> case the jar will be missing its dependencies unless you expect them to be
> in MANIFEST.MF.
>
> In Maven repositories Class-Path is generally not set in MANIFEST.MF.
>


Jars.txt is just a way to add jars in the classloader it is present in -
webapp or ear lib one - without putting the files physically there. It is
close to old configurable tolcat classloader and new webresource
abstraction which can do it as well.


> >
> >
> >> You have 3 scopes and 2 modes in Vestige.
> >> Mode CLASSPATH is creating one classloader with all jars inside, not
> easy
> >> to share.
> >> Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies
> >> some good practice (use of context classloader for example).
> >>
> >> After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to
> get
> >> it shared, this scope implies some other good practice (static field
> >> immutable for example).
> >>
> >> About memory issue, I don't get your point.
> >> I will not keep all jars content in memory I will use shared locks
> (fcntl)
> >> to keep the content of RandomAccessFile the way it was when I checked
> it.
> >> VestigeJar#open will create an InputStream reading from this locked
> >> RandomAccessFile.
> >>
> >
> > Oki but 

Re: War Maven artifacts deployment

2019-03-17 Thread Gaël Lalire

Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a écrit :

> Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
> écrit :
> 
>> Hello Romain,
>> 
>> I already explained why I do not want to give file or jar:file URL, even
>> if I have it.
>> Maven resolver is giving me File, I create a VestigeJar from it
>> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
>> I also create a mvn: URL accessible through getCodeBase however it is
>> only for policy permission you should not use openStream on it (although I
>> had to make it possible to get BouncyCastle working).
>> 
> 
> I get that but it also can conflict with other resolver using mvn:, open
> new security issues and break some libs - speaking having dropped a lib
> doing exactly that at work for all these reasons.

mvn: was implemented two weeks before, it is only for ProtectionDomain. And 
ProtectionDomain is used by almost no library.
VestigeClassloader send vrt: URL. These ones start with / and does not break 
libraries relying on context URL.
It will break those expecting jar:file URL though but Java9 with its jrt: URL 
will also break them, so I don't care.

> 
> 
>> I think that SecureClassLoader is not secure enough because it only checks
>> classes not resources.
>> In a world using XML to create, configure and link instances (Spring), it
>> is terrible to let resources unchecked.
>> 
>> That's also why VestigeClassLoader#getResource is returning vrt: URL and
>> not jar:file: URL.
>> 
> 
> Classloaders generally check in their own calls, not in the resource
> itself. Can' t you validate the resource before actually reasing it? Sounds
> saner and closer to security manager common configs.

Yes but it is not secure even with read lock.
The read lock is on the file not the path. You can remove and even replace the 
file while the read lock is still here.
So my check succeeds, I give a jar:file URL then the file is replaced, the 
jar:file is open and get the new file (hacked one).

> 
> 
>> The easiest way to implements War Maven artifacts deployment is to use
>> directly Maven resolver API and give file or jar:file URL to Tomcat.
>> 
> 
> Or war: since tomcat supports it.

Of course

> 
> 
> 
>> I could have done that, but guess what, I'm willing to give TomEE EAR
>> Maven artifacts deployment after Tomcat.
>> In the TomEE my company uses there is a horrible CLASSPATH because they
>> wanted to avoid RMI call between EAR.
>> That is where Vestige is useful, it allows to choose which jar(s) should
>> be shared without any global impact.
>> 
> 
> Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
> about it cause all is there to do it afaik.

Thanks for the pointer, I will check it because I really don't like global 
CLASSPATH.
For my business case it will almost certainly work, however I'm pretty sure it 
has not the power of Vestige.
I don't know if you chose to create one classloader grouping all jars in 
jar.txt in which case you will have issues when a library is deployed in 2 
different versions.
Or if you chose to create one classloader per entry in jar.txt in which case 
the jar will be missing its dependencies unless you expect them to be in 
MANIFEST.MF.

In Maven repositories Class-Path is generally not set in MANIFEST.MF.

> 
> 
>> You have 3 scopes and 2 modes in Vestige.
>> Mode CLASSPATH is creating one classloader with all jars inside, not easy
>> to share.
>> Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies
>> some good practice (use of context classloader for example).
>> 
>> After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to get
>> it shared, this scope implies some other good practice (static field
>> immutable for example).
>> 
>> About memory issue, I don't get your point.
>> I will not keep all jars content in memory I will use shared locks (fcntl)
>> to keep the content of RandomAccessFile the way it was when I checked it.
>> VestigeJar#open will create an InputStream reading from this locked
>> RandomAccessFile.
>> 
> 
> Oki but then you are in jar:file mode ;)

In a way, but I give only the InputStream not the URL so the JarURLConnection 
of JarScannerCallback can't be fetched.

> 
> 
>> Regards,
>> Gaël Lalire
>> 
>> Le 17 mars 2019 à 10:17, Romain Manni-Bucau  a
>> écrit :
>> 
>> Hi Gaël,
>> 
>> In Tomee we plugged before to enrich the classloader and then tomcat -and
>> other libs - works normally using jar urls.
>> 
>> Cant you use a listener to do that and convert m2 urls to plain jar files -
>> at the end it is local files i guess otherwise you generally consume too
>> much memory to be prod friendly?
>> 
>> 
>> Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
>> écrit :
>> 
>> Hello Tomcat developers,
>> 
>> I made a software to enable update of Java applications named Vestige.
>> To achieve that, Vestige use Maven, downloading Maven artifacts and
>> creating classloaders linked with 

Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
écrit :

> Hello Romain,
>
> I already explained why I do not want to give file or jar:file URL, even
> if I have it.
> Maven resolver is giving me File, I create a VestigeJar from it
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
> I also create a mvn: URL accessible through getCodeBase however it is
> only for policy permission you should not use openStream on it (although I
> had to make it possible to get BouncyCastle working).
>

I get that but it also can conflict with other resolver using mvn:, open
new security issues and break some libs - speaking having dropped a lib
doing exactly that at work for all these reasons.


> I think that SecureClassLoader is not secure enough because it only checks
> classes not resources.
> In a world using XML to create, configure and link instances (Spring), it
> is terrible to let resources unchecked.
>
> That's also why VestigeClassLoader#getResource is returning vrt: URL and
> not jar:file: URL.
>

Classloaders generally check in their own calls, not in the resource
itself. Can' t you validate the resource before actually reasing it? Sounds
saner and closer to security manager common configs.


> The easiest way to implements War Maven artifacts deployment is to use
> directly Maven resolver API and give file or jar:file URL to Tomcat.
>

Or war: since tomcat supports it.



> I could have done that, but guess what, I'm willing to give TomEE EAR
> Maven artifacts deployment after Tomcat.
> In the TomEE my company uses there is a horrible CLASSPATH because they
> wanted to avoid RMI call between EAR.
> That is where Vestige is useful, it allows to choose which jar(s) should
> be shared without any global impact.
>

Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
about it cause all is there to do it afaik.


> You have 3 scopes and 2 modes in Vestige.
> Mode CLASSPATH is creating one classloader with all jars inside, not easy
> to share.
> Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies
> some good practice (use of context classloader for example).
>
> After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to get
> it shared, this scope implies some other good practice (static field
> immutable for example).
>
> About memory issue, I don't get your point.
> I will not keep all jars content in memory I will use shared locks (fcntl)
> to keep the content of RandomAccessFile the way it was when I checked it.
> VestigeJar#open will create an InputStream reading from this locked
> RandomAccessFile.
>

Oki but then you are in jar:file mode ;)


> Regards,
> Gaël Lalire
>
> Le 17 mars 2019 à 10:17, Romain Manni-Bucau  a
> écrit :
>
> Hi Gaël,
>
> In Tomee we plugged before to enrich the classloader and then tomcat -and
> other libs - works normally using jar urls.
>
> Cant you use a listener to do that and convert m2 urls to plain jar files -
> at the end it is local files i guess otherwise you generally consume too
> much memory to be prod friendly?
>
>
> Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
> écrit :
>
> Hello Tomcat developers,
>
> I made a software to enable update of Java applications named Vestige.
> To achieve that, Vestige use Maven, downloading Maven artifacts and
> creating classloaders linked with jar inside m2 repository.
>
> I made it to update my IBM notes connector (POP access provider).
>
> The fact it is downloading Maven artifacts makes the assembly
> (jar-with-dependencies of maven-assembly-plugin) of the connector not
> mandatory.
>
> In a business project I saw that war artifacts were filling the
> repository, so they had to regularly remove older version from it.
> I thought it would be great if we could remove the WEB-INF/lib from the
> published war and still be able to deploy it with Tomcat.
>
> I did that, the WebResource API helps me a lot.
> However I had to disable JarScanner API (tld & fragments) because it's
> using JarURLConnection and my API is not providing jar:file: nor file: URL.
> My API won't provide them because I want to be able to check a pgp
> signature before any use of an artifact in m2 repository.
> If I check the signature and send a jar:file: or file: URL it won't be
> secure because there is no way to prevent the modification of the file
> after the check.
> To be secure I will probably lock the file for reading, then check the
> signature, and give locked InputStream.
>
> I would like you to change the JarScanner API/Impl so it won't rely on
> JarURLConnection anymore (maybe WebResource ?).
> Also I have to replace some Tomcat classes (
>
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13
> )
> that is not future proof.
> Could you provide some extension(s) so I could do the same thing without
> replacing any Tomcat class ?
>
> Hoping that you get interested enough 

Re: War Maven artifacts deployment

2019-03-17 Thread Gaël Lalire
Hello Romain,

I already explained why I do not want to give file or jar:file URL, even if I 
have it.
Maven resolver is giving me File, I create a VestigeJar from it 
https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
I also create a mvn: URL accessible through getCodeBase however it is only for 
policy permission you should not use openStream on it (although I had to make 
it possible to get BouncyCastle working).

I think that SecureClassLoader is not secure enough because it only checks 
classes not resources.
In a world using XML to create, configure and link instances (Spring), it is 
terrible to let resources unchecked.

That's also why VestigeClassLoader#getResource is returning vrt: URL and not 
jar:file: URL.

The easiest way to implements War Maven artifacts deployment is to use directly 
Maven resolver API and give file or jar:file URL to Tomcat.

I could have done that, but guess what, I'm willing to give TomEE EAR Maven 
artifacts deployment after Tomcat.
In the TomEE my company uses there is a horrible CLASSPATH because they wanted 
to avoid RMI call between EAR.
That is where Vestige is useful, it allows to choose which jar(s) should be 
shared without any global impact.

You have 3 scopes and 2 modes in Vestige.
Mode CLASSPATH is creating one classloader with all jars inside, not easy to 
share.
Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies some 
good practice (use of context classloader for example).

After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to get it 
shared, this scope implies some other good practice (static field immutable for 
example).

About memory issue, I don't get your point.
I will not keep all jars content in memory I will use shared locks (fcntl) to 
keep the content of RandomAccessFile the way it was when I checked it.
VestigeJar#open will create an InputStream reading from this locked 
RandomAccessFile.

Regards,
Gaël Lalire

Le 17 mars 2019 à 10:17, Romain Manni-Bucau  a écrit :

> Hi Gaël,
> 
> In Tomee we plugged before to enrich the classloader and then tomcat -and
> other libs - works normally using jar urls.
> 
> Cant you use a listener to do that and convert m2 urls to plain jar files -
> at the end it is local files i guess otherwise you generally consume too
> much memory to be prod friendly?
> 
> 
> Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
> écrit :
> 
>> Hello Tomcat developers,
>> 
>> I made a software to enable update of Java applications named Vestige.
>> To achieve that, Vestige use Maven, downloading Maven artifacts and
>> creating classloaders linked with jar inside m2 repository.
>> 
>> I made it to update my IBM notes connector (POP access provider).
>> 
>> The fact it is downloading Maven artifacts makes the assembly
>> (jar-with-dependencies of maven-assembly-plugin) of the connector not
>> mandatory.
>> 
>> In a business project I saw that war artifacts were filling the
>> repository, so they had to regularly remove older version from it.
>> I thought it would be great if we could remove the WEB-INF/lib from the
>> published war and still be able to deploy it with Tomcat.
>> 
>> I did that, the WebResource API helps me a lot.
>> However I had to disable JarScanner API (tld & fragments) because it's
>> using JarURLConnection and my API is not providing jar:file: nor file: URL.
>> My API won't provide them because I want to be able to check a pgp
>> signature before any use of an artifact in m2 repository.
>> If I check the signature and send a jar:file: or file: URL it won't be
>> secure because there is no way to prevent the modification of the file
>> after the check.
>> To be secure I will probably lock the file for reading, then check the
>> signature, and give locked InputStream.
>> 
>> I would like you to change the JarScanner API/Impl so it won't rely on
>> JarURLConnection anymore (maybe WebResource ?).
>> Also I have to replace some Tomcat classes (
>> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13)
>> that is not future proof.
>> Could you provide some extension(s) so I could do the same thing without
>> replacing any Tomcat class ?
>> 
>> Hoping that you get interested enough to help me improve the Maven
>> artifact deployment support, I send you my best regards.
>> 
>> PS:
>> You can test the vwar, an xml which describes the war to deploy
>> (essentially repository URL, groupId, artifactId, version), deployment by :
>> - download (https://gaellalire.fr/vestige/) & install & run Vestige
>> - go to http://localhost:8480/
>> - click on install
>> - write "tomcat" in repository application name
>> - write "8.0.32" in repository application version
>> - write "tc" in local application name
>> - click install button
>> - click play button
>> - go to http://localhost:8080/mywar/hello (servlet test) and
>> http://localhost:8080/mywar/hi.jsp?max=5 (jsp 

buildbot failure in on tomcat-7-trunk

2019-03-17 Thread buildbot
The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1294

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] 9a1a15dbb6ec9be33b46f04edd91cad9cbe47f9a
Blamelist: Mark Thomas 

BUILD FAILED: failed compile

Sincerely,
 -The Buildbot




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



Re: [tomcat] branch 7.0.x updated (a3d815c -> 9a1a15d)

2019-03-17 Thread Mark Thomas
On 17/03/2019 10:52, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> markt pushed a change to branch 7.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
> 
> 
> from a3d815c  Don't exclude the ide support sample files for idea when 
> packaging the src for a release
>  new 8334104  Add JDBC 4.1 methods so Tomcat 7 compiles with Java 7 
> onwards

Hmm.

That didn't work to well. I'll try again...

Mark

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



[tomcat] branch 7.0.x updated (a3d815c -> 9a1a15d)

2019-03-17 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from a3d815c  Don't exclude the ide support sample files for idea when 
packaging the src for a release
 new 8334104  Add JDBC 4.1 methods so Tomcat 7 compiles with Java 7 onwards
 new 9a1a15d  Remove the unnecessary JDBC 4.0 markers since Java 6 is 
minimum version

The 11904 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../apache/tomcat/dbcp/dbcp/BasicDataSource.java   | 12 +--
 .../dbcp/dbcp/DelegatingCallableStatement.java | 31 ++---
 .../tomcat/dbcp/dbcp/DelegatingConnection.java | 39 ++
 .../dbcp/dbcp/DelegatingDatabaseMetaData.java  | 31 ++---
 .../dbcp/dbcp/DelegatingPreparedStatement.java |  4 ---
 .../tomcat/dbcp/dbcp/DelegatingResultSet.java  | 26 ---
 .../tomcat/dbcp/dbcp/DelegatingStatement.java  | 16 +++--
 .../apache/tomcat/dbcp/dbcp/PoolingDataSource.java | 12 +--
 .../org/apache/tomcat/dbcp/dbcp/PoolingDriver.java | 10 ++
 .../dbcp/dbcp/cpdsadapter/DriverAdapterCPDS.java   | 10 ++
 .../dbcp/cpdsadapter/PooledConnectionImpl.java |  6 
 .../dbcp/datasources/InstanceKeyDataSource.java| 12 +--
 12 files changed, 173 insertions(+), 36 deletions(-)


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



Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Hi Gaël,

In Tomee we plugged before to enrich the classloader and then tomcat -and
other libs - works normally using jar urls.

Cant you use a listener to do that and convert m2 urls to plain jar files -
at the end it is local files i guess otherwise you generally consume too
much memory to be prod friendly?


Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
écrit :

> Hello Tomcat developers,
>
> I made a software to enable update of Java applications named Vestige.
> To achieve that, Vestige use Maven, downloading Maven artifacts and
> creating classloaders linked with jar inside m2 repository.
>
> I made it to update my IBM notes connector (POP access provider).
>
> The fact it is downloading Maven artifacts makes the assembly
> (jar-with-dependencies of maven-assembly-plugin) of the connector not
> mandatory.
>
> In a business project I saw that war artifacts were filling the
> repository, so they had to regularly remove older version from it.
> I thought it would be great if we could remove the WEB-INF/lib from the
> published war and still be able to deploy it with Tomcat.
>
> I did that, the WebResource API helps me a lot.
> However I had to disable JarScanner API (tld & fragments) because it's
> using JarURLConnection and my API is not providing jar:file: nor file: URL.
> My API won't provide them because I want to be able to check a pgp
> signature before any use of an artifact in m2 repository.
> If I check the signature and send a jar:file: or file: URL it won't be
> secure because there is no way to prevent the modification of the file
> after the check.
> To be secure I will probably lock the file for reading, then check the
> signature, and give locked InputStream.
>
> I would like you to change the JarScanner API/Impl so it won't rely on
> JarURLConnection anymore (maybe WebResource ?).
> Also I have to replace some Tomcat classes (
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13)
> that is not future proof.
> Could you provide some extension(s) so I could do the same thing without
> replacing any Tomcat class ?
>
> Hoping that you get interested enough to help me improve the Maven
> artifact deployment support, I send you my best regards.
>
> PS:
> You can test the vwar, an xml which describes the war to deploy
> (essentially repository URL, groupId, artifactId, version), deployment by :
> - download (https://gaellalire.fr/vestige/) & install & run Vestige
> - go to http://localhost:8480/
> - click on install
> - write "tomcat" in repository application name
> - write "8.0.32" in repository application version
> - write "tc" in local application name
> - click install button
> - click play button
> - go to http://localhost:8080/mywar/hello (servlet test) and
> http://localhost:8080/mywar/hi.jsp?max=5 (jsp test)
>
> The vwar will be at $VESTIGE_BASE/app/tc/webapps/mywar.vwar
> Where $VESTIGE_BASE is :
> - $HOME/Vestige on Mac OS X
> - $HOME/vestige on Linux
> - %userprofile%\Vestige on Windows
> - the place you unzip the file if you chose to install the standalone
> version (a ZIP file)
>
> You can also see it at
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/blob/master/installer/src/main/resources/mywar.vwar
>
> tomcat_vestige sources at
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige
> tomcat_vestige descriptor at
> https://gaellalire.fr/vestige/repository/tomcat/tomcat-8.0.32.xml
> mywar sources at https://gaellalire.fr/gitlab/vestige_app/mywar (its pom
> https://gaellalire.fr/gitlab/vestige_app/mywar/blob/master/pom.xml
> excludes lib folder)
>
>


War Maven artifacts deployment

2019-03-17 Thread Gaël Lalire
Hello Tomcat developers,

I made a software to enable update of Java applications named Vestige.
To achieve that, Vestige use Maven, downloading Maven artifacts and creating 
classloaders linked with jar inside m2 repository.

I made it to update my IBM notes connector (POP access provider).

The fact it is downloading Maven artifacts makes the assembly 
(jar-with-dependencies of maven-assembly-plugin) of the connector not mandatory.

In a business project I saw that war artifacts were filling the repository, so 
they had to regularly remove older version from it.
I thought it would be great if we could remove the WEB-INF/lib from the 
published war and still be able to deploy it with Tomcat.

I did that, the WebResource API helps me a lot.
However I had to disable JarScanner API (tld & fragments) because it's using 
JarURLConnection and my API is not providing jar:file: nor file: URL.
My API won't provide them because I want to be able to check a pgp signature 
before any use of an artifact in m2 repository.
If I check the signature and send a jar:file: or file: URL it won't be secure 
because there is no way to prevent the modification of the file after the check.
To be secure I will probably lock the file for reading, then check the 
signature, and give locked InputStream.

I would like you to change the JarScanner API/Impl so it won't rely on 
JarURLConnection anymore (maybe WebResource ?).
Also I have to replace some Tomcat classes 
(https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13)
 that is not future proof.
Could you provide some extension(s) so I could do the same thing without 
replacing any Tomcat class ?

Hoping that you get interested enough to help me improve the Maven artifact 
deployment support, I send you my best regards.

PS:
You can test the vwar, an xml which describes the war to deploy (essentially 
repository URL, groupId, artifactId, version), deployment by :
- download (https://gaellalire.fr/vestige/) & install & run Vestige
- go to http://localhost:8480/
- click on install
- write "tomcat" in repository application name
- write "8.0.32" in repository application version
- write "tc" in local application name
- click install button
- click play button
- go to http://localhost:8080/mywar/hello (servlet test) and 
http://localhost:8080/mywar/hi.jsp?max=5 (jsp test)

The vwar will be at $VESTIGE_BASE/app/tc/webapps/mywar.vwar
Where $VESTIGE_BASE is :
- $HOME/Vestige on Mac OS X
- $HOME/vestige on Linux
- %userprofile%\Vestige on Windows
- the place you unzip the file if you chose to install the standalone version 
(a ZIP file)

You can also see it at 
https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/blob/master/installer/src/main/resources/mywar.vwar

tomcat_vestige sources at 
https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige
tomcat_vestige descriptor at 
https://gaellalire.fr/vestige/repository/tomcat/tomcat-8.0.32.xml
mywar sources at https://gaellalire.fr/gitlab/vestige_app/mywar (its pom 
https://gaellalire.fr/gitlab/vestige_app/mywar/blob/master/pom.xml excludes lib 
folder)



signature.asc
Description: Message signed with OpenPGP using GPGMail


[GUMP@vmgump-vm3]: Project tomcat-tc7.0.x (in module tomcat-7.0.x) failed

2019-03-17 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc7.0.x has an issue affecting its community integration.
This issue affects 4 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-test-apr :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...
- tomcat-tc7.0.x-test-bio :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...
- tomcat-tc7.0.x-test-nio :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on junit exists, no need to add for property junit.jar.
 -INFO- Optional dependency tomcat-tc7.0.x-validate failed with reason build 
failed
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar
 -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
 -Dbase.path=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-build-libs 
[Working Directory: /srv/gump/public/workspace/tomcat-7.0.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar:/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar:/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
-
[javac]   ^
[javac]   where T is a type-variable:
[javac] T extends Object declared in class Class
[javac] 
/srv/gump/public/workspace/tomcat-7.0.x/java/org/apache/tomcat/dbcp/jocl/ConstructorUtil.java:60:
 warning: [unchecked] unchecked call to isAssignableFrom(Class) as a member 
of the raw type Class
[javac] 
if(paramtypes[j].isAssignableFrom(argTypes[j])) {
[javac]  ^
[javac] 
/srv/gump/public/workspace/tomcat-7.0.x/java/org/apache/tomcat/dbcp/jocl/JOCLContentHandler.java:497:
 warning: [unchecked] unchecked call to add(E) as a member of the raw type 
ArrayList
[javac] _typeList.add(temp.getType());
[javac]  ^
[javac]   where E is a type-variable:
[javac] E extends Object declared in class ArrayList
[javac] 
/srv/gump/public/workspace/tomcat-7.0.x/java/org/apache/tomcat/dbcp/jocl/JOCLContentHandler.java:498:
 warning: [unchecked] unchecked call to add(E) as a member of the raw type 
ArrayList
[javac] _valueList.add(temp.createObject());
[javac]   ^
[javac]   where E is a type-variable:
[javac] E extends Object declared in class ArrayList
[javac] 
/srv/gump/public/workspace/tomcat-7.0.x/java/org/apache/tomcat/dbcp/jocl/JOCLContentHandler.java:599:
 warning: [unchecked] unchecked call to add(E) as a member of the raw type 
ArrayList
[javac] _typeList.add(type);
[javac]  ^
[javac]   where E is a type-variable:
[javac] E extends Object declared in class ArrayList
[javac] 
/srv/gump/public/workspace/tomcat-7.0.x/java/org/apache/tomcat/dbcp/jocl/JOCLContentHandler.java:600:
 warning: 

Bug report for Tomcat 8 [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|53930|Opn|Enh|2012-09-24|allow capture of catalina stdout/stderr to a comma|
|55243|New|Enh|2013-07-11|Add special search string for nested roles|
|55252|New|Enh|2013-07-12|Separate Ant and command-line wrappers for JspC   |
|55383|New|Enh|2013-08-07|Improve markup and design of Tomcat's HTML pages  |
|9|New|Enh|2013-09-14|UserDatabaseRealm enhacement: may use local JNDI  |
|55675|New|Enh|2013-10-18|Checking and handling invalid configuration option|
|55788|New|Enh|2013-11-16|TagPlugins should key on tag QName rather than imp|
|55969|New|Enh|2014-01-07|Security-related enhancements to the Windows Insta|
|56166|New|Enh|2014-02-20|Suggestions for exception handling (avoid potentia|
|56361|New|Enh|2014-04-08|org.apache.tomcat.websocket.WsWebSocketContainer#b|
|56398|New|Enh|2014-04-11|Support Arquillian-based unit testing |
|56399|New|Enh|2014-04-11|Re-factor request/response recycling so Coyote and|
|56402|New|Enh|2014-04-11|Add support for HTTP Upgrade to AJP components|
|56448|New|Enh|2014-04-23|Implement a robust solution for client initiated S|
|56522|Opn|Enh|2014-05-14|jasper-el 8 does not comply to EL Spec 3.0 regardi|
|56546|New|Enh|2014-05-19|Improve thread trace logging in WebappClassLoader.|
|56713|New|Enh|2014-07-12|Limit time that incoming request waits while webap|
|56724|New|Enh|2014-07-15|Restart Container background thread if it died une|
|56890|Inf|Maj|2014-08-26|getRealPath returns null  |
|56966|New|Enh|2014-09-11|AccessLogValve's elapsed time has 15ms precision o|
|57130|New|Enh|2014-10-22|Allow digest.sh to accept password from a file or |
|57287|New|Enh|2014-11-29|Sort files listed by DefaultServlet   |
|57421|New|Enh|2015-01-07|Farming default directories   |
|57486|New|Enh|2015-01-23|Improve reuse of ProtectedFunctionMapper instances|
|57665|New|Enh|2015-03-05|support x-forwarded-host  |
|57701|New|Enh|2015-03-13|Implement "[Redeploy]" button for a web applicatio|
|57830|New|Enh|2015-04-18|Add support for ProxyProtocol |
|58052|Opn|Enh|2015-06-19|RewriteValve: Implement additional RewriteRule dir|
|58072|New|Enh|2015-06-23|ECDH curve selection  |
|58143|Opn|Enh|2015-07-15|The WebppClassLoader doesn't call transformers on |
|58577|New|Enh|2015-11-03|JMX Proxy Servlet can't handle overloaded methods |
|58837|New|Enh|2016-01-12|support "X-Content-Security-Policy" a.k.a as "CSP"|
|58935|Opn|Enh|2016-01-29|Re-deploy from war without deleting context   |
|59232|New|Enh|2016-03-24|Make the context name of an app available via JNDI|
|59423|New|Enh|2016-05-03|amend "No LoginModules configured for ..." with hi|
|59758|New|Enh|2016-06-27|Add http proxy username-password credentials suppo|
|60281|Ver|Nor|2016-10-20|Pathname of uploaded WAR file should not be contai|
|60721|Ver|Nor|2017-02-10|Unable to find key spec if more applications use b|
|60781|New|Nor|2017-02-27|Access Log Valve does not escape the same as mod_l|
|60849|New|Enh|2017-03-13|Tomcat NIO Connector not able to handle SSL renego|
|61668|Ver|Min|2017-10-26|Possible NullPointerException in org.apache.coyote|
|61877|New|Enh|2017-12-08|use web.xml from CATALINA_HOME by default |
|61917|New|Enh|2017-12-19|AddDefaultCharsetFilter only supports text/* respo|
|62150|New|Enh|2018-03-01|Behavior of relative paths with RequestDispatcher |
|62214|New|Enh|2018-03-22|The "userSubtree=true" and "roleSubtree=true" in J|
|62245|New|Enh|2018-04-02|[Documentation] Mention contextXsltFile in Default|
|62496|New|Enh|2018-06-27|Add possibility write remote user/auth type to res|
|62912|New|Enh|2018-11-15|Tomcat adds a space character in the Content-Type |
|63080|New|Enh|2019-01-16|Support rfc7239 Forwarded header  |
|63195|Inf|Enh|2019-02-21|Add easy way to test RemoteIpValve works properly |
+-+---+---+--+--+
| 

Bug report for Tomcat 9 [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|57505|New|Enh|2015-01-27|Add integration tests for JspC|
|57661|New|Enh|2015-03-04|Delay sending of 100 continue response until appli|
|58242|New|Enh|2015-08-13|Scanning jars in classpath to get annotations in p|
|58530|New|Enh|2015-10-23|Proposal for new Manager HTML GUI |
|58548|New|Enh|2015-10-26|support certifcate transparency   |
|58859|New|Enh|2016-01-14|Allow to limit charsets / encodings supported by T|
|59203|New|Enh|2016-03-21|Try to call Thread.interrupt before calling Thread|
|59344|Ver|Enh|2016-04-18|PEM file support for JSSE |
|59750|New|Enh|2016-06-24|Amend "authenticate" method with context by means |
|59901|New|Enh|2016-07-26|Reduce I/O associated with JSP compilation|
|60997|New|Enh|2017-04-17|Enhance SemaphoreValve to support denied status an|
|61971|New|Enh|2018-01-06|documentation for using tomcat with systemd   |
|62048|New|Enh|2018-01-25|Missing logout function in Manager and Host-Manage|
|62072|New|Enh|2018-02-01|Add support for request compression   |
|62140|New|Enh|2018-02-27|catalina.sh should document the verbs it accepts a|
|62312|New|Enh|2018-04-18|Add Proxy Authentication support to websocket clie|
|62405|New|Enh|2018-05-23|Add Rereadable Request Filter |
|62488|New|Enh|2018-06-25|Obtain dependencies from Maven Central where possi|
|62611|New|Enh|2018-08-09|Compress log files after rotation |
|62695|Inf|Nor|2018-09-07|Provide sha512 checksums for Tomcat releases publi|
|62696|New|Enh|2018-09-07|Consider use of sha256 for signing of .exe files o|
|62723|New|Enh|2018-09-14|Clarify "channelSendOptions" value in cluster docu|
|62773|New|Enh|2018-09-28|Change DeltaManager to handle session deserializat|
|62814|New|Enh|2018-10-10|Use readable names for cluster channel/map options|
|62841|New|Enh|2018-10-20|Refactor DeltaSession locking |
|62843|New|Enh|2018-10-22|Tomcat Russian localization   |
|62920|New|Enh|2018-11-17|Maven Plugin For Tomcat 9.0.x |
|62964|New|Enh|2018-11-29|Add RFC7807 conformant Problem Details for HTTP st|
|63023|New|Enh|2018-12-20|Provide a way to load SecurityProviders into the s|
|63049|New|Enh|2018-12-31|Add support in system properties override from com|
|63191|Inf|Nor|2019-02-20|RemoteEndpoint.Async#sendText(String, SendHandler)|
|63237|New|Enh|2019-03-06|Consider processing mbeans-descriptors.xml at comp|
+-+---+---+--+--+
| Total   32 bugs   |
+---+

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



Bug report for Tomcat Connectors [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|46767|New|Enh|2009-02-25|mod_jk to send DECLINED in case no fail-over tomca|
|47327|New|Enh|2009-06-07|Return tomcat authenticated user back to mod_jk (A|
|47750|New|Maj|2009-08-27|ISAPI: Loss of worker settings when changing via j|
|47795|New|Maj|2009-09-07|service sticky_session not being set correctly wit|
|48830|New|Nor|2010-03-01|IIS shutdown blocked in endpoint service when serv|
|49822|New|Enh|2010-08-25|Add hash lb worker method |
|49903|New|Enh|2010-09-09|Make workers file reloadable  |
|52483|New|Enh|2012-01-18|Print JkOptions's options in log file and jkstatus|
|53883|Inf|Maj|2012-09-17|isapi_redirect v 1.2.37 crashes w3wp.exe  on the p|
|54621|New|Enh|2013-02-28|[PATCH] custom mod_jk availability checks |
|56489|New|Enh|2014-05-05|Include a directory for configuration files   |
|56576|New|Enh|2014-05-29|Websocket support |
|57402|New|Enh|2014-12-30|Provide correlation ID between mod_jk log and acce|
|57403|New|Enh|2014-12-30|Persist configuration changes made via status work|
|57407|New|Enh|2014-12-31|Make session_cookie, session_path and session_cook|
|57790|New|Enh|2015-04-03|Check worker names for typos  |
|61476|New|Enh|2017-09-01|Allow reset of an individual worker stat value|
|61621|New|Enh|2017-10-15|Content-Type is forced to lowercase when it goes t|
|62093|New|Enh|2018-02-09|Allow use_server_errors to apply to specific statu|
|63214|New|Nor|2019-02-27|Using JkAutoAlias, Filenames with Spaces Cannot be|
+-+---+---+--+--+
| Total   20 bugs   |
+---+

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



Bug report for Taglibs [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|38193|Ass|Enh|2006-01-09|[RDC] BuiltIn Grammar support for Field   |
|38600|Ass|Enh|2006-02-10|[RDC] Enable RDCs to be used in X+V markup (X+RDC)|
|42413|New|Enh|2007-05-14|[PATCH] Log Taglib enhancements   |
|46052|New|Nor|2008-10-21|SetLocaleSupport is slow to initialize when many l|
|48333|New|Enh|2009-12-02|TLD generator |
|57548|New|Min|2015-02-08|Auto-generate the value for org.apache.taglibs.sta|
|57684|New|Min|2015-03-10|Version info should be taken from project version |
|59359|New|Enh|2016-04-20|(Task) Extend validity period for signing KEY - be|
|59668|New|Nor|2016-06-06|x:forEach retains the incorrect scope when used in|
|61875|New|Nor|2017-12-08|Investigate whether Xalan can be removed  |
+-+---+---+--+--+
| Total   10 bugs   |
+---+

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



Bug report for Tomcat Native [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|53940|New|Enh|2012-09-27|Added support for new CRL loading after expiration|
|57815|New|Enh|2015-04-15|Improve error message when OpenSSL does not suppor|
|59286|New|Nor|2016-04-07|Socket binding failures when using APR|
|62626|Inf|Nor|2018-08-15|Tomcat 9.0.10 APR/Native crashes  |
|62911|New|Enh|2018-11-15|Add support for proxying ocsp  requests via ProxyH|
|63159|New|Nor|2019-02-08|Problem with native/Makefile.in introduced with na|
|63199|New|Nor|2019-02-22|sslsocket handshake JVM crash |
+-+---+---+--+--+
| Total7 bugs   |
+---+

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



Bug report for Tomcat Modules [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|50571|Inf|Nor|2011-01-11|Tomcat 7 JDBC connection pool exception enhancemen|
|51595|Inf|Nor|2011-08-01|org.apache.tomcat.jdbc.pool.jmx.ConnectionPool sho|
|51879|Inf|Enh|2011-09-22|Improve access to Native Connection Methods   |
|52024|Inf|Enh|2011-10-13|Custom interceptor to support automatic failover o|
|53199|Inf|Enh|2012-05-07|Refactor ConnectionPool to use ScheduledExecutorSe|
|54437|New|Enh|2013-01-16|Update PoolProperties javadoc for ConnectState int|
|54929|Inf|Nor|2013-05-05|jdbc-pool cannot be used with Java 1.5, "java.lang|
|55078|New|Nor|2013-06-07|Configuring a DataSource Resource with dataSourceJ|
|55662|New|Enh|2013-10-17|Add a way to set an instance of java.sql.Driver di|
|56046|New|Enh|2014-01-21|org.apache.tomcat.jdbc.pool.XADataSource InitSQL p|
|56088|New|Maj|2014-01-29|AbstractQueryReport$StatementProxy throws exceptio|
|56310|Inf|Maj|2014-03-25|PooledConnection and XAConnection not handled corr|
|56586|New|Nor|2014-06-02|initSQL should be committed if defaultAutoCommit =|
|56775|New|Nor|2014-07-28|PoolCleanerTime schedule issue|
|56779|New|Nor|2014-07-28|Allow multiple connection initialization statement|
|56790|New|Nor|2014-07-29|Resizing pool.maxActive to a higher value at runti|
|56798|New|Nor|2014-07-31|Idle eviction strategy could perform better (and i|
|56804|New|Nor|2014-08-02|Use a default validationQueryTimeout other than "f|
|56805|New|Nor|2014-08-02|datasource.getConnection() may be unnecessarily bl|
|56837|New|Nor|2014-08-11|if validationQuery have error with timeBetweenEvic|
|56970|New|Nor|2014-09-11|MaxActive vs. MaxTotal for commons-dbcp and tomcat|
|56974|New|Nor|2014-09-12|jdbc-pool validation query defaultAutoCommit statu|
|57460|New|Nor|2015-01-19|[DB2]Connection broken after few hours but not rem|
|57729|New|Enh|2015-03-20|Add QueryExecutionReportInterceptor to log query e|
|58489|Opn|Maj|2015-10-08|QueryStatsComparator throws IllegalArgumentExcepti|
|59077|New|Nor|2016-02-26|DataSourceFactory creates a neutered data source  |
|59569|New|Nor|2016-05-18|isWrapperFor/unwrap implementations incorrect |
|59879|New|Nor|2016-07-18|StatementCache interceptor returns ResultSet objec|
|60195|New|Nor|2016-10-02|No javadoc in Maven Central   |
|60522|New|Nor|2016-12-27|An option for setting if the transaction should be|
|60524|Inf|Nor|2016-12-28|NPE in SlowQueryReport in tomcat-jdbc-7.0.68  |
|60645|New|Nor|2017-01-25|StatementFinalizer is not thread-safe |
|61032|New|Nor|2017-04-24|min pool size is not being respected  |
|61103|New|Nor|2017-05-18|StatementCache potentially caching non-functional |
|61302|New|Enh|2017-07-15|Refactoring of DataSourceProxy|
|61303|New|Enh|2017-07-15|Refactoring of ConnectionPool |
|62432|New|Nor|2018-06-06|Memory Leak in Statement Finalizer?   |
|62598|New|Enh|2018-08-04|support pool with multiple JDBC data sources  |
|62910|Inf|Nor|2018-11-15|tomcat-jdbc global pool transaction problem   |
+-+---+---+--+--+
| Total   39 bugs   |
+---+

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



Bug report for Tomcat 7 [2019/03/17]

2019-03-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|50944|Ver|Blk|2011-03-18|JSF: java.lang.NullPointerException at com.sun.fac|
|53620|New|Enh|2012-07-30|[juli] delay opening a file until something gets l|
|55104|New|Enh|2013-06-16|Allow passing arguments with spaces to Commons Dae|
|55470|New|Enh|2013-08-23|Help users for ClassNotFoundExceptions during star|
|55477|New|Enh|2013-08-23|Add a solution to map an realm name to a security |
|56148|New|Enh|2014-02-17|support (multiple) ocsp stapling  |
|56181|New|Enh|2014-02-23|RemoteIpValve & RemoteIpFilter: HttpServletRequest|
|56300|New|Enh|2014-03-22|[Tribes] No useful examples, lack of documentation|
|56438|New|Enh|2014-04-21|If jar scan does not find context config or TLD co|
|56614|New|Enh|2014-06-12|Add a switch to ignore annotations detection on ta|
|56787|New|Enh|2014-07-29|Simplified jndi name parsing  |
|57367|New|Enh|2014-12-18|If JAR scan experiences a stack overflow, give the|
|57827|New|Enh|2015-04-17|Enable adding/removing of members via jmx in a sta|
|57872|New|Enh|2015-04-29|Do not auto-switch session cookie to version=1 due|
|57892|New|Enh|2015-05-05|Log once a warning if a symbolic link is ignored (|
|59716|New|Enh|2016-06-17|Allow JNDI configuration of CorsFilter|
|60597|New|Enh|2017-01-17|Add ability to set cipher suites for websocket cli|
|63167|New|Enh|2019-02-12|Network Requirements To Resolve No Members Active |
|63266|New|Nor|2019-03-16|NullPointerException at org.apache.catalina.loader|
+-+---+---+--+--+
| Total   19 bugs   |
+---+

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