[Bug 63500] Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #5 from Bruno  ---
Created attachment 36625
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36625&action=edit
Native stack trace from core dump of same process with debuginfo

Installed the debug info and retrieved new native trace.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63500] Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #4 from Bruno  ---
It does fail right at the beginning.

Attached the traces.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63500] Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #3 from Bruno  ---
Created attachment 36624
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36624&action=edit
Native stack trace from core dump of same process

gdb java core
where
bt full

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63500] Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #2 from Bruno  ---
Created attachment 36623
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36623&action=edit
Error report generated by the JVM

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: CDI support improvements

2019-06-13 Thread Rémy Maucherat
On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
wrote:

>
> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
> is likely the one but looks like johnzon was not scanned nor registered
> programmatically
>
> Maybe code this bean:
>
> @Produces("application/json") // jaxrs import
> @Provider //jaxrs import
> @Dependent // cdi import
> public class MyJson extends JsonbJaxrsProvider {}
>
> Should be enough if it is the issue (or use delegation instead of
> inheritance)
>

Thanks for the debug method, it worked very well :) So there's now a lot of
possible improvements I can look at.

Rémy


[Bug 63500] Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #1 from Christopher Schultz  ---
Looks like this fails on startup. Can you enable core dumps, re-try, and get a
native stack trace of the error?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: CDI support improvements

2019-06-13 Thread Romain Manni-Bucau
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
is likely the one but looks like johnzon was not scanned nor registered
programmatically

Maybe code this bean:

@Produces("application/json") // jaxrs import
@Provider //jaxrs import
@Dependent // cdi import
public class MyJson extends JsonbJaxrsProvider {}

Should be enough if it is the issue (or use delegation instead of
inheritance)

Le jeu. 13 juin 2019 à 18:45, Rémy Maucherat  a écrit :

> On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau 
> wrote:
>
>> can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs
>> jars) too?
>>
>
> Ok, thanks. Still not working though, and this part of the code doesn't
> have debug logs of any kind, so I'll now have to trace the whole thing. It
> feels bad I have to do that as serializing json didn't seem *so* complex
> overall in the first place.
>
> Rémy
>
>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :
>>
>>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
 Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
 or jakarta jars) you just need:

 org.apache.cxf:cxf-core:3.3.2
 org.apache.cxf:cxf-rt-security:3.3.2
 org.apache.cxf:cxf-rt-transports-http:3.3.2
 org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
 org.apache.cxf:cxf-integration-cdi:3.3.2
 org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
 Microprofile you need it)

>>>
>>> About CXF, I still have one issue related to json.
>>> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No
>>> message body writer has been found for class
>>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
>>> ContentType: application/json
>>> It should be very simple, but for whatever reason I cannot get it to
>>> work (I added cxf-rt-rs-extension-providers which has the json provider).
>>> Anyway it's mostly a cosmetic issue at this point.
>>>
>>> I now know what I want to do with CXF, but it's certainly harder than
>>> for OWN (no surprise).
>>>
>>> Rémy
>>>
>>>


Re: CDI support improvements

2019-06-13 Thread Rémy Maucherat
On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau 
wrote:

> can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
> too?
>

Ok, thanks. Still not working though, and this part of the code doesn't
have debug logs of any kind, so I'll now have to trace the whole thing. It
feels bad I have to do that as serializing json didn't seem *so* complex
overall in the first place.

Rémy


> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :
>
>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
>> wrote:
>>
>>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>>> or jakarta jars) you just need:
>>>
>>> org.apache.cxf:cxf-core:3.3.2
>>> org.apache.cxf:cxf-rt-security:3.3.2
>>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>>> org.apache.cxf:cxf-integration-cdi:3.3.2
>>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>>> Microprofile you need it)
>>>
>>
>> About CXF, I still have one issue related to json.
>> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
>> body writer has been found for class
>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
>> ContentType: application/json
>> It should be very simple, but for whatever reason I cannot get it to work
>> (I added cxf-rt-rs-extension-providers which has the json provider). Anyway
>> it's mostly a cosmetic issue at this point.
>>
>> I now know what I want to do with CXF, but it's certainly harder than for
>> OWN (no surprise).
>>
>> Rémy
>>
>>


Re: CDI support improvements

2019-06-13 Thread Romain Manni-Bucau
can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
too?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :

> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
> wrote:
>
>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>> or jakarta jars) you just need:
>>
>> org.apache.cxf:cxf-core:3.3.2
>> org.apache.cxf:cxf-rt-security:3.3.2
>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>> org.apache.cxf:cxf-integration-cdi:3.3.2
>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>> Microprofile you need it)
>>
>
> About CXF, I still have one issue related to json.
> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
> body writer has been found for class
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
> ContentType: application/json
> It should be very simple, but for whatever reason I cannot get it to work
> (I added cxf-rt-rs-extension-providers which has the json provider). Anyway
> it's mostly a cosmetic issue at this point.
>
> I now know what I want to do with CXF, but it's certainly harder than for
> OWN (no surprise).
>
> Rémy
>
>


Re: CDI support improvements

2019-06-13 Thread Rémy Maucherat
On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
wrote:

> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
> jakarta jars) you just need:
>
> org.apache.cxf:cxf-core:3.3.2
> org.apache.cxf:cxf-rt-security:3.3.2
> org.apache.cxf:cxf-rt-transports-http:3.3.2
> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
> org.apache.cxf:cxf-integration-cdi:3.3.2
> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
> Microprofile you need it)
>

About CXF, I still have one issue related to json.
org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
body writer has been found for class
org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
ContentType: application/json
It should be very simple, but for whatever reason I cannot get it to work
(I added cxf-rt-rs-extension-providers which has the json provider). Anyway
it's mostly a cosmetic issue at this point.

I now know what I want to do with CXF, but it's certainly harder than for
OWN (no surprise).

Rémy


[Bug 63500] New: Core dump using APR tomcat native with certificateRevocationListFile

2019-06-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

Bug ID: 63500
   Summary: Core dump using APR tomcat native with
certificateRevocationListFile
   Product: Tomcat 9
   Version: 9.0.21
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: bruno.pmari...@gmail.com
  Target Milestone: -

I'm using tomcat 9.0.21 and tomcat-native 1.2.21 on top of CentOS 7.6.1810.

Current issue is this one from catalina.out:
-
13-Jun-2019 10:43:32.132 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based
Apache Tomcat Native library [1.2.21] using APR version [1.4.8].
13-Jun-2019 10:43:32.135 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities:
IPv6 [true], sendfile [true], accept filters [false], random [true].
13-Jun-2019 10:43:32.135 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
13-Jun-2019 10:43:32.141 INFO [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized [OpenSSL 1.0.2k-fips  26 Jan 2017]
13-Jun-2019 10:43:32.518 INFO [main] org.apache.coyote.AbstractProtocol.init
Initializing ProtocolHandler ["http-apr-2007"]
13-Jun-2019 10:43:32.545 INFO [main] org.apache.coyote.AbstractProtocol.init
Initializing ProtocolHandler ["https-openssl-apr-2008"]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f989117c860, pid=23986, tid=0x7f9910185700
#
# JRE version: OpenJDK Runtime Environment (8.0_191-b12) (build 1.8.0_191-b12)
# Java VM: OpenJDK 64-Bit Server VM (25.191-b12 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C  [libcrypto.so.10+0x168860]  X509_STORE_set_flags+0x0
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /opt/temp/java_error23986.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
-

The crash log shows

-
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j 
org.apache.tomcat.jni.SSLContext.setCARevocation(JLjava/lang/String;Ljava/lang/String;)Z+0
j 
org.apache.tomcat.util.net.openssl.OpenSSLContext.addCertificate(Lorg/apache/tomcat/util/net/SSLHostConfigCertificate;)V+77
j 
org.apache.tomcat.util.net.openssl.OpenSSLContext.init([Ljavax/net/ssl/KeyManager;[Ljavax/net/ssl/TrustManager;Ljava/security/SecureRandom;)V+191
j 
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(Ljava/util/List;)Lorg/apache/tomcat/util/net/SSLContext;+16
j 
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(Lorg/apache/tomcat/util/net/SSLHostConfig;)V+81
-

Which is the code
https://github.com/apache/tomcat-native/blob/7a20a500587dc92944dee05cee5b388ae8443842/native/src/sslcontext.c#L640

Connector configuration:
-


  

  

-

When I remove the line setting the revogation list,
"certificateRevocationListFile=\"/certs/server/x509_trusted.crl\"", it just
works. Same PEM file works in old tomcat-7.0.69 using also APR and tomcat
native.
Tried versions back until 9.0.17 with same issue. With 9.0.16 and 9.014 I have
different issue.

On tomcat 9.0.14 same setup worked but on shutdown I had a core dump. With
tomcat 9.0.16 same setup worked but on shutdown I had an even weird core dump.
Starting tomcat 9.0.17 it stopped starting. I noticed that tomcat native
changed from 1.2.19 to 1.2.21 when that happen.

Tested also building a tomcat-native with latest openssl and latest apr as
static linked in with same issue. So I assume it's not some weird library issue
but something else.

Happy to provide more data or even do other tests.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[jira] [Created] (MTOMCAT-317) `additionalClasspathDirs` has null value even when initialized with "mvn tomcat7:run"

2019-06-13 Thread Abel Salgado Romero (JIRA)
Abel Salgado Romero created MTOMCAT-317:
---

 Summary: `additionalClasspathDirs` has null value even when 
initialized with "mvn tomcat7:run"
 Key: MTOMCAT-317
 URL: https://issues.apache.org/jira/browse/MTOMCAT-317
 Project: Apache Tomcat Maven Plugin
  Issue Type: Bug
  Components: tomcat7
Affects Versions: 2.2, 3.0
Reporter: Abel Salgado Romero
Assignee: Olivier Lamy (*$^¨%`£)


I am trying to add additional libraries that are inside an "endorsed" directory 
inside a pre-packaged tomcat7 with `additionalClasspathDirs` but these are not 
added.

I run and debugged life (with `mvnDebug`) with v 2.2 and the 3.0-SNAPSHOT found 
in  https://github.com/apache/tomcat-maven-plugin.git and in both cases 
`additionalClasspathDirs` in 
`org.apache.tomcat.maven.plugin.tomcat7.run.RunMojo` is null.

Additionally tried with no success:
* Removing the alias from the attribute
* Hardcoding the path with my jars in the same plugin -> the app still failed 
with ClassNotFound, ¿should I add all the jars instead of a dir?


environment:
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-04T21:00:29+02:00)
Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.1\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: 
C:\eld4\jdk-7u80-windows-x64\jre
Default locale: es_ES, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [tomcat] redgeek01 closed pull request #168: Create php3.php

2019-06-13 Thread GitBox
redgeek01 closed pull request #168: Create php3.php
URL: https://github.com/apache/tomcat/pull/168
 
 
   


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



[GitHub] [tomcat] redgeek01 opened a new pull request #168: Create php3.php

2019-06-13 Thread GitBox
redgeek01 opened a new pull request #168: Create php3.php
URL: https://github.com/apache/tomcat/pull/168
 
 
   Create php3.php


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