[Bug 63505] enhancement - support of stored procedures for DataSourceRealm authentication

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63505

--- Comment #3 from Eugène Adell  ---
The first one retrieves the user's password, the second the user's roles.

Better ideas to names these attributes are of course welcome.

-- 
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: Tomcat-Native - Time to move to git?

[Igal Sapir]

On 6/17/2019 2:18 PM, Rainer Jung wrote:

Am 17.06.2019 um 18:56 schrieb Mark Thomas:

Hi,

I'm starting to look at OCSP stapling for our OpenSSL based connectors
and I suspect a Tomcat Native release will be required. Even if it isn't
for this, it has been a while since the last Tomcat Native release so I
expect we'll need to do one fairly soon anyway.

The complication is the svn:external that picks up the
org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
this no longer works.

I looked at a workaround using the "GitHub makes itself look like svn"
but that timed out for the Tomcat repo. I suspect due to size.

I then looked at Git based solutions. sub-modules and sub-trees look to
be the two options. Of the two, sub-trees looks better:
- it is more suited to "read-only" importing
- it doesn't require any additional commands to populate the imported
   code

However, using sub-trees means moving Tomcat-Native to git. Before I
start a formal vote to do so, are there any objections?

The process would be:
- ensure git mirror is up to date
- break the svn->git mirror
- start using git
- update web site etc
- move svn code to archive

Given how the migration of the main repos went, I'm not expecting any
major issues.


+1


+1

Igal



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

[Bug 63505] enhancement - support of stored procedures for DataSourceRealm authentication

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63505

--- Comment #2 from Christopher Schultz  ---
What are userProcStoc and roleProcStoc abbreviations for? Those names look
weird.

-- 
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: Tomcat-Native - Time to move to git?

[Rainer Jung]

Am 17.06.2019 um 18:56 schrieb Mark Thomas:

Hi,

I'm starting to look at OCSP stapling for our OpenSSL based connectors
and I suspect a Tomcat Native release will be required. Even if it isn't
for this, it has been a while since the last Tomcat Native release so I
expect we'll need to do one fairly soon anyway.

The complication is the svn:external that picks up the
org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
this no longer works.

I looked at a workaround using the "GitHub makes itself look like svn"
but that timed out for the Tomcat repo. I suspect due to size.

I then looked at Git based solutions. sub-modules and sub-trees look to
be the two options. Of the two, sub-trees looks better:
- it is more suited to "read-only" importing
- it doesn't require any additional commands to populate the imported
   code

However, using sub-trees means moving Tomcat-Native to git. Before I
start a formal vote to do so, are there any objections?

The process would be:
- ensure git mirror is up to date
- break the svn->git mirror
- start using git
- update web site etc
- move svn code to archive

Given how the migration of the main repos went, I'm not expecting any
major issues.


+1

Rainer


-
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

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63500

--- Comment #6 from Mark Thomas  ---
The stack trace suggests the fix for bug 62094 was incorrect.

Looking at the trace, the proposed patch and the commit, I think the patch was
not applied correctly.

-- 
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 56148] support (multiple) ocsp stapling

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=56148

--- Comment #6 from Mark Thomas  ---
This will need code changes in Tomcat Native. A rough outline of what is
required is provided by:
https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_tlsext_status_arg.html

-- 
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: Tomcat-Native - Time to move to git?

[Coty Sutherland]

On Mon, Jun 17, 2019 at 12:56 PM Mark Thomas  wrote:

> Hi,
>
> I'm starting to look at OCSP stapling for our OpenSSL based connectors
> and I suspect a Tomcat Native release will be required. Even if it isn't
> for this, it has been a while since the last Tomcat Native release so I
> expect we'll need to do one fairly soon anyway.
>
> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.
>
> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
>
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>   code
>
> However, using sub-trees means moving Tomcat-Native to git. Before I
> start a formal vote to do so, are there any objections?
>
> The process would be:
> - ensure git mirror is up to date
> - break the svn->git mirror
> - start using git
> - update web site etc
> - move svn code to archive
>
> Given how the migration of the main repos went, I'm not expecting any
> major issues.
>

No objections from me :)


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

Re: Tomcat-Native - Time to move to git?

[Rémy Maucherat]

On Mon, Jun 17, 2019 at 6:56 PM Mark Thomas  wrote:

> Hi,
>
> I'm starting to look at OCSP stapling for our OpenSSL based connectors
> and I suspect a Tomcat Native release will be required. Even if it isn't
> for this, it has been a while since the last Tomcat Native release so I
> expect we'll need to do one fairly soon anyway.
>
> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.
>
> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
>
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>   code
>
> However, using sub-trees means moving Tomcat-Native to git. Before I
> start a formal vote to do so, are there any objections?
>
> The process would be:
> - ensure git mirror is up to date
> - break the svn->git mirror
> - start using git
> - update web site etc
> - move svn code to archive
>
> Given how the migration of the main repos went, I'm not expecting any
> major issues.
>

+1

Rémy

Tomcat-Native - Time to move to git?

[Mark Thomas]

Hi,

I'm starting to look at OCSP stapling for our OpenSSL based connectors
and I suspect a Tomcat Native release will be required. Even if it isn't
for this, it has been a while since the last Tomcat Native release so I
expect we'll need to do one fairly soon anyway.

The complication is the svn:external that picks up the
org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
this no longer works.

I looked at a workaround using the "GitHub makes itself look like svn"
but that timed out for the Tomcat repo. I suspect due to size.

I then looked at Git based solutions. sub-modules and sub-trees look to
be the two options. Of the two, sub-trees looks better:
- it is more suited to "read-only" importing
- it doesn't require any additional commands to populate the imported
  code

However, using sub-trees means moving Tomcat-Native to git. Before I
start a formal vote to do so, are there any objections?

The process would be:
- ensure git mirror is up to date
- break the svn->git mirror
- start using git
- update web site etc
- move svn code to archive

Given how the migration of the main repos went, I'm not expecting any
major issues.

Mark

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

[Bug 56148] support (multiple) ocsp stapling

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=56148

--- Comment #5 from Mark Thomas  ---
Just switching implementations (no config changes)

NIO-OpenSSL - no stapling
APR-OpenSSL - no stapling

Next step is to look at OpenSSL config and API to see a) if this can be enabled
and b) what the options are for doing so.

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

[Romain Manni-Bucau]

Le lun. 17 juin 2019 à 16:17, Rémy Maucherat  a écrit :

> On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau 
> wrote:
>
>> Hi Rémy,
>>
>> Great progression! Congrats!
>>
>> I have a few (details) notes - guess i'm opening an open door but just to
>> ensure:
>>
>> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
>> bound on on /api but generally thanks to an Application
>> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
>> shouldn't host that config and we would link it through a context listener
>> or servletcontextinitializer (both will work and rely on tomcat internals)
>>
>
> I am not comfortable mapping a servlet on /* by default, it would be
> annoying, so I changed the mapping to /api/*. I used a web-fragment for now
> since it's a decent Servlet API feature and has plenty of configuration
> flexibility.
> Adding additional CXF integration would be good but is work, a filter
> could useful. Moving CXF to a container integration is even more work and
> doesn't looks that practical to me.
>
> The CDI context listener configuring CXF if is present sounds possible (it
> can programmatically add the CDI CXF servlet, no problem), it does sound a
> bit weird conceptually but it's a good option.
>
>
>> 2. In beans.xml, rather than annotated mode - which skips a lot of
>> classes which can be used in CDI - we tend to prefer discovery mode
>> "full" + trim:
>> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
>>
>
> I don't understand how that works, if I add scanning to tomcat-cxf.jar, it
> loads all classes (which fails). So that's why I'm not doing it.
>

If you can detail that, I can surely help.
If you can change the code, adding @Vetoed on classes you don't want to be
CDI beans can help too.
The annotated mode - default in cxf - was here to "work out of the box",
however the defaults were not that great and it is easy to fall in a case
where "it should work". All mode is more reliable and aligned on the "old"
(1.0) scanning where all beans are here, the  addition was there to
drop the useless types and ensure the deployment stays "light".
So long story short, full+trim is likely the less error prone and
priviledged mode today.


>
>
>> 3. Why not merging SPI files thanks to maven?  (shade part, end of
>> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
>> 4. You have a spring config (cxf.xml), not sure it is intended?
>> 5. jettison is not needed since it is not the one used for json
>> serialization (guess you can drop several cxf deps)
>>
>
> Very good idea, I made changes and fixed these items.
>



BTW, is the assembly available?


>
> Rémy
>
>

Re: CDI support improvements

[Rémy Maucherat]

On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau 
wrote:

> Hi Rémy,
>
> Great progression! Congrats!
>
> I have a few (details) notes - guess i'm opening an open door but just to
> ensure:
>
> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
> bound on on /api but generally thanks to an Application
> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
> shouldn't host that config and we would link it through a context listener
> or servletcontextinitializer (both will work and rely on tomcat internals)
>

I am not comfortable mapping a servlet on /* by default, it would be
annoying, so I changed the mapping to /api/*. I used a web-fragment for now
since it's a decent Servlet API feature and has plenty of configuration
flexibility.
Adding additional CXF integration would be good but is work, a filter could
useful. Moving CXF to a container integration is even more work and doesn't
looks that practical to me.

The CDI context listener configuring CXF if is present sounds possible (it
can programmatically add the CDI CXF servlet, no problem), it does sound a
bit weird conceptually but it's a good option.


> 2. In beans.xml, rather than annotated mode - which skips a lot of classes
> which can be used in CDI - we tend to prefer discovery mode "full" + trim:
> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
>

I don't understand how that works, if I add scanning to tomcat-cxf.jar, it
loads all classes (which fails). So that's why I'm not doing it.


> 3. Why not merging SPI files thanks to maven?  (shade part, end of
> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
> 4. You have a spring config (cxf.xml), not sure it is intended?
> 5. jettison is not needed since it is not the one used for json
> serialization (guess you can drop several cxf deps)
>

Very good idea, I made changes and fixed these items.

Rémy

[Bug 56148] support (multiple) ocsp stapling

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=56148

--- Comment #4 from Mark Thomas  ---
I can confirm this "just works" if you have a suitably configured certificate
(LetsEncrypt in my test), a Java version that supports it (JDK 11.0.3+7 in my
test), are using a JSSE based connector (NIO with JSSE in my test) and have set
the appropriate system property
(-Djdk.tls.server.enableStatusRequestExtension=true).

Confirmed with SSLLabs.

Next up is testing with an OpenSSL based connector.

-- 
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: JDK 13 enters Rampdown Phase One

[Rory O'Donnell]

Thanks Mark for the Update on both.

Rgds,Rory

On 17/06/2019 17:10, Mark Thomas wrote:

Tomcat 9.0.x latest source
ant clean test

JDK-13-ea25 and JDK-14-ea01 complete without warnings or errors.

Mark

On 16/06/2019 07:00, Rory O'Donnell wrote:

Hi Mark,

*JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/*

   * Per the JDK 13 schedule [1], we are now in Rampdown Phase One.
   o For more details , see Mark Reinhold's email to jdk-dev mailing
 list [2]
   o The overall feature set is frozen, no further JEPs will be
 targeted to this release.
   * Changes in this build 25 [4]

*Request for feedback on JEP 353 integrated in b24
*

JEP 353: Reimplement the Legacy Socket API" has been integrated into
jdk-13+24. It would be very useful if applications or libraries using
java.net.Socket or java.net.ServerSocket APIs could test with this build
and report any issues found. The JEP provides information on the system
property that can be used to switch back to the old implementation and
that may be useful to check for behavior differences between the old and
new implementation. It would be very useful to get feedback via the
OpenJDK net-dev mailing list, bugs via the usual channel.

*Updates to Release Notes since last email*

   * b25 - Support Kerberos cross-realm referrals (RFC 6806) (JDK-8215032
 )
   * b25 - Add -XX:SoftMaxHeapSize flag (JDK-8222145
 )
   * b24 - Reimplement the Legacy Socket API (JDK-8221481
 )
   o see above request for feedback
   * b24  - Deprecated rmic tool For Removal (JDK-8217412
 )
   * b24 - New String constants for Canonical XML 1.1 URIs (JDK-8224767
 )
   * b23 - Support for Unicode 12.1 (JDK-8221431
 )
   * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432
 )

*OpenJDK 14 **Early Access build 1 **is now available **at : -
jdk.java.net/14/*

   * These early-access, open-source builds are provided under the GNU
 General Public License, version 2, with the Classpath Exception
 .
   * Changes in this build [5]

**

Rgds, Rory

[1] http://openjdk.java.net/projects/jdk/13/#Schedule

[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html
[3] http://jdk.java.net/13/release-notes
[4] JDK 13 - Changes in b25 here

[5] JDK 14 - Changes in b1 here


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland



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


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland


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

Re: JDK 13 enters Rampdown Phase One

[Rémy Maucherat]

On Sun, Jun 16, 2019 at 8:01 AM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *JDK 13 Early Access build **25 is now available **at : -
> jdk.java.net/13/ *
>
>
>- Per the JDK 13 schedule [1], we are now in Rampdown Phase One.
>   - For more details , see Mark Reinhold's email to jdk-dev mailing
>   list [2]
>- The overall feature set is frozen, no further JEPs will be targeted
>   to this release.
>- Changes in this build 25 [4]
>
>
> *Request for feedback on JEP 353 integrated in b24 *
>
> JEP 353: Reimplement the Legacy Socket API" has been integrated into
> jdk-13+24. It would be very useful if applications or libraries using
> java.net.Socket or java.net.ServerSocket APIs could test with this build
> and report any issues found. The JEP provides information on the system
> property that can be used to switch back to the old implementation and that
> may be useful to check for behavior differences between the old and new
> implementation. It would be very useful to get feedback via the OpenJDK
> net-dev mailing list, bugs via the usual channel.
>

This does sound like a significant stability risk for Tomcat 7, to be
honest.

Rémy


> *Updates to Release Notes since last email*
>
>- b25 - Support Kerberos cross-realm referrals (RFC 6806) (JDK-8215032
>)
>- b25 - Add -XX:SoftMaxHeapSize flag (JDK-8222145
>)
>- b24 - Reimplement the Legacy Socket API (JDK-8221481
>)
>   - see above request for feedback
>   - b24  - Deprecated rmic tool For Removal (JDK-8217412
>)
>- b24 - New String constants for Canonical XML 1.1 URIs (JDK-8224767
>)
>- b23 - Support for Unicode 12.1 (JDK-8221431
>)
>- b21 - Upgrade CLDR to Version 35.1 (JDK-8221432
>)
>
> *OpenJDK 14 **Early Access build 1 **is now available **at : -
> jdk.java.net/14/ *
>
>- These early-access, open-source builds are provided under the GNU
>General Public License, version 2, with the Classpath Exception
>.
>- Changes in this build [5]
>
>
>
> Rgds, Rory
> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
> 
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html
> [3] http://jdk.java.net/13/release-notes
> [4] JDK 13 - Changes in b25 here
> 
> [5] JDK 14 - Changes in b1 here
> 
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin,Ireland
>
>

Re: JDK 13 enters Rampdown Phase One

[Mark Thomas]

Tomcat 9.0.x latest source
ant clean test

JDK-13-ea25 and JDK-14-ea01 complete without warnings or errors.

Mark

On 16/06/2019 07:00, Rory O'Donnell wrote:
> Hi Mark,
> 
> *JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/*
> 
>   * Per the JDK 13 schedule [1], we are now in Rampdown Phase One.
>   o For more details , see Mark Reinhold's email to jdk-dev mailing
> list [2] 
>   o The overall feature set is frozen, no further JEPs will be
> targeted to this release.
>   * Changes in this build 25 [4]
> 
> *Request for feedback on JEP 353 integrated in b24
> *
> 
> JEP 353: Reimplement the Legacy Socket API" has been integrated into
> jdk-13+24. It would be very useful if applications or libraries using
> java.net.Socket or java.net.ServerSocket APIs could test with this build
> and report any issues found. The JEP provides information on the system
> property that can be used to switch back to the old implementation and
> that may be useful to check for behavior differences between the old and
> new implementation. It would be very useful to get feedback via the
> OpenJDK net-dev mailing list, bugs via the usual channel.
> 
> *Updates to Release Notes since last email*
> 
>   * b25 - Support Kerberos cross-realm referrals (RFC 6806) (JDK-8215032
> )
>   * b25 - Add -XX:SoftMaxHeapSize flag (JDK-8222145
> )
>   * b24 - Reimplement the Legacy Socket API (JDK-8221481
> )
>   o see above request for feedback
>   * b24  - Deprecated rmic tool For Removal (JDK-8217412
> )
>   * b24 - New String constants for Canonical XML 1.1 URIs (JDK-8224767
> )
>   * b23 - Support for Unicode 12.1 (JDK-8221431
> )
>   * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432
> )
> 
> *OpenJDK 14 **Early Access build 1 **is now available **at : -
> jdk.java.net/14/*
> 
>   * These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Changes in this build [5]
> 
> **
> 
> Rgds, Rory
> 
> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
> 
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html
> [3] http://jdk.java.net/13/release-notes
> [4] JDK 13 - Changes in b25 here
> 
> [5] JDK 14 - Changes in b1 here
> 
> 
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin,Ireland
> 


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

[CONF] Apache Tomcat > Apache Tomcat Home

[Mark Thomas (Confluence)]

Title: Message Title



 
 
 
There's 1 new edit on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Apache Tomcat Home 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited this page 
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here's what changed: 
 
 
 
 
 
 
 
 
 
 
 ... 
 
 Design and Development Issues  
 Debugging  
 TomcatCon  
 Tomcat Training Course  
 FAQ  
 ...  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Go to page history 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
View page 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 6.15.2  
 
 
  
 
 
 
 
 
 
 
 
 

Re: CDI support improvements

[Romain Manni-Bucau]

PS/FYI: just noticed jetty did the same kind of work with weld 4 years ago:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-cdi/cdi-servlet/src/main/config/etc/jetty-cdi.xml,
great Tomcat is catching up :).

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



Le lun. 17 juin 2019 à 10:52, Romain Manni-Bucau  a
écrit :

> Hi Rémy,
>
> Great progression! Congrats!
>
> I have a few (details) notes - guess i'm opening an open door but just to
> ensure:
>
> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
> bound on on /api but generally thanks to an Application
> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
> shouldn't host that config and we would link it through a context listener
> or servletcontextinitializer (both will work and rely on tomcat internals)
> 2. In beans.xml, rather than annotated mode - which skips a lot of classes
> which can be used in CDI - we tend to prefer discovery mode "full" + trim:
> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
> 3. Why not merging SPI files thanks to maven?  (shade part, end of
> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
> 4. You have a spring config (cxf.xml), not sure it is intended?
> 5. jettison is not needed since it is not the one used for json
> serialization (guess you can drop several cxf deps)
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :
>
>> Hi Romain,
>>
>> 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 your help, I was able to make cxf work for me, and then
>> package it in a less error prone way (
>> https://github.com/rmaucher/tomcat-cxf ).
>> It does the following:
>> - Use a bean to add the json provider
>> - Package the necessary dependencies for json, jax-rs and cdi
>> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot
>> of time by using the regular cxf servlet, ultimately noticing that the
>> trace wasn't using cdi)
>> tomcat-owb should then be placed in lib, add the Server listener. It will
>> CDI enable all webapps (if they use the support). CXF then uses that
>> support. Due to its intricacies (and also the fact that it's not
>> lightweight), I don't think CXF is a good choice to put in the main Tomcat
>> lib folder (and at the moment, it won't work out of the box in that case).
>>
>> I tested with a health bean from the "tck":
>> @Health
>> @ApplicationScoped
>> public class SuccessfulHealth implements HealthCheck {
>> @Override
>> public HealthCheckResponse call() {
>> return HealthCheckResponse.named("successful-check").up().build();
>> }
>> }
>> With the addition of the geronimo-health (which is a CDI extension),
>> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
>> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
>> /rest/health). I expect the other mp APIs like metrics to work in a similar
>> way.
>>
>> Rémy
>>
>>

Re: CDI support improvements

[Romain Manni-Bucau]

Hi Rémy,

Great progression! Congrats!

I have a few (details) notes - guess i'm opening an open door but just to
ensure:

1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
bound on on /api but generally thanks to an Application
(+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
shouldn't host that config and we would link it through a context listener
or servletcontextinitializer (both will work and rely on tomcat internals)
2. In beans.xml, rather than annotated mode - which skips a lot of classes
which can be used in CDI - we tend to prefer discovery mode "full" + trim:
https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
3. Why not merging SPI files thanks to maven?  (shade part, end of
http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
4. You have a spring config (cxf.xml), not sure it is intended?
5. jettison is not needed since it is not the one used for json
serialization (guess you can drop several cxf deps)

Hope it makes sense.

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



Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :

> Hi Romain,
>
> 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 your help, I was able to make cxf work for me, and then package
> it in a less error prone way ( https://github.com/rmaucher/tomcat-cxf ).
> It does the following:
> - Use a bean to add the json provider
> - Package the necessary dependencies for json, jax-rs and cdi
> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot of
> time by using the regular cxf servlet, ultimately noticing that the trace
> wasn't using cdi)
> tomcat-owb should then be placed in lib, add the Server listener. It will
> CDI enable all webapps (if they use the support). CXF then uses that
> support. Due to its intricacies (and also the fact that it's not
> lightweight), I don't think CXF is a good choice to put in the main Tomcat
> lib folder (and at the moment, it won't work out of the box in that case).
>
> I tested with a health bean from the "tck":
> @Health
> @ApplicationScoped
> public class SuccessfulHealth implements HealthCheck {
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("successful-check").up().build();
> }
> }
> With the addition of the geronimo-health (which is a CDI extension),
> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
> /rest/health). I expect the other mp APIs like metrics to work in a similar
> way.
>
> Rémy
>
>

Re: CDI support improvements

[Rémy Maucherat]

Hi Romain,

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 your help, I was able to make cxf work for me, and then package
it in a less error prone way ( https://github.com/rmaucher/tomcat-cxf ).
It does the following:
- Use a bean to add the json provider
- Package the necessary dependencies for json, jax-rs and cdi
- Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot of
time by using the regular cxf servlet, ultimately noticing that the trace
wasn't using cdi)
tomcat-owb should then be placed in lib, add the Server listener. It will
CDI enable all webapps (if they use the support). CXF then uses that
support. Due to its intricacies (and also the fact that it's not
lightweight), I don't think CXF is a good choice to put in the main Tomcat
lib folder (and at the moment, it won't work out of the box in that case).

I tested with a health bean from the "tck":
@Health
@ApplicationScoped
public class SuccessfulHealth implements HealthCheck {
@Override
public HealthCheckResponse call() {
return HealthCheckResponse.named("successful-check").up().build();
}
}
With the addition of the geronimo-health (which is a CDI extension),
geronimo-health-common, microprofile-health-api-1.0, and the fat jar
tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
/rest/health). I expect the other mp APIs like metrics to work in a similar
way.

Rémy

Re: [Bug 63510] No

[Mark Thomas]

On 16/06/2019 17:18, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63510
> 
> --- Comment #2 from Rainer Jung  ---
> Bugzilla is not a playground.
> Stop this immediately or you will get blocked.

I think you have more patience than me. I was going through this idiot's
edits this morning and had already disabled the BZ account for
mazik...@yahoo.com

I'll clean things up in the database as best I can.

Mark

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

[tomcat] branch master updated: Edit the Graal changelog to clarify

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 5c5525e  Edit the Graal changelog to clarify
5c5525e is described below

commit 5c5525e794c8689a0e211ea3af3e9ffcd4d31159
Author: remm 
AuthorDate: Mon Jun 17 09:42:56 2019 +0200

Edit the Graal changelog to clarify

The native image tool cannot process the regular Tomcat packaging, so
edit changelog to indicate Graal support needs a single JAR such as
tomcat-maven.
---
 webapps/docs/changelog.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index eecddf8..40aabe9 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -250,8 +250,8 @@
 Switch from FindBugs to SpotBugs. (fschumacher)
   
   
-Start Graal native image compatibility. Support is initially targeted
-at the tomcat-maven packaging. (remm)
+Start Graal native image compatibility, using the tomcat-maven
+packaging. (remm)
   
   
 63403: Fix TestHttp2InitialConnection test failures when


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