Re: CDI support improvements
> On Jun 12, 2019, at 6:35 AM, Rémy Maucherat wrote: > > On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg > wrote: > > Rémy's enhancements are great - the better and cleaner the integration, the > better for all those projects. > But Romain and David are also correct: it's very easy to become a committer > on all the involved projects, especially for people known to deliver > outstanding code and to be excellent community players! I'll restate my position below just to be clear I am a fan of the effort. > Having a build reference to TomEE or OWB in Tomcat would introduce cycles in > our builds. This is not really a good thing. > > That did not seem very practical to me so the said code is quite Tomcat-like > right now and most importantly it needs the fixes made in 9.0.21, so it won't > work with any older Tomcat. If you really can take it over (and un-Tomcatize > the code, I suppose), no problem. The "Tomcat-like" is the part I really like. Some historical perspective from my eyes: - In Geronimo we did the integration "outside" Tomcat, by stripping it down - In TomEE we did the integration "inside" Tomcat, but making no changes I see this as a first attempt to potentially make some things easier in Tomcat itself and that is exciting and worth encouraging. > > > B.) We should also try to keep code and responsibilities at a single place > and shall try to avoid duplications. This has nothing to do with 'ownership' > - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do > with users knowing exactly where to look at if they are searching for a bug > or even want to contribute a new feature. > > Ok, so I guess I don't need to do anything further in that area since you > prefer to continue covering it. I'll move on to other items on my todo list > then. I personally wouldn't want to see that. I restate that from my perspective, I'd be happy to make every attempt to drop no-longer-needed code from TomEE and uptake the newer code in Tomcat. My only pause is if people actually want a CDI integration here. If people think it's worth at least a poke, however, I'm all in. Is this something people would want and what is the best way to do it here-here? (not in one of our personal repos) -David
[Bug 63487] WsSessionListener does not implement HttpSessionListener.sessionCreated
https://bz.apache.org/bugzilla/show_bug.cgi?id=63487 --- Comment #2 from Trevin Beattie --- Oh! Sorry; I forgot about default interface methods. I’ll need to debug the running application somehow to figure out if there’s a conflicting API being loaded and how … -- 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
Current owb-tomcat module is stable and could be used if some people need it but it does not prevent us to make trunk 9.last based IMHO. Maybe give a shout to owb dev list when you have something you want to integrate and Ill be happy to review and support it. Le mer. 12 juin 2019 à 18:13, Mark Struberg a écrit : > > > > Am 12.06.2019 um 15:35 schrieb Rémy Maucherat : > > > > > That did not seem very practical to me so the said code is quite > Tomcat-like > > right now and most importantly it needs the fixes made in 9.0.21, so it > won't > > work with any older Tomcat. If you really can take it over > > (and un-Tomcatize the code, I suppose), no problem. > > There are multiple options on the table. > One would be to have this code checked via reflection. > The other is to just add a new module which is for tomcat9++ > > > > > > B.) We should also try to keep code and responsibilities at a single > place and shall try to avoid duplications. This has nothing to do with > > > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it > has a lot to do with users knowing exactly where to look at if they > > > are searching for a bug or even want to contribute a new feature. > > > > Ok, so I guess I don't need to do anything further in that area since > you prefer to continue covering it. I'll move on to other items on my todo > list then. > > > > We need a JIRA ticket in OWB with a description of the suggested > improvements. > After all we'd love to understand and document what improvements you would > like to implement. > > And of course a patch would also be highly welcome! > > txs and LieGrue, > strub > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: CDI support improvements
> Am 12.06.2019 um 15:35 schrieb Rémy Maucherat : > > That did not seem very practical to me so the said code is quite Tomcat-like > right now and most importantly it needs the fixes made in 9.0.21, so it won't > work with any older Tomcat. If you really can take it over > (and un-Tomcatize the code, I suppose), no problem. There are multiple options on the table. One would be to have this code checked via reflection. The other is to just add a new module which is for tomcat9++ > > > B.) We should also try to keep code and responsibilities at a single place > > and shall try to avoid duplications. This has nothing to do with > > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a > > lot to do with users knowing exactly where to look at if they > > are searching for a bug or even want to contribute a new feature. > > Ok, so I guess I don't need to do anything further in that area since you > prefer to continue covering it. I'll move on to other items on my todo list > then. > We need a JIRA ticket in OWB with a description of the suggested improvements. After all we'd love to understand and document what improvements you would like to implement. And of course a patch would also be highly welcome! txs and LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 58768] Add Logging to Response.sendRedirect
On Wed, Jun 12, 2019 at 5:51 PM Mark Thomas wrote: > On 12/06/2019 16:17, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=58768 > > > > --- Comment #2 from david --- > > Sigh. The idiot is back with a different email address. > > Account locked, spam cleaned up, etc. > Thanks ! :) Rémy
Re: [Bug 58768] Add Logging to Response.sendRedirect
On 12/06/2019 16:17, bugzi...@apache.org wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=58768 > > --- Comment #2 from david --- Sigh. The idiot is back with a different email address. Account locked, spam cleaned up, etc. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58768] Add Logging to Response.sendRedirect
https://bz.apache.org/bugzilla/show_bug.cgi?id=58768 --- Comment #2 from david --- thanks. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com -- 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 61120] Tomcat 8.5.15 with HTTP/2: URL path parameters lost
https://bz.apache.org/bugzilla/show_bug.cgi?id=61120 --- Comment #3 from sam zain --- This is CVE-2017-7675. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com -- 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 58768] Add Logging to Response.sendRedirect
https://bz.apache.org/bugzilla/show_bug.cgi?id=58768 --- Comment #2 from sam zain --- Fixed in trunk for 9.0.0.M3 onwards, 8.0.x for 8.0.32 onwards and 7.0.x for 7.0.68 onwards. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com -- 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 62343] CORS security: reflecting any origin header value when configured to * is dangerous
https://bz.apache.org/bugzilla/show_bug.cgi?id=62343 --- Comment #3 from sam zain --- this 's really useful. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com -- 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
On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg wrote: > Hi folks! > > Really happy to see so much love and interest for all those awesome ASF > projects! > > Rémy's enhancements are great - the better and cleaner the integration, > the better for all those projects. > But Romain and David are also correct: it's very easy to become a > committer on all the involved projects, especially for people known to > deliver outstanding code and to be excellent community players! > > So at the end I really don't care much in which project stuff ends up. > There are just a few ideas I'd like to have you think about: > > A.) There should be a clear 'dependency graph'. > This is not so much a maven issue but really more a question of clear > design. > Tomcat is clearly the foundation of an EE server. It provides the > ClassLoader setup, the servlet engine, etc. > Tomcat provides abstract ways to integrate whatever wants to integrate > with it via abstraction mechanisms. This might be CDI or Spring or Guice, > or whatever! > > On top of this comes the CDI container who manages the instances. So all > those parts live in OWB. Including the integration. So I'd keep the Tomcat > integration as part of OWB. > > Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI > container and TomEE as fully blown JavaEE server. > > Having a build reference to TomEE or OWB in Tomcat would introduce cycles > in our builds. This is not really a good thing. > That did not seem very practical to me so the said code is quite Tomcat-like right now and most importantly it needs the fixes made in 9.0.21, so it won't work with any older Tomcat. If you really can take it over (and un-Tomcatize the code, I suppose), no problem. > > B.) We should also try to keep code and responsibilities at a single place > and shall try to avoid duplications. This has nothing to do with > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a > lot to do with users knowing exactly where to look at if they are searching > for a bug or even want to contribute a new feature. > Ok, so I guess I don't need to do anything further in that area since you prefer to continue covering it. I'll move on to other items on my todo list then. Rémy > > makes sense? > > txs and LieGrue, > strub > > > > > Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau >: > > > > Hell Rémy, > > > > I commented inline > > > > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat a écrit : > > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau < > rmannibu...@gmail.com> wrote: > > My 2cts would be that we have the luck to be fully ASF here so each > project can likely get back its missing piece(s) and we stay overall > consistent instead of creating yet another fork in our beloved foundation > (we already have some concurrent servers or even jdbc pools which does not > help much user land). > > > > @Rémy do you track the issues you encounter somewhere? > > For instance "CXF is not user friendly" but once you have CDI you get > CXF set up just adding a servlet. Here, an initializer would have been > friendly but then you would encounter the servlet initializer ordering > issue. > > > > Ok :) > > > > So: > > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really > figure out what's mandatory (there's a WHICH_JARS file, so that cannot be > that good). > > > > Depends, if you use maven it is fine ;). > > > > 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) > > > > - (Ok I figured it out) Looking at the integration(s), I quickly notice > there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and > cxf-rt-transports-http (did I miss any ?). They all need that I define a > Servlet it seems (no idea why at least some of these don't do it for me). > > > > There are two main concepts: the integration (cdi, spring, blueprint, > ) and the transport (http, jms, ...). Http transport goes through the > servlet and the integration relies on the transport to forward the messages > (request) to the CXF server which does the link with the beans. > > > > - After getting somewhere and trying a mp health test with your Geronimo > Health CDI bundle, I got: > > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both > org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks > and > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks > are equal candidates for handling the current request which can lead to > unpredictable results > > 11-Jun-2019
[GUMP@gump-vm]: Project tomcat-native-1.2-1.1.0-configure (in module tomcat-native-1.2-1.1.0) failed
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-native-1.2-1.1.0-configure has an issue affecting its community
integration.
This issue affects 3 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-native-1.2-1.1.0-configure : Tomcat native library using Apache
Portable Runtime
- tomcat-native-1.2-1.1.0-make : Tomcat native library using Apache
Portable Runtime
- tomcat-native-1.2-1.1.0-make-install : Tomcat native library using
Apache Portable Runtime
Full details are available at:
http://gump-vm.apache.org/tomcat-native-1.2-1.1.0/tomcat-native-1.2-1.1.0-configure/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Made directory
[/srv/gump/public/workspace/tomcat-native-1.2-1.1.0/dest-20190612]
-INFO- Failed with reason build failed
The following work was performed:
http://gump-vm.apache.org/tomcat-native-1.2-1.1.0/tomcat-native-1.2-1.1.0-configure/gump_work/build_tomcat-native-1.2-1.1.0_tomcat-native-1.2-1.1.0-configure.html
Work Name: build_tomcat-native-1.2-1.1.0_tomcat-native-1.2-1.1.0-configure
(Type: Build)
Work ended in a state of : Failed
Elapsed: 1 sec
Command Line:
/srv/gump/public/workspace/tomcat-native-1.2-1.1.0/native/configure
--with-apr=/srv/gump/public/workspace/apr-1/dest-20190612
--with-ssl=/srv/gump/public/workspace/openssl-1.1.0/dest-20190612
--prefix=/srv/gump/public/workspace/tomcat-native-1.2-1.1.0/dest-20190612
[Working Directory: /srv/gump/public/workspace/tomcat-native-1.2-1.1.0/native]
-
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.2.22
checking for chosen layout... tcnative
checking for APR... yes
configure: APR 1.7.0 detected.
setting CC to "gcc"
setting CPP to "gcc -E"
setting LIBTOOL to
"/srv/gump/public/workspace/apr-1/dest-20190612/build-1/libtool"
adding "-I/usr/lib/jvm/java-8-oracle/include" to TCNATIVE_PRIV_INCLUDES
checking for JDK os include directory... linux
adding "-I/usr/lib/jvm/java-8-oracle/include/linux" to TCNATIVE_PRIV_INCLUDES
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from
/srv/gump/public/workspace/openssl-1.1.0/dest-20190612/${exec_prefix}/lib and
/srv/gump/public/workspace/openssl-1.1.0/dest-20190612/include
checking OpenSSL library version >= 1.0.2... configure: error: Your version of
OpenSSL is not compatible with this version of tcnative
-
To subscribe to this information via syndicated feeds:
- RSS:
http://gump-vm.apache.org/tomcat-native-1.2-1.1.0/tomcat-native-1.2-1.1.0-configure/rss.xml
- Atom:
http://gump-vm.apache.org/tomcat-native-1.2-1.1.0/tomcat-native-1.2-1.1.0-configure/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20190612120005, gump-vm.apache.org:vmgump:20190612120005
Gump E-mail Identifier (unique within run) #1.
--
Apache Gump
http://gump.apache.org/ [Instance: gump-vm.apache.org]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 63492] close_time No recovery
On 12/06/2019 10:05, bugzi...@apache.org wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=63492 > > --- Comment #2 from ducklife --- I've disabled this idiot's account and deleted the spam comment along with the other spam comments they had made on other projects. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: CDI support improvements
Hi folks! Really happy to see so much love and interest for all those awesome ASF projects! Rémy's enhancements are great - the better and cleaner the integration, the better for all those projects. But Romain and David are also correct: it's very easy to become a committer on all the involved projects, especially for people known to deliver outstanding code and to be excellent community players! So at the end I really don't care much in which project stuff ends up. There are just a few ideas I'd like to have you think about: A.) There should be a clear 'dependency graph'. This is not so much a maven issue but really more a question of clear design. Tomcat is clearly the foundation of an EE server. It provides the ClassLoader setup, the servlet engine, etc. Tomcat provides abstract ways to integrate whatever wants to integrate with it via abstraction mechanisms. This might be CDI or Spring or Guice, or whatever! On top of this comes the CDI container who manages the instances. So all those parts live in OWB. Including the integration. So I'd keep the Tomcat integration as part of OWB. Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI container and TomEE as fully blown JavaEE server. Having a build reference to TomEE or OWB in Tomcat would introduce cycles in our builds. This is not really a good thing. B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they are searching for a bug or even want to contribute a new feature. makes sense? txs and LieGrue, strub > Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau : > > Hell Rémy, > > I commented inline > > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat a écrit : > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau > wrote: > My 2cts would be that we have the luck to be fully ASF here so each project > can likely get back its missing piece(s) and we stay overall consistent > instead of creating yet another fork in our beloved foundation (we already > have some concurrent servers or even jdbc pools which does not help much user > land). > > @Rémy do you track the issues you encounter somewhere? > For instance "CXF is not user friendly" but once you have CDI you get CXF set > up just adding a servlet. Here, an initializer would have been friendly but > then you would encounter the servlet initializer ordering issue. > > Ok :) > > So: > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really > figure out what's mandatory (there's a WHICH_JARS file, so that cannot be > that good). > > Depends, if you use maven it is fine ;). > > 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) > > - (Ok I figured it out) Looking at the integration(s), I quickly notice there > are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and > cxf-rt-transports-http (did I miss any ?). They all need that I define a > Servlet it seems (no idea why at least some of these don't do it for me). > > There are two main concepts: the integration (cdi, spring, blueprint, ) > and the transport (http, jms, ...). Http transport goes through the servlet > and the integration relies on the transport to forward the messages (request) > to the CXF server which does the link with the beans. > > - After getting somewhere and trying a mp health test with your Geronimo > Health CDI bundle, I got: > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both > org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks > and > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks > are equal candidates for handling the current request which can lead to > unpredictable results > 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse > javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error > at > org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79) > at > org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89) > at >
[Bug 63492] close_time No recovery
https://bz.apache.org/bugzilla/show_bug.cgi?id=63492 --- Comment #2 from ducklife --- The article is very meticulous and profound. It gives me quite a large amount of knowledge. Great help for my work. https://vex-3.com -- 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
On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau wrote: > Hell Rémy, > > I commented inline > > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat a écrit : > >> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau >> wrote: >> >>> My 2cts would be that we have the luck to be fully ASF here so each >>> project can likely get back its missing piece(s) and we stay overall >>> consistent instead of creating yet another fork in our beloved foundation >>> (we already have some concurrent servers or even jdbc pools which does not >>> help much user land). >>> >>> @Rémy do you track the issues you encounter somewhere? >>> For instance "CXF is not user friendly" but once you have CDI you get >>> CXF set up just adding a servlet. Here, an initializer would have been >>> friendly but then you would encounter the servlet initializer ordering >>> issue. >>> >> >> Ok :) >> >> So: >> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really >> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be >> that good). >> > > Depends, if you use maven it is fine ;). > > 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) > > >> - (Ok I figured it out) Looking at the integration(s), I quickly notice >> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and >> cxf-rt-transports-http (did I miss any ?). They all need that I define a >> Servlet it seems (no idea why at least some of these don't do it for me). >> > > There are two main concepts: the integration (cdi, spring, blueprint, > ) and the transport (http, jms, ...). Http transport goes through the > servlet and the integration relies on the transport to forward the messages > (request) to the CXF server which does the link with the beans. > Ok. > > >> - After getting somewhere and trying a mp health test with your Geronimo >> Health CDI bundle, I got: >> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] >> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both >> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks >> and >> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks >> are equal candidates for handling the current request which can lead to >> unpredictable results >> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] >> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse >> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error >> at >> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79) >> at >> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111) >> at >> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450) >> at >> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89) >> at >> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78) >> at >> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420) >> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101) >> ... >> Caused by: java.lang.IllegalAccessException: Class >> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class >> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint >> with modifiers "private" >> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102) >> at >> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296) >> at >> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288) >> at java.lang.reflect.Method.invoke(Method.java:491) >> at >> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442) >> ... 47 more >> >> That's where I am right now. The way to use CXF with Tomcat should be >> more obvious. >> > > Geronimo Health has a common and a cdi modules (cdi one being not suffixed > in terms of naming). Both are exactly the same except cdi one uses CDI > beans for the wiring and common is reusable in an OSGi container. > Common is not intended to be scanned. > I will add a scan=none in the jar since it is not done today and leads to > that issue if not excluded from the scanned jar - can be done through > openwebbeans.properties. > > -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to > give another try with a snapshot > I will continue experimenting ! > > >> >> OWB did not have most of these issues, the amount of libraries is >> manageable and the integration was labelled
Re: CDI support improvements
Hell Rémy, I commented inline Le mar. 11 juin 2019 à 23:29, Rémy Maucherat a écrit : > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau > wrote: > >> My 2cts would be that we have the luck to be fully ASF here so each >> project can likely get back its missing piece(s) and we stay overall >> consistent instead of creating yet another fork in our beloved foundation >> (we already have some concurrent servers or even jdbc pools which does not >> help much user land). >> >> @Rémy do you track the issues you encounter somewhere? >> For instance "CXF is not user friendly" but once you have CDI you get CXF >> set up just adding a servlet. Here, an initializer would have been friendly >> but then you would encounter the servlet initializer ordering issue. >> > > Ok :) > > So: > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really > figure out what's mandatory (there's a WHICH_JARS file, so that cannot be > that good). > Depends, if you use maven it is fine ;). 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) > - (Ok I figured it out) Looking at the integration(s), I quickly notice > there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and > cxf-rt-transports-http (did I miss any ?). They all need that I define a > Servlet it seems (no idea why at least some of these don't do it for me). > There are two main concepts: the integration (cdi, spring, blueprint, ) and the transport (http, jms, ...). Http transport goes through the servlet and the integration relies on the transport to forward the messages (request) to the CXF server which does the link with the beans. > - After getting somewhere and trying a mp health test with your Geronimo > Health CDI bundle, I got: > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both > org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks > and > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks > are equal candidates for handling the current request which can lead to > unpredictable results > 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse > javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error > at > org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79) > at > org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78) > at > org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420) > at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101) > ... > Caused by: java.lang.IllegalAccessException: Class > org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint > with modifiers "private" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102) > at > java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296) > at > java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288) > at java.lang.reflect.Method.invoke(Method.java:491) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442) > ... 47 more > > That's where I am right now. The way to use CXF with Tomcat should be more > obvious. > Geronimo Health has a common and a cdi modules (cdi one being not suffixed in terms of naming). Both are exactly the same except cdi one uses CDI beans for the wiring and common is reusable in an OSGi container. Common is not intended to be scanned. I will add a scan=none in the jar since it is not done today and leads to that issue if not excluded from the scanned jar - can be done through openwebbeans.properties. -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give another try with a snapshot > > OWB did not have most of these issues, the amount of libraries is > manageable and the integration was labelled as "tomcat7". The main issue > with OWB is that integration had issues [it needed some adjustments in > Tomcat to avoid instance manager replacement timing issues; other more > cosmetic problems were the use of both Catalina internal components and
